Aculab Cloud and Protected Health Information

Compliance with HIPAA Privacy and Security Rules

You may have seen our press release recently announcing Aculab Cloud conformance with HIPAA and HITECH regulations. In that release, we stated that Aculab is able to enter into HIPAA Business Associate Agreements (BAA) with its Covered Entity customers providing healthcare platforms.

The point regarding a HIPAA BAA is important news for any customer or potential customer considering using a cloud-based communications-platform-as-a-service, such as Aculab Cloud, as part of the solutions it offers to healthcare service providers in the United States.

It is important, because businesses offering patient management and advisory (PMA) or electronic healthcare records (EHR) solutions are obliged to ensure compliance with the HIPAA Privacy and Security Rules. If businesses use a communications API platform, such as Aculab Cloud, in delivering their solutions, it’s clear that such use can be subject to those rules.

To understand the obligation in relation to platforms like Aculab Cloud, it’s important for you to consider the HIPAA Rules.

The HIPAA Privacy and Security Rules

Privacy Rule

The Privacy Rule addresses the use and disclosure of individuals’ Protected Health Information (PHI) by organisations subject to the Rule. Such organisations are called Covered Entities and their Business Associates. The balanced Rule seeks to ensure that individuals’ health information is properly protected, while permitting the disclosure of health information needed for high quality healthcare and to protect the public’s well being. The standards inherent in the Rule also provide for individuals’ rights to understand and control how their health information is used.

Security Rule

The Security Rule encompasses federal safeguards for protecting PHI that is created, received, held, maintained or transmitted in electronic form, then called e-PHI. Those safeguards must be put in place by Covered Entities and their Business Associates to ensure the confidentiality and integrity of e-PHI. The Rule is intended to allow the adoption of technologies to improve the quality and efficiency of patient care, such as those used in PMA, EHR, pharmacy and laboratory systems.

What is considered PHI

In essence, PHI is information that relates to the individual’s health condition, or the provision of healthcare to the individual, that identifies, or can be used to identify, the individual.


The HIPAA Rules apply to Covered Entities and their Business Associates who transmit e-PHI. The PMA and EHR services provided by Aculab’s customers clearly include management and administration services, both of which are included in the limited list of services identified in the Privacy Rule, and the transmission of e-PHI. Customers use Aculab Cloud for a variety of solutions, including those involving patient management, advisory, care, diagnosis, results, rehabilitation, messenger, and information systems.

Aculab as the operator of Aculab Cloud is not a Covered Entity and Aculab’s healthcare customers may not be Covered Entities. However, an Aculab customer performing functions or activities that involve the use or disclosure of e-PHI, by providing services to a Covered Entity, is by definition a Business Associate. The relationship between a Covered Entity and a Business Associate is through a BAA. In the case of a service provider to a Business Associate, the service provider becomes a Business Associate and, for the purpose of the BAA, the other party becomes a Covered Entity. That means Aculab is the Business Associate and its customer is the Covered Entity.


Of course, one way to remain compliant is to not process, store or transmit e-PHI using a communications-platform-as-a-service, but that rather defeats the purpose of such platforms.

The following paragraphs provide some high-level suggestions for achieving compliance with the HIPAA Privacy and Security Rules when using a platform, such as Aculab Cloud, to process and transmit e-PHI involved in a PMA or EHR solution.


Password authentication to access e.g., recordings, voicemail messages or voice response systems doesn’t alter the fact that such data is e-PHI and, if it is created, received, processed, stored or transmitted via Aculab Cloud, it is subject to the Privacy and Security Rules. However, that is a rather good method of ensuring compliance. That is, by applying protective measures, which are the essence of what is required by the Rules.


Similarly, whether or not the data is voice or speech and broadcast or transmitted over encrypted channels, it remains e-PHI and is subject to the Rules. Encrypting the data is not a means of avoiding your obligation; it is merely an effective means of complying with the Rules and meeting your obligation.


With regard to SMS, it’s clear that you can’t send a short message over an encrypted channel; it remains plain text on transmission. Furthermore, by virtue of sending an SMS to a patient, you cannot avoid including the destination number, which number could be used to identify the individual, thus qualifying the text as e-PHI. What you can do is to ensure the content of text messages contains no sensitive patient data. A message stating “Your appointment for tomorrow at 10:15 is confirmed” is compliant, whereas a message stating “Your appointment at the <insert too much information> clinic…” would not be.


Voice recordings can be made by healthcare professionals and patients alike, and their existence can’t be ignored from a compliance standpoint. An effective method of protecting and securing recordings is to encrypt the resultant file. However, there are additional precautions around how you handle the encryption that you would do well to consider.

You should ensure that the encrypted file and the encryption key are never sent via the same route, nor retained by the platform after use. That means the key should be received by the platform only when needed at the time of use, never stored on the platform, and destroyed after use, simultaneously with transmission of the encrypted file. Similarly, the source recording should be deleted.

Message playback

The process is similar, albeit in reverse, for playback of a .wav file, for example, to relay information in the form of a message to a patient. On receipt of the encrypted file for transmission, you should ensure the applicable key is available only at the time of decryption in order to playback the message. As above, the key should be received via a different route from the message and destroyed after use, along with the original encrypted message.

Fax handling

Once again, the process is similar when sending fax messages, the use of which technology is still common and widespread in healthcare. On receipt of the encrypted fax for transmission, you should ensure the applicable key is available only at the time of decryption in order to transmit the fax. As above, the key should be received via a different route and destroyed after use, as with the original encrypted message. It’s the reverse for receiving a fax and forwarding the corresponding encrypted message to the intended receiver.

More information

More information is available on the HIPAA website.

Aculab provides the above information as a courtesy. It is not intended to constitute legal advice, which Aculab is not in a position to provide. You should always seek professional legal advice, and particularly in relation to your status and obligations in relation to HIPAA and other applicable laws and regulations.

Comments are closed.

You may also like

Webinar - How to avoid a data breac…

5 ways to secure your voice and messaging apps The billion-dollar healthcare industry, giv… More

Callglide uses Aculab Cloud in Sale…

A cloud-based customer contact solution binding together inbound and outbound communicatio… More

Aculab announces new biometric spea…

Easily add voice authentication solutions to any business application 9th March 2017, Milt… More

Aculab Cloud secures protected heal…

HIPAA assured protection of sensitive patient data 13th December 2016, Milton Keynes, UK … More