With OCR raising the seriousness levels of all covered entities in the healthcare Eco-system, it’s important for providers as well as Independent Software vendors (ISVs) to comprehend the various requirements that HIPAA imposes. The write-up below touches upon these requirements from a software capability perspective.
Technical safeguards focus on the technology that stores or processes PHI. Technical safeguards have been classified into 5 different focus areas of a software application used for providing healthcare services. These areas are technology agnostic so whether your application is on Microsoft, Java or any other open source, they still apply.
- Unique User Identification (required): The application should be able to uniquely identify a patient and health data stored in the system. This could be a unique numbering or MRN referred across the application.
- Emergency Access Procedure (required): There should be a provision or a way to access the application to access ePHI in case of emergency. This user access should allow to fetch the PHI to aid the emergency services to deliver the care.
- Automatic Logoff (addressable): This is a most common problem across applications where they allow unauthorized access when the terminal/desktop is unattended for a long time. An easy way to achieve this is to track the user action and if the terminal/desktop is unattended for a specific duration, trigger auto log off function thus safe-guarding the PHI from possible security compromise.
- Encryption and Decryption (addressable): As per NIST guidelines, organizations should adopt an appropriate encryption method for storage/access of PHI and at the user end to ensure data is secured. Common authentication mechanisms are passwords, personal identification numbers (PIN), cryptographic tokens, biometrics, and smart cards
Audit Controls (required)
- Every action that results in change of PHI information should be tracked in order to identify the context of change such as changed by whom, when, what was the change and status before the change. This is also part of Meaningful use stage 2 measure.
- Mechanism to Authenticate ePHI (addressable): as per the integrity requirement specified in the standard 45 CFR § 164.312(c) (1), requires covered entities to implement policies and procedures to ensure that the data, when exchanged or processed shouldn’t get altered in an unauthorized way. This can be achieved by implementing key based encryption, checksum and transmitting over a secured channel.
- The system should verify the credentials before allowing the user to access PHI information. Common user authentication mechanism employed are password, personal identification numbers (PIN), cryptographic tokens, biometrics, and smart cards.
- Integrity Controls (addressable): as described above, the PHI when transmitted should be encrypted and transmitted over a secured channel like SSL.
- Encryption (addressable): Implement a mechanism to encrypt ePHI whenever deemed appropriate.
In general the software used for archiving, transmitting and showing the PHI should be in compliance with all above requirements. If there is any breach of security, there should be a mechanism to report incident as required by § 164.410.
While no system can be totally secured, HIPAA aims to have organizations to realize the importance of security and build mechanisms to ensure it. They need to have preventive, reactive and investigative capabilities built into the systems. In addition, they need to adopt processes that evolve over time.
This is the first one among the set of articles that aim to educate readers about HIPAA requirements and their systemic implications. Stay tuned for the next few that address the pitfalls, requirements for data centre hosted solutions and more…