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.
Friday, April 11, 2008
Wednesday, April 9, 2008
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.
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.
Monday, March 31, 2008
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
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
Wednesday, March 26, 2008
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.)
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.)
Wednesday, March 19, 2008
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?
Monday, March 17, 2008
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.
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.
Subscribe to:
Posts (Atom)