Mirth Connect 4.1.1 Released!

Mirth Connect 4.1.1 is now available as an appliance update and on our GitHub page. This release contains modifications to the Welcome to Mirth Connect screen and two fixed defects. See the release notes for the list of fixes and updates.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

HL7 2.x to 3.0 transform?

  • Filter
  • Time
  • Show
Clear All
new posts

  • HL7 2.x to 3.0 transform?

    Any have any sample transforms that go from HL7 2.x source format into a HL7 3.0 destination?

    Doing one from scratch using mappings will be doable, but rather tedious. As a result, I was wondering if it might not be better to convert the 2.x into XML format, then run an XSLT against the XML to get to 3.0 format?

    If so, has anyone tried invoking XSLT from transformer javascript? If so, any examples you can pass on?

    Thanks all!

  • #2
    Re:HL7 2.x to 3.0 transform?

    Since a generic 2.x to 3.0 transform is a bit too broad a requirement, I figured I would narrow this down.

    Anyone has done such a transform for the more specific domain of Lab Results Reporting from a lab back to the ordering clinician?

    There is a lot of turmoil in this standards area with respect to 2.x vs 3.0. Message-based approaches seem to be recommending HL7 2.5.1 whereas document-based approaches are using CDA V2 (an HL7 V3.0 variant).

    Message-based is typically used to report real time results and events. Whereas Document-based is used to share clinical information typically coming from an EMR and shared with other clinicians. In this regard, message-based is a bit closer fit to lab-to-clinic results reporting, but there is a lot of overlap and either could be used.

    HL7 v2.5.1 has borrowed a lot of concepts from V3.0, and has tried to limit the interpretability by adding many more real world constraints to the spec.

    One issue is a practical one, in that 2.x is widely implemented, and 3.0 is hardly to be found in the wild.

    Then we have the 2.xml encoding. XML is very nice to use, primarily due to it's theoretically better human readability (though the CDA and 2.XML standards are hardly what one could call human readable. ;-) ) and even more so, due to the wide range of tooling available to handle (ie. parse, transform, etc.) XML.

    Ah....HL7 continues to live up to it's colloquial label as the "non-standard standard". ;-)

    Post edited by: [email protected], at: 08/29/2007 10:36