Interoperability has become a hot topic in the world of health IT – yet due to its inherent complexity, it remains the biggest hurdle to efficient and effective use of communication across a broad spectrum of systems and solutions. Whether healthcare organizations are using EMRs, telemedicine, patient portals, mHealth or EMPIs, it is necessary for there to be a “common denominator” between those systems in order to achieve interconnectivity. The common denominator is an open architecture platform by which all communication can occur.
Google and Apple are two high-profile examples of open architecture platforms – Google with Android and Apple with iOS. Both companies encourage the introduction of new, highly useful functionality through plug-n-play applications, despite having been developed by different companies. Not all companies, however, are as open and welcoming as Apple and Google.
At the opposite end of the spectrum are the closed architecture platforms such as Epic and Greenway that don’t easily allow for third-party vendors to interface with their EMRs. Meaningful Use has forced these companies to allow interoperability, albeit not without varying degrees of resistance.
If the healthcare industry wants to go down the path that leads to interoperability, open sources, open standards and open platforms are the vehicles that are going to lead us there – and the keys with which to start these vehicles are application programming interfaces (APIs). APIs will specify how software components will interact with one another when all the systems involved are tied together. APIs, for example, can tie-in multiple EMRs so that data is shared easily between different systems.
What should a healthcare organization look for when tying together multiple systems?
In order to facilitate a successful interface, the first thing to look for is that the system being used is on an open source architecture. Here are some other key areas to focus on when engaging with and selecting an API interface engine vendor:
- The prospective vendor should use an open architecture. Mirth Connect is one choice. It is one of the largest open source architecture platforms within the healthcare space. Mirth Connect provides the necessary tools for API interface vendors to develop, test, deploy and monitor an interface; and it has a large and active community of users. Whatever architecture is used, adaptability and flexibility are key to a successful interface.
- Choose a developed API that can handle multiple EMRs. Even if you currently operate with a single EMR, at some point in the future you may want to add another software system, such as practice management or billing. This will require building an EMR interface. If the vendor you choose already handles multiple EMRs through its API, you know they will be ready should those changes occur. It’s important to keep in mind that each organization is unique in its structure, areas of specialty, personnel and workflow processes. Even if a vendor has not currently developed a specific API with your EMR, don’t eliminate them from your list. What matters is that they have experience successfully interfacing previous client spec requirements.
- Select a combined EMR and patient portal that meets or preferably exceeds Meaningful Use attestation. For some organizations it’s all about meeting the minimal requirements in order to receive Meaningful Use funding. However, it is important to note that the Meaningful Use program is currently in its early stages, and attestation requirements could still be added or removed. For example, due to uncertainties regarding the likelihood of patient engagement, revisions could still be made to future requirements for Meaningful Use. Being on board with a vendor who is “ahead of the curve” will go a long way in saving future changes (and headaches) from being made to your system.
There is no question that open platforms within the health IT world are inevitable. When that becomes the common knowledge, the possibilities for improvement within the healthcare industry will be endless.
