|
|
| (18 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| − | 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]]. | + | There are a considerable number of implementations of HL7 version 3 based on a [[Development Edition]], a [[Normative Edition]] (e.g. 2010) or a Project Specific Edition (e.g. the NHS). This document aims to describe the most important lessons learned from these implementations, as well as some of the frequently asked questions related to the implementation of HL7 version 3. |
| | | | |
| − | As with all FAQs some of the questions or responses may sound "obvious" to you; this may not necessarily be true for other implementers. | + | As with all FAQs some of the documentation provided on these pages 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:
| + | Note: parts of this FAQ are currently (November 2010) undergoing major changes/updates. |
| − | *[[Implementation FAQ:Implementer Organization|Implementer Organization]]
| |
| − | *[[Implementation FAQ:Interface Development|Interface Development]]
| |
| − | *[[Implementation FAQ:Interface Deployment|Interface Deployment]]
| |
| − | *[[Implementation FAQ:Framework Issues|Framework Issues]] (national/regional infrastructures)
| |
| − | *[[Implementation FAQ:Migration from version 2|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.
| + | This FAQ is organized into a number of categories, mainly in order to limit the size of the individual pages: |
| − | | + | *General: |
| − | ----
| + | **[[Implementation FAQ:Getting started|Getting started]] (getting to know the HL7v3 standard; education; resources) |
| − | | + | **[[Implementation FAQ:Implementer Organization|Implementer Organization]] (organizational recommendations for v3 implementer organizations) |
| − | | + | *Localization: |
| − | == Source and target systems lack rich semantics ==
| + | **[[Implementation FAQ:Localized specifications|Localized specifications]] (localizing the HL7 v3 standard) |
| − | Black and white TV to HDTV to black and white
| + | *Implementation: (architecture and design) |
| − | :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. [[User:Rene spronk|Rene spronk]] 06:21, 26 May 2006 (CDT)
| + | **[[Implementation FAQ:Interface Development|Interface Development]] (software implementation) |
| − | :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. [[User:Charliemccay|Charliemccay]] 04:06, 2 Jun 2006 (CDT)
| + | *Deployment: |
| − | :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. [[User:Rik Smithies|Rik Smithies]] 16:41, 7 Jun 2006 (CDT) | + | **[[Implementation FAQ:Interface Deployment|Interface Deployment]] |
| − | | + | *Special topics: |
| − | == version 3 documentation not as easy to use as V2 documents ==
| + | **[[Implementation FAQ:Use of Transports with HL7 v3|Use of Transports with HL7 v3]] |
| − | 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.
| + | **[[Implementation FAQ:Framework Issues|Framework Issues]] (national/regional infrastructures) |
| − | :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. [[User:Rene spronk|Rene spronk]] 12:46, 21 May 2006 (CDT)
| + | **[[Implementation FAQ:Migration from version 2|Migration from version 2]] (e.g. mapping) |
| − | | + | **[[Implementation FAQ:Encryption and Security|Encryption and Security]] and [[Implementation FAQ:Digital Signatures|Digital Signatures]] |
| − | 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.
| |
| − | [[User:Alexander.henket%40enovation.nl|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... [[User:Rene spronk|Rene spronk]] 12:59, 21 May 2006 (CDT)
| |
| − | ::This is how I do start-using-V3 implementation tutorials - to do this at home, get [http://www.amazon.com/gp/product/0764543814/103-2866471-7042209?v=glance&n=283155 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. [[User:Charliemccay|Charliemccay]] 04:35, 2 Jun 2006 (CDT)
| |
| − | | |
| − | :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.
| |
| − | | |
| − | :You also need to decide which parts of the end to end data processing are done while your application creates the intermediate XML and what is to be done afterwards in XSLT. Some tasks are better handled by traditional compiled languages. Converting between coding systems, for instance, needs large datasets and not well suited to XSLT. You should probably convert clincial codes (eg. from UK Read code to SNOMED CT) using your application code or stored procedures. Conversion of dates to HL7 formats can be done in XSLT but it is fiddly and may be slower than converting at the point the data is written to intermediate XML. Aim to produce an intermediate XML that is suitable for restructuring into HL7, but that no longer requires a lot of complex processing.
| |
| − | | |
| − | :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. [[User:Rik Smithies|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. [[User:Rene spronk|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. [[User:Rene spronk|Rene spronk]] 12:57, 21 May 2006 (CDT)
| |
