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.

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.

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.

Specification for HL7 Version 3 Interactions

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

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?

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

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

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)

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

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

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

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

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)