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.