Difference between revisions of "Implementation FAQ:Migration from version 2"
Charliemccay (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 18: | Line 18: | ||
===Don't assume v2 - v3 mapping can be done at the integration layer=== | ===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 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 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. | ||
Revision as of 19:29, 6 September 2006
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
Contents
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:
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).
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.
