HL7 version 3

Infoway Fall Partnership Conference

2011-11-29T11:42:00.001-08:00

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

2011-08-30T09:51:00.000-07:00

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

2009-06-09T11:23:00.000-07:00

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

2009-06-08T17:44:00.000-07:00

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

2009-06-08T14:14:00.000-07:00

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"

Lab Microbiology/generic/Pathology Model rationale.

2009-06-05T15:49:00.001-07:00

Louise writes:
Just to give a little background: The reason we developed the Micro and AP patterns (which are derivations of the Generic Model) was primarily so we could more tightly bind vocabulary to the business purpose.

During the development process, we created a discussion paper to determine the most appropriate approach and this is where we landed. In addition, we also have documentation to identify what the impact would be if an implementer was to attempt to use the Generic Result pattern to send Micro and/or AP results. I will dig these up as I think these are critical to any decisions going forward regarding a potential 're-evalution' of the original approach for AP.

June 5th 2009

Query parameters

2009-06-05T15:39:00.001-07:00

1) When multiple query parameters are specified (e.g. a collection date and a specific test/observation) then, I assume the parameters are "AND". I.e. query for result records where patient ID=12345 AND the collection date is 01Jan-15Jan AND the ordered test is a Hemoglobin.
- This is true

2) When a query parameter allows a list (e.g. ObservationCode allows 0..100) this is an "OR". (e.g. query for result records where patient ID=12345 AND collection date is 01Jan-15Jan AND (observationCode=hemoglobin OR observationCode=WBC OR observationCode=PT)
- This is true

WSDLs for HL7 v3 messages

2009-06-04T11:07:00.001-07:00

In the future we may start to publish WSDLs, or at least "WSDL templates". (The specific WSDLs will of course vary by jurisdiction as each HIAL will have their own base URLs.) SCWG 6 is working on a specification called Transport Level Interoperability that formally defines the expectation for pan-Canadian WSDLs, among other things. You can find information about it in a sub-folder on the discussion forum. There are also weekly TLI calls on Wednesdays. (Check the 'meetings' folder for dial-in info.)
Writes Lloyd in SCWG#6, May 25th, 2009.

xsi:nil="true"

2009-05-20T08:19:00.000-07:00

I can't find an authorative source on the use of xsi:nil vs. nullFlavor in HL7v3.

The ITS 1.0 only mentions that xsi:nil is allowed.

From what I've browsed on various lists, wiki, Google etc. I've come to the following picture: if some_element is declared with nillable="true" in it's schema, the following is allowed:

and is equivalent to:

and to:

is that correct?

And if minOccurs="0", are the three above equivalent to absence of some_element in the instance?

Finally, is also allowed?

Regards,

Marc
Grahame Grieve:

| Agree with Charlie except there is no need to use xsi:nil on the
| datatypes And it should not be done

I agree it would have been better if the form had never been allowed; but if a spec is out, and not very clear on the issue, there's no way to retrospectively disallow it. I guess all we can do in NL is to discourage it, maybe phase it out; but there's no way it can be suddenly illegal.

Cheers,

Marc
From the HL7 ITS lists 20th May 2009.

voc.xsd

2009-04-17T08:59:00.000-07:00

The Voc.xsd file shipped with Canadian standards contains all the concept domains for vocabulary used in the schemas, but it also contained an awful lot more until MR2009. In MR2009, the HL7 inc values were finally excised to leave those concept domains used in Canada.

Lloyd on Schematron and validation

2009-03-10T09:20:00.001-07:00

Lloyd McKenzie wrote:
Hi Adam,

The philosophy the MIF has taken thus far is as follows:
- If you can put a rule in the schema, do that. Schema rules can be enforced by editors on the fly, used for type-ahead, used for code-generation, etc. They're also easier to write and to get right.
- If you can't put a rule in schema, put it in as an x-path expression in schematron. At least those can be easily invoked on XML instances
- If you can't express the rule in an X-path (e.g. URLs must resolve to a live link, no recursion allowed in code system hierarchies, etc.), then document it as a comment for software developers to implement in code.

We can use schema as well as XSLT/Schematron in the publication validation process, and I can't see any reason why we wouldn't always do both. Even if the schema wasn't customized, we'd still want to do schema validation to confirm that it's legal XHTML. Moving all validation into Schematron is crazy. You can enforce element order, nesting and most type definitions far easier with the schematron language than you can with XPath.

I recognize that "as you type" validation is hard. I'm not sure it's fair to say it's impossible. However, it may be more expensive than is reasonable to implement. That said, we want to get as close to "as you type" validation as we can. Anything that's easy to customize in whatever WYSIWYG XHTML editor that allows us to more closely approximate the rules in the MIF, we should do. For the rest, I agree that a "validate" or "verify" button is reasonable. It would also be good if you couldn't actually close/leave the window or apply changes so long as there's an outstanding validation issue. However, I'm not clear on why the validation process couldn't (or shouldn't) use all three validation approaches - schema, XSLT and code.

Schema validation can be performed in an Ant script. Changing the schema isn't an issue. MIF schemas change regularly. Though the markup schema is unlikely to change much if at all (either the schema, schematron or programatic rules). I recognize that when schemas change, this may mean changing software. However, when anything in the MIF changes, it may mean changing software. How the rules happen to be encoded shouldn't impact whether software change is necessary or desirable. I'll admit that w3c schema validation messages aren't as human readable as schematron rules, but that's a small price to pay for direct support in XML validation tools, code generation, type-ahead, etc. And schema validation can be (and currently is) applied in batch just like XSLT validation.

I'm not arguing against external validation. We currently have, and will continue to use, external validation during the publication process for various reasons including those you mentioned (external references that can't be known at design time, custom tweaking by users outside of the UI, tooling bugs, changing rules, etc.). However, we also want as much validation as humanly possible to be done at design time. Every error that's caught within the authoring process is an error we don't have to deal with in the 5 days between final content submission and ballot opening.

On some of your other points:
- We specify maximum lengths on everything so that from a user-interface, data storage and software design perspective, we know what may be enountered and can write code accordingly.
- Id references are for things like referring to tables, figures, graphics, etc. from elsewhere in the fragment. And our source materials don't currently use GUIDs. Seeing as some of the source materials are hand-authored, they shouldn't be required to use GUIDs. And because multiple XHTML fragments from multiple sources may be combined in a publication instance, we can only ensure uniqueness within the fragment, not a whole document.
- In the cut and paste scenario, the "accept what they pasted and report it in the error report" is definitely the least desirable of the options. We don't want users submitting invalid content. We don't have the bandwidth to fix content on their behalf. If they decide to use a different authoring tool and copy and paste, then they have the responsibility for getting that content clean. It is not the responsibility of HL7 HQ or the publishing process. In the event that bad content does sneak through, it's just going to get kicked back to the author anyhow. May as well get it right the first time.

Lloyd
March 10th 2009

First HL7 International Conference in The Netherlands

2009-01-21T21:08:00.000-08:00

HL7 Conference, Noordwijkerhout, The Netherlands

Friday, Saturday April 29th, April 30th

The May working group meeting for HL7 International is taking place outside north America for the first time this year.

Sierra sent me along to find out what was going on and to contribute to the working groups.

It was nice to be back in Britain again after quite a long time away. It was nice to see that everyone was still comfortably miserable, (as evinced by a chap who, as he ran over the foot of the lady sitting next to me in the meeting room, said "I told you twice to move your bag!"); and that Heathrow airport is still a vast maze of confusion both for passengers and for the staff who work there. There may be something about the acronym of the British Airport Authority that is important here.

I left one area which had a left arrow for international flights and a right arrow for local flights, only to find that they joined up immediately to go down a flight of steps....

I managed to go through passport control without meaning to - there was really no way to avoid it - but finally edned up at the right place to catch a flight to Amsterdam. Through the departure gate we went, down a long slope and onto - a bus! Yes, having been transported by bus from one terminal to another, we were now treated to a bus trip that took us through the Dickensian underworld of Heathrow airport, finally arriving on the tarmac just behind the jets of an Airbus A320!

On the flight were Helen Stevens, Leon Salvail and Bob Grant. We travelled through the airport together, and marvelled Dutch efficiency as the wheelchair Leon borrowed had holders for crutches. When we entered an elevator however, a buzzer went off that told me to leave my cart behind, which I duly did. Then we were puzzled because it went off again. Was it Leon's crutches? No. Step out Bob. It was Bob! Bob had triggered the clever Dutch cart detector. Bob took the stairs. I hope he doesn't take it personally.

We rented a car and all four of us drove out to Noordwijkerhout (pronounced roughly Nord-vike-er-out - no spitting allowed). In the conference brochure, the location for the conference in the Netherlands had been rather glibly described as "Amsterdam" when in fact Amsterdam is an hour or so away by car.

Saturday, Sunday, April 30th, May 1st

On Saturday evening, after a nap, I went into Amsterdam and observed the Koninginsdag festivities - the Queen's birthday. It was very busy in Amsterdam, but pleasant enough to walk around, stepping over beer cans, and Dutchman full of the contents of the empty cans.

Sunday - The Canadians met together in the evening, and discussed which working groups we would attend. Who's who? From left to right: Alexis Grassie, ?, Grant Gillis (HL7 Canada), Bob Grant, Leon Salvail, Louise Brown, ?,?,?,?, Llloyd Mackenzie, Michael van Campen, Garry ?

Also, not in the picture, was someone I met at lunch who lives in Charlottetown and works for Kodak. There was a "Connect-a-thon" at the hotel immediately prior to this conference.

Monday, 2nd May

After attending a first timer's meeting at 7:30am, I went to the main session where there was an overview of the H7 international. Interestingly, there were 19 Canadians at the HL7 Conference, and only 10 from Germany and 12 from France. The vast majority of attendees were Americans.

Most of the day was spent in the Control/Query working group. We started off working through some outstanding comments on ballott material. There was a very long discussion on versioning, and I think everyone realised that there was a lot of work to be done to figure out what was to be versioned, and how that versioning should be represented in messages.

Tuesday 3rd May

I had breakfast with a group of people, including Rene Spronk, who were discussing why HL7 International is contemplating shipping a snazzy CD with the latest ballot material on it. They came to the conclusion that there was no point in shipping it at all for the content; it was just a stunt, and therefore required eye-catching artwork, to be left on a coffee table somewhere.

Control/Query had a joint session with Personnel Management, so we had Leon, Bob, Louise Brown and a few other familiar faces there. The discussion centred around how we should define registries, repositories and master files. It didn't seem crucial to me box all systems in, and of course, Wittgenstein would say, "It's a registry, if you say it is - look at the use." So we decided that there was a spectrum, not three tight boxes, and that the discussion was only valuable as glossary material, having no technical impact.

In the second quarter, we talked about web services, and were dealing with some negative comments. There was an outstanding negative comment about the fact that HL7 is apparently favouring proprietary work.

In the third quarter, I attended a session by John Quinn, in the Process Improvement Committee, where he gave an overview of the process for ballots, voting, and membership. He discussed the differences between version 2 and version 3, and the motivation for moving to version 3.

One thing I learned was that usually only members can vote, but that sometimes there are public votes in which anyone can vote.

There was a shorter session in the fourth quarter for the Control/Query Working Group, where the Security SIG came and presented some of their work. They seemed to be tackling some of the same issues as the CQ committee, and so a motion was passed so that the Web services security work in CQ (WS-Security) can be jointly undertaken with the the Security SIG.

In the evening, NeoTools had organised a party in Amsterdam, but rather than committing myself to a very late night, I preferred a slightly quieter pursuit of renting a bicycle at the hotel and cycling through the local villages. It was really pleasant to be out on the bike and not have to fight any traffic. Bike paths are everywhere - clearly signed, and often with their own traffic lights.

Wednesday 4th May

In the morning I went to the Modelling and Methodology (M & M) session and listened in as the Security SIG people made another presentation. It seems to me that they have an uphill battle. They are trying to capture enough information to formalised Role Based Access Control (RBAC), but there are issues about the granularity of the information they are capturing, and even then, the information relates only to operations and objects, such as "read Patient Record." What about restrictions on data elements in the objects? They are going to produce something for the next ballot cycle (September), so this is something worth watching.

I stayed with M & M for the next session, and chatted to Jane Curry (former Sierran from Edmonton) for a while. This session was all about conformance, and, as usual, the group worked through the finer points of negative material.

In the final session, I moved back to Control Query, where version 3 conformance issues were being discussed. We spent a long time discussing how to represent units of measure such as a "puff," which is used in many hospitals. There isn't a convenient way currently to represent this information since it needs to be tied to a particular medicine that is released at a certain rate from a certain container.

There was also a discussion on "messy datatypes" : CS (Character Set), Media-Type, and URL Scheme.

Tomorrow is Liberation Day, and the Dutch hold a two minute silence in the evening in remembrance of those who have died in the second world war. The HL7 conference took part in this remembrance this year at a reception held at the famous Keukenhof gardens. We had a guided tour of the gardens, which are still beautiful with tulips and a few brave daffodils. Then we had the two minute silence, and dinner.

I got talking to quite a few people, including one chap from Quovadx. He told me that "Cloverleaf" is alive again - that is now their product name, after three products were merged.

Most of the people that I talk to here are highly skeptical of any straightforward route towards implementation of version 3. Most believe that it will take significant time and work to get two systems to exchange messages reliably!

Here's another funny thing: Everyone has a laptop, but almost everyone with a laptop is hammering away on the keyboard and not participating in the discussions!

Thursday 5th May

This morningI abandoned Control Query in favour of a joing session hosted by the EHR Technical Committee, Vocabulary and Patient Care. There was a summary of work done with the US National Library of Medicine to produce an implementation guide and to produce a respository of vocabulary. The vocabulary project is going about its business by collecting as many existing vocabularies as it can and synthesising.

There was a fascinating overview of projects and countries that are using HL7 v3. A fairly substantial list was winnowed down to about eight participants, and these participants are just beginning to provide a great deal of information. The foremost project appears to be in Finland, where there is now an extensive network of hospitals and health authorities sharing data with HL7 v3. Also selected was a project in Spokane, Washington, which although fairly local, is apparently making widespread use of version 3. Canada's e-MS project was on the list, but not selected for in depth study. The UK's NHS project was also on the list, but also not selected - apparently because it was too huge and too broad in scope that it would be difficult to target the study the questionnnaire to the right people.

The chap in front of me was ignoring all this interesting information and typing up a powerpoint slide entitled "Objective of Cooperability", whatever that is.

For the second quarter I dropped in on Leon and Bob in Personnel Management to see how they were doing working through their harmonisation proposals. The tempo seemed a little different than most of the rest of my week at Control Query; each Teechnical Committee is more or less formal it seems. One item under discussion was the addition of OrganizationEntityType. This is currently not in the Reference Information Model (RIM), but no one was sure exactly what was in the RIM. The action item was therefore to clarify this.

For the third quarter, I returned to Control Query, where abstract data types were under discussion. The most interesting discussion here was that there is a bit if in-fighting at the international level because the HL7 committee appears to be in a tussle with the European standards organisation about which data types to use. Australia is disappointed about this in fighting, and has threatened to withhold support for either, and develop its own datatype standards unless the Americans and Europeans sort themselves out. The chairman, an American, used a word that I have so far only heard my Indian colleagues use: "updation." Perhaps that word is creeping into general use.

On Thursday evening, there was a Facilitators roundtable. All the Technical Committees were present, and they each gave a summary of current issues that needed the attention of the HL7 Board. Most of the issues brought forward resulted in action items for one Technical Committee to converse with another. There was a lot of discussion about overlapping CMETs and Data types, and the issue of versioning was raised again.

Lloyd Mackenzie gave a tooling update. There is a Visio tool, a RoseTree tool, and a v3 Generator tool. The last tool is the most interesting. It generates the "Model Interchange Format" which is not, as the name suggests, for exchanging Models. It is actually a representation of everything that HL7 knows about: vocabulary, DMIMs, datatypes, interactions and so on. With the MIF format, one can generate schemas or do other work. MIF is rapidly becoming the representation format for HL7 artifacts.

Because there is such a lot of work to be done to create reliable tooling, the HL7 Board has announced a full time paid position for a Tooling Support person. There is another tool in the works, and that is an HL7 MIF to UML translator.

So that was about it.

Friday Morning, 6th May

All in all a very successful conference. I had breakfast this morning with the CQ crowd, and we talked more about MIF format. Graham from Australia seems to be the most knowledgeable here. I now have a foundation of face-to-face contact on which to build. When I post to the CQ list, these people will at least know who I am.

Conformance strengths

2009-01-09T16:28:00.001-08:00

Each data type property identifies whether and how that property is expected to be supported. Possible values, noted in italics in the data type specifications, are:

1. Not Permitted The property must never appear in an instance. Applications may raise an error if they receive it.

2. Optional The element may be supported by applications if they choose (and they must declare their decision in their conformance statement). If not supported, the element must be ignored if received. I.e. Applications MUST NOT raise an error upon receiving an unsupported optional element.

3. Required The property must be supported by all applications (they are able to capture and/or display it), but won’t necessarily always be present in an instance.

4. Populated The property must be supported (able to be captured and/or displayed) and must always appear in the instance, but may appear with a flavor of null.
The term 'populated' is not an official HL7 conformance strength. It was used in Canada to differentiate

Required 1..n (where a value must be supplied but can contain a flavour of null) from

Required 0..n (where no value need be supplied).

5. Mandatory The property must be supported and must always be present with a non-null value.

In general, if an attribute (or data type property) is not available (i.e. cannot be valued), then the rest of the data type properties (mandatory or not) should not be present. Exceptions to this rule will be documented in affected data types (e.g. CD).

HL7 v3 international datat types spec.

2009-01-09T16:22:00.000-08:00

The datatypes spec has recursive defintions at the abstract level:
Radov, Nick wrote on the INM HL7 list:

I've been reviewing the V3 data types and am puzzled by the definition of equality for ED http://www.hl7.org/v3ballot/html/infrastructure/datatypes/datatypes.htm#prop-ED.equal. It states that "Two values of type ED are equal if and only if their mediatype and data are equal." The mediaType property is a CS. And CS includes a code property, which is an ST. ST is a specialization of ED, and now we're back where we started. It seems like it would be impossible to implement the ED equality algorithm as specified since that would lead to infinite recursion. Is that intentional or an error in the spec?

The abstract types are included in the XSDs though and this will cause trouble. Not impossible to deal with but not so nice.

HL7 international batch messages

2009-01-08T10:32:00.000-08:00

Rene Spronk writes in lists.hl7.org INM list:
The Batch material has never gone normative, it is still awaiting the outcome of the Wrappers R2 project/effort.

See http://wiki.hl7.org/index.php?title=Batch_Topic_DSTU_R1_Issues for issues related to the interpretation of Batch that haven't been included in the material yet.

Note that the InM decision that a Batch Wrapper does NOT constitute a transactional grouper (which it was in v2) is a major one. A Batch is a grouper for Transmission purposes only.

If you need a transactional grouper (= something you reject as a whole because one of its component interactions has an error) you'll need to deal with that at the controlAct wrapper, e.g.through nested controlActs (something that isn't available at this point in time).

Batch messages

2009-01-08T10:28:00.000-08:00

Batch messages in HL7 are created with a wrapper of HL7 interactions.

xsi:nil

2009-01-08T10:26:00.000-08:00

From the HL7 lists:
Xsi:nil is what allows you to exclude mandatory class attributes and associations when you declare a parent association as “null”. For example, assume you have a patient role with a 1..1 non-mandatory association to playing person which in turn has mandatory attributes name and date of birth.

In schema, you’ll end up with a 1..1 “nillable” element called PlayingPerson which in turn has 1..1 non-nillable elements for name and birthTime. If for some reason the person information is unknown, the instance would send the playingPerson element with an attribute of xsi:nil=”true”, nullFlavor=”UNK”, and no child elements. Normally, that would be a violation of the schema because both name and birthTime have a minimum cardinality of 1. However because xsi:nil is set to true, the schema validator essentially “skips” validating the contents of the nil element, which is what you want.
- Lloyd Mckenzie writes.

All non-mandatory associations should therefore be declared as nillable. (We don’t do the same thing with datatypes because none of the datatype properties have a minimum cardinality of 1 in the schema.)

datatypes-base.xsd

2008-10-01T14:21:00.000-07:00

The definintive version of datatypes-base.xsd is March 19, 2007 at the UV level. In Canada we have a slightly different version but I think this will change and we will align with HL7 Inc's UV version.

Canadian Datatype flavours

2008-09-29T14:53:00.000-07:00

For many datatypes, Lab is proposing the use of particular datatype .Flavors. which are named
constraints on datatypes. These Flavors are generally referenced directly within the pCLMN
specification. There is presently discussion within HL7 about how to represent in an instance what
Flavour of a datatype is in use (as a parallel to xsi:type which identifies the international datatype in use).
This mechanism will be used within Lab instances once defined and approved at the international level.

The mechanism for for flavours is the attribute "SpecalizationType" which shows the flavour, such as "II.PUBLIC" as a concrete type derived from the abstract "II" type.

How the HL7 tooling works

2008-09-26T18:44:00.001-07:00

"Empty" 'required' associations collapse into mandatory booleans in the Word view. The presence of the association constitutes true, the absence constitutes false. The business intention is a boolean that indicates whether the issue will be stored or not. However in HL7, this is represented by the presence or absence of an association.

Notification messages in V3

2008-09-24T13:46:00.001-07:00

Do notifications require an application response?
The storyboards show notifications having a response, but in fact notifications never have a receiver responsibility. It falls to transport whether you need to issue and accept acknowledgments.

MIF Schemas

2008-09-05T09:53:00.000-07:00

The MIF files that have been published historically are MIF 1.1.

MIF 1.1 release hasn't been published for quite some time and there have been fixes to MIF 1.1 in the last 3 years. To see the most recent, you'll need to go to the source control tab to grab the most current schemas.

2.1.2 is the most current release of MIF 2. It's what is/will be used with the Instance Editor and which other tools are migrating to use. If you're building tools, I'd recommend using that release.

- From Lloyd M

Sending Fixed values – comment by Jean Duteau

2008-09-05T08:46:00.001-07:00

In Nunavut, where they have high latency issues due to being a satellite network for internet, (and I would assume that Newfoundland might have some of these issues), the jurisdictional apps might decide that leaving out the fixed fields is a good way to reduce the size of the messages. So they might come to agreement with their POS vendors that none of them will send nor validate the fixed fields.

So I think the best we can do is the rules that I stated earlier:

Transmitters should send fixed fields for greatest compatibility.

Receivers must not error if a fixed field is not sent.

Receivers must error if a fixed field is sent and is not correct.

Transmitter and Receivers are allowed to agree on a fixed field policy that is different than above, if circumstances warrant.

Jean Duteau

A note on Z segments

2008-09-01T11:41:00.000-07:00

Z-segments are site specific segments defined by a vendor or implementation to include information that is not otherwise included in the messages being used or, in some cases, to replace existing information in a more desirable format or structure. These segments can only be understood by other systems with a detailed implementation guide for the site or system where they were created.

From an Infoway Standards Adoption paper on HL7 v3

ControlActReasonCode

2008-08-25T09:44:00.001-07:00

The ControlActReasonCode identifies why a specific query, request, or other trigger event occurred

Values for status of properties

2008-06-10T15:31:00.001-07:00

1. Not Permitted The property must never appear in an instance. Applications may raise an error if they receive it.
2. Optional The element may be supported by applications if they choose (and they must
declare their decision in their conformance statement). If not supported, the element must be ignored if received. I.e. Applications MUST NOT raise an error upon receiving an unsupported optional element.
3. Required The property must be supported by all applications (they are able to capture and/or display it), but won't necessarily always be present in an instance.
4. Populated The property must be supported (able to be captured and/or displayed) and must always appear in the instance, but may appear with a flavor of null
5. Mandatory The property must be supported and must always be present with a non-null
value.

In general, if an attribute (or data type property) is not available (i.e. cannot be valued), then the rest of the data type properties (mandatory or not) should not be present. Exceptions to this rule will be documented in affected data types (e.g. CD).

In addition, data type properties may indicate maximum lengths. Systems will be able to capture and display an element as long as the maximum length, but it will not be able to send an element that is longer. Therefore a sending application must never send more than allowed by the specification and receiving applications. If longer data is truncated (within the maximum length) a warning message should
be provided.

All CMETs in Volume 1

2008-05-16T09:09:00.001-07:00

The SC team has discussed releasing ALL CMETs in
Volume 1 and, I believe, that is the plan for the next full release.

BAG and IVL types translated differently when generating XSDs from MIF

2008-05-12T13:11:00.000-07:00

Rajeev says:
SET – This is a bag. When translated to XSD the cardinality defines the number of nodes and each node is of the type defined in the supplierBindingArgumentDatatype. I.e. SET [0..5] indicates that there will be 5 nodes of type II.BUS. However, what cannot be enforced in XSD are rules like “in a SET each node must be unique”.

IVL – This is not a bag, but an interval consisting of nodes with other data types. Therefore, this becomes a data type itself. In the example below IVL_TS.FULLDATETIME is the data type. This, in theory, translates as an interval node with multiple child nodes, each of which is declared as TS.FULLDATETIME.

You have to remember that when reading a MIF, don’t think XSD. Read the MIF as per the spec. and then think of how we may translate to XSD. It took me a while to get into this mode of thinking.

HL7 keeps some information private!

2008-05-07T10:49:00.000-07:00

\Committee-defined semantic models in XML are maintained by the Control/Query Committee. Notable among these are the specification for Version 3 data types, and the specification for Version 3 XML ITS for data types. In this circumstance, the committee maintains a semantic definition of the topic in an XML file whose schema and/or DTD are known only to the committee.

Schema Tightening

2008-05-06T10:44:00.001-07:00

– Value sets are carried through to schemas.
– Fixed values are fixed in schemas.
Commitment to machine process able interchange of
message models.
– HL7 MIF ( Message Interchange Format ).
– Supplied with many of the domain message models from MIM 5.x
onwards.
– Will be supplied with all future message models.
– Key for all future tooling developments.

Kavanagh, Connecting for Health, UK

ANY Datatype in Canadian HL7 version 2 datatypes specification

2008-04-11T09:05:00.000-07:00

Rajeev Ayer says:
The ANY data type unfortunately, cannot be defined in any one way using XSD. This will have to be done using a combination of XSD and schematron.

The way I have implemented this is as follows:
1. The XSD ensures that the specializationType attribute must be supplied and must be set to one of the data types that are defined in the spec.

2. The schematron rule will then ensure that the xsi:type attribute of that element is set to the same value as the specializationType.

With these two rules in place, the element should be validated accordingly.

I know this is not backward compatible, but nothing about this part of the specification is backward compatible, so we will have to improvise.

Specification for HL7 Version 3 Interactions

2008-04-09T06:55:00.000-07:00

An overview of the HL7 Version 3 interaction is given here for the purpose of conveying where information about a Version 3 interaction can be found by an application or message handling service that will be responsible for implementing the transport of HL7 Version 3 interactions. At the highest level, an HL7 Version 3 Interaction is composed of 2 parts:

An "HL7 Transmission wrapper(s)" (always)

The "HL7 Transmission Content" (optional)

HL7 Transmission Wrapper

A "HL7 Transmission wrapper" includes information needed by a sending application or message handling service to package and route the V3 interaction to the designated receiving application(s) and/or message handling service(s). This wrapper also includes attributes that influence the message handling behavior of the receiving application that is consistent with the HL7 defined messaging interaction for which the interaction has been created.

All HL7 Version 3 interactions have an appropriately configured "HL7 Transmission wrapper".

The HL7 Transmission Wrapper exists to two different forms:

The Message Transmission Wrapper. This wrapper contains zero or one instances of HL7 Transmission Content.

The Batch Transmission Wrapper. This wrapper contains zero or more Message Transmission Wrappers. Each Message Transmission Wrapper contains zero or one instances of HL7 Transmission Content. The Batch wrapper is occasionally used to group Message Transmissions.

An interaction that has the Message Transmission Wrapper as its "outermost" wrapper is commonly referred to as a "message" or a "message-based interaction". An interaction that has the Batch Transmission Wrapper as its "outermost" wrapper is commonly referred to as a "batch" or a "batch-based interaction".

HL7 Transmission Content The HL7 Transmission Content is comprised of 2 parts:

A "Trigger Event Control Act" (required for all messages except accept-level acknowledgements, for which it is not permitted)

The "HL7 Domain Content" specified by an HL7 domain specific technical committee (required for each Trigger Event Control Act)

The "Trigger Event Control Act" contains administrative information related to the "controlled act" which is being communicated as a messaging interaction. It is also the part of HL7 messages that can convey status or commands for logical operations being coordinated between healthcare applications, e.g., the coordination of query specification/query response interactions and registry act interactions.

The "HL7 Domain Content" is the primary domain content of the messaging interaction (when it is present). It contains domain specific content that is specified by an HL7 technical committee to satisfy a use case driven requirement for an HL7 messaging interaction. If an interaction contains HL7 Domain Content, then it also contains a Trigger Event Control Act.

Levels of Acknowledgement

The HL7 standard has historically maintained "Application (Level 7) Processing Rules" regardless of the lower layer protocols of the communications environment to guarantee reliable message delivery. Briefly, these rules specify

A commit-level acknowledgement by a receiver

An accept-level acknowledgement by a transmission receiver

An application level response by an interaction receiver

The HL7 transmission wrapper will specify what levels of acknowledgement will be provided by the receiving system and/or application. The levels are the commit-level, the accept-level and the application-level.

Commit Level Acknowledgement

A commit-level acknowledgement is sent once the transmission has been saved to reliable storage by the protocol software on the receiving system. The implementation of the commit-level acknowledgement will differ depending on the underlying Transport Protocol. The commit-level acknowledgement is not an HL7 interaction, and is out of scope of this domain.

Note that all Transmission Infrastructures have to offer support for reliable messaging as of Release 2 of this domain. See the Abstract Transport Protocol domain for details of this requirement.

Accept Level Acknowledgement

The protocol software on the receiving system makes an initial determination as to whether or not the interaction can be accepted, based on factors such as:

The syntactical correctness of the interaction, if the design of the receiving system includes this type of validation at this phase

The interaction identifier, structure type identifier, version, processing code, processing mode code, if the design of the receiving system includes this type of validation at this phase.

The Sending system will determine (as conveyed in the HL7 Transmission Wrapper) whether or not an accept-level acknowledgement has to be sent by the Receiver. All receiving applications have to be able to send an accept-level error interaction should they discover an issue which prevents them from processing an interaction. All sending applications are required to be able to receive and process these accept-level interactions. (they may do this by e-mailing the system manager, or flag something in an audit file, the exact process is left up to the application).

Notes:

An accept-level error interaction may be generated by any routing application (e.g. interface engines) or by its destination. The Sending system should process these accept-level errors as if they were sent by the Receiver. See the Abstract Transport Specification for a description of the expected behaviour of Intermediaries, Bridges and Gateways.
Accept-level acknowledgement interactions are always sent to the sending device as contained in the Transmission Wrapper. The RespondTo class of the initial interaction is not used.
Application Level Response

If the interaction, as indicated by the interaction identifier in the HL7 transmission wrapper, indicates that the initiating system also requires an application response (a.k.a. application acknowledgment, functional response, or query response), this can be returned as an immediate response or as the initial message of a later (or deferred) exchange.

For the Application Level Response, the receiving system acts as the initiator. Since the interaction the receiving system sends is application-specific, the models of these application-level response interactions are defined in the relevant application-specific domain. Whether an application response may request another application acknowledgement interaction, is dependent on the design of the message interaction sequence as defined in the relevant application-specific domain.

Application-level response interactions are sent to the RespondTo device as contained in the Transmission Wrapper of the initial interaction. If the RespondTo class is not present in the initial interaction is not used, the response interaction will be sent to the Sender device.

Coded Simple - Vocabulary conformance

2008-03-31T15:13:00.001-07:00

Only domains of the Coded Simple (CS) data type are being balloted for inclusion in the standard. By definition, the allowable values are limited to what is included in the standard. Changes to a CS value set require another ballot of the standard. Constraints that refer to CS value sets are bound to the vocabulary release that was in effect when the artifact in which the constraint is contained was ballot approved. Regarding domains using the Coded with Equivalent (CE) data type where the coding strength is CWE, they will grow/change more frequently than ballots via a harmonization process by the Vocabulary Technical Committee. After each harmonization, these domains will be published in a numbered release. An organization will document the vocabulary version in their statement of vocabulary conformance.

PRPA_IN101004 - Client Registry - where is it?

2008-03-31T12:08:00.000-07:00

In Canada we are using a message PRPA_IN101004. When I look at the HL7 Normative Edition, I see in the schemas an XSD for PRPA_IN101004, which is the resolve duplicates notification.

However, I can't find any reference to the interaction in the Patient Administration domain.
Do you know whether PRPA_IN101004 is in fact in the Normative Edition?

Finally, I had to ask Llloyd Mckenzie to post on my behalf for despite requesting membership to the PAFM list, I am still not subscribed. Who is managing the PAFM list on HL7.org so that I can find out why my request for membership has not been approved?

Answer:

The interaction you are looking for passed Membership ballot (to be published as DSTU) in the January 2006 ballot cycle which was too late for inclusion in the 2006 Normative Edition. You can go to the 2006JAN ballot or wait for the 2007 Normative Edition (to answer the obvious next question, no I do not know when HL7 will publish the 2007 Normative Edition but I think it should be soon).

Gregg

HL7 international Provider Registry material

2008-03-26T09:11:00.001-07:00

The HL7 international Provider Registry material was submitted for ballot in 2005, but is currently only has Draft for Comment status.

Comments that might be provided:
1. That the choice of which classes/attributes are tagged for updatemode and audit attributes looks arbitrary -- which it is, because the mapping was only intended to support the PRS object model. The model needs to be generalized.

2. More class and attribute level documentation is needed. We have raised the bar higher since this model was designed and should expect, at a minimum, to see a description and rationale for every single component.

3. The query models should be rationalized. The identifier search should be much leaner. The detail search should be tightened to require an Identifier - no fishing.

4. I suspect there are datatypes that need to be tightened up.

5. I would complain about the publication, which fails to supply a single xml or xsd example of the use of the extended attributes. (This was a publishing glitch that never got fixed.)

HL7 datatype flavours

2008-03-19T09:13:00.001-07:00

LM says that flavours are not necessarily known by all recipients. The problem with this is that the abstract types, such as II and TS, are not intended to be reified. So why would a system be built that understood only abstract types?

The Model Interchange Format (MIF)

2008-03-17T15:17:00.001-07:00

The MIF contains conformance rules for nodes
The MIF defines what should be attributes and child nodes
The MIF declares the pan-Canadian data types for HL7 attributes, however, it does not define then anywhere
It declares the code strength (which I don’t think is accurate, especially since all the vocab has not been released)
It declares the code domain, but the codes themselves are not in machine readable format

In conclusion, I don’t believe that the MIF can fully validate a message instance of an HL7 message.

Volume 7 of the pan-Canadian standards - the SHR

2008-01-07T09:28:00.000-08:00

FYI - Just wanted to let you know that Vol. 7 will become the official Shared Health Record (SHR) Implementation Guide (IG)and the iEHR Standards IG will become part of Vol. 7. In my note to you on Dec. 26th responding to your questions, I indicated that Vol. 7 should be made part of the iEHR Standards IG, but the decision has now been made to incorporate the iEHR IG into volume 7. This was only clarified recently for Dragana and me [Marion Lyver].

Extending XML

2008-01-03T16:54:00.001-08:00

So, bit of key info from Lloyd McK on extensions - apparently there are rules saying (somewhere) that extensions must be derived from RIM and existing datatypes. Not sure how this is expected to be enforced and certainly provides an unfair constraint on the implementer to have the solution space pre-defined. I am a strongly against this beyond "should".

Scope and Tracking Framework - effective Dates

2008-01-03T16:46:00.000-08:00

Use of effective from and effective to columns in the Scope and Tracking Framework.
The intention is to identify what the allowed values are for the effectiveTime in the ControlAct. If AllowFutureDate is true, the effective time can be different from the author time. E.g. Send a message now asking for a prescription to be suspended next Tuesday. The "allow end" means you can specify and end date as well. E.g. Suspend this on Tuesday and release it a week later.

v3 Generator

2008-01-02T20:33:00.000-08:00

The v3 Generator may not generate nodes in the same order if the sortOrder of the objects varies. The sort order in java may change for a lot of reasons:
Your fundamental assertion is correct. However "inputs" can be interpreted fairly broadly:
- Sort order has changed based on the JVM (one of the 1.4 versions did wonky things)
- Sort order can change when you generate with new RIM vocabulary and formal naming input files
- Sort order can change when you manipulate a Visio file, as changing the z-order of shapes within the diagram can affect class names, which in turn affects sort order. Adding or removing classes can do the same.
- Changes to the tools, reflecting updated methodology or fixes to bugs can also change names and thus sort order

However, if all of those variables remain constant, the sort order will remain the same from generation to generation. Hope that answers your question (Lloyd MacKenzie)

My eHealth 2007 presentation

2007-11-30T13:37:00.000-08:00

http://www.e-healthconference.com/_ehealth2007web/pdf_presentations/wed_use_of_ehr_cripps.pdf

HL7 message development in Canada

2007-11-30T02:32:00.000-08:00

The pan-Canadian working groups are often too far ahead of usage to be that helpful. The model currently is that representatives from each province come together and try to figure out what would need to be messaged in a Canadian standard. In a way, it's a requirements-driven process, but without the prototypes and usage that accompany systems development, it doesn't seem to yield the right results.

A better approach would be to wait for a province that has a burning need to exchange medical information to come forward, and for CHI to plant key resources on the project team who do real work towards the project goal. CHI could then be sure that decisions weren't made on the project that would limit the applicability of messages to other provinces. The advantage of tying message development into a project of course is that the project has a deliverable: the software.

With a hard deliverable at the end, a phased approach with early prototypes, in which complex issues, including messaging, are tackled early, will yield a product that is at least adequate for initial system-system communication in one provincial setting, and will form a good basis for such communication in other provinces.

What CHI needs to do is manage standards in such a way that the initial production is tied to a project, and roll out standards in alpha, beta, and final form, and in such a way that momentum is gained through iterative, cumulative releases.

The outcome of a project must of necessity include artifacts that the developers understand and that testers have created to test the system. As other projects pick up that material and need to change it, the cycle of standards maintenance can begin.

Here in Canada, rather than wait for several jurisdictions to propose changes to the standards, changes have been thrust upon the provinces whether there is need for them or not. In other words, it's often too early to know whether a standard is deficient or not until it's tried and tested in a couple of places.

It simply is not prudent to attempt to create an all-singing all-dancing solution to anything in a big bang approach. Carefully staged, iterative prototypes are the right approach to creating technical solutions to complex problems.

Invest a little, learn some lessons, invest some more, reach a small beach-head; invest again and learn more; establish a base camp; and so on, up the mountain.

Initiate Identity Hub

2007-08-13T13:44:00.000-07:00

The Identity Hub can't officially store audit dates against attributes. It stores the dates against operations, and then the attributes are linked to the operations. So if you have an HL7 message arriving with different dates on different attributes, you end up having to execute a number of MemPut operations. So it CAN be done, but it's messy, and I'd be a little concerned about performance, in that instance. Of course, if you go to Update mode as well (instead of Snapshot mode) then an inbound message is likely to contain only one set of dates (business and technical) anyway so would only occasion one MemPut.

Incidentally, I don't think eDrug has a requirement for Update Mode. Current Pharmanet demographic updates to CRS are considered Snapshots, so if they don't change an address, they still have to supply it. The Update Mode requirement is probably coming from somewhere else, though.