Electronic health records have made patient privacy a key concern. As a result regulatory requirements such as HIPAA and PHIPA have been mandated to protect and prevent the misuse of patient data. These laws extend to other organizations involved in the electronic exchange of health information. For example, in 2009 the HITECH Act mandated compliance with HIPAA for all covered entities.
From a software developer’s point of view, these regulations require the implementation of two systems: access control and an audit trail. While these systems are simple in principle, it is important to ensure they are developed in a structured fashion that addresses privacy laws while maintaining user flexibility. Examples of recent privacy breaches demonstrate the continuing need for strict privacy protection:
- $800,000 HIPAA settlement in medical records dumping case
- County Government Settles Potential HIPAA Violations
- Nurse pleads guilty to HIPAA Violation
When developing clinical software, be sure to balance access control and audit trail mechanisms carefully. The software must respect privacy laws, but should not prevent users from efficiently accomplishing their tasks. In healthcare, a good audit trail allows for a relaxed access control mechanism. The best access control policies are those that are not overly restrictive. They should offer an override mechanism to prevent inappropriate access.
Keep in mind that a user session lifecycle is much different for an EHR mobile app than mobile consumer apps. In consumer apps a user simply needs to login once, and then that login is stored for easy access over the long term. Depending on the emphasis on security, you might want the user to be logged out after switching contexts, after a timeout, and so forth. Usability testing can help with creating a balance between a simple, intuitive user experience and security requirements.
When emergencies arise, for example, the law allows access to personal data in a life and death situation. In a practical environment, such as a hospital, clinicians may require immediate access to a record without justifying that access beforehand.
Access control restricts actions such as viewing, editing, or deleting data elements based on a user role type. There are three design approaches for role-based access control:
Screen-Based Access Control
Access control policies which are loaded per page or screen require frequent database access but result in more dynamic access control behavior. Although user privileges can be revoked or granted instantly, the need for loading the access control policies can slow down the server — especially when there are many concurrent users.
User Session Access Control
Loading access control policies once a session begins leads to a lack of control given that a user can have privileges revoked, but still be allowed to continue until the end of the session.
Either of these policies are sufficient to address HIPAA access control requirements and CCHIT certification in the case of electronic health records.
Case-by-Case Access Control
A more advanced method of access control. It requires the user to be defined on a case- by-case basis. For example, a hospital may decide that only medical staff involved in the care of a particular patient should be allowed to access that patient’s file. Only staff members meeting the pre-defined criteria are then granted access. If an additional clinician requires access, the user would need to self-authenticate (the action would subsequently be audited) or be added by the system administrator. This method is more precise but uses more overhead than the two above- mentioned approaches. In cases of emergency, access control systems should allow users to override system restrictions by forcing user confirmation of access override.
Implementing an Audit Trail
To ensure emergency related access is tracked, a solid audit trail is required. An audit trail serves as a record of all events such as “user x viewed the record for patient y”, and alerts users that their actions are being recorded.
There are three standard ways to implement an audit trail:
Save to a Log File
In this case, actions are recorded in a predefined format in a file rather than a database. File system privileges for the file must be restricted so that only a trusted administrator has access. This log file should also reside on storage with redundancy in place.
Save to a Database
This implementation is more in line with audit trail and node authentication best practices. All actions are stored in a separate database instance and used only for audit records. The physical machine resides on a protected network that offers administrator access only. The format of the audit record can take any form as long as it records the user, the patient, the date and time, and the data that was modified (if applicable).
Record Every Database Action
This method implements an application such that every SQL command along with the parameters and the user associated with the command session is saved. The detailed nature of this approach can make it very difficult to trace access breaches.
Download The Complete Guide to Engaging Digital Health Software