Implementation FAQ:Migration from version 2

This page contains questions related to the migration of HL7 version 2 to version 3, mostly from a non-technical perspective.

Back to Implementation FAQ

Questions

Selling point for V3

Question: What is the real value of the reference model in V3 – what is the life of the system –this can be a long time for strategic programs. These need to be future-proofed.

• Two documents from the Marketing Committee's document page that discuss the rationale for using HL7 version 3:
  • Draft HL7 v3 Value Proposition Document
  • Canada Infoway v3 Infosheet

Question: I have a running system using V2, how do I justify moving to V3, especially as V2 just keeps getting better.

• The justification of v3 lies in those areas that v2 doesn't cover (e.g. inter-organizational communications, CDA, clinical genomics).

v3 equivalent of v2 null

Question: In v2, "" (null) is used to inform the receiver that "any value it has for the field should be erased from its database". What's the equivalent in v3?

• Closest thing would be an UpdateMode of "delete"
• If you're in snapshot mode (i.e. not operating using updateMode), then it's up to the receiver whether they choose to get rid of information you don't supply.
• Even with updateMode, if it's a Notification, you're simply stating what you've done, not what the receiver must do. Only with a Request would the receiver be obligated to actually remove the value (and then only if they agree to act on the overall request).

Recommendations

Don't assume v2 - v3 mapping can be done at the integration layer

If your application already supports HL7 v2: HL7 v2-v3 migration by means of a mapping is problematic. The main problem is not the mapping itself (although HL7 v3 is much more detailed than HL7 v2), but the behaviour of the application. This is mainly a business flow issue. The dynamic behaviour and trigger events in V2 and V3 are sufficiently different, that your application behaviour will need to map on to them differently.

• If your application has to support both HL7 v3 as well as HL7 v2: create a new communication module for the HL7 v3 messages/documents, and use it in parallel to the HL7 v2 communication module.
• If one has an application which has a v2 interface (and where the creation of a new fullblown v3 interface is not an option - for whatever reason), it may be relatively easy to enrich an existing message (using Z-segments if need be) with content needed to populate a v3 message. Translation can then be done by a communication server. Such an approach would ease the mapping problem.

Source and target systems lack rich semantics

Black and white TV to HDTV to black and white

If both the sending as well as the reciving system are "semantically challenged" then this'll need to be addressed first. Introducing v3 in such an environment doesn't add any benefit. Rene spronk 06:21, 26 May 2006 (CDT)

Unless there is a long term plan to evolve the systems to be more semantically rich -- thus there is a good case for introducing the V3 communications infrastructure using simple flows first (where other approaches would also have worked), IF there is a strategy to introduce richer flows and application functionality in due course. Charliemccay 04:06, 2 Jun 2006 (CDT)

There are generally at least 3 semantic representations involved: sending system, message format and the receiving system. There will be problems if it is possible to message concepts that don't exist in the receiving systems. It's not so bad if the sender only supports a subset of the message's features. The rest can often be ommitted or defaulted. Unless carefully controlled, message designs tend to evolve to be the sum of all system's functionality, so everyone is happy populating their data un-degraded into messages. Getting data out again and using it is generally the harder part. This is not a messaging issue, it's a functionality mismatch issue, regardless of how the data associated with that feature might be sent. Rik Smithies 16:41, 7 Jun 2006 (CDT)