Building a HIPAA-compliant Healthcare Application

Read on as we explore HIPAA compliance benefits and technical aspects in healthcare applications.

HL7, on the other hand, is a nonprofit organization that focuses on communication channels for exchanging data electronically. It ensures that data is HIPAA compliant and follows protocols for secure messaging. While HL7 primarily concentrates on messaging, it also ensures that data transferred via its protocols is HIPAA compliant. These two entities are major healthcare data security and privacy players.

• Administrative Safeguards: These can include appointing a privacy official or ensuring that your staff is properly trained.
• Physical Safeguards: Examples of physical safeguards include setting up alarm and security systems and locking areas where important files are stored.
• Technical Safeguards: Technical HIPAA safeguards may include data encryption, antivirus software, automatic log-off, and audit controls.

What is ePHI?

ePHI stands for Protected Health Information. It refers to any health information that is electronically stored. This includes any medical information recorded by hospitals, doctors, personal caretakers, or third-party service providers for a patient.

• HIPAA Privacy Rule: This rule applies only to covered entities, not business associates. Covered entities, such as hospitals or primary healthcare partners, have the most access to sensitive information and must define the bridges and gaps between the data sets that are shared. For example, if a business entity is working with a hospital, it is up to the hospital to decide how much data related to a particular patient they will share.
• HIPAA Security Rule: The security rule covers both business associates and covered entities. It focuses on how to handle the Protected Health Information (PHI) that they have.
• HIPAA Breach Notification Rule: The breach notification rule again applies to both business associates and covered entities. Its purpose is to identify data breaches containing any sort of PHI.
• HIPAA Omnibus Rule: This rule mandates that business associates working for any healthcare application must also be HIPAA compliant. This is because informed associates working on a healthcare application would be aware of HIPAA compliance and create a digital solution that meets HIPAA standards. An app that fails the HIPAA checklist would not be useful to a business partner.

The patient may be undergoing sensitive treatment that they do not wish to disclose to everyone. Unfortunately, the current system is not closed, and patient information is usually stored in files, either as hard copies or in third-party applications. As a result, most of the sensitive information is still vulnerable and can be accessed by anyone apart from doctors. This is where HIPAA can step in and improve the security of patient information.

• HIPAA Training: Our team underwent HIPAA training to learn about different terminologies, use cases of HIPAA, data that should be protected, and data that can be kept open.
• Strong Password Hashing: We chose a strong password hashing algorithm, which is hard to traverse back.
• Role-based Authentication: We implemented role-based authentication to have authorized access throughout the application.
• Encrypting Sensitive Files: Finally, we encrypted sensitive files on the server side.

Let's start by looking at the implementation of role-based authentication. In the image below, two tables are marked: Appointments and Timeslots. In a typical use case, appointments should be accessible to both doctors and patients. Therefore, the Appointment table allows these users to read and write data with some custom checks in place. Both the physician and the member have permission to insert and update data in this table.

On the other hand, the Timeslot table is where the physician or doctor makes their availability known. Members do not have much to see or do in this table; they only have permission to select data. They cannot update or insert data points in the Timeslot table.

In the Hasura link we created, it returns the headers in the SDTP link. We then passed the same role ID to the JWT. The image below shows a decoded version of the JWT. For this specific user, the role is a member. We have also included the allowed roles in the JWT claims. Currently, we only accept two roles: "member" and "physician". For the user "Arindam Ganguly" the role is "member". This ensures that users with the member role can only access routes specific to members, not physicians. Similarly, if the role were "physician", the member's routes or the member's part/module of the application would not be accessible to the physician.

What is KMS?

For even greater security, you can use asymmetric keys. With this method, you have a separate private key, which is required to decrypt a specific file. It's important to note that when using KMS, you must have the necessary permissions. You can refer to the AWS official documentation for guidance on obtaining the required permissions, which may require contacting the administrator for your IAM users.

Here, we have three main functions: encrypting the file, uploading the encrypted file with KMS encryption, and uploading the encrypted file to the S3 Bucket. If you refer to the image below, we utilize the “aes-256-cbc” algorithm for file encryption. Once the file is encrypted, we proceed to upload it to the S3 Bucket. Currently, we have kept the S3 Bucket as an open bucket instead of a private one. However, if you are using a private bucket, you can specify the user groups that have access to it. We chose an open bucket for now due to the limited and non-real-time nature of our data.

The image below shows the bucket where we have implemented our encryption. It is a screenshot of a single file. When we click on a file from our KMS-enabled file system and try to open the link, we receive an "access denied" error. This happens because when the file is opened in the browser, it tries to access the KMS key ID needed to access the file. The access is denied since the browser has no clue about the KMS key ID. While opening it from the app, it reads the key ID from the metadata itself.

It is important to note that although we have implemented HIPAA in Next.js and Hasura, HIPAA is not technology-specific. It provides a set of rules; it is up to you and your tech stack to determine how to implement them. If those rules are satisfied, you can implement HIPAA in any language or framework used to develop your applications. The primary goal of HIPAA is to protect patient’s sensitive information.
Check out the video below to learn more about this project and listen to Arindam Ganguly's full talk!