Difference between revisions of "Implementation FAQ"
Line 24: | Line 24: | ||
: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) | :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) | ||
− | 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. [[User:Alexander Henket|Alexander Henket]] 21:37, 2 June 2006 | + | 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|Alexander Henket]] 21:37, 2 June 2006 | ||
== fill the blanks transforms == | == fill the blanks transforms == |
Revision as of 20:00, 2 June 2006
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.
Contents
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)
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)
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)