HL7.nl 2006 v3 Implementer training

Flipchart notes

On 20060906 HL7 Netherlands held a v3 Implementation training. At the beginning of the training the attendees were asked to name some of the v3 implementation issues known to them. At the end of the training the issues were discussed. Some of them were answered by the contents of the training, others were not. See image for the original flipchart notes (in Dutch).

The issues raised (in English, with notes from the discussion) were:

• Wrappers contain lots of new details
  • Things like authors/overseers in the controlAct wrapper didn't exist in v2, therefore database changes are required to capture the information. Applications are used to capture metadata related to payload acts, vendors now have to deal with metadata in a new catergory.
• Creation of documentation/specifications by vendors. Creating those is largely duplicating the efforts of the Framework or the HL7 v3 documentation itself. There are no tools to support vendors in this proces.
  • If one had a Realm/Framework defined repository (with localized artefacts) the generation of futher constraints and documentation of the resulting artefacts would be easy. Currently a vendor has to start from scratch.
  • Would be nice to at least have a checklist or template of what should be in an implementation guide. Recommendation that future (eclipse-based) documentation tool be able to generate PDF as well as HTML - when reviewing/studying 1 specific domain HTML one needs to be able to print it. HTML is useful as reference material, but not for reading cover-to-cover.
• What is the relationship between HL7 models and my internal database model? Should the latter be derived from the former? And if so, at what abstraction level? D-MIM? R-MIM? How to transform to ER model?
  • See Implementation FAQ:Interface Development
• How to select the best coding/value system (as a vendor, or as a healthcare provider organization)
  • Any best practices on how to select the best (from a long term, inter-organizational standpoint) terminology? In how far should a provider organization require that the vendor adhere to specific (HL7-defined) value sets? Vendors may have a tendency to use codes (whatever codes they already have) and assign a new OID to that existing codeSystem. Any best practices in constraining value sets?
• Tools - some tools aren't able to deal with the v3 schema
  • Recommendation of attendees is to create a Wiki page which shows which versions of what tools work with the v3 schema, and what tools need a workaround. Known issue with some .NET based tools. Symphonia toolkit has a problem with minOccurs=0 maxOccurs=0 construct used in datatypes schema.
  • See (new page) Implementation FAQ:processing v3 schema with standard tools
• Version 2 to version 3 mapping issue
  • A new migration strategy was suggested: 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 whetever 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.
  • See Implementation FAQ:Migration from version 2
• Code generated based on WSDLs based on HL7v3 WS profile can't be used, too complex

Two additional issues came up during the presentations itself:

• 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?
  • Probably related to updatemode if one would like to remove one name (e.g. with one specific use-code) from a set of names.
  • See Implementation FAQ:Migration from version 2
• The introduction of new v3 Trigger Events (which are more detailed than in v2) may lead to significant changes in application software, especially if triggers are not database-based, but are based on a subroutine being called whenever a user has completed some activity/action.