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"/>
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.
