XML Implementable Technology Specification for V3 Structures
 HL7 V3 XMLITSSTR, R1-2005 9/26/2005 (Retired HL7 Standard)  |
| Editor | Matthew
Stephens matt@ramseysystems.co.uk Ramsey Systems Ltd |
| Co-Chair/Editor | Charles
McCay charlie@ramseysystems.co.uk Ramsey Systems Ltd |
| Editor | Dale
Nelson dale@zed-logic.com Zed-Logic Informatics, LLC |
| Editor | Kai
Heitmann hl7@kheitmann.nl University of Cologne (DE) / Heitmann Consulting & Services (NL) |
| Editor | Paul
Biron Paul.V.Biron@kp.org Kaiser Permanente |
| Co-Chair | Paul
Knapp pknapp@continovation.com |
Last Published: 10/03/2005 12:07 PM
HL7® Version 3 Standard, © 2005 Health Level Seven®, Inc. All Rights Reserved.
HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S. Pat & TM Off
Table of Contents
Preface
i
Acknowledgements
This standard is the result of over five years of intense work through e-mail, telephone conferences and meeting discussions. Wes Rishel (Gartner Group) was the principle author of previous drafts of DTDs for HMD-level elements and Version 3 Datatypes, Paul V. Biron (Kaiser Permanente), Skirmantas Kligys (Oracle), Joey Coyle (Intermountain Healthcare), Dale Nelson (Zed-Logic Informatics, LLC), Charlie McCay (Ramsey Systems Ltd) and Matthew Stephens (Ramsey Systems Ltd) continued this work, taking into account the use of W3c schema for XML processing. Important ideas have been contributed by Gunther Schadow, Bob Dolin (Kaiser Permanente), Vassil Peytchev (Epic), Mark Tucker (Regenstrief Institute), and George W. Beeler (Beeler consulting). Kai U. Heitmann (HL7 Germany) is the principle author of this document, and it was subsequently edited by Dale Nelson and Charlie McCay. Matthew Stephens is the current editor of this document.
ii
Prerequisites
It is a prerequisite that readers have a general knowledge of XML technology. Readers unfamiliar with XML may gain the requisite knowledge from the following standards:
iii
Assumptions
It is assumed that the reader is familiar with HL7 version 3 terminology - especially those related to message definition (HL7 information model terminology, Message Instances, Message Types, Interactions, CMETs, wrappers, etc.). For more information on these, refer to the V3 Guide
iv
Document Objective
The objective of this document is to present an Implementable Technology Specification (ITS) for the encoding rules for HL7 Version 3 messages based on the Extensible Markup Language XML.
Several XML encoding methods could serve as a messaging syntax for HL7 V3 messages. This document represents the method that is recommended by HL7, describing the underlying rules and principles. The corresponding data type descriptions necessary for this specification are described in the Data Types XML ITS.
1
Overview
1.1
Introduction and Scope
This document describes how HL7 V3 compliant messages can be expressed using XML. It describes how the definition of the set of valid XML instance documents is derived from a specific HL7 Message Type. It covers ISO levels 5 and 6. Those familiar with V2 might call these the "XML encoding rules" for HL7 Version 3 messages.
2
Mapping to the XML Instance
This section describes how an HL7 V3 Message Type can be represented in an XML instance document. The representation is determined algorithmically from the HL7 Message Type definition.
2.1
Overview
For the purposes of this document, we will be referring to HL7 V3 Message Types since they represent a fully specified, constrained, implementable definition of an HL7 V3 message in a serial tabular format. However, one should recall that HL7 Message Types are derived from higher level message definitions such as HMDs and information models (RMIMs, etc). All information contained in HL7 message types is ultimately derived from the V3 RIM. Therefore, although the Message Type is useful for defining how to create an XML instance for a message or document in an algorithmic way, the semantics may be better understood by also looking at higher level representations. For more information on HL7 V3 Message Types, HMDs, and RMIMs, please refer to the V3 Guide.
- The set of XML instances that are conformant for each message type described by an HMD has a structure with elements corresponding to class clones, and both element and attributes corresponding to class clone attributes. HL7 structural attributes of the class clone are represented as XML attributes, all other HL7 attributes are represented as child elements in the XML instance. The association names determine the names of the elements that represent the class clones.
- Some Message Type definitions refer to CMETs. This specification describes how embedded CMETs are encoded in a message instance as well.
- CDA documents are all derived from a single message type.
- To encode an HL7 message wrappers are defined to provide information both for message transmission (Transmission Wrapper) and for semantic interpretation (Control Act Wrapper). An HL7 Interaction defines a complete message including the Message Type and associated Transmission Wrapper and Control Act Wrapper. This specification describes how the wrappers are represented in an XML Message Instance.
- Each HL7 attribute has a Data Type associated with it. The XML implementation of these data types is described in a companion document - the XML ITS Data Types
2.2
XML structures derived from an HMD
The XML elements and attributes in a message instance correspond one-to-one with individual rows in the HMD with the root element representation for a transmission wrapper being the only exception. This is explained in more detail below.
Structural attributes like classCode, moodCode etc., are represented as XML attributes in the instance. Where these have fixed values defined in the HMD, they may be omitted from the instance. Where there is a default value, and the default is appropriate for the instance, the XML attribute may be omitted. Where an XML attribute has been omitted the receiving system should assume the fixed or default value as specified in the HMD.
2.3
Use of XML Namespaces
All XML elements and attributes (except for
informal extensions and the contents of ED datatypes) are to be
represented in the namespace defined by "urn:hl7-org:v3".
Attributes "type" and "nil" from the xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" namespace may be used. The "type" attribute will be used to indicate the datatype of elements where this could be ambiguous.
In this document all examples will be written
with the assumption that hl7 has been declared as a prefix
for the hl7 namespace as follows:
xmlns:hl7="urn:hl7-org:v3". Note that any valid namespace
prefix (or none) may be used in practice.
The use of namespaces within the ED datatype are discussed in the XML ITS Data Types.
XML content from other namespaces (except within an ED datatype) will be assumed to be informal extensions as described later in this document and be ignored by receiving systems that do not recognize them.
2.4
Determination of the XML representation
2.4.1
Cardinality
For each row in the HMD representing a class, attribute, or association the cardinality in the HMD sets the upper and lower limits on the number of elements that may be included in the instance which correspond to that row. Note that it is never possible to repeat structural attributes, and these are optional in the XML instances if a default or fixed value has been set.
2.4.2
Message Elements That Are HL7 Classes
The name for the element representing the Class is taken either from the association name, or in the case of the root element representation for a transmission wrapper, from the InteractionID.
Where the Class is flagged as Mandatory it must be included in the message for the message to be valid.
The XML representation of these elements are determined by the SRC column, whose value will be one of: "N", "R", "U", "I", or "C".
2.4.2.1
Associations with direct content
If the value of the SRC column is "N" or "R" then the XML representation will be a sequence of child elements, one for each HMD row of type "Attr" followed by one for each HMD row of type "Assoc" whose InMET column equals the Row column of the row in question.
Example:
<hl7:author typeCode="AUT" xmlns:hl7="urn:hl7-org:v3">
<hl7:assignedEntity classCode="ASSIGNED">
<hl7:id root="2.16.840.1.113883.2.1.4.2" extension="G0000017"/>
<hl7:code code="008"/>
</hl7:assignedEntity>
</hl7:author>
2.4.2.2
Choices
The preceding is true unless the value of OfMET contains a choice of more than one message element type. In this case, the XML representation represents the choice as a choice of one or more XML elements corresponding to those identified in the ofMET row. Each element will have content derived as described in this section from the row in the HMD with that Element Name.
If the value of the SRC column is “I” or “U” then the XML representation is the same as defined for the row in the HMD being referenced. In the case of “I” the content in the row must also be identical.
Example:
<hl7:accountHolder xmlns:hl7="urn:hl7-org:v3">
<hl7:id root="AAAABBBB-1452-6352-7363-DEA51FEA5241"/>
<hl7:heldAccountHolderPerson classCode="PSN" determinerCode="INSTANCE">
<hl7:name>
<hl7:given>Adam</hl7:given>
<hl7:family>Everyman</hl7:family>
</hl7:name>
<hl7:addr>
<hl7:streetAddressLine>
2222 Home Street
</hl7:streetAddressLine>
<hl7:city>Ann Arbor</hl7:city>
<hl7:state>MI</hl7:state>
<hl7:postalCode>99999</hl7:postalCode>
<hl7:country>USA</hl7:country>
</hl7:addr>
</hl7:heldAccountHolderPerson>
</hl7:accountHolder>
2.4.2.3
CMETs
If the value of the SRC column is "C" (i.e., the HMD row is defined by a CMET) then the XML representation of the element is determined by applying the rules in “Message Elements That Are RIM Classes” to the requisite CMET found in the OfMET column.
If the value of the SRC column is “I” or “U” then the XML representation is the same as defined for the row in the HMD being referenced. In the case of “I” the content in the row must also be identical.
Example:
<hl7:contact xmlns:hl7="urn:hl7-org:v3">
<hl7:id root="AAAA1234-ADE1-543A-CFD4-DACE42D93FAC"/>
<hl7:statusCode code="active"/>
<hl7:telecom value="tel:+441234123456"/>
<hl7:effectiveTime value="20040314"/>
<hl7:contactPerson>
....
</hl7:contactPerson>
</hl7:contact>
2.4.3
Message Elements That Are HL7 Attributes
HL7 structural attributes are conveyed as attributes. Where there is a default or fixed value defined in the HL7 static model then the attribute may be omitted from the XML representation, and the receiving system will behave as though the fixed or default value was sent. Note that according to the Refinements and Localization document "the default is a single value, once a default has been set, it may not be further constrained. Moreover, the assertion of default values may only be done by an HL7 Technical Committee as it prepares a ballot, or by an HL7 International Affiliate that is preparing a region-specific profile".
Non-structural attributes are represented as elements with the name taken from the “Element Name” in the HMD. The XML representation of these elements are determined by the OfMET. Specifically, for rows of type "Attr", the value of OfMET will be the name of a Version 3 Data Type, and hence, the XML representation will be as described in the XML ITS Data Types.
Example:
<hl7:author typeCode="AUT" xmlns:hl7="urn:hl7-org:v3">
<hl7:assignedEntity classCode="ASSIGNED">
<hl7:id root="2.16.840.1.113883.2.1.4.2" extension="G0000017"/>
<hl7:code code="008"/>
</hl7:assignedEntity>
</hl7:author>
2.4.4
Interactions
Interactions are defined for HL7v3 messages, but are not relevant for CDA documents. See the V3 Guide for further details on how and why interactions are defined and used.
Interactions are represented by an XML element named using the artifact code for the interaction. The content model of this element is determined by the Message Type for the transmission wrapper.
Where the transmission wrapper contains a Control Act class, this class is replaced by the Control Act Message Type as specified for the interaction. If the Control Act Message Type contains an entry point stub, then this is replaced by the Message Type for the payload as defined in the interaction.
The Interaction element must have an attribute “ITSversion” that provides a version identifier for the XML ITS (Datatypes and Structures) that is to be used.
2.5
Informal Extensions
In order to support informal extensions as described in the HL7 V3 Conformance and extensibility specification, it is permitted to include additional XML elements and attributes that are not included in the HL7 definition of a message type. These extensions should not change the meaning of any of the standard data items, and receiving applications must be able to safely ignore these elements.
When included in an instance local extensions MUST be in a namespace other than the HL7v3 namespace. Such extensions must not be included within an ED datatype, since it would not always be possible to distinguish between foreign namespace items that form part of the content of the standard ED datatype, and content that was intended to be an informal extension. Since all conformant content (outside of elements of type ED) is in the HL7 namespace, the sender can put any extension content into a foreign namespace (any namespace other than the HL7 namespace), and the receiver will be able to recognise that such content may be safely ignored. However, attributes in the xsi namespace should not be considered as foreign for the purposes of deciding whether content is an informal extension. Receiving systems must not report an error if such extensions are present.
Example:
<hl7:inFulfillmentOf xmlns:hl7="urn:hl7-org:v3">
<hl7:priorActRequest>
<ex:MessageRequests
xmlns:ex="http://www.example.com/messaging">
<ex:RequestedMessage>
001-345-234
</ex:RequestedMessage>
</ex:MessageRequests>
</hl7:priorActRequest>
</hl7:inFulfillmentOf>
2.6
Backwards and Forwards compatibility
When there are different versions of either the abstract HL7 artifact definitions, or of the ITS, it is anticipated that these versions will be no more than a single XSLT transform apart.
While setting the rules for version compatibility between different versions of the same HL7v3 artifact is beyond the scope of this specification, it is anticipated that it will be possible to generate XSLT transformations to convert between versions. There may be changes in valuesets for domains that need to be addressed in some other way, but again this is beyond the scope of an ITS specification.
It is a constraint on the definition of future versions of the XML ITS that it must be possible to write an XSLT transformation to map between instances of the same artifact created under the different versions of the ITS.
2.7
The Use of Schema Processors
Schema processing is not a conformance requirement although this specification has been designed to make schema processing beneficial. Where schemas are used receivers may use alternate schemas (including DTDs) than the ones provided by HL7.
Sending applications should not provide schema location hints for the HL7 namespace and receiving applications that perform schema processing should ignore such hints if provided and instead should use whatever other means they have at their disposal to locate the relevant official HL7 schemas or their own customizations thereof. It is in the interest of the receivers own security and safety not to use sender supplied schemaLocation hints.
3
References
[rfDatatypes1]
HL7Version 3
Data Types Abstract
[rfDatatypes2]
HL7
Version 3 ITS XML Data Types
[rfXMLschema]
World Wide Web Consortium. XML Schema.
http://www.w3.org/TR/xmlschema-0/
http://www.w3.org/TR/xmlschema-1/
http://www.w3.org/TR/xmlschema-2/
World Wide Web Consortium. XML Schemas Part 1: Structures.
http://www.w3.org/TR/xmlschema-1/
World Wide Web Consortium. XML Schemas Part 2: Datatypes.
http://www.w3.org/TR/xmlschema-2/
[rfXML]
World Wide Web Consortium. Extensible Markup Language, 1.1 W3C
Recommendation 04 February 2004.
http://www.w3.org/TR/2004/REC-xml11-20040204/
[rfXMLnamespace]
World Wide Web Consortium. Namespaces in XML.
http://www.w3.org/TR/REC-xml-names/
[rfXPath]
World Wide Web Consortium. XML Path Language.
http://www.w3.org/TR/xpath/
[rfXSLT]
World Wide Web Consortium. XSL Transformations (XSLT).
http://www.w3.org/TR/xslt/
[rfV3guide]
Version 3 Guide.
http://www.hl7.org/home/content/HTML-menus/V3Guide.htm
{rfV3Glossary}
Version 3 Glossary
4
Appendix A
4.1
Example Instance for an Interaction
The following is an example instance for the interaction "PRPA_IN040301" taken from the emergency encounter topic in the patient administration domain.
<?xml version="1.0" encoding="utf-8"?>
<!--Example copyright 2004 by Health Level Seven, Inc. -->
<!-- Example message for PRPA_IN403001 - Emergency
Encounter Started interaction -->
<hl7:PRPA_IN403001 xmlns:hl7="urn:hl7-org:v3">
<hl7:id root="2.16.840.1.113883.1.6"
extension="1-976-245"
displayable="true"/>
<hl7:creationTime value="20040927100100"/>
<hl7:versionCode code="V3PR1"/>
<hl7:interactionId root=" 2.16.840.1.113883.2.1.3.2.4.12"
extension=" PRPA_IN403001" displayable="true"/>
<hl7:processingCode code="P"/>
<hl7:processingModeCode code="T"/>
<hl7:acceptAckCode code="AL"/>
<hl7:receiver>
<hl7:device>
<hl7:id root="2.16.840.1.113883.19.3.2408"
extension="123" displayable="true"/>
<hl7:name use="L">
<hl7:given>Good Health Lab System</hl7:given>
</hl7:name>
</hl7:device>
</hl7:receiver>
<hl7:sender>
<hl7:device>
<hl7:id root="2.16.840.1.113883.19.3.2409"
extension="456" displayable="true"/>
<hl7:name use="L">
<hl7:given>
Good Health Patient Admin System
</hl7:given>
</hl7:name>
</hl7:device>
</hl7:sender>
<!-- ControlAct starts here -->
<hl7:controlActProcess>
<hl7:code code="PRPA_TE403001"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="HL7TriggerEventCode"/>
<hl7:effectiveTime value="20040927095000"/>
<hl7:authorOrPerformer typeCode="AUT">
<hl7:assignedEntity classCode="PRS">
<hl7:id root="2.16.840.1.113883.19.3.2409"
extension="10001" displayable="true"/>
<hl7:telecom value="tel:+1(955)555-1005" use="MC"/>
<hl7:telecom value="mailto:admit@eg.net"/>
<hl7:assignee>
<hl7:assigneePerson>
<hl7:name use="L">
<hl7:given>Eric</hl7:given>
<hl7:family>Emergency</hl7:family>
</hl7:name>
</hl7:assigneePerson>
</hl7:assignee>
</hl7:assignedEntity>
</hl7:authorOrPerformer>
<hl7:dataEnterer>
<hl7:time value="20040927100000"/>
<hl7:assignedEntity classCode="PRS">
<hl7:id root="2.16.840.1.113883.19.3.2409"
extension="10055" displayable="true"/>
<hl7:assignee>
<hl7:assigneePerson>
<hl7:name use="L">
<hl7:given>Christopher</hl7:given>
<hl7:family>Clerk</hl7:family>
</hl7:name>
</hl7:assigneePerson>
</hl7:assignee>
</hl7:assignedEntity>
</hl7:dataEnterer>
<hl7:subject>
<!--Example payload for Emergency Encounter Started
(PRPA_MT403001) -->
<hl7:encounterEvent>
<hl7:id root="2.16.840.1.113883.19.3.2409"
extension="12345" displayable="true"/>
<hl7:code code="EMER"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode" displayName="emergency"/>
<hl7:statusCode code="active"/>
<hl7:effectiveTime>
<hl7:low value="20040927095000" inclusive="true"/>
</hl7:effectiveTime>
<hl7:priorityCode code="EM"
codeSystem="2.16.840.1.113883.5.7"
codeSystemName="ActPriority"
displayName="emergency"/>
<hl7:confidentialityCode code="N"
codeSystem="2.16.840.1.113883.5.25"
codeSystemName="Confidentiality"
displayName="normal"/>
<hl7:reasonCode code="MEDNEC"
codeSystem="2.16.840.1.113883.5.8"
codeSystemName="ActReason"
displayName="Medical_Necessity"/>
<hl7:admissionReferralSourceCode code="7"
codeSystem="2.16.840.1.113883.5.39"
codeSystemName="EncounterReferralSource"
displayName="Emergency_Room"/>
<hl7:specialCourtesiesCode code="NRM"
codeSystem="2.16.840.1.113883.5.40"
codeSystemName="EncounterSpecialCourtesy"
displayName="norrmal_courtesy"/>
<hl7:subject>
<hl7:patient>
<hl7:id root="2.16.840.1.113883.19.3.2409"
extension="444551234" displayable="true"/>
<hl7:addr use="HP">
<hl7:streetAddressLine>
2222 Home Street
</hl7:streetAddressLine>
<hl7:city>Ann Arbor</hl7:city>
<hl7:state>MI</hl7:state>
<hl7:postalCode>99999</hl7:postalCode>
<hl7:country>USA</hl7:country>
</hl7:addr>
<hl7:patientLivingSubject>
<hl7:birthplace>
<hl7:addr use="BIR">
Ann Arbor, MI USA
</hl7:addr>
</hl7:birthplace>
<hl7:name>Adam A Everyman</hl7:name>
<hl7:administrativeGenderCode code="M"
codeSystem="2.16.840.1.113883.5.1"
codeSystemName="AdministrativeGender"
displayName="Male"/>
<hl7:birthTime value="19550304"/>
</hl7:patientLivingSubject>
<hl7:providerOrganization>
<hl7:id root="2.16.840.1.113883.19.3.2409"
extension="1-976-245" displayable="true"/>
<hl7:name use="L">
<hl7:suffix qualifier="LS">
Inc.
</hl7:suffix>
Good Health Hospital
</hl7:name>
<hl7:addr use="HP">
<hl7:streetAddressLine>
2222 Hospital Street
</hl7:streetAddressLine>
<hl7:city>Ann Arbor</hl7:city>
<hl7:state>MI</hl7:state>
<hl7:postalCode>99999</hl7:postalCode>
<hl7:country>USA</hl7:country>
</hl7:addr>
</hl7:providerOrganization>
</hl7:patient>
</hl7:subject>
<hl7:admitter>
<hl7:time>
<hl7:low value="20040927095000"
inclusive="true"/>
</hl7:time>
<hl7:assignedPerson classCode="PRS">
<hl7:id root="2.16.840.1.113883.19.3.2409"
extension="10001" displayable="true"/>
<hl7:telecom value="tel:+1(955)555-1005"
use="MC"/>
<hl7:telecom value="mailto:admit@eg.net"/>
<hl7:assignee>
<hl7:assigneePerson>
<hl7:name use="L">
<hl7:given>Eric</hl7:given>
<hl7:family>Emergency</hl7:family>
</hl7:name>
</hl7:assigneePerson>
</hl7:assignee>
</hl7:assignedPerson>
</hl7:admitter>
<hl7:attender>
<hl7:time>
<hl7:low value="20030927095000"
inclusive="true"/>
</hl7:time>
<hl7:statusCode code="active"/>
<hl7:assignedPerson classCode="PRS">
<hl7:id root="2.16.840.1.113883.19.3.2409"
extension="10001" displayable="true"/>
<hl7:telecom value="tel:+1(955)555-1006"
use="MC"/>
<hl7:telecom value="mailto:attend@eg.net"/>
<hl7:assignee>
<hl7:assigneePerson>
<hl7:name use="L">
<hl7:given>Eric</hl7:given>
<hl7:family>Emergency</hl7:family>
</hl7:name>
</hl7:assigneePerson>
</hl7:assignee>
</hl7:assignedPerson>
</hl7:attender>
<hl7:location>
<hl7:time>
<hl7:low value="20040927095000"
inclusive="true"/>
</hl7:time>
<hl7:statusCode code="active"/>
<hl7:serviceDeliveryLocation>
<hl7:code code="ER"
codeSystem="2.16.840.1.113883.5.111"
codeSystemName="RoleCode"
displayName="Emergency_room"/>
<hl7:statusCode code="active"/>
<hl7:location>
<hl7:name>ER - Room 4 - Bed B</hl7:name>
</hl7:location>
</hl7:serviceDeliveryLocation>
</hl7:location>
<hl7:notificationContact>
<hl7:notificationParty>
<hl7:id root="2.16.840.1.113883.19.3.2409"
extension="1-976-245" displayable="false"/>
<hl7:addr use="HP">
<hl7:streetAddressLine>
5555 Home Street
</hl7:streetAddressLine>
<hl7:city>Ann Arbor</hl7:city>
<hl7:state>MI</hl7:state>
<hl7:postalCode>99999</hl7:postalCode>
<hl7:country>USA</hl7:country>
</hl7:addr>
<hl7:telecom value="tel:+1(555)555-2010"
use="H"/>
<hl7:contactParty>
<hl7:Person>
<hl7:id root="2.16.840.1.113883.19.3.2409"
extension="1-976-245" displayable="false"/>
<hl7:name use="L">
<hl7:given>Carrie</hl7:given>
<hl7:given>C</hl7:given>
<hl7:family>Contact</hl7:family>
</hl7:name>
<hl7:administrativeGenderCode code="F"
codeSystem="2.16.840.1.113883.5.1"
codeSystemName="AdministrativeGender"
displayName="Female"/>
</hl7:Person>
</hl7:contactParty>
</hl7:notificationParty>
</hl7:notificationContact>
<hl7:pertinentInformation1>
<hl7:valuablesLocation negationInd="false">
<hl7:text mediaType="text/plain">
Mr. Everyman's valuables were checked into
patient valuables location ER-3.
</hl7:text>
<hl7:value mediaType="text/plain">
Mr. Everyman arrived with a wedding ring,
a Timex watch, a wallet with $35 and an
American Express credit card, and a set of
house and car keys. These items were stored
for safekeeping during his stay.
</hl7:value>
</hl7:valuablesLocation>
</hl7:pertinentInformation1>
<hl7:pertinentInformation2>
<hl7:priorityNumber value="1"/>
<hl7:observationDx negationInd="false">
<hl7:code code="ADMDX"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"
displayName="admitting_diagnosis"/>
<hl7:statusCode code="active"/>
<hl7:value code="518.82"
codeSystem="2.16.840.1.113883.5"
codeSystemName="ICD9" codeSystemVersion="9"
displayName="Acute Respiratory Distress"/>
</hl7:observationDx>
</hl7:pertinentInformation2>
<hl7:arrivedBy contextControlCode="OP"
contextConductionInd="true" typeCode="ARR">
<hl7:transportationEvent moodCode="EVN">
<hl7:text mediaType="text/plain">
Ambulance
</hl7:text>
</hl7:transportationEvent>
</hl7:arrivedBy>
</hl7:encounterEvent>
</hl7:subject>
</hl7:controlActProcess>
</hl7:PRPA_IN403001>
5
Appendix B
5.1
RIM structural attributes
The RIM structural attributes are enumerated below.
| Act | moodCode |
| Act | classCode |
| Act | negationInd |
| Act | levelCode |
| ActRelationship | typeCode |
| ActRelationship | ActRelationship inversionInd |
| ActRelationship | contextControlCode |
| ActRelationship | contextConductionInd |
| ActRelationship | negationInd |
| Entity | classCode |
| Entity | determinerCode |
| Participation | typeCode |
| Participation | contextControlCode |
| Role | classCode |
| Role | negationInd |
| RoleLink | typeCode |