Keeping patient data safe with open source tools

Keeping patient data safe with open source tools

Learn how one healthcare startup addresses HIPAA's data protection requirements.

open on blue background with heartbeat symbol
Image by :

Subscribe now

Get the highlights in your inbox every week.

Healthcare is experiencing a revolution. In a tightly regulated and ancient industry, the use of free and open source software make it uniquely positioned to see a great deal of progress.

I work at a scrappy healthcare startup where cost savings are a top priority. Our primary challenge is how to safely and efficiently manage personally identifying information (PII), like names, addresses, insurance information, etc., and personal health information (PHI), like the reason for a recent clinical visit, under the regulations of the Health Insurance Portability and Accountability Act of 1996, HIPAA, which became mandatory in the United States in 2003.

Briefly, HIPAA is a set of U.S. regulations that were created in response to the need for safety in healthcare data transmission and security. Titles 1, 3, 4, and 5 relate to the healthcare industry and insurance regulation, and Title 2 protects patient privacy and the security of the PHI/PII. Title 2 dictates how and to whom medical information can be disclosed (patients, medical providers, and relevant staff members), and it also loosely describes technological security that must be used, with many suggestions.

The law was written to manage digital data portability through some amount of time (though several updates have been added to the original legislation), but it couldn’t have anticipated the kinds of technological advancements that have been introduced, so it often lacks detail on exactly how to keep patient data safe. Auditors want to see best-effort, authentically crafted and respected documentation—an often vague but compelling and ever-present challenge. But no regulation says we can’t use open source software, which makes our lives much easier.

Our stack consists of Python, with readily available open source security and cryptography packages that are typically already baked into the requirements of Python web frameworks (which in our case is Klein, a framework built with Twisted, an asynchronous networking framework for Python). On the front end, we’ve got AngularJS. Some of the free security Python packages we use are cryptography, itsdangerous, pycrypto, and somewhat unrelatedly, magic-wormhole, a fairly cryptographically secure file sending tool that my team and I love, built on Twisted and the Python cryptography packages.

These tools are integral to our HIPAA compliance on both the front-end and server side, as described in the example below. With the maturity and funding of FOSS (shout-out to the Mozilla Foundation for funding the PyPI project, the packaging repository all Python developers depend on), it’s possible for a for-profit business to not only use and contribute to a significant amount of open source but also make it secure.

One of our early challenges was how to use Amazon Web Services' (AWS) message queuer, SQS (Simple Queueing Service), to transmit data from our application server to our data interface server (before SQS encrypted traffic end to end). We separate the data intake/send instance from the web application instance to make the data and the application incommunicable to one another. This reduces the security surface should an attacker gain access. The purpose of SQS, then, is to transmit data we receive from partners for continuing care and store it temporarily in application memory, and data that we send back to our data and interface engine from the application to add to patient’s chart on the healthcare network’s medical records system.

A typical HIPAA-compliant installation requires all data in transit to be encrypted, but at the time, SQS had no HIPAA-compliant option. So we use GNU Privacy Guard (GnuPG), which can be difficult to use but is reliable and cryptographically secure when applied correctly. This ensures that any data housed on the application server for any period of time is encrypted with a key we created for this service. While data is in transit from the application to the data interface, we encrypt and decrypt it with keys that live only on the two components.

While it’s easier than ever to use open source software, we are still working on contributing back. Even as the company attorneys and marketing folks determine the best and safest way to publicize our OSS projects, we’ve had some nibbles at our pip packages and repositories from others looking for the exact solution we present. I’m excited to make the projects we've issued better known, to steward more of our open source code to those who want it, and to encourage others to contribute back in kind.

There are a number of hurdles to this innovation in healthcare, and I recommend the excellent EMR & HIPAA blog, which offers a terrific, accessible daily newsletter on how many organizations are addressing these hurdles technically, logistically, and interpersonally.


About the author

A blonde woman who is waving as though saying "Hi!", wearing a gray and purple snow hat and beige glasses
Rachel Kelly - Rachel Kelly is an operations engineer in Portland, Oregon at a small healthcare startup. Rachel chaired a Python conference called PyDX, and was also part of the organizing team for Portland PyLadies. She enjoys public transit, Kubuntu Linux, hanging out with her cool husband and cats, and laying on the couch with a nintendo or two.