MediGuru Logo

HIPAA Security – In the beginning…

HIPAA Security – In the beginning… .  

While bringing-in insurance portability, rules, and standards regarding responsible handling of electronic Protected Health Information is also presented as a federal code. This is to be followed in letter and spirit by all the types of covered entities. But as vague it may sound, HIPAA clearly lays out a specific set of responsibilities in three main areas (privacy, security, and enforcement) for the protection of certain individually identifiable health information. Additionally, standards for breach and other administrative rules (like clinical codes etc.) are also covered. 

[Neo!… the proverbial red pill path is to look for the full finalized text published in 45 CFR Parts 160, 162 and 164] 

In this primer, we will only aim to familiarize ourselves on how we go about ensuring that privacy. For the start, the CFR gives us a Privacy Rule and a Security Rule. The Privacy Rule establishes the standards for the protection of the PHI. 

Ok… now that is as brief as it can get. Now how do we operationalize these? 

That is what is given as a set of standards in the Security Rule. This Security Rules establishes the “technical and non-technical safeguards” that ensures that privacy. And, of course, we must have our system and management be compliant.  

Let us unfold the pages of these rules set as two major chapters. One pertaining to the people part of the system and the other pertaining to the associated health information.  

“Authorized personnel only!”: 

The system must allow only specifically known people by means of an Authentication system that ensures only the right people are able to reach the system’s information pages. Additionally, we must allow only relevant information to the personnel by using electronic Authorization. 

Mediguru, even in its minimalist avatar, uses the Identity Server for authenticating the different users and third-party systems (including partner cloud services). Authorization is managed and administered natively by the system and is imbibed into the end user UX/IA ensuring ease of administering compliancy. Integration options includes Azure Active Directory or On-prem Active Directory and other native and third party IAM providers. 

Authentication and Authorization is carried to the MongoDB to ensure access control only for the data owner.  

Traceability and Accountability: 

The most important aspect of operationalizing the privacy rule is in having the means in the system that efficiently tracks every important action done by the people. The system shall hold the users accountable for all those activities that comes under his/her purview. Mediguru’s audit trail provides this information from across the board and across all the workflows. 

Semi-automated and fully automated audit for the individual user activities and the database access are provided. Thereby holding the people accountable for. 

Storage and Transit: 

Patient Information is to be stored in an encrypted format. The data gets transported across different microservices and to third party systems. Thus, securing all such connections becomes necessary to ensure nobody eavesdrops or gains unwarranted access. Encrypting that data is mandatory as well. 

All service-to-service, UI to Service, Service-to-Third-party, Service-to-Backend calls, incoming calls from Third party-to-Service etc. are encrypted using the TLS layer. While HIPAA does not insist on using any particular security technology or transport protocol, it does provide important compliancy rules to follow. TLS v1.3 would require to securely manage certificates that will be used for In-Transit encryption across all communication channels. Depending on deployment and application requirements, Mediguru supports custom encryption if necessary, in-addition to the default TLS v1.3 encryption to further secure the channel. Apart from TLS/SSL Usage for all the services, the Percona Server for MongoDB allows for the storage and transport encryption for Mediguru. Optionally, Percona can be substituted with higher tier licenses for the MongoDB server. 

While not being elaborate, this primer will allow you to plan for compliancy in terms of the technical work that is involved. No two systems are the same and the compliancy is governed by – the most vital part – the compliancy administration and management operations by the covered entities, care providers and their business associates. 

The best way to start off implementing compliancy is to enumerate and list the functional and technical components that is to be deployed part of the solution and go through a compliancy checklist in the below areas: 

    • Authentication
    • Authorization
    • System RBAC Management Privacy Compliancy
    • Audit
    • Encryption at Rest
    • Encryption in Transit
    • Secure Management of Infrastructure Operations
    • Policies and Procedures for the above list of planning work items

Let there be privacy!