There are a lot of opportunities for efficiencies to be gained and for new technologies to be leveraged if non-EMR systems and devices were to exchange data in a manner that is easy-to-use, efficiently, timely, and cost-effective. The traditional integration model used by the healthcare industry involves building many unique interfaces. An analytics system for a healthcare system or ACO (accountable care organization) will need to build different interfaces – sometimes heavily customized – for each EMR or even for each instance of each EMR (depending on the EMRs involved). At some level, the costs in maintaining the complexity exceed the benefits of the actual interfaces, and, thus, the benefits of integration are lost. This inhibits care improvement activities and efforts to reduce healthcare costs.
A third-party seeking to successful integrate with an EMR vendor – whether it be in sending data, receiving, or both – should seek out to build a durable, common data model that allows the development effort to be spent on extending functionality and not on building the same interfaces repeatedly to meet the requirements of each integration partner. The vendor’s efforts can be spent on defining consistent ways to read and parse data such as HL7 2.x messages, CCDAs, QRDA files, and payer claims. The data can then be built into a unified format that can be queried by or pushed to third-parties. The common data model can then be exposed via an API – application programming interface – that developers of any system can use to receive data. The alternative would be the more-often-than-not current state where a third-party uses an integration engine such as MIRTH or Rhapsody to build a CCDA interface for vendors x, y, and z; an ADT interface for another vendor, etc. Each of these interfaces must be maintained separately. If, for example, a change needs to be made to how ADTs are processed, all of the individual interfaces would need to be updated which introduces more opportunities for errors and insecure code to enter into an environment. The alternative, a common data model would process data once – i.e., one ADT process, one CCDA process, etc. When a change needs to be made, it can be made once. All of the data translation for the recipients of the data would be made after the inbound data is loaded into the data model. When the data is sent outbound, it would be pushed in a singular format – e.g., XML of JSON. The receiver, if they wish, could simply implement a way to receive the common format; otherwise, if it their choice, they can force the data to be translated into a format used by the receiver with their integration engine.
Healthcare APIs combined with common data models can finally move the industry closer to the goal of more-or-less seamless interoperability. It would also bring healthcare IT closer to many other industries where APIs are much more mature. Such APIs would also enable patients to also exercise more control over their data as they could use devices and software such as an Apple Watch or Fitbit to monitor their health status. Increasingly device manufacturers are increasingly looking to leverage such models to empower diabetic patients to monitor their glucose levels more and to use a myriad of devices to keep patients with CHF (congestive heart failure) in their homes and out of Emergency Rooms and Skilled Nursing Facilities. These APIs can also make providers more efficient by automatically receiving such data, aggregating it, and using business rules to alert providers if a certain event is triggered. For example, if a patient is at home using a Bluetooth-enabled scale, and they have CHF, their cardiologist’s practice can be alerted if their weight increases by a certain amount; an endocrinologist can receive an alert if a diabetic’s glucose reaches a certain level.
In an environment where providers and health systems are being pushed to take on more risk and possibly move to full capitation, APIs backed by common data models can allow for EMRs to connect with secondary systems and devices to not only lower the cost and time barriers to integrations but to also utilize newer technologies to enable more proactive care management of complex, cost-intensive patients.