The Verbose HL7V3- Part 1

In Mid-2006 Gartner in a note on HL7V3 stated that HL7V3.0 messages are quite verbose and applications require considerable effect to understand and process the message. Gartner suggested that HL7V3 messages need a critical midcourse correction and suggested to HL7 Inc to act vigorously to make HL7V3 messages easier to use and more compact.

In the next couple of posts I would look into the reasons and complications behind the verbose nature of HL7V3 and conclude by presenting the solutions on offer to overcome the problems associated with this verbose nature of HL7V3. This post will also help you to some extent to understand how to browse through an R-MIM.

Why are HL7V3 Messages Verbose?

HL7V3 messages are XML messages which are model driven and model driven XML are usually verbose in nature compared to custom written bespoke XML messages designed to convey the same information.

Why do we need Model driven messages?

Currently in the healthcare industry point-to-point messaging is common and non-standardised data exchange is the norm leading to data quality issues, confusions and processing errors sometimes with grave consequences affecting patient care. So it’s absolutely necessary to have a common understanding of the data that is being exchanged to eliminate the misinterpretations. To facilitate this, a level of semantic interoperability is required.

Semantic interoperability can be achieved using a common information exchange reference model so that data is shared and defined unambiguously. XML schema models are derived from this reference model and used to generate run time schemas which cannot be modified directly unless the model itself is modified. As different applications build XML messages sourced from the reference model they end up having the same content and construct facilitating meaningful data exchange. HL7 Inc produced a global semantic model for healthcare called Reference Information Model (RIM) which is the basis for HL7V3 messages [Refer to the HL7V3 Primer post dated January 2008 at

http://healthcareinformatics3000feet.blogspot.com/2008/01/hl7v30-primer.html].

So what’s the issue?



Well, let’s take a sample example and see what exactly the issue is. The following is an extract from XML instance to represent author of a clinical document based on the discharge summary CDA schema taken from CFH-MIM6.3 available on HL7-UK Website

Now let’s look in detail at the representation of the author. The R-MIM representation of the first part is shown below

The author representation starts with the author as participant. It contains the following attributes

1. “typecode” with a fixed value of “AUT” – Indicating this class is that of author

2. “functioncode" to indicate the function of document author from a pre-defined vocabulary. In this case it has a fixed value of “OA” indicating originating author.

3. “contextControlCode” - Specifies how the author contributes to the context of the discharge report and whether it may be propagated to descendent acts whose association allows such propagation.

4. “contentId” - An identifier for a template which constrains the classes and attributes which follow. This is more of a structural navigational aid and not an indicator of semantic meaning. In this case it is the AssignedAuthorSDS template.

5. “time” - The time at which the author authored the clinical document.

The XML representation of the above is shown below

The AuthorChoice leads to template for the author who is in a directory called SDS-Spine Directory of Services. The R-MIM representation of author in SDS is shown below

The AssignedAuthorSDS identifies a person playing the role of author. The role information includes the user identifier and role profile information of the author along with the job role.The AssignedAuthorSDS contains the following attributes.

1.“classCode” - A fixed value of “Assigned” indicating that this role is assigned

2.“id” – it has a cardinality of [1..2] with two identifiers one to identify the user id and one to identify the role profile of the person to whom the role is assigned

3.“code” - A code from a vocabulary which defines the person’s job role and with displayname associated with code

4.“templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the AssignedAuthor template.

The XML representation of the above is shown below

The role AssignedAuthorSDS has links to person entity which is playing the role of the author. The attributes within the person entity are given below

1. “classCode” - A fixed value of “PSN” indicating that this entity is a person

2. “determinerCode” – A fixed value of “INSTANCE” to indicate this is a instance of person
Name – Name of the person

3. “templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the AssignedPerson template.

The XML representation of the above is shown below

The role AssignedAuthorSDS has links to the represented organisation to which the author belongs to. The attributes within the organisation entity are given below.

1. “classCode” - A fixed value of “ORG” indicating that this entity is a organisation

2.“determinerCode” – A fixed value of “INSTANCE” to indicate this is a instance of an organisation

3.“id” – A unique identifier which identifies the organisation nationally

4.“name” – name of the organisation

5.“templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the representedOrganisation template.

The XML representation of the above is shown below

Still not clear on what’s the issue here?

Well a simple XML representation of the author as described above would have probably looked something like this

Hmm…

But is it that not the price you pay for using a model to provide semantic interoperability?

Yes it is but the verbose nature of the HL7V3 problems are creating huge problems as mentioned above regarding the effect to understand and process the message correctly apart from hogging the network bandwidth and destroying one of the unique the advantage of XML messages- “Readability” which is critical for developers and testers.

So what can we do?

There is a huge debate going on if we can take an alternative path to provide semantic interoperability with simpler XML messages. We will discuss those options in our next post.

Acknowledgements and Copyrights

1. HL7-UK / CFH - MIM 6.3 - Copyrights for R-MIM

2. Acknowledgements - Is it Possible to be Simple Without being Stupid?

Exploring the Semantics of Model-driven XML - Ann Wrightson

Null Flavors in HL7V3

The concept of null in HL7v3 is very different from HL7V2.x (See my old post on Null values in HL7V2.x. http://healthcareinformatics3000feet.blogspot.com/2007/11/null-values-in-hl7v2x.html). This is essentially to do with lack of support for optionality in HL7V3 – Reference Information Model which itself rose from the issues associated with optionality in HL7V2.x – see else where in this blog for strengths and weaknesses of HL7V2.x and HL7V3.0.

At a high level we can say that in HL7V3 the multiple exceptional values, i.e. values other than recommended or allowed by message specifications are grouped under the banner of NullFlavor. nullFlavor is a property of every data type through ‘extension.’ This property is valued and communicated as part of a message when information is missing. The flavor provides the reason why the information is missing. This can be best illustrated by the following example

The Character String with Code (SC) data type contains a character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code.

If the name of the software(e.g. RamboRavage) is known


< softwareName> RamboRavage < /softwareName >

To indicate the name of software (RamboRavage)and code of the software(RaRv)

< softwareName code="1" codeSystem=" 2.22.222.2.222222.2.2.2.2.2222" displayName=" RamboRavage" >RaRv</softwareName>

To indicate that the software name is unknown

<softwareName nullFlavor=" UNK" />

It need to be remembered that a nullFlavor is not permitted simultaneously with a value. The various types of null flavour as per the latest HL7V3 ballot pack are given below

1.NI -no information- This is the most general and default exceptional value. There is no information which can be inferred from this exceptional value.

2.MSK- masked – This particular item has a known proper value, but it cannot be released in a given context due to security, privacy or other reasons.

3. OTH- other -There is a value, but it is not an element in the value domain of a variable
NINF negative infinity of numbers
PINF positive infinity of numbers

4.UNK- unknown - proper value is applicable, but not known.

• ASKU - asked but unknown – information was sought from the source but not known (e.g., patient was asked but didn't know)
  
• NAV temporarily not available - Information is not available at this time but it is expected that it will be available later.
  
• NASK not asked - The Information was not requested from the patient
  
• QS Sufficient quantity – The actual quantity is not known but sufficient enough to achieve a specific goal. For example the advice can be add sufficient quantity of water to 10 mg of medicine
  
• TRC trace – The content is tool small to measure but a nonzero value

5. NA not applicable – There is no proper value for this data item for this patient; for example the date of last menstrual period is not applicable for a male.

The practical use of null can be gauged from different scenarios. For example a unconscious patient brought to the hospital have to be registered and most Patient Administration systems need at least one address. If the patient address is not known the patient address element <addr> can be set to UNK and sent to other down stream systems or repositories. If Sensitive/VIP patients need to be sent to other systems and if they do not have the same levels of security and control as the sending system have the sending system can send a null flavor of MSK indicating that they do not wish to expose the patients address.

But the usage of nullflavor has come under for huge criticism from different quarters notably from Barry Smith(Ref:http://hl7-watch.blogspot.com) where it was pointed out that the different nullflavors might lead to the need for different reasoning services and might become an overhead for message processing by applications. The other criticism of nullflavor is that the need for mandatory values for attributes would force systems to be modified to restrict users who normally ignore non-mandatory fields on screen to fill them with nullflavors. They need to be manually filled in with the real reason for that null value and proper nullflavor need to be entered on the screen. Some of the nullflavors like NAV (temporarily unavailable) are not very user intuitive terms for them to be selected. The values of +infinity and –infinity are mathematical conceptual numbers and does not indicate non-availability of data in any manner.

Organization such as CEN have rejected HL7V3 data types apart from Australia opposing the current draft ISO health data types standard (ISO 20190) based on HL7 v3 data types and one of the reasons it has been rejected or opposed is the huge confusion over usage of nullflavors(see the debate on nullflavors on openEHR website).

Business Case for HL7V3.0

My previous posts clearly indicate that HL7 V3.0 represents a quite radical departure from the HL7V2.x standards in its development methodology. Most of the early adopters believed that the HL7V3.0 would replace HL7V2.x in its entirety, but the reality of the substantial investments in HL7V2.x systems by different organizations and vendors soon became apparent. The recent versions of HL7V2.x notably HLV2.6/HL7V2.7 added new features e.g. EHR messages which enhanced the capabilities of V2.x standards matching the features of Version 3.0. The areas area’s where V3 was supposed to solve V2.x problems e.g. Clinical Messages were found to be very work-intensive with issues pending around these domains.

The last released normative edition HL7V2006 as shown in the Figure below indicate that some of the domains have not yet been approved for example Specimen domain( Informative).The final standards of some domains are in a trial form ( - DSTU = Draft Standard for Trial Use)only for example Patient Administration which maps onto ADT in HL7V2.x.

2006 Normative Edition Domains [Copyright: HL7]

Currently one Normative Edition is coming out per year and this is increasing the uncertainty around this version.Figure below shows the world wide usage of different HL7 versions. The figure indicates that HL7 V3 is not in wide use and V2 would need to be supported for a long time

HL7 Version Usage Statistics [Copyright : Neotool]

The business case for using HL7V3.0 for sites which already has HL7 v2.x deployed is different from that sites of which do any have any variant of HL7V2.x implemented is also different. Another important factor that needs to be considered for building a business case for deploying version 3.0 in an organization is the extent of usage of department specific systems rather than an integrated system.

HL7 Sites: Large numbers of organizations around the world have made huge investments and effort in developing and maintaining HL7 V2.x interfaces. Most of these deployments have taken place in the last few years and it will take huge effort in convincing these sites to give up HL7V2.x and adapt HL7V3.0. If the requirements and need of the organizations are met by the existing v 2.x implementations then it would make little sense in replacing them with expensive V3.0 implementations not withstanding the thought the long term infrastructure and support costs for V2.x depending on the volumetric increase. However for new domains which are not yet deployed in that clinical setting it would be advantageous to start with V3.0.

Non-HL7 Sites: For Non-HL7 sites the factors that needed to be considered for V3.0 implementation are the capabilities of the existing applications in that clinical setting and the consideration of features and needs of the clinical setting that cannot be provided by version 2.x such as semantic interoperability, support for research, genomics, web services and integrating with nation wide or region wide EHR systems. But the semantic richness and the transport protocols of V3.0 does make it a better alternative to V2.x to take advantage of the COTS products features to quicken development. It has been observed that early adopters of V3 are typically "green field” sites with no HL7 complaint systems. Other implementation sites are academic and research oriented deployments and a few others are sites which implemented HL7 V3 to adhere with regulatory agency compliance specifications.


The complexity in understanding HL7 v3.0 is a major challenge for a clinical enterprise to implement HL7V3.0. The organization which wishes to implement HL7V3.0 needs to get involved the activities of HL7 organization and educate the stakeholders before impacting the effort involved in making their environment HL7 V3.0 compliant. The effort involved in making applications in an organization conform to V3.0 is proportionate to the application functionality required by the defined role of the application. The vendors of the application might not modify their applications to suit to the specific organization needs hence an organization should carefully tread the HL7 V3.0 path only after studying the market trends associated with HL7 V3. The market trend does indicate HL7 V2.x and V3.0 coexisting together for the next few years.

HL7V2.x to HL7V3.0 Translation Issues Details-2

In continuation of my previous post this post lists the other issues associated with HL7 v2.x to HL7v3 translation

Conformance Patterns: The other major issue with the transformation of messages is the behavior of application when a particular information exchange takes place. In HL7V3.0 apart from the trigger events and interactions there exists the notion of application role as senders and receivers. The application role is characterized as the entire set of interactions for which the sender and receiver are responsible for transmitting. HL7V3.0 clearly defines the possible interactions and the application behavior associated these interactions in the form of responses for which the sender and receiver needs to adhere to. The differences in messages between V2.x and V3.0 and absence of clear guidance on V2.x regarding application behavior on receipt of message makes the transformation exercise more difficult.

Vocabulary: It is a well known fact that 80% of HL7 V2.x message failures are a result of code mismatches. HL7V2.x needs a translation table for each interface and this puts a huge overhead on HL7V2.x implementation. Version 2.x has no formal binding of standard vocabularies to structures. The bindings are ad hoc and always site specific. However Version 3.0 has a strong semantic foundation in explicitly defined concept domains drawn from the standard terminologies. Each concept in a vocabulary domain (a defined set of coded concepts) is represented using a code from a specific vocabulary. The mapping of an ad hoc vocabulary to a standard vocabulary is problematic as cases like one-to-many and many-to-many mappings will be encountered which can be resolved only manually and cannot be automated. One major issue with vocabulary is the emergence of SNOMED as vocabulary of choice for HL7V3.0 messages. SNOMED Post-coordination which describes representation of a Concept using a combination of two or more codes is not possible for V2.x messages up to V2.4 and this makes the mapping and translation more difficult.

Cardinality Constraints: The mapping of cardinality constraints between HL7V3.0 and HL7V2.x is very complex due to the HL7V2.x messages being shallower and less expressive than HL7V3.0 messages. So HL7V2.x messages are unlikely to be able to represent the full range of allowed cardinalities of attributes and associations that HL7V3.0 message can represent

Wrappers: The information present in the HL7V2.x TCP-IP MLLP wrapper is insufficient to populate the ebXML/SOAP HL7V3.0 wrappers to enable the communication and routing of the messages at the integration layer level where HL7 wrappers are not considered. HL7 V3.0 XML ITS can use MLLP for transport but the HL7 interaction semantics defined in the V3.0 standard transport specification using SOAP/ebXML will be disturbed.

HL7V2.x - HL7V3.0 Transformation / Translation

The adoption of any new messaging standard will be faster only if there exists a clear and defined transformation and migration strategy between the new standards and existing standards. It is always preferred to handle such a strategy in a middleware so as not to modify the core clinical applications to cater to the standard which is very expensive in the shorter run. However till now there is no clearly defined guidance to facilitate such a transformation of messages between Version 2 and Version 3.

These differences in methodology make the transformation from one version to another difficult. Technically it is possible to map the segments in V2 messages to XML sub-tree in XML schema with defined conversion mapping rules. However site specific interpretations of V2.x with user defined segments and fields make the transformation to V3.0 based on a common reference model appear like a mapping from a proprietary standard to a universal standard.

There are several instances where HL7 V2-V3 mapping has been attempted and tools are made available for specific projects like caBIG (Cancer Biomedical Informatics Grid) and commercial tools like Oracle HTB. Figure below shows a generic architecture used in these different initiatives. The mapping in these tools is manual and there is no pre-defined intelligent mapping or guidance provided with the tool sets. Exceptional domain expertise is required to perform the mapping in these tools.

The message structures used by HL7 v2 and V3 are different and the initial step involves converting the messages to a common canonical format before the mapping can be done. The V3.0 XML format is not compatible with the string delimited non-XML V2.x format. The V2.x XML encoding will enable it to be compatible with V3.0 XML format. The canonical transformation component will enable both these XML messages to be converted into an intermediate format to enable the mapping. The mapping between V2 and V3 is relatively straight forward in some cases of demographic data and clinical data where HL7V2.x segments directly map onto HL7 V3 classes. In other areas it has been not possible to map the different versions. A summary of some of the the difficulties faced during the mapping are [ Full details in my to be shortly published white Paper ]

Data Types

• Formats of Character Strings to Semantic data values
• Context and Content driven mapping issues leading to information loss

Conformance Patterns

• Clear definition of roles for Senders and Receivers in HL7V3.0
• No Clear guidance on application behaviour using HL7V2.x

Vocabulary

• V3.0 has strong semantic foundation and V2.x has no formal binding to Voc
• No one to one data types exist

Cardinality Constraints

V2.x messages shallower and less expressive than HL7V3.0 messages


Wrappers

Insufficient information in HL7V2.x-MLLP compared to HL7V3.0-ebXML/SOAP

HL7V3 and ebXML - Part 3

I apologise for the delay in publishing the Part 3 of the ebXML and HL7V3. I see that a portion of hits to my blog are coming from the links provided by Marc de Graauw in Section 7 of his article Implementing “Web Services in Dutch Healthcare” at http://www.ringholm.de/docs/03030_en.htm. I thank him for considering my blog posts worth the mention.

What is ebXML MSH?

HL7 V3 message triggered from Sender are sent over their integration layer as HL7 Request to sender MSH (Message Service Handler). MSH is a piece of software used to send and receive ebXML messages. Figure below shows the functions of MSH.

The textual description of the services depicted above is given below

Ø MSH Service Interface – This is the abstract interface applications use to interact with MSH to send and receive messages.

Ø Header Processing – the creation of the ebXML Header elements for the messages sent from the applications. It also involves parsing of header elements and interactions with contract properties. [See below for Contract Properties]

Ø Security Services – this includes digital signature creation in the messages (which may be used in headers), verification, encryption, authentication and authorization.

Ø Message Packaging – this will perform the enveloping of an ebXML Message (ebXML header elements and payload) into its SOAP Messages with Attachments container

Ø Reliable Messaging Services – this service handles the delivery and acknowledgment of ebXML Messages. It also deals with persistence of messages, retry, error notification and acknowledgment of messages requiring reliable delivery.

Ø Transport Binding – This is the abstract interface between the MSH and the various protocol stacks.

Ø Error Handling – this handles the logging and reporting of errors encountered during MSH or Application processing of a message.

Contract Properties

To understand the exchange of messages between two MSH’s we need to understand the term “contract properties”

Each MSH processes the messages sent by the other MSH by the contracted interface properties. These properties describe Quality of Service (QoS) from reliability and security point of view. The MSH uses these properties to build the ebXML wrapper. The contract properties are defined during message definition process and agreed between two organizations or two system vendors who will exchange the messages. Contract properties are defined for each HL7 interaction. The contract properties given for each interaction are identified by a CPAId. The sender will use the CPAId that is relevant for that HL7 message interaction and agreed with the receiver.

The relevant contract properties are Service, Action, Persist Duration, RetryInterval, Retries, AckRequested, SyncReplyMode, Actor, EndPoint, IsAuthenticated etc.- See HL7V3 and ebXML – Part 1 for details about these properties.

ebXML Message Exchange :

Figure below shows the sequencing involved in ebXML message exchange

Let me explain the flow in the above sequence diagram

1. In a typical implementation the Sender builds the HL7 message with the HL7 Wrapper and passes it onto the sender MSH

2. The sender MSH looks at the message interaction id and looks up in the database for the contract properties for the message and builds the ebXML wrapper.

3. The ebXML message sent by sender MSH containing the HL7 message payload will get ebXML acknowledgement synchronously on the same connection over HTTP 202. The ebXML Acknowledgements are sent without a payload.

4. If the ebXML acknowledgement from Receiver MSH is not received within a time interval Sender MSH resends the message. The number of retries and retry time interval are dependant upon the contract properties attached with that message.

5. If the number of retries expires depending upon the message business functionality Sender MSH will report the error back to application which sent the message or enter into a HL7 slow retry method.

6. In case of ebXML errors Receiver MSH sends a message with the same end-point binding associated with ebXML acknowledgement service except that a Message Error will be sent.

7. The business responses or application acknowledgements from Receiver MSH in response to the message sent are received and processed by the Sender MSH exactly in the same fashion as Receiver MSH does on receiving a request from Sender MSH.

The above description is only for direct reliable message exchange between two MSH's ; we can have intermediary exchange with two MSH's communicating to each other using anothe MSH or we can also have direct unreliable message exchange. I have not discussed them here not i do intend to discuss them here.

HL7V3 and ebXML - Part 2

In this post we will look at the second MIME part which we mentioned in the first part as Payload Containers containing application level payloads. We will observe what exactly is contained in the Payload containers. The payload container contains HL7V3 composite messages composed of three parts

Ø Transmission or Transport Wrapper

Ø Control Act Wrapper

Ø HL7 Domain content

Figure below shows the structure of the second MIME part when expanded

The Transport wrapper includes information needed by a sending application or ebXML message handler route HL7V3 composite Message to the intended receiving application(s) and/or message handler.

As in the first post let me take an example and explain it

-------------------------------

<PRPA_IN040000UV15 xmlns="urn:hl7-org:v3" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 PRPA_IN040000Uv15.xsd">
<id root="36E66A20-1DD2-11B2-90FA-80CE4046A4A7"/>
<creationTime value="20061123154933"/>
<versionCode code="V3PR1"/>
<interactionId root="2.16.840.1.113883" extension="PRPA_IN040000UV15"/>
<processingCode code="P"/>
<processingModeCode code="T"/>
<acceptAckCode code="NE"/>
<Receiver typeCode="RCV">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.2.4.99.1" extension="12345"/>
</device>
</Receiver>
<Sender typeCode="SND">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.2.4.99.1" extension="67890"/>
</device>
</Sender>
<ControlActEvent classCode="CACT" moodCode="EVN">
<author typeCode="AUT">
<----->
< ----->
</author>
<subject typeCode="SUBJ" contextConductionInd="false">
<RegistrationRequest classCode="REG" moodCode="RQO">
<subject typeCode="SBJ">
<patientRole classCode="PAT">
<addr use="H">

<postalCode>SL11NH</postalCode>
<streetAddressLine>oxform farm</streetAddressLine>
<streetAddressLine/>
<streetAddressLine/>
<streetAddressLine>Slough</streetAddressLine>
<useablePeriod>
<low value="19550101"/>
</useablePeriod>
</addr>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<name use="L">
<family>Ashok</family>
<given>Mehra</given>
</name>
<administrativeGenderCode code="2"/>
<birthTime value="19550101"/>
</patientPerson>

<----------------->
<------------------>


</RegistrationRequest>
</subject>
</ControlActEvent>
</PRPA_IN040000UK15>

-------------------------------

1. The second MIME starts with the name of the message interaction ; name space and schema location

<PRPA_IN040000Uv15 xmlns="urn:hl7-org:v3" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 PRPA_IN040000Uv15.xsd">

PRPA_IN040000Uv15 is the name of the message interaction and is the same as the one included in the Action element of ebXML wrapper.

2. The next attribute is the unique identifier for this message. It is based on the I I – Instance identifier data type. Instance identifier contains root of type UID(Unique identifier ) , extension(ST) , assigningAuthorityName(ST) and displayable(Boolean). Most of the case the root alone may be the entire instance identifier. Figure below shows a case where the identifier has a DCE UUID held in the root attribute

<id root="36E66A20-1DD2-11B2-90FA-80CE4046A4A7"/>

3. The next set of relevant attributes are given below

<creationTime value="20061123154933"/>
<versionCode code="V3PR1"/>
<interactionId root="2.16.840.1.113883" extension="PRPA_IN040000UV15"/>
<processingCode code="P"/>
<processingModeCode code="T"/>
<acceptAckCode code="NE"/&gt;

The creationTime is date and time that the sending system created the message and it uses the datatype-TS

The versionCode is the domain of HL7 version codes for the Version 3 standards. Values are to be determined by HL7 and added with each new version of the HL7 Standard. HL7V3 2006 normative edition has a default value of V3PR1. In UK-CFH land this field is used to define the version of MIM-Message Implementation Manual from to which the message interaction belongs to e.g. V3NPfIT3.1.10 indicating that this message interaction is from MIM3.1.10.

The interaction identifier is a unique reference to the message type, trigger event and application roles that send and receive the message. This is the same as the one populated in the Action element of ebXML wrapper. The root contains the OID value. An OID (object identifier) is a numeric string that is used to uniquely identify an object. OIDs are intended to be globally unique. They are formed by taking a unique numeric string (e.g. 1.3.5.7.9.24.68) and adding additional digits in a unique fashion (e.g. 1.3.5.7.9.24.68.1, 1.3.5.7.9.24.68.2, 1.3.5.7.9.24.68.1.1, etc.)

The processing code is used to identify the environment that the message must be processed in. The possible values for this are D-Debugging; P-Production and T-Training.


The processingModeCode is a code identifying the mode that this message is being sent in. The possible values for this are A-Archive Mode; I- Initial Mode ; R- Restore from Archive and T- Current Processing.

The acceptAckcode is a code identifying the conditions under which accept acknowledgements are required to be returned in response to this message. The possible values are AL- Always, ER- Error and NE- Never.


4. The transport wrapper carries information about the receiver and sender systems for the messages as shown below

<Receiver typeCode="RCV">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.2.4.99.1" extension="12345"/>
</device>
</Receiver>
<Sender typeCode="SND">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.2.4.99.1" extension="67890"/>
</device>

It starts with the typeCode; The three RIM back-bone classes -- Participation, ActRelationship and RoleLink -- are not represented by generalization-specialization hierarchies. these classes represent a variety of concepts, such as different forms of participation or different kinds of relationships between acts. These distinctions are represented by a typeCode attribute that is asserted for each of these classes. For a receiver the receiver has a typeCode value of RCV-Receiver and for Sender SND-Sender. Both sender and receiver carry the information identifying the device.

The device starts with a Classcode [w.r.t Entity ClassCode is an HL7 defined value representing the class or category that the Entity instance represents.] and for both sender and receiver has a fixed value DEV indicating that the entity is a device. It also has a determinerCode which is an HL7 defined value representing whether the Entity represents a kind-of or a specific instance. In this case it is an “INSTANCE”.

It optionally carries the telecom value – WP indicating that it is a work phone. The id is a single unique identifier of the accredited system that represents the party who is either sending or receiving the message. The root carries the OID and the extension carries the application identifier. Optionally it can also carry the Name , Manufacturer , Software name and the represented organization as shown below.

<receiver typeCode="RCV">
<telecom use="WP" value="tel:+31303248724"/>
<device classCode="DEV" determinerCode="INSTANCE">
<id extension="700856" root="2.16.840.1.113883.2.4.99.1"/>
<name use="L">
<given>CAREEX</given>
</name>
<agencyFor classCode="AGNT">
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id extension="100100" root="2.16.840.1.113883.2.4.99.1"/>

<name use="L">
<given>Uxbridge Hospital</given>
</name>
</representedOrganization>
</agencyFor>
</device>
</receiver>

5.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 Control Act does not appear in accept level acknowledgements (i.e., messages used only for conveying the status of message communications) or with messages carrying commands to coordinate the operation of message handling services

The "semantic content" of a HL7V3 message is the combination of the ControlAct and the payload. Tofully understand the trigger event you need both. The Control Act just says "Please 'do something' with 'this thing'".The payload is needed to indicate what 'this thing' is. However, the bulk of the trigger event information is attached to the Control Act.

<ControlActEvent classCode="CACT" moodCode="EVN">
<author typeCode="AUT">
< ----->
< ----->
</author>
<subject typeCode="SUBJ" contextConductionInd="false">

The message types defined in the Message Control Act Infrastructure section of the HL7V3 2006 Normative ballot are highly generic and inclusive. Message designers and implementers can further refine and constrain Trigger Event Control Acts.

6.The last part of the message is the "HL7 Domain Content" which is the primary domain content of the messaging interaction .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. For example the below is an loose example of a RegistrationRequest domain in which a extract of the message used to capture the details of patient used to register a patient are sent.

<RegistrationRequest classCode="REG" moodCode="RQO">
<subject typeCode="SBJ">
<patientRole classCode="PAT">
<addr use="H">
<postalCode>SL11NH</postalCode>
<streetAddressLine>oxform farm</streetAddressLine>
<streetAddressLine/>
<streetAddressLine/>
<streetAddressLine>Slough</streetAddressLine>
<useablePeriod>
<low value="19550101"/>
</useablePeriod>
</addr>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<name use="L">
<family>Ashok</family>
<given>Mehra</given>
</name>
<administrativeGenderCode code="2"/>
<birthTime value="19550101"/>
</patientPerson>

<----------------->
<------------------>
</RegistrationRequest>

In the final post next week in ths series i will try to explain the actual implemenation mechanics.

HL7V3 and ebXML - Part 1

In 2003 HL7 Board of Directors approved usage of ebXML for transporting HL7V3 messages as Draft Standard for Trail Use (DSTU) . The English Connecting for Health is one of the first major users of this transport and all HL7V3 asynchronous messages communications in that project is performed using ebXML. This is the first of blogs to understand the relationship between HL7v3 and ebXML . In this process we will also discuss the structure of HL7V3 message as well.


Figure below shows the general structure and composition of an ebXML message

The ebXML Message is a MIME/Multipart message envelope structured in compliance with the SOAP Messages with Attachments specification and is referred to as Message Package.

The Message Package is divided logically into two MIME parts

• A MIME part, referred to as Header Container containing one SOAP 1.1 compliant message. This message is referred to as SOAP message



• Zero or more additional MIME parts referred to as Payload Containers containing application level payloads

The SOAP Message is an XML document that consists of the SOAP Envelope element. The SOAP Envelope element consists of the following:

• SOAP Header element - This is a generic mechanism for adding features to a SOAP Message, including ebXML specific header elements.



• SOAP Body element. - This is a container for message service handler control data and information related to the payload parts of the message.

In this post let’s discuss the first MIME part containing the SOAP envelope. Let me take an example of ebXML wrapper and run through so that the context can be understood.

Now let us analyse the wrapper in detail

--------------------------------------------------------

<soap-env:Envelope

xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd" xmlns:hl7ebxml="urn:hl7-org:transport/ebXML/DSTUv1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd" >
<soap-env:Header>
<eb:MessageHeader soap-env:mustUnderstand="1" eb:version="2.0">
<eb:From>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP1 </eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP2</eb:PartyId>
</eb:To>
<eb:CPAId>ABC22</eb:CPAId>
<eb:ConversationId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:ConversationId>
<eb:Service>urn:org:names:services:MPI</eb:Service>
<eb:Action>PRPA_IN040000UV15</eb:Action>
<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
</eb:MessageData>
<eb:DuplicateElimination/>
</eb:MessageHeader>
<eb:AckRequested soap-env:mustUnderstand="1" eb:version="2.0" eb:signed="false" soap-env:actor="urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH" />
</soap-env:Header>
<soap-env:Body>
<eb:Manifest eb:version="2.0">
<eb:Reference xlink:href="cid:payload@hl7.com">
<eb:Schema eb:location="http://www.info.org.uk/schema/HL7-Message.xsd" eb:version="15" />
<hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />
</eb:Reference>
</eb:Manifest>
</soap-env:Body>
<soap-env:Envelope>

----------------------------------------------------

1. The wrapper starts with name space declaration

<soap-env:Envelope
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"
xmlns:hl7ebxml="urn:hl7-org:transport/ebXML/DSTUv1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd >

Name space declaration for the ebXML SOAP extensions may be included in the SOAP Envelope, Header or Body elements, or directly in each of the ebXML SOAP extension elements.

The SOAP namespace: “http://schemas.xmlsoap.org/soap/envelope/ “ resolves to a W3C XML Schema specification. The ebXML OASIS ebXML Messaging TC has provided an equivalent version of the SOAP schema conforming to the W3C Recommendation version of the XML Schema specification
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd

The XML schema-instance namespace qualified schemaLocation attribute in the SOAP envelope to indicate to validating parsers a location of the schema document should be used to validate the document is also included.
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd


[HL7-ebXML] extends the ebXML headers within the HL7 ebXML namespace. The namespace declaration for the extensions has a required value of:
xmlns:hl7ebxml=”urn:hl7-org:transport/ebxml/DSTUv1.0”

2. The next is SOAP Header Element

<soap-env:header>

The SOAP Header element is the first child element of the SOAP Envelope element. The SOAP Header contains MessageHeader which is required element containing routing information for the message as well as other context information about the message. The other element is SyncReply which is a element indicating the required transport state to the next SOAP node.

The SOAP Header element is the first child element of the SOAP Envelope element. The SOAP Header contains MessageHeader which is required element containing routing information for the message as well as other context information about the message. The other element is SyncReply which is an element indicating the required transport state to the next SOAP node.

3. The Message Header starts with Version and SOAPUnderstand attribute as shown below

<eb:MessageHeader soap-env:mustUnderstand="1" eb:version="2.0">

The REQUIRED version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".

The REQUIRED SOAP mustUnderstand attribute on SOAP Header extensions, namespace qualified to the SOAP namespace (http://schemas.xmlsoap.org/soap/envelope/), indicates whether the contents of the element MUST be understood by a receiving process or else the message MUST be rejected in accordance with SOAP [SOAP]. This attribute with a value of '1' (true) indicates the element MUST be understood or rejected.

4. The next element is the From Element

<eb:From>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP1</eb:PartyId>
</eb:From>

The REQUIRED From element identifies the Party that originated the message. It can contain logical identifier such as DUNS number or other identifiers that also imply a physical location such as an email address. It contains the Party Id element. The PartyId element has a single attribute, type and the content is a string value. The type attributeindicates the domain of names to which the string in the content of the PartyId element belongs. The value of the type attribute MUST be mutually agreed and understood by each of the Parties. It is RECOMMENDED that the value of the type attribute be a URI.

5. The next element is the To Element

<eb:To>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP2</eb:PartyId>
</eb:To>

The REQUIRED To element identifies the Party that is the intended recipient of the message. It can contain logical identifier such as DUNS number or other identifiers that also imply a physical location such as an email address. It contains the Party Id element. The PartyId element has a single attribute, type and the content is a string value. The type attribute indicates the domain of names to which the string in the content of the PartyId element belongs. The value of the type attribute MUST be mutually agreed and understood by each of the Parties. It is RECOMMENDED that the value of the type attribute be a URI.

6.The CPAId element is a string that identifies the parameters governing the exchange of messages between the parties.

<eb:CPAId>ABC22</eb:CPAId>

The recipient of a message MUST be able to resolve the CPAId to an individual set of parameters, taking into account the sender of the message. The value of a CPAId element MUST be unique within a namespace mutually agreed by the two parties. The value ABC22 reference the contract properties assigned to each service/action.

7. The ConversationId element is a string identifying the set of related messages that make up a conversation between two Parties. It MUST be unique within the context of the specified CPAId.

<eb:ConversationId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7 </eb:ConversationId>

The Party initiating a conversation determines the value of the ConversationId element that SHALL be reflected in all messages pertaining to that conversation. The ConversationId enables the recipient of a message to identify the instance of an application or process that generated or handled earlier messages within a conversation. It remains constant for all messages within a conversation. The value used for a ConversationId is implementation dependent.

8. The Service element identifies the service that acts on the message and it is specified by the designer of the service

<eb:Service>urn:org:names:services:MPI</eb:Service>

The designer of the service may be:
• a standards organization, or
• an individual or enterprise

The above value indicates that it has something to do with the Master Patient Index

9.The Action element identifies a process within a Service that processes the Message. Action SHALL be unique within the Service in which it is defined

<eb:Action>PRPA_IN040000UV15</eb:Action>

The value of the Action element is specified by the designer of the service. The above value is the message interaction that is sent with this ebXML wrapper and used for the MPI service.

10. The MessageData element provides a means of uniquely identifying an ebXML Message. It contains the following:

MessageId element
Timestamp element
RefToMessageId element

<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
</eb:MessageData>

MessageId is a globally unique identifier for each message conforming to MessageId.

Timestamp is a value representing the time that the message header was created conforming to a dateTime [XMLSchema] and MUST be expressed as UTC

RefToMessageId element has a cardinality of zero or one. When present, it MUST contain the MessageId value of an earlier ebXML Message to which this message relates. If there is no earlier related message, the element MUST NOT be present. For example if is present the Message Data will be something like

<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
<eb:RefToMessageId>39E66A20-2DD3-22B3-91FA-81CE4147A4A7 </eb:RefToMessageId>

11.The DuplicateElimination element, if present, identifies a request by the sender for the receiving MSH to check for duplicate messages

<eb:DuplicateElimination/>

12. The AckRequested element is an OPTIONAL extension to the SOAP Header used by the Sending MSH to request a Receiving MSH, acting in the role of the actor URI identified in the SOAP actor attribute, returns an Acknowledgment Message. The AckRequested element contains the following:

• a version attribute
• a SOAP mustUnderstand attribute with a value of "1"
• a SOAP actor attribute
• a signed attribute

<eb:AckRequested soap-env:mustUnderstand="1" eb:version="2.0" eb:signed="false" soap-env:actor="urn:oasis:names:tc:ebxml- msg:actor:toPartyMHS" />

The SOAP mustUnderstand attribute on SOAP Header extensions, namespace qualified to the SOAP namespace (http://schemas.xmlsoap.org/soap/envelope/), indicates whether the contents of the element MUST be understood by a receiving process or else the message MUST be rejected in accordance with SOAP [SOAP]. This attribute with a value of '1' (true) indicates the element MUST be understood or rejected.

The version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".


The AckRequested element MUST be targeted at either the Next MSH or the To Party MSH (these are equivalent for single-hop routing). This is accomplished by including a SOAP actor with a URN value with one of the two ebXML actor URNs defined in sections 2.3.10 and 2.3.11 or by leaving this attribute out. The default actor targets the To Party MSH.


The REQUIRED signed attribute is used by a From Party to indicate whether or not a message received by the To Party MSH should result in the To Party returning a signed Acknowledgment Message – containing a [XMLDSIG] Signature element . Valid values for signed are:
true - a signed Acknowledgment Message is requested, or
false - an unsigned Acknowledgment Message is requested

13.The Manifest element identifies the payload messages that are carried with the ebXML message. Manifest is included in the SOAP:Body. These references can be:

· References to the attached MIME parts using the cid reference mechanism.
· References to remote content not included in the message but accessible via other means and referenced via a URI

<eb:Manifest eb:version="2.0">
<eb:Reference xlink:href="cid:payload@hl7.com">
<eb:Schema eb:location="http://www.info.org.uk/schema/HL7-Message.xsd" eb:version="15" />
<hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />
</eb:Reference>
</eb:Manifest>

The version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".

The Reference element is a composite element consisting of the following subordinate elements:
• zero or more Schema elements – information about the schema(s) that define the instance document identified in the parent Reference element
• zero or more Description elements – a textual description of the payload object referenced by the parent Reference element

The Reference element itself is a simple link [XLINK]. In this context it has the following attribute content

xlink:href – this REQUIRED attribute has a value that is the URI of the payload object referenced. It SHALL conform to the XLINK [XLINK] specification criteria for a simple link.

The schema element provides a means of identifying the schema and its version defining the payload object identified by the parent Reference element. The Schema element contains the following attributes:
• location – the REQUIRED URI of the schema
• version – a version identifier of the schema


The final element is the payload element. This element contains style or standard to which the message in the payload conforms. In this case it is “HL7". It contains the encoding method for the standard which is used to encode the message in the payload. For HL7v3.0 we use "XML". Finally the version of the standard to which the payload message conforms and for HL7V3.0 its 3.0.