MARC-HI eHealth Blog

Here at the lab we deal quite a bit with XML Schemas and run into a few (very annoying) problems. To help these problems we developed a simple, lightweight tool for working with XML Schemas called the SchemaTool (available at http://142.222.45.21/downloads/pub/bin/schematool-1.1.exe).

Schema tool includes a few utilities that make is a great tool for looking at any schema (even if they aren’t health care related).

1. Schema Diff - Shows the structural differences between two schemas.
2. Schema View - Shows a “structural” view of any xml schema (without DTD information).
3. Schema Copy - Copies a schema and all of the dependent schemas to the specified directory (this is extremely useful for large, complex standards with lots of xs:include and xs:import where you want only one schema)
4. XPath Builder - This is a build in feature of the SchemaViewer. As you click nodes in the schema structure an XPath to the current node will be build (shortcut is right-click -> copy xpath).

Screenshot of the differencing is below:

SchemaTool Interface

We’ve been experimenting with ways of simplifying HL7v3 Models into more compact, simplified structures without the loss of any data. We are doing this as background work to better understand the challenges of the XML ITS in the HL7 version 3 standard. Assuming the MIF files as a starting point, here are the first 4 algorithms we could come up with:

1) The “recycler”

This algorithm identifies classes that seem to be duplicates of other classes in the models, removes them and replaces them with a generic version of the class. We identify matches based on the content attributes of the classes (they must be a 100% match of name and type), and we also do a simple class name comparison to improve the accuracy further. For example, if the Class B’s name is SHR_Author_Identified_Confirmable and Class C’s name is LAB_Author_Identified_Confirmable and therefore only differ by the first few characters we declare a match and substitute in a generic Author_Identified_Confirmable class. This algorithm also helps identify where more rigorous composition could have been used during the modeling phase and has the potential to be used in a design feedback cycle to improve modelling in the future.

2) “Cat-cars”

This algorithm identifies simple classes that can be rolled into their parent classes. This algorithm is probably the most controversial since we are simplifying the hierarchy at the expense of possibly altering the semantics of the model. For example if Class A was a Cat and Class B was a Car, this algorithm would create Cat-Cars, which is probably not what the modellers intended. However, there is a significant reduction in complexity of the generated code and schemas, and in the XML or IDE enviroments the resulting structures are much more understandable and simple to use.

3) The “shrink-ray”

This algorithm looks for classes that contain subclasses that only contain a single property. It replaces the subclasses with the properties themselves.

4) The “short-circuit”

This algorithm detects and collapses classes whose only purpose is to act as a structural connector to an underlying class.

We have implemented these algorithms as pipeline extensions to GPMR - our General Purpose MIF Rendering Tool, the output format being simplified XSDs. We will be analyzing some test cases in the next few weeks where we compare the original panCanadian standard XSDs vs. the ones we can generate from our tool and plan to post some results here.

Today we released a “community technology preview” edition of our HL7v3 API we call the Everest Framework to Open Health Tools. This work was sponsored by the Natural Science and Engineering Research Council of Canada and Canada Health Infoway. The version of the API we released is a messaging-oriented set of structures that map 1:1 to the panCanadian HL7v3 messages. It is intended to be used as a basis for creating higher-level APIs that encapsulate the business case functionality of the EHRS. Feel free to browse the Everest support site or contact Duane for more information on the API and how it can be used to build HL7v3 applications.

Some people have asked me what the NSERC project money is for, so I thought I would briefly describe the NSERC project here today.

The official title of the project application is “Building the Canadian Electronic Health Records Solution Reference Implementation” and I think that pretty much sums it up. If you are not familiar with the Canadian EHRS, more information can be found by heading over to the Canada Health Infoway site at www.infoway.ca (free reg required)and searching for the “EHRS Blueprint”, of which there are a few versions with different levels of detail available (if you have a hard time finding it, email me at duane.bender@mohawkcollege.ca for a direct link).

Essentially the EHRS is the provincial (or jurisdictional or regional) healthcare IT infrastructure that implements the electronic healthcare record. It contains the major repositories for healthcare data (lab results, imaging, observations, referrals, etc.). It is not a replica of all data, it is simply the “information which is suitable to be shared” between providers.

The NSERC project timeline is 5 years (2009-2014) with a staff of about 10 people involved at various commitment levels (students, faculty, project managers, etc.). The project activity breaks down into 4 main areas:

1) building a reference implementation of the EHRS “from scratch” - this will be released as open source software (BTW this was started in Aug 2007 and was about 20% complete when NSERC funding was provided to take this to completion)

2) integrating and testing common off the shelf applications and vendor solutions in the EHRS environment

3) experimenting with (optimizing and simplifying) HL7v3 messaging and protocols

4) developing an API that will allow POS applications to easily connect to the EHRS

Along with the NSERC research, our lab does contract-directed research on a cost-recovery basis, mainly for software vendors wishing to experiment in an EHRS environment. We have a public HIAL on the Internet with approximately 20% of the Canadian EHRS functionality available. Above the HIAL we have many vendor applications that can be deployed for specific testing scenarios.

If you have a project inquiry, please feel free to contact me directly duane.bender@mohawkcollege.ca

http://www.cbc.ca/health/story/2009/05/27/f-electronic-health-records.html

Mohawk College today received $2.3 M from the Natural Sciences and Engineering Research Council of Canada to continue the Applied Research project around the prototyping of the Canada Health Infoway EHR Blueprint. The money will provide sustainable funding to operate our lab for 5 years.  

Here is the official release from NSERC:

http://www.nserc-crsng.gc.ca/Media-Media/NewsRelease-CommuniqueDePresse_eng.asp?ID=143

For the second year in a row, we participated in the Interoperability Showcase at the Canadian eHealth Conference. This year’s show was in Quebec City the week of June 1st to 3rd 2009.

The Mohawk EHRS reference implementation acted as the HIAL for one of the jurisdictions in the show. We successfully interconnected POS applications (AbelSoft, Practice Solutions, Intelliware) DIS applications (DeltaWare), Client Registry infrastructure (Initiate Systems), clinical terminology systems (3M Health Data Dictionary), Health systems management applications (Canadian Institute for Health Information - CIHI), EHR Viewer applications (ORION Health), remote chronic condition monitoring (American Telecare), telehealth portal (NEXJ Systems), scheduling (iScheduler), security and audit systems including our ATNA message sink and forwarding service to HIPAAT and IBM. We also ran the HIAL activity display (the “Visualizer“).

The Visualizer is taking on a life of it’s own - there has been a good deal of interest in using it in a “real” jurisdictional system. We are currently working with one province to find out if this is feasible.

Welcome to the Mohawk College MARC-HI eHealth Blog. I am your host, Duane Bender.

Here we will discuss the technical side of eHealth, HL7 version 3, IHE and other eHealth systems, based on our day to day experiences in our research lab. We hope that this will provide some value to the implementers of eHealth standards in Canada and around the world.

I also reserve the right to post articles around software engineering in general, C#, .NET, Java, SOA, ESB, etc.