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

ControlActReasonCode

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

Values for status of properties

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.