Interoperability continues to be a significant topic in healthcare IT. As most in the industry can attest, reality has not kept pace with promises made by vendors and regulatory pressure has not completely eradicated the data silo model that is, admittingly, rather profitable for EMR vendors. Moreover, the costs to extract data for uses by third parties is often prohibitively expensive for small to midsize providers if integrations need to occur with many care partners. That said, integration with EMRs and amongst EMRs is possible and organizations – both clinics and hospitals – looking to meaningfully use EMR data outside of the originating system have multiple options to achieve such goals.
The first option that clinics can use are traditional interfaces. Such interfaces often involve extracting CCDAs (continuity of care documents), appointment data, demographic data, or lab/radiology results and sending them to an endpoint. For example, a health system may have an interface between a practice management system and separate EMR program that sends demographic data when a new patient is registered in the EMR, or it may have a scheduling interface that sends new appointments to the EMR from the practice management system. A hospital RIS (radiology information system) or LIS (lab information system) may have HL7 results interfaces with numerous private physician practices that refer patients frequently to the hospital for care. Often – with the possible exception of the latter example – these interfaces are point-to-point – i.e., there is a single connection from entity to another. For integration projects that need not worry about scaling significantly or concern themselves with significant data transformation – for example mapping internal codes in one system to codes used by another system for lab tests – such integrations are often sufficient and, likely, the most cost-effective option.
When, however, integration projects require the need for scaling or significant data translation, more efficient options exist. A clinic or hospital (which may have the talent in-house), can implement and use an integration engine to receive data from a single end point – an EMR for example – manipulate the data for use by different end points and send it to one or more end points. A good example would be compounding the use of CCDAs (continuity of care document). After an organization has implemented an integration engine such as QSI’s Mirth or Interfaceware’s Iguana, it can setup a CCDAs interface with an EMR. Let’s use the example of Allscripts. After each visit, the instance of Allscripts will automatically generate a CCDA and send it to the integration engine. The integration engine can then have multiple channels that make use of such data. One can, for example, send the document to an HIE (health information exchange), another can send the CCDA to another EMR, and, finally, a third channel can translate the document, after extracting specific data elements, into a different format – let’s use a comma delimited or CSV file – and then automatically submit the new file to a health plan for inclusion in their HEDIS system. The main item to recognize is that an integration engine is a combination of a transport tool – i.e., a tool that sends information rom end point to another – and a programming environment that allows competent engines to greatly manipulate data to make it more readily digestible by recipients. Often an integration engine sits on one or more3 servers in a data center.
APIs or Application Programming Interfaces
Probably the newest way – and maybe the most promising – to integrate with EMRs is through an API or application programming interface. An API allows programmers to developer what amounts to a plug-in (think Flash) for an EMR that performs certain activities. It can, for example, extract data and send it to a third-party system, or it can maintain a single sign-on system that allows a provider or other EMR user to seamlessly move between systems without having to login to another system or look up a patient manually in another system. One product example is a clinical analytics system called Health Endeavors. For multiple EMRs it has a single sign-on that allows providers – from the point of care – to click a button and automatically login to their system and bring up a patient profile that includes claims, HEDIS, and other data on a patient. If a practice is a member of an ACO, this information can help more quickly drive decisions about determining if a patient should be in care management or enrolled in a CCM (chronic care management) program. APIs can perform a lot of the work that integration engines can do, but the workload can be more streamlined, and the infrastructure simplified as each API can be written to the EMRs specifications so that only the data translation tasks that need to be performed for that specific EMR get performed. An integration engine, by design, is much less distributed than an API. Moreover, an API – once written – can be readily deployed to innumerable instances of a specific EMR without much work involved.
There is, however, work to be done with APIs. Some EMR vendors do not have significant APIs released, and some of the APIs that are released are either costly to use or insufficient for many data integration tasks. As the regulatory framework around APIs develops further, such issues are likely to be ameliorated.
Organizations undertaking data integration projects will – no matter the mechanism used – likely encounter challenges and headaches; however, the inclusion of a strong multi-stakeholder team along with a disciplined focus on keeping the end goal in focus will better ensure project success. The means one uses to integrate should be wholly determined by available resources and efficiency. It is important to evaluate all possible methods for every project to ensure that resources are not being wasted by simply continuing a certain habituated method of data integration.