Informizely customer feedback surveys
By using the Aculab site, you agree with our use of cookies.
  • Cloud voice, SMS and fax

    Powerful, easy to integrate voice, SMS and fax APIs.

    Find out more

  • Voice biometrics

    Add enhanced security and user convenience with biometric voice authentication to your customer contact apps
     

    Find out more

  • Gateways

    For IP and TDM interworking, protocol conversion and more
     

    Find out more

  • Telephony hardware and software

    Reliable, deployment proven technology for a wide range of enterprise and telco grade telecom applications
     

    Find out more

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.

Compliance with HIPAA Privacy and Security Rules

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 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.

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.

Applicability

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.

Compliance

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.

Authentication

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.

Encryption

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.

SMS

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.

Recordings

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

To find out about Aculab's cloud platform for HIPAA compliance, check out the HIPAA, security & encryption page.

For more information on the HIPAA regulations, check out 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.

The Aculab blog

News, views and industry insights from Aculab

  • Jail time for biometrics

    The people who work in the Broadville Retention Centre, a temporary home for semi-retired hoodlums, love working there. The centre in south-west London, England, has views of flightpaths from Heathrow Airport; sights evocative of the freedom temporarily denied its residents. Workers at the centre on the other hand enjoy freedom of movement, not only in coming and going according to their shift patterns, but also within the building complex.

    Read more

  • Aculab Cloud and the EU GDPR

    The EU General Data Protection Regulation (GDPR) is important to Aculab and its customers in the EU region, and also for our non-EU customers who use Aculab Cloud for their customers who reside in the EU. This is a summary of what we have done to ensure the privacy and security of customer data on Aculab Cloud.

    Read more

  • Preparing to meet the EU GDPR rules with Aculab Cloud

    Firstly, lets establish what the GDPR is, and why it’s important to Aculab and its customers in the EU region, and also for our non-EU customers who use Aculab Cloud for their customers who reside in the EU.

    Read more

  • Improved Aculab Cloud documentation and a new console

    We’ve been busy in the background recently at Aculab with a major website refresh. Aculab has evolved over decades (40 years this year!) from a vendor supplying hardware to a much more software-centric product company. We still sell telecom gateways extensively, but nowadays the bulk of our enabling technology business is software, and in particular our communications platform-as-a-service (CPaaS) product, Aculab Cloud.

    Read more

  • Interoperability is predictable

    Way back in 2007, while presenting a seminar in Prague, someone asked me for my prediction on when SS7 would no longer be in use. My answer was suitably vague, but something on the lines of, “at least 10 to 15 years.” Ten years on, I wasn’t wrong. Still, I may not be right. SS7 is showing its age, but it’s not about to draw its pension just yet.

    Read more