Common Message Element Types

Common Message Element Types (CMETs) are used in many HL7 messages. They encapsulate common "chunks" of messages so that they can be reused. It can be useful to know which message element types are used in the message so that you understand what all the "chunks" are and whether they apply to the transport wrapper, the control act wrapper or the payload. But how do you know which CMETs are used in a message? Let's say that you are working with all the volumes of the pan-Canadian MR2009 standard. You could just open a schema (*.XSD) and look at the include statements. But the problem is that you don't get to see what the included XSDs include, so you have to open those, and then open the their includes and so on. This is time-consuming, awkward and confusing. If you have access to an XML development environment such as Altova XMLSpy or Oxygen, you can open up a schema, and all the child schemas are opened for you. Some of these child schemas will be CMETs. Both tools have a kind of structure-browser that allows you to see what's included and see where a CMET is referenced. So you might start with a CMET such as COCT_MT090502CA (R_AssignedOrganization identified-confirmable) and see all the interactions where it is used. One of the problems with this approach though is that you don't know whether the CMET has been used in the transport, control act or payload portion of the message. To find out which CMETs are used in payloads, you need to look at the XML files provided as part of the Visio models. These XML files include the attribute "CMETid" and if you search for that attribute you can find out which CMETs are used in the payload. You are still left with the issue of checking whether a referenced CMET includes other CMETs or not. You should also be aware that some models include several CMETs.

Some pan-Canadian Tooling

One of the things that has been a bit of a challenge with the HL7 v3 standards is that the learning curve is quite steep. There is a WIKI up now https://emri.infoway-inforoute.ca/ that discusses some tools to help with this process. You can request access to more of the WIKI from the start page.

Infoway Fall Partnership Conference

The Infoway Fall (2011) Partnership conference was well attended with a focus on innovation. There were some great presentations, and the tools to help one create correctly localised versions of national messages and generate Java (or .Net) APIs from them were demonstrated. Information about these tools is available publically: https://emri.infoway-inforoute.ca/Products

Interesting Musings

There have been some interesting musings on HL7 v3 recently on this site: http://www.healthintersections.com.au/?p=476#comment-574 . I don't think you can say whether HL7 v3 is successful or not just like that - there's a gradation obviously - but the comments are really interesting.

How about this for an unconventional idea though? If two parties agree to use exactly the same HL7 messages - in other words the over the wire format for a given interaction is agreed completely - then both sides have a template with placeholders for variables. So in this case really all you need to send is the delta. The full sent message and the expected full received message are the same except for the items of information. So if we consider that full message a template, then one could mark out where variables a,b,c etc would be expected. If you know that, then you might be able to send just the variables and not all the surrounding message infrastructure since the receiving party already has it.

The NHS in the UK is considering abandoning its centralised storage of eHealth records. See the Parliamentary report. There's a news article here about it.

Null flavours

The convention is Canada is to expect applications to capture null flavor only if the minimum cardinality is greater than 0.
So if it's Required, you don't have to do anything.

Canada's latest maintenance release V02R04.01

Here's a summary of significant changes in this latest delta release (June 2009):

• MIF 1 and MIF 2 files have been published for Volume 1 (Infrastructure)
• Voc.xsd has been republished
• Schemas missing from V02R04.0 were included in Vol 3 (Shared interactions)
• Client Registry MIF and schemas for PRPA_MT101106CA were regenerated.
• Provider Registry MIF 2 – regenerated all MIF2 and schemas.
• Location registry (vol 6) – regenerated all MIF 2 & Schema interaction files.
• SHR (Vol 7) – REPC_MT000005CA regenerated (duplicated “SubjectOf1” problems); REPC_IN000001CA changes; MIF 2 & schemas regenerated for these.
• Pharmacy (Vol 8) – All MIF 2 & schemas regenerated.
• Lab (Vol 9) – Only MIF 2 regenerated. Presumably MIF 1 files are OK.
• Claims (Vol 12) – MIF 2 interaction files regenerated.
• Record access (Vol 13) – all MIF 2 regenerated. Schemas for COMT_MT400001CA regenerated.

Message exchange patterns

Send Message, No Response:
- One-Way MEP
Send Message, Immediate Response:
- Request-Response MEP
- Response can be Application Ack, Application Response (Query)

Send Message, Deferred Response
- Two One-Way MEP
Send Message with both Immediate and Deferred Responses
- One Request-Response MEP and one One-Way MEP between receiver and sender

Rene Spronk, January 2008 "HL7 Implementation Mechanics"