Executive Summary

Current processing approaches

1. GP2GP (1 message) in 2002 - R. Smithies

   1. Semantic processing

XSLT transforms converting HL7 XML into a format closer to internal database. This produced an XML file suitable for storing quickly into the local database, and was also simple and quick to generate from the local database, with minimal application processing. Since mapping would vary from message to message and between versions, the idea was to capture this logic in a transform, where it is easier to change, and easy to support multiple versions simultaneously. A basic schema validation was done to ensure the message was ok, but there is plenty of time for this in a GP2GP process (especially in a non-live pilot). Message parsing was more or less hard coded using element names (wasn’t aware that RIM-based parsing was possible).

2. Comment

This shows that, however you are actually supposed to process the message, people may do it the "wrong" way purely through inexperience. They are then stuck in that approach, for better or worse. I believe this is a key factor, both for message designers who don't know how messages may get parsed, and for suppliers who are doing it for the first time. So, partly this is failure of communication on HL7's part, and partly that it's not intuitive and people don't "get it" automatically (since whatever HL7 say, people won't always read it).

2. NHS CFH design support tool: Clinical Statement Renderer - R. Smithies

   1. Semantic processing

I avoid class names where possible and find that it works fairly well. Even if class names cannot be avoided altogether, it can help to work on structural codes first. For example, to identify all the "classCode='OBS'", do common processing first, and then process the specifics based on element name.

Recently I have written code for my own purposes, and for the message team, that processes messages. The "Clinical Statement Renderer" program aims to display any message based on CSMP, for instance to help check that example XML has in it what the developer actually intended. It's easy to design a message and put data into it. But if you stop there there is no guarantee that it's possible to get anything out of it properly.

So, by extracting the data again, the renderer helps prove that the message can hold what it is intended for. Since there are several CSMP based domains (DI, Lab, eTP, GP Summary etc) all the code in the renderer is entirely RIM based and there is no reference to any element names. It is hard coded to RIM attribute names though, since these don't change in the XML ITS, and are in effect "structural". The renderer can cope, more or less unchanged, with any CSMP type message it encounters. This is an advantage that would be lost it it used element names.

2. Comment

So, (generic) semantic processing is possible, and has been done, but my application is something of a special case.

For one thing it's not "production code". More importantly it has a specific aim of being a general purpose tool, that only knows the RIM and not anything about any particular message.

If a part of message has a specific use, that isn't conveyed by structural codes, but is only communicated in the element names (or only indicated externally, in the MIM for instance), it will display it, but has no way of knowing the specific use. I would contend that, in the context of the current methodology and ITS, such a message wasn't well designed.

CSMP style messages are themselves a special case, as to some degree they aren't processed to individual attribute level, but rather are only "translated". In other words you may not look at the meaning of a statement's act.code specifically, but instead you would just convert it to your internal database format and store it. Then your application would work on the code, as it does on any other code in its database, eg showing BP on the CHD screen. I would always hope that it was clinical codes of "BP" that got shown rather than what was called "BloodPressure" in the message.

GP systems are clinical code based, so having to map from an element name back to the "fixed" code for BP is actually a handicap. In most cases they just want to store all the codes into a single table, not caring if it's a blood pressure or not. CSA might be a special case, since it may not do filtering that requires knowing the code, it can in theory just display elements named BloodPressure.

Other messages, like PDS, are scarcely RIM processable, and I can see these would need some hard coding, or some careful use of SCT codes to allow identifying the pieces. These codes would be fixed in the message and need hard coding into the receiving app. Here there is a good argument for just using expressive element names.

Although my renderer/viewer app has a special use, that suppliers may not need for their core business processing, its still a valid thing to want to do, and it would be a shame if such a generic app was no longer feasible. Most likely a transform back to the XML ITS would be needed before using the tool on new ITS based messages. At the very least it would be desirable if this transform could always be achieved without it needing hand coding, otherwise generic tools will be useless. To make the renderer work with the new GP Summary version of the ITS, without the fixed codes, I have had to write something that processes the schemas first.

By the way I have no direct experience of Java based processing, or code generation from HL7 schemas.

3. NHS National Programme for IT Local Service Provider - I. Singh

In regards to [most of our suppliers], the processing is tied to the message definition but there is no explicit use of the schema itself to drive the processing and consequently there is no separate notion of fixed and default values. In regards to the following questions therefore:

1. whether the application uses fixed and default values (those values are indicated as mandatory attributes with fixed value in MIM 2.3)

The application does use the concept of fixed and default values but it explicitly places fixed values in relevant attributes when writing messages e.g. in classCode and moodCode attributes (and other places e.g. determinerCode)

2. whether during the message processing the schema corresponding to the incoming message is used for any reasons

The schema corresponding to the incoming message is not used

3. whether during the message processing fixed values are searched for e. g. by xPath in the incoming message

Fixed values in classCode and moodCode attributes are not used when reading messages in. However, for other attributes, this would need to checked based upon the specific attribute.

4.