This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "RIMBAA: Infoway MBT"

From HL7Wiki
Jump to navigation Jump to search
 
Line 15: Line 15:
 
The source input is the MIF files generated for the constrained (jurisdiction localized) message RMIMs and Interactions.
 
The source input is the MIF files generated for the constrained (jurisdiction localized) message RMIMs and Interactions.
  
 +
 +
== Details ==
 +
(November 2012, from an e-mail)
 +
 +
With regards to the tooling, there are two tools in our "arsenal" that are used together as part of  larger pipeline.
 +
 +
The first one is Message Remixer: a web application that allows a user to edit the HL7 model and create what we call deltas from an input set of Model Interchange Format (MIF) files. It is a multi-user tool that allows almost all changes to be applied in the model. The output is new MIF files.
 +
 +
The second tool is Message Builder: separated into two parts, Message Builder Generator takes as input MIF files and generates a Message Set which is a simplified XML version of the input model (it reduces the current Canadian HL7 model from about 16,000 concepts to about 4,000 by removing duplication) but at the same time maintains full knowledge of the original model. The Message Set in turn is used to generate Java and C# (CLI) objects, one per model concept. Message Builder Runtime then makes use of those objects to construct, marshal and validate the HL7 XML messages. It also does terminology validation ad lookups.
 +
 +
You can get more information on both tools here: [https://infocentral.infowayinforoute.ca/3_Tools_and_solutions https://infocentral.infowayinforoute.ca/3_Tools_and_solutions]
 +
 +
We have also created an automated build process that can be kicked off from Message Remixer and creates and packages all the generated code, the Message Builder Runtime components publishes them along with the documentation artefacts (generated by GPMR, a tool built by Duane's team as part of the Everest framework) to or wiki platform, Infocentral.
 +
 +
CDA documents can be processed only if they are defined using MIF and any non-text payload is defined as a MIME type.
 +
 +
In terms of sharing, we are not currently looking at openly sharing the tools as they currently exist. Message Builder Runtime is open sourced under a commercial friendly Apache 2 license (so that our EMR vendors are  able to include the libraries in their products) but it is not of much use without the model specific classes that are generated.
  
 
==Discussion==
 
==Discussion==

Latest revision as of 08:47, 29 November 2012


In progess - not complete

Background

In Canada the standard for exchange of information is defined at the national level but each province or territory will localize based on their local constraints. The national vendors are then faced with a balkanization of the national standards. To assist is dealing with this complex environment, Canada Health Infoway contracted a company to provide a process to allow vendors to build against a single, fairly consistent programmatic interface and with simple configuration move from jurisdiction to jurisdiction.

History

The contract to build was awarded in late 2009 to Intelliware to create the tool to generate Java Jar or .Net DLL with the interface API implemented. The initial Java versions of the MBT (Message Builder Tool) were available in beta during the summer of 2010. Full versions of the Java version were reputed to be running in late 2010, early 2011. The author has been unable to confirm if the .Net version is available.

Architecture

The source input is the MIF files generated for the constrained (jurisdiction localized) message RMIMs and Interactions.


Details

(November 2012, from an e-mail)

With regards to the tooling, there are two tools in our "arsenal" that are used together as part of larger pipeline.

The first one is Message Remixer: a web application that allows a user to edit the HL7 model and create what we call deltas from an input set of Model Interchange Format (MIF) files. It is a multi-user tool that allows almost all changes to be applied in the model. The output is new MIF files.

The second tool is Message Builder: separated into two parts, Message Builder Generator takes as input MIF files and generates a Message Set which is a simplified XML version of the input model (it reduces the current Canadian HL7 model from about 16,000 concepts to about 4,000 by removing duplication) but at the same time maintains full knowledge of the original model. The Message Set in turn is used to generate Java and C# (CLI) objects, one per model concept. Message Builder Runtime then makes use of those objects to construct, marshal and validate the HL7 XML messages. It also does terminology validation ad lookups.

You can get more information on both tools here: https://infocentral.infowayinforoute.ca/3_Tools_and_solutions

We have also created an automated build process that can be kicked off from Message Remixer and creates and packages all the generated code, the Message Builder Runtime components publishes them along with the documentation artefacts (generated by GPMR, a tool built by Duane's team as part of the Everest framework) to or wiki platform, Infocentral.

CDA documents can be processed only if they are defined using MIF and any non-text payload is defined as a MIME type.

In terms of sharing, we are not currently looking at openly sharing the tools as they currently exist. Message Builder Runtime is open sourced under a commercial friendly Apache 2 license (so that our EMR vendors are able to include the libraries in their products) but it is not of much use without the model specific classes that are generated.

Discussion

Pros

  • Message validation occurs at generation time for no cost
  • Developers are protected from dealing with XML generation
  • Using the generated API on both ends of the exchange guarantees interoperability (but not working interoperability :) )

Cons

  • The variation in message implementations can be minor compared to the workflow differences from jurisdiction to jurisdiction. Workflow differences cannot usually be hidden behind an API.
  • The implementation technologies are not limited to Java and .Net
  • Many developers are comfortable generating XML
  • Examples of instances are in XML, generation of the XML instances using the API is now 'magic', the developer now has less resource when problems arise.