Considerations for applications
The following provides 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 data such as 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 good method of ensuring compliance, as applying protective measures is the essence of the Rules’ requirements.
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.
You can’t send a short message over an encrypted channel; it remains plain text on transmission. Furthermore, an SMS sent to the patient includes the destination number, which could be used to identify the individual, thus qualifying the text as e-PHI. So, you need to ensure that 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 are subject to compliance. An effective method of protecting and securing recordings is to encrypt the file. However, there are further considerations around how you handle the encryption. For example, the encrypted file and the encryption key should never be sent via the same route, nor retained by the platform after use. 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. The source recording should also be deleted.
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 play the message back. As above, the key should be received via a different route from the message and destroyed after use, along with the original encrypted message.
The process is similar when sending fax messages, the use of which technology is still widespread in healthcare for the transfer of health records. 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. Again, 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