...
A question has been raised about whether we should support multiple standards. The feeling of the community is that we would eventually like to support multiple standards that are deemed useful. For example, FHIR may be useful in the future for more advanced querying of the SHR data. This brings up the question of external-facing standards (the ones the users of the HIE use) and the internal-facing standards (the ones used between components of the HIE) should always be the same or if we can expect to do transformation between different standards. The feeling of the community has been that we should not do transformations between different standards and rather expose multiple standards interfaces both internally and externally if needed. the reason for this is that it can be complex mapping and transforming messages between formats. This does not mean that we will do no transformation of messages, merely, that the transformation that we expect will be needed are transformation of the base standards to a more con formant conformant form of that same base standards. For example, enriching a HL7 message to contain additional required patient information.
Each of the above standards are described in more details detail below:
HL7 v2
Overview
HL7 v2 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 HL7 v2 to be used in more current day web services.
...
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 the 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 means that different IHE profiles are needed for each different use casescase. 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.
...
It seems from our reading that the use of HL7 v3 in its base form is too difficult and takes a lot of health informatics experts to specify the messages that are needed. So base HL7 v3 does not seem like the way to go for our use case. FHIR looks like a good option for the future but it is currently too new, the tooling support is poor and fact that it is only now entering its trial use period makes it a poor first choice. This leaves us with profiles HL7 v2 which many people are familiar with and have used with success and IHE profiles (perhaps using HL7 v3 CDA for clinical content). With HL7v2 we will have to profile our own messages to gain semantic interoperability and this can be time consuming and would require end users to know how we profile our HL7v2 but the process is known and building and modifying HL7 v2 message is simple due to the age of the standard. IHE profiles have the benefit of being highly specified so that systems can easily interoperate 'out-of-the-box' however, only specific use cases are profiled and if the data we want to collect falls outside of these profiles then this would not work or would require custom specification.We are currently unsure which of profiled HL7 v2 or IHE profile (XDS with CDA content) would be best for us to use moving forward. Further discussion and understanding of what each one entails is required
The SHR community believes that we should support IHE profiled CDA documents as the primary mechanism for transmitting clinical content due to OpenHIEs involvement with IHE and due to the wide spread use of CDA at the moment. We also believe that HL7 v2 messages should be supported at a base level to allow legacy systems to communicate in this simpler format until such time as they can be upgraded to support CDA documents.