Conformance strengths

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.

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

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

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

xsi:nil

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

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

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.