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.

All CMETs in Volume 1

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

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!

\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

– 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

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.