Why is it so Hard to Integrate Telemedicine into EHRs? Part 1
Part 1: Which EHR?
From a telemedicine vendor’s viewpoint, the first challenge to integration is “which EHR”?
There are more than 1,000 implementations of EHRs and not all of them follow recognized standards such as HL7 v2, HL7 v3, FHIR, openEHR and VISTA. Many have home grown infrastructures with interfaces to one or more of these standards for purposes of providing an integration path, making it a challenge to integrate telemedicine into EHRs.
These standards are quite different so providing an interface to each one requires effort. Worse still is that communications between two entities each having a standards based interface does not mean that those two entities will be able to pass information.
There is almost always some level of customization required.
The dominant EHR standard in the field today is HL7 version 2.x
HL7 version 2.x is the oldest EHR standard, originating in 1987. It provides an interoperability specification for health and medical transactions for hospital information systems.
It was developed in an ad hoc fashion to integrate various hospital systems such as between administrative and clinical. This allowed for rapid adoption since developers could concentrate on local conventions and issues. This heavy usage of local customization became baked in and made each integration task a custom effort. This spawned an HL7 integration engine business sector, which is still going strong today.
HL7 v2 with its field separators, component separators, subcomponent separators, field repeat separators, escape characters and most significant, the Z segments, is not complex, but every implementation is highly customized.
HL7 version 3 started in 1995 to address the short comings of HL7 v2. The standards professionals took control of this effort and did a top-down abstraction approach where the platform is agnostic and decoupled from implementation. The end result was a standard that is not directly implementable. The complexity of transforming the model from the abstract to concrete implementation elements was daunting. Even more discouraging, no two actual implementations would be compatible. Given the difficulties several early high visibility implementations encountered, adoption of HL7 v3 started slow and has tapered off from there.
But the short comings of HL7 v2 are so significant, that the standards oriented people did not give up. In 2011, an independent group of HL7 architects started on a new approach capitalizing on modern Internet capabilities – specifically REST (Representational State Transfer). This allows an implementation that is stateless, uses HTTP methods, uses XML (nice carry over from HL7 v3) or JSON (JavaScript Object Notation) as resource representations and has resources at predictable URLs. This new try is called FHIR (Fast Healthcare Interoperability Resources). As the R in FHIR implies, it is built on the concept of “resources” (e.g. Patient Resources, Device Resources, Document Resources).
By taking the RESTful approach and avoiding both the ad hoc approach of HL7 v2 and the top down approach of HL7 v3, it had an attractive beginning. 
But FHIR is abstract and doesn’t specify implementation details. (Sound familiar?) It is still being developed and while it has a lot of support, it doesn’t have that many implementations in the field.
Integrate Telemedicine into EHRs? HL7 v2 Reigns
In spite of its shortcomings and criticisms, HL7 v2 implementations rule. So, if you want to connect to the greatest installed EHR base, then you have to talk HL7 v2.
Over 90% of hospitals in the USA use HL7 v2 and it is unreasonable to expect them to rip out something that has been working (for many years) and replace it with something new and as yet unproven. New implementations are clearly the best targets for FHIR. But to have relevance in an HL7 v2 world, a FHIR to HL7 v2 interface engine is needed for each of those FHIR implementations.
Since the RESTful approach of FIHR simplifies transversing the Internet it is ideal at the originating end of an interface transaction. The receiving end with an HL7 v2 implementation would need a FHIR interface engine. Easy for the originating end, but still an effort at the receiving end because of the local HL7 customization.
If FHIR could go beyond its abstraction rules a bit and specify a certain amount of implementation details specifically for telemedicine, then it could be extremely useful.
On the other side, if HL7 could pare back the myriad of local options to a core minimum needed for telemedicine, we could have a focused specification with relative ease of implementation. More on this in later installments of this series of articles.
What about other protocols like openEHR and VistA?
At their core, HL7 v2 and FHIR are messaging oriented. They provide guidance on moving information between systems. They don’t specify how data is stored. OpenEHR is all about how to store information. It describes an efficient method of database mapping that enables rapid retrieval of information.
In the telemedicine world, the EHR is typically a separate entity and a key task for a telemedicine system is to get clinical information it gathers to that EHR. That is, once the telemedicine system collects clinical information, it’s all about messaging to get that information to the EHR.
That leaves OpenEHR outside the theme of this discussion series.
The Veterans Information Systems and Technology Architecture (VistA) is a nationwide information system and Electronic Health Record (EHR) developed by the U.S. Department of Veterans Affairs (VA). VistA consists of over 180 applications for clinical, financial, and administrative functions within a single, integrated database, allowing all applications to share a single, authoritative source of data for all veteran-related care and services. It has received particularly high marks for connectivity and utility as a clinical tool. VistA is open source.
Since VistA includes communications, it might make sense for a telemedicine system to use its available interfaces to get information from the telemedicine system into VistA. In fact for the few telemedicine systems chosen to be used within the VA, that would be expected. Outside the VA network, having a VistA interface is not common. Finally, the VA has announced that it does not intend to continue the development of VistA and will move to a commercial platform (from Cerner).
That leaves VistA outside this discussion series.
Take-away on the approach to integrate telemedicine into EHRs
The big take-away from this review so far is that the telemedicine world needs to figure out how to live with HL7 v2.x and that FHIR has certain aspects to offer.
In the next part, we’ll talk about ways we can go about doing that.
View Part 2: Why is it so Hard to Integrate Telemedicine into EHRs? What not to do.
View Part 4: Why is it so Hard to Integrate Telemedicine into EHRs? FHIR LIHT
For more information on telemedicine in general, visit www.telemedicine.com. 
With over 20 years in telemedicine, C. R. (Rich) Abbruscato is one of the pioneers in the telemedicine market. He is founder of RNK Products (using the brand Telehealth Technologies) a company dedicated to the design, development and manufacture of telemedicine medical devices (most notably real-time stethoscopes) and telemedicine systems.
Rich is a Guest Contributor for EHRGuide.org.
