Implementation FAQ

There are a considerable number of implementations of HL7 version 3 based on a Development Edition, a Normative Edition (e.g. 2005) or a Project Specific Edition (e.g. the NHS). This document aims to describe the most important lessons learned from these early implementations, as well as some of the frequently asked questions related to the implementation of HL7 version 3. The document is maintained by the Implementation Committee, but please add questions and/or answers it is intended to be a living and useful document. The committee will review the document at each Working Group Meeting, and also at regular committee conference calls.

As with all FAQs some of the questions or responses may sound "obvious" to you; this may not necessarily be true for other implementers.

The current question/issue has been organized into a number of categories, mainly in order to limit the size of the individual pages:

• Implementer Organization
• Interface Development
• Interface Deployment
• Framework Issues (national/regional infrastructures)
• Migration from version 2

The remainder of this page contains a number of new questions/issues that have not been moved to one of the above pages yet. Please add any new questions or issues below, especially if you're not sure (yet) in which of the above categories it should be.

---

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)

version 3 documentation not as easy to use as V2 documents

In v2.3.1 as a PDF -- one big document and using the find button is a great way to find what you want. This is particularly good as a single document.

It would seem the implementers need to press Pubs/tooling somewhat harder to get a search option in the standard publication. This has been discussed before as far as I know, but the timing of such a solution is unclear. Rene spronk 12:46, 21 May 2006 (CDT)

Even if there is no search feature sometimes a better index could already work miracles. While implementing you sometimes need info on stuff you don't know the domain for. If so then you're pretty much lost. While looking for MFMT related info it would have been nice to have some kind of portal page for schemas, a portal page for rmims, one for dmims, one for cmets and so on.

Another progress killer is looking up OIDs. The HL7.org OID registry has a nice enough interface, but the Dutch vocabulary and other OID related stuff is just a pain to find. It would be ever so nice for even the HL7.org documentation to find the OID root named right at the top of the page when you drill down into the vocab. Saves a lot of hassle. Alexander Henket 21:37, 2 June 2006

fill the blanks transforms

V3 startup for implementers can be done by creating “fill the blanks” transforms.

This is very pragmatic. I'm not aware that this approach is being addressed in any of the implementation oriented Tutorial. It probably needs to be discussed, as quick-and-dirty implementation methods tend to be used more than theoretically flawless implementations... Rene spronk 12:59, 21 May 2006 (CDT)

This is how I do start-using-V3 implementation tutorials - to do this at home, get Michael Kay's XSLT Programmers Reference (and it would be crazy to even try and spell XSLT without a copy of this on your desk). It has a section on fill-in-the-blanks stylesheets. You take a fully populated message - top and tail it to turn it into a stylesheet, then replace each of the data items with <xsl:value-of ...> or the same wrapped in an <xsl:for-each ...>. This gets you to a working transform from internal XML to hl7v3 XML in very short order. At this stage you sit back and feel good. You then need to extend it with some <xsl:if ...> conditionals to deal with the bits that the example did not cover. Annother glow of achievement. Then work out what to do about the bits that the HL7v3 message needed, but were not in your internal XML. These items should have been identified as you went through filling in the blanks - with big red warnings in the output. Then you have a working output. Pat on the back from other people now, and a chance to read some more of the XSLT Programmers Reference for ideas about how to make the transform modular and do other fancy stuff. Charliemccay 04:35, 2 Jun 2006 (CDT)

Note: If you are working with XSLT you need to define an intermediate XML format for your data. This can be in "close to HL7" form or in "close to native" form. It's normally sensible to quickly export your data in a near-native format, and then encapsulate just the HL7 specifics in the XSLT. This means you can target various HL7 messages from the same intermediate file format by varying only the transform. See Implementation FAQ:Interface Development for details.

Another thing to bear in mind is that error handling is very tricky in XSL. XSLT tends to be a one-shot process that either succeeds or fails, and it isn't easy to recover from error conditions or interact with the user in the middle. It's often best to deal with any likely exceptions in procedural code when targetting your intermediate format, and do just the final rendering into HL7 in the XSLT. Rik Smithies 22:09, 7 Jun 2006 (BST)

V2 implementation profiles are easy to read

It is

What does this mean for v3 implementations? We just have to make sure v3 implementation guides are easy to read. Rene spronk 12:49, 21 May 2006 (CDT)

get some example implementation guides on the wiki

Good idea, the only ones I have on offer are however in Dutch. The use of a Realm-specific language is one of the key features of an implementation guide. Rene spronk 12:57, 21 May 2006 (CDT)