Before the advent of powerful and more compact computers, information management in the health sector was localised and dependent on paper workflows.   As computer applications began to be developed to offset the use of paper, data repositories were created to contain patient information. They were in effect silos that had no means to communicate with each other or share information.  

There was a need for a common language that allowed information to be passed between disparate systems. A conduit if you will.  This need for a common communication medium inspired the invention of  Electronic Data Interchange. There were a variety of flavours of EDI that developed over time. First there was X12 and EDIFACT and then a brand new HIPAA compliant standard called Health Language 7 (HL7) intended for use in the health industry. An exchange standard that could stand on its own.

With HL7, data could be translated into a common format that both sender and receiver systems could understand. The first HL7 implementations involved point to point connections. It facilitated the exchange process but not in an efficient way. There was a need for middleware that could connect to multiple source points and to multiple destination points. The middleware would serve as a routing function. It would also serve as a filtering mechanism. Large amounts of HL7 messages could be funnelled to this system which could be filtered by message type or some other criteria. Messages that did not fit the criteria would be discarded or killed. One data source could feed several destinations. That would involve another value add called transformation which essentially involved mapping inbound data to outbound data fields. 

This middleware became known as an integration engine. Integration engines evolved over time to include more functionality, better user interfaces, more connectivity and better performance for high volume environments. They had names such as Cloverleaf, eGate, rhapsody, Mirth, Ensemble.

The first HL7 messages were linear messages. They had a header section and multiple data sections delimited by vertical bars. These sections were called segments. Each segment was divided up into smaller chunks called fields. The HL7 standard defined the format and content of each of these sections. There was a contingency for information not included in the standard and that was known as a Z segment which could be user defined.

HL7 V2 messages have been the work horse of the health industry for many years and are effective in increasing the movement and sharing of data in hospital environments.

As time passed, subject matter experts in the HL7 organisation determined that HL7 v2 did not fit the real world as well as it should. They set about to develop a new "use case” of current day clinical interactions.  HL7 V3 was borne.

The essence of V3 included incorporating a model-based methodology, semantic foundations encompassing a reference information model, data types and terminology domains. It also allowed for the use of software engineering tools.

The Reference Information Model or RIM as it was known was an object-based model. The essential components were classes, attributes, associations and generalisations.

There were four primary subject areas known as Entity, Role, Participation and Acts. Putting a context to these terms, there are actions taken to treat patients which include requesting orders, reporting results, creating diagnoses and treatment and others.

This is where the language of the V3 standard gets a little obtuse. All of these actions or happenings are referred to as Acts in the model. Different acts are related through act Relationships. Participation defines the context. Which provider did it, who was the patient, Where was it performed at?

The participants are called roles and can refer to a patient, provider, even a specimen, employee and so on. Each one of the roles is played by Entity which can be a person, organisation, some kind of material, a place or a device etc.

The reference model displays how all of these components link, intertwine and interact with each other. Without going into too much more detail, putting it into practice requires a good deal of knowledge about clinical interactions. 

With all the messaging currently being done in HL7 V2, what would be the scope of effort needed to convert V2 to V3? The answer is HUGE. Which is why the impetus for costing and carrying out conversions was not an easy sell. V3 has not caught on except for one exception.

[In the US] Meaningful Use had a requirement for document sharing. It needed document content that could carry all of the information necessary to satisfy the continuity of care requirements for patients transitioning between care situations,  i.e. from a hospital to clinic, etc.

Within the RIM there is a section called clinical document architecture (CDA) that contains all of the elements described above (entity, participant, role, etc.) 
One of the end products or artefacts which is an XML document contains all the essential information groups required for continuity of care. It is actually called a Continuity of Care Document or CCD.  It constrains the CDA Model.  

CCDs are propagated when a patient is discharged from a hospital and contain a snapshot in time of the patient's condition. These documents are stored in a repository and shared with other health organisations who have a trust relationship when patient care is needed.

HL7 V2 is still the workhorse for hospital information movement. But this does not diminish the need for something better. In fact new ideas are pointing to a different way of handling health information along the same lines as V3 with a view to representing patient interactions in a more realistic way but also in a simpler and more direct context. With less baggage so to speak. 

A new standard, called FHIR (pronounced as Fire) stands for Fast Healthcare Interoperability Resources. It is meant to correct the lessons learned around the implementation of V2, V3 and CDA. It can work standalone or in collaboration with existing HL7 standards.

The main component of FHIR is called a Resource. Any content that is exchangeable is defined as a Resource. The philosophy of FHIR is to build a base set of resources that define a core set of information that is shared by all implementations. An extension mechanism covers the disparities.

In V3 we have model by constraint in contrast with FHIR which is a model which combines components together. Either a single resource or multiple resources could be used to implement specific use cases.

Resources utilize data types that are reusable elements, have common metadata and are human readable. FHIR resources can be implemented in a variety of ways such as messaging, service based architecture and REST. Resources could be used for clinical content, message headers and conformance as an example.

The evolution of information management and data movement in the health environment continues on. The technological divide that separates the past from the present serves as a reminder that technology innovation, growth and implementation is the impetus for efficiency, quality and economic sustainability in the health sector.  

Constrained only by initiative. FHIR has great promise to deliver information infrastructure that is both cost effective, efficient and maintainable. It seems an easier sell than HL7 V3 which seemed to have too high a degree of complexity. Hospitals are seeking to create better patient experiences and the efficacious application of technology plays a vital role in that endeavour.

Lowell Buschert is a Senior IT integration analyst with 30+ years’ experience interfacing disparate systems with particular focus on Hospital Information Systems (HIS), Electronic Health Record (EHR) Systems and Health Information Exchanges (HIE). He is currently a Middleware Senior Analyst at Baptist Health in Jacksonville, Florida.