|
|
| Line 9: |
Line 9: |
| | *Localization: | | *Localization: |
| | **[[Implementation FAQ:Localized specifications|Localized specifications]] (localizing the HL7 v3 standard) | | **[[Implementation FAQ:Localized specifications|Localized specifications]] (localizing the HL7 v3 standard) |
| − | *Implementation: (software architecture and design) | + | *Implementation: (architecture and design) |
| − | **[[Implementation FAQ:Interface Development|Interface Development]] | + | **[[Implementation FAQ:Interface Development|Interface Development]] (software implementation) |
| − | **[[Implementation FAQ:processing v3 schema with standard tools|Processing v3 schema with standard tools]] (standard tools FAQ)
| |
| | *Deployment: | | *Deployment: |
| | **[[Implementation FAQ:Interface Deployment|Interface Deployment]] | | **[[Implementation FAQ:Interface Deployment|Interface Deployment]] |
| Line 17: |
Line 16: |
| | **[[Implementation FAQ:Use of Transports with HL7 v3|Use of Transports with HL7 v3]] | | **[[Implementation FAQ:Use of Transports with HL7 v3|Use of Transports with HL7 v3]] |
| | **[[Implementation FAQ:Framework Issues|Framework Issues]] (national/regional infrastructures) | | **[[Implementation FAQ:Framework Issues|Framework Issues]] (national/regional infrastructures) |
| − | **[[Implementation FAQ:Migration from version 2|Migration from version 2]] | + | **[[Implementation FAQ:Migration from version 2|Migration from version 2]] (mapping) |
| | **[[Implementation FAQ:Encryption and Security|Encryption and Security]] and [[Implementation FAQ:Digital Signatures|Digital Signatures]] | | **[[Implementation FAQ:Encryption and Security|Encryption and Security]] and [[Implementation FAQ:Digital Signatures|Digital Signatures]] |
| − |
| |
| − |
| |
| − | 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 they 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. [[User:Rene spronk|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. [[User:Charliemccay|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. [[User:Rik Smithies|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. [[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.
| |
| − |
| |
| − | 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)
| |
| − |
| |
| − | 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. [[User:Rik Smithies|Rik Smithies]] 22:09, 7 Jun 2006 (BST)
| |
| − |
| |
| − | ::You can get around using XSLT by using template engines, in particular if you want to fill in the blanks directly from your domain model and not from a intermediate XML format. The principle is the same, you just don't use <xsl:> tags but the ones provided by the template engine, which often supports OGNL syntax. I made good experience with [http://velocity.apache.org/ Velocity] (Java specific), that also supports all kind of control statements, loops, ifs, and extensions e.g. in order to fill in the current timestamp. And, you can use the same mechanism to create v2 messages, as its not restricted to XML in any way.[[User:Christian.ohr|Christian.ohr]] 05:46, 22 September 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. [[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)
| |
| − |
| |
| − | Another option is a collection of [[Implementation Guides|implementation guides]] including links the specifications.
| |
