Canadian Datatype flavours

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

"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

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

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

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

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