Why are Email and Text Messaging Not HIPAA compliant?

Many people falsely believe that traditional email and texting of private health information is HIPAA compliant. This is simply not true and anyone who is currently using these methods is putting their organization at risk.

HIPAA regulations require that all private health information (PHI) remain private and be only accessible by authorized personnel. This means that when transmitting PHI two things have to be ensured. First the PHI needs to be encrypted when being transmitted. This ensures that PHI remains private even when transmitted over a public network like the Internet. Second, PHI should only be viewable by the intended recipient and not by any entity that is being used to transport that information.

A good example of a HIPAA compliant method for delivering PHI is the US Postal Service (snail mail). When a doctor mails a letter containing PHI to a patient both criteria are met. Since the letter is in a sealed envelope and the seal will only be broken by the recipient, then no one along the transport path has access to the PHI including the postal service itself.

With these criteria in mind lets see why texting and email are not HIPAA complaint. When an email is sent lets see what is actually happening. Lets suppose a physician who has and email address like drjones@communityhospital.com sends an email to a patient whose email address is janedoe@gmail.com. What happens here is that there are two email servers involved with the transmission of this email, one at community hospital and one at gmail. When Dr. Jones sends the email, his email client on his computer or smart phone connects with his email server at community hospital and transmits the email message to the community hospital server. Next the community hospital server finds where the gmail server is located on the Internet and then transmits the email to the gmail server using a standard protocol called simple mail transfer protocol (SMTP). SMTP is the protocol used to transmit information between email servers over the Internet and it is not encrypted. This is a why message sent via email are not secure and therefore not HIPAA compliant.

The analogy to this would be like mailing a letter without using an envelope. Anyone handling the letter could read the content of the letter.

What happens if someone at community hospital sends an email to someone else at community hospital? Is that HIPAA compliant? This depends on the setup of the community hospital mail server. If the server only accepts encrypted connections and never accepts connections from its clients that are not encrypted, then this transmission may be HIPAA compliant since the community hospital email server does not have to communicate with an outside server and the communication is only internal. Even in this situation, it is important to note that for anyone with a communityhospital.com email account, any communication coming from or going to an outside server (i.e. anyone without a communityhospital.com email address) is not HIPAA compliant.

What about texting? Is texting HIPAA compliant? First, we need to know that there two types of text messages. The first is simple message service or SMS messages. These messages are handled by cell phone carriers. These messages are not encrypted in transport and can also be read by personnel at the carriers themselves and are therefore not HIPAA compliant. The second type of text message is sent via a text message service like Apple’s iMessage. A service like iMessage does encrypt the message in transport, but this information is not handled in a HIPAA compliant manner by Apple which runs the servers for iMessage. It is for this reason that Apple clearly states that iMessage is not HIPAA compliant.

But email and texting are a very convenient method of communication. It is for this reason that many providers even knowing that these methods are not HIPAA compliant still use these methods clandestinely. But with MedTunnel which is a free service that works like email or texting, but is also HIPAA compliant, this is no longer necessary.

How is MedTunnel HIPAA compliant?

The main purpose of MedTunnel is to provide a free, HIPAA compliant, and secure service for transmitting private health information (PHI) through the Internet. The core architecture of our product was designed to meet HIPAA and security guidelines. MedTunnel provides a secure conduit through the Internet for PHI transmission. In fact, our security protocol is such that no one at MedTunnel, even at the CEO level can access PHI even if they wanted to.

Since MedTunnel acts only a secure conduit for PHI transmission and MedTunnel does not have access to any PHI and does not permanently store any PHI, a HIPAA Business Associate Agreement is not required in order to use MedTunnel. For more detailed information regarding our security protocol and HIPAA regulations compliance, please see below.

b. The server generated key is randomly generated by the server for each message transmitted via MedTunnel so therefore is unique for each message. This prevents brute-force attacks on the data.

c. The MedTunnel key is only known by MedTunnel personnel and not known by the Independent Third Party.

d. The Independent Third Party key is only known by an Independent Third Party and not known by MedTunnel.

e. Neither MedTunnel or Third Party have access to PHI since all 3 keys are required to unencrypt PHI and therefore, MedTunnel only acts as a secure conduit for PHI transmission and is not subject to needing a HIPAA Business Associate Agreement.

After encryption, the encrypted PHI is stored on the MedTunnel cloud storage. Only encrypted data is stored and no unencrypted data is stored.

The data is not stored permanently, but is automatically deleted from the cloud storage after 14 days.

MedTunnel HIPAA Compliance Matrix

Conduct an accurate and thorough
assessment of the potential risks and
vulnerabilities to the confidentiality,
integrity, and availability of electronic
protected health information held by the
covered entity.

MedTunnel’s applications are designed
to protect private health information
(PHI).

MedTunnel monitors the general
activity on its servers and it has
designed a detailed audit and logging
report for its customers.

Assigned Security
Responsibility
164.308(a)(2)

Security Official (R)

Identify the security official who is
responsible for the development and
implementation of the policies and
procedures required by this subpart for the
entity.

Kishore Tipirneni MD, our CEO, is also
in charge of security and has
designed and implement many other
HIPAA compliant software
applications that are used throughout
the medical industry on a daily basis.

Workforce security
164.308(a)(3)

Authorization and/or
supervision (A)

Implement procedures for the
authorization and/or supervision of
workforce members who work with
electronic protected health information or
in locations where it might be accessed.

MedTunnel's infrastructure is such that
no workforce member even at the CEO
level can inadvertently or on with intent
access any patient data.

Workforce clearance
procedure (A)

Implement procedures to determine that
the access of a workforce member to
electronic protected health information is
appropriate.

MedTunnel's infrastructure is such that
no workforce member even at the CEO
level can inadvertently or on with intent
access any patient data.

Termination procedure
(A)

Implement procedures for terminating
access to electronic protected health
information when the employment of a
workforce member ends or as required by
determinations made as specified in
paragraph (a)(3) (ii)(B) of this section.

Since no MedTunnel employee can
access PHI, there is no need to
terminate access upon the end of
employment of a workforce member.

Information
access
management
164.308(a)(4)

Isolating healthcare
clearinghouse function
(R)

If a healthcare clearinghouse is part of a
larger organization, the clearinghouse must
implement policies and procedures that
protect the electronic protected health
information of the clearing- house from
unauthorized access by the larger
organization.

MedTunnel has no clearinghouse
functions.

Access authorization (A)

Implement policies and procedures for
granting access to electronic protected
health information, for example, through
access to a workstation, transaction,
program, process, or other mechanism.

As MedTunnel does not permanently
store PHI, the control of this function is
at the level of the administrator for that
account or group.

Access establishment and
modification (A)

Implement policies and procedures that, based
upon the entity’s access authorization policies,
establish, document, review, and modify a
user’s right of access to a workstation,
transaction, program, or process.

As MedTunnel does not permanently store
PHI, the control of this function is at the
level of the administrator for that account or
group.

At MedTunnel, we provide the tools so
that the administrator for an account or
group can set this policy.

Password management (A)

Procedures for creating, changing, and
safeguarding passwords.

At MedTunnel, we provide the tools so
that the administrator for that account or
group can set this policy.

Security incident
procedures
164.308(a)(6)

Response and reporting
(R)

Identify and respond to suspected or known
security incidents; mitigate, to the extent
practicable, harmful effects of security incidents
that are known to the covered entity; and
document security incidents and their outcomes.

At MedTunnel, security is our primary
focus and expertise. We have implemented
a distributed solution that virtually
eliminates risk of a potential breach while
minimizing its impact. If there were to be a
breach, appropriate reports would be made.

Since MedTunnel does not permanently
store PHI and only acts as a secure conduit
for PHI, all data should be backed up by the
sender of the data.

Disaster recovery plan (R)

Establish (and implement as needed) procedures
to restore any loss of data.

Since MedTunnel does not permanently
store PHI and only acts as a secure conduit
for PHI, all data should be backed up by the
sender of the data and the sender should
have procedures to restore any loss of data.

Emergency mode
operation plan (R)

Establish (and implement
as needed) procedures to enable the
continuation of critical business processes
for protection of the security of electronic
protected health information while
operating in emergency mode.

As all data that passes through our
MedTunnel servers is secure, we do not
need to make any operational changes
for an emergency.

Testing and revision
procedure (A)

Implement procedures for periodic testing
and revision of contingency plans.

MedTunnel has a continuous process to
improve the availability of our service.

Applications and data
criticality analysis (A)

Assess the relative criticality of specific
applications and data in support of other
contingency plan components.

MedTunnel provides secure messaging
applications. We constantly assess
various components of the system and
make contingency plans.

Evaluation
164.308(a)(8)

Technical and nontechnical
evaluation (R)

Perform a periodic technical and nontechnical
evaluation, based initially upon
the standards implemented under this rule
and subsequently, in response to
environmental or operational changes
affecting the security of electronic
protected health information, that
establishes the extent to which an entity’s
security policies and procedures meet the
requirements of this subpart.

At MedTunnel, security is our primary
focus and expertise. We are constantly
evaluating all security procedures.

Business associate
contracts and
other arrangements
164.308(b)(1)

Written contract or
other arrangement (R)

Document the satisfactory assurances
required by paragraph (b)(1) of this
section through a written contract or other
arrangement with the business associate
that meets the applicable requirements of
§ 164.314(a).

As MedTunnel is strictly a conduit and
we do not even access the information
that passes through our servers on a
random or infrequent basis, we do not
even meet the minimum requirements
(as noted in the Federal Register, Vol.
75, No. 134, p. 40873) to be considered
a Business Associate.

Facility access
controls
164.310(a)(1)

Contingency operations
(A)

Establish (and implement as needed)
procedures that allow facility access
in support of restoration of lost data
under the disaster recovery plan and
emergency mode operations plan in the
event of an emergency.

At MedTunnel, our cloud servers are
under an SSAE-16 Compliant cloud
service provider.

Facility security plan
(A)

Implement policies and procedures
to safeguard the facility and the
equipment therein from unauthorized
physical access, tampering, and theft.

MedTunnel does not keep or store PHI
in our office. All data is securely routed
and passes directly through our SSAE-
16 Compliant cloud servers.

Access control and
validation procedures
(A)

Implement procedures to control and
validate a person's access to facilities
based on their role or function, including
visitor control, and control of access to
software programs for testing and
revision.

Since there are no paper or digital PHI
records stored in the MedTunnel office,
we do not need to enforce these
stringent policies; front desk based
controls are implemented. Data Center
access controls follow SSAE-16
standards and procedures as well as
industry best practices.

Maintenance records
(A)

Implement policies and procedures to
document repairs and modifications to
the physical components of a facility,
which are related to security (for
example, hardware, walls, doors, and
locks).

Since there are no paper or digital PHI
records stored in the MedTunnel office,
this standard does not apply to us.

Workstation use
164.310(b)

Function and attributes
(R)

Implement policies and procedures that
specify the proper functions to be
performed, the manner in which those
functions are to be performed, and the
physical attributes of the surroundings of
a specific workstation or class of
workstation that can access electronic
protected health information.

At MedTunnel, we only provide the
application and not the hardware so this
standard does not apply to us.

MedTunnel’s secure messaging
applications provide true end-to-end
encryption. Message traffic is encrypted
with 2048 bit RSA keys as wells as with
a 256 bit AES-CBC. The sender
encrypts the message and only the
intended receiver can decrypt the
message.

Audit controls
164.312(b)

(R)

Implement hardware, software, and/or
procedural mechanisms that record
and examine activity in information
systems that contain or use electronic
protected health information.

At MedTunnel, we provide the tools so
that the account owner or group
administrator can monitor system usage.

Integrity
164.312(b)

Mechanism to
authenticate electronic
protected health
information (A)

Implement electronic mechanisms to
corroborate that electronic protected
health information has not been altered or
destroyed in an unauthorized manner.

As MedTunnel does not have access to
PHI, this standard does not apply
to us.

Person or entity
authentication
164.312(d)

(R)

Implement procedures to verify that a
person or entity seeking access to
electronic protected health information is
the one claimed.

At MedTunnel, we provide the tools so
that the account owner or administrator
for a group can control access to the
PHI.