Anytime I have a question about EHRs, how they work? what’s possible? I turn to Mark Olchesky. He’s worked for Epic and is now the Chief Data Officer at Catalyze. Not only does he just get these systems inside and out, he knows how to explain things (at least to me) in a way that makes sense.
In this post, Mark will share with you a tool we collaboratively built to help solve the belabored question, “how do I get data into and out of an EHR?”
Take it away Mark.
How to Access EHR Data Today
A few months ago, I had the pleasure of presenting at the Open mHealth Summit in San Francisco. Catalyze and Open mHealth had teamed up to solve a major problem within the Digital Health Community: extracting discrete data from EHRs in a standardized, open format. The presentation demonstrated the findings of that collaboration. Catalyze is proud to be one of the first sponsors of Open mHealth and we want to share more about the work we’ve done with OmH and why we believe that open standards are vital to the improvement of interoperability.
Why Open Source Tooling and Standards
Generally speaking, when most Digital Health startups and intra-organizational projects get started, standards are rarely top of mind. Likely, no one pays you the vendor to solve a problem which involves standards. Furthermore, those who are your customers are not the best source for knowing which standards to implement.
Over time, however, standards become vital and technical/strategic debt eventually must be paid off. In 2015, it’s hard to bring a new product into a healthcare organization without a story or a plan around how your data will not be siloed. Likewise, you must demonstrate how it will mix seamlessly with the rest of the data within the organization. In most cases, this involves integrating with the existing EHR system at the healthcare organization. Regardless of your thoughts on EHRs, integrating data in stand-alone applications and devices is now required.
Work needs to be done in mapping these standards together. HL7v2, HL7v3, CDAs, FHIR and a continually evolving landscape of APIs continue to be built. As a new company, or a company getting into a realm where standards are so important, how do you know how to pick a winner?
Introducing Pulse
The intent of Pulse is to provide an open-source framework for porting discrete data from various methods out of the EHR into the standards based OmH data models. Since most data in the OmH dataset is still exchanged through HL7v2, this is where we began with the project.
What do you get with Pulse?
- JavaScript templates which map HL7 messages to OmH messages and vice-versa. This provides the mapping logic in an easy to understand format for re-use in other tooling which you may want to use: https://github.com/openmhealth/pulse/blob/master/javascript/OMHtoORU.js
- Channels and Code Templates that are ready to deploy on the open-source Mirth interface engine: https://github.com/openmhealth/pulse/tree/master/mirth_channels & https://github.com/openmhealth/pulse/tree/master/global_code_templates
- These templates allow you to start receiving, monitoring and sending HL7v2 over TCP (the most common way of exchanging data) on a well-documented open-source tool. I can vouch for it personally; Mirth is the underlying engine of our Scripts and integration offering at Catalyze.
- HL7 and OmH data examples: https://github.com/openmhealth/pulse/tree/master/samples/
Using our tooling, you’ll see that these messages map to each other and can be used for testing purposes.
Next Steps
Introducing new data mappings of common EHR standards are next for Pulse. Catalyze and Open mHealth plans to introduce similar mappings for CCDAs and FHIR soon. In the meantime, if you have any questions about Pulse or HL7, or would like to contribute, please submit an issue or a Pull Request to the Pulse repo.