Implementing OpenMRS in the USA: HIPAA and downloading

Hello! I am part of a student run free clinic sponsored by a medical school. We are looking at different EMRs to use instead of paper charts. I have a few questions about this one! Please answer as much as you can as any info will be much appreciated.

  1. I have read it is not HIPAA compliant. I have also read there is a way to make it so? What would that process be/how difficult is it, and is there a price range to be expected?

  2. Other EMRs we have looked at are downloaded onto a computer and connected by secure wifi. We will also have a hard drive with the data elsewhere for HIPAA. Is this EMR the same? If not, how difficult is it to implement?

Hi @brennansmith450, you are at liberty to download a given openmrs version from this link Releases – or install an SDK following the steps listed on this guide OpenMRS SDK - Documentation - OpenMRS Wiki.

It’s worth noting that the majority of HIPAA compliance is not something a software package can provide for you as most of HIPAA compliance requires the development of organizational-specific policies, procedures, and plans. The major technical requirement of the HIPAA Security rule is that data be encrypted in-transit and at rest when not stored on a server within the organization’s firewall. In practice, this means you should ensure that every laptop, mobile device, and ideally desktop that access the EMR has full-disk encryption.

We have some standard documentation on securing an OpenMRS instance on the Wiki and it would be advisable to follow it.

From a compliance perspective, OpenMRS does have three major weaknesses:

  1. By default user permissions control the parts of the applications they are able to access not the specific data, e.g., you can set things up so a user cannot see patients at all, but once they can see patients they can see any patient. A mitigation here would be to use the Data Filter module, but this requires customisation to implement whatever business rules your organization has around who can access data and under what circumstance. I’m not sure if it has a “break the glass” feature (basically a button that allows a user temporary, audited access to a patient record they would not ordinarily have access to for emergency situations). For ambulatory clinics (which is most of what OpenMRS supports), such a feature is generally less necessary that inpatient units in hospitals.
  2. While we have some of the necessary password controls, I think that by default many of them are not enabled or the 2.x RefApp doesn’t pay any attention to them. Again, this could be addressed (actually, this is a smaller project than the above), but is a bit non-trivial. This can be mitigated by moving your authentication out of OpenMRS into an OAuth2 server and using the OAuth2 Login module.
  3. OpenMRS’s auditing is generally inadequate. Specifically, we have some auditing around writes and updates to data that could be leveraged to build a proper audit log, but there are no audit trails for reads to patient data in the system. A proper auditing system could be built as an OpenMRS module and plugged into the system. This would require someone with familiarity with at least Java, Spring, and Hibernate, but isn’t impossible to do. Alternatively, it might be possible to build an auditing system external to the application, e.g., something that reads OpenMRS’s log files to build a proper audit log or a web proxy sitting in front of OpenMRS that turns web requests into appropriate audit records. This is probably the biggest gap and also the hardest one to plug. (There’s a very old module here that aimed to provide some audit capabilities, but it’s not maintained, likely only to work with very old versions of OpenMRS, and still doesn’t provide auditing of patient record reads).

Yes, exactly that. You setup a server instance on one computer and other computers are able to connect to it via a web interface over whatever network you have available (so secure Wifi would work).