You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

There are a number of different standard available for exchanging clinical information between disparate systems. For the OpenHIE Shared Health Record (SHR) we need to choose to support the standard that make the most sense for our environment. OpenHIE implementation will focus on middle to low income countries so that we can make the most impact where it counts. Therefore, we have some key criteria that will influence the decision of what the 'best' standards to support. These are as follows:

  • Easily Implementable - The standard should be easy to implement in point of care systems and within the HIE as countries will have to support and maintain these with a lower number of skilled informatics specialists.
  • Size efficient - The messages should be size efficient due to possible bandwidth restricts in low resource settings.
  • Understandable - The standard should be easily understandable and not require informatics professionals to work with the standard.
  • Mature tooling - The standard should have some mature tooling to assist application to implement the needed functionality for the standard.

Currently, the community believes that there are a few standards that exist that we should be looking at for use within the SHR, these are:

  • HL7 v2
  • HL7 v3
  • IHE profiles
  • FHIR

Each of these has are described in more details below:

HL7 v2

Overview

HL7v2 messages are very popular and are commonly used as a message exchange format. This standard has been around for a long time so it has a large number of freely available tools that developers can make use of. It consists of a large number of message types for many different use cases each with their own structure and defined syntax. For technical interoperability HL7v2 employs the MLLP protocol that build upon TCP sockets. HL7 v2 messages can be encoded in either the ER7 (pipes and bars) format or as XML. The XML format allows thes to be used in more current day web services.

How could this standard be used in the SHR

We could make use of a specific message types that we profile ourselves to that the use of them well known. For example we could make use of the ORI_R01 message type to transmit patient encounters by using the OBX segments within the message.

Pros/Cons

Pros:

  • Mature tooling
  • Well know and understood
  • Efficient message size

Cons

  • Legacy format
  • Z segments ruins interoperability
  • The base standard need to be profiled to provide actual interoperability between systems

HL7 v3

Overview

HL7v3 attempts to solve the semantic interoperability problem by employing the use of a generic reference information model (the RIM) that all HL7v3 message must conform to. This, however, led to the message size growing very large and made HL7v3 difficult to understand and implement due to the generality of the data model. HL7v3 requires that one restricts the base standard down to a usable subset that is to be used. For low resource setting this becomes difficult due to the limited number of informatics experts available to do this and the time required to do so. HL7v3 messages take the form of large structured XML messages.

How could this standard be used in the SHR

Unknown. Would we have to restrict and profile HL7v3 message for our own use?

Pros/Cons

Pros:

  • All messages map to the RIM

Cons

  • Very large message size
  • Standard need extensive work by informatics specialists to be usable for a domain
  • Not a large amount of tooling support
  • Difficult to understand and use

Resources

IHE Profiles

Overview

Integrating the Healthcare Enterprise (IHE) is an initiative that attempts to improve the way in which health information systems share information. IHE produce technical specifications for health information systems interoperability. Specifications that relate to a particular problem are grouped in an IHE profile. Standardised IHE profiles such as XDS or PIX describe and restrict the use of other standards in order to achieve full system, syntactic and semantic interoperability. IHE profiles are pragmatic as they attempt to make use of existing standard that already have wide adoption so that integration of IHE profile into existing systems can be simplified. IHE profiles are also very use case specific. This has the benefit of allowing them to clearly specify exactly how semantic interoperability can be achieved, however, it also mean that different IHE profiles are needed for each different use cases. IHE covers many of the priority use cases, however, it is difficult to cover all use cases due to the many different uses of health system information exchange world-wide.

How could this standard be used in the SHR

We could identify certain standards that could achieve the goal that we need for a SHR (transmitting structured and unstructured clinical information). For example, we could make use of the XDS profile to convey documents and make use of defined CDA document types to ensure semantic interoperability.

Pros/Cons

Pros:

  • Standards are tested in the field
  • Highly specified transaction and message formats help developers

Cons

  • IHE profiles concentrate on specific use cases and are not by definition general use, you have to implement a profile for each use cases you would like to support
  • Each profile could make use of a variety of different standards.

FHIR

Overview

Fast Healthcare Interoperability Resources (FHIR™) defines a set of 'resources' to represent health and healthcare administration-related information. These resources express granular clinical and administrative concepts that can be electronically exchanged in order to quickly and effectively solve system interoperability problems in healthcare and related processes. The resources cover the basic elements of healthcare - patients, admissions, diagnostic reports, medications and problem lists - with their typical data elements and also support a range of richer and more complex clinical models. The simple direct definitions of the resources are based on thorough requirements gathering, formal analysis and extensive cross-mapping to other relevant standards.

How could this standard be used in the SHR

We could implement a subset of the FHIR standard that would be suitable for our needs. For example, the Document, Observation, AllergyIntolerence, CarePlan etc. resources.

Pros/Cons

Pros:

  • Maps to the HL7v3 RIM
  • Easy to implement and understand as it REST-based
  • Makes use of current best practice techniques
  • Learnt from the mistakes of v3

Cons

  • The standard is new and is not balloted as of yet

Resources

  • No labels

This work is licensed under a Creative Commons Attribution 4.0 International License.