1 HL7 Version 3-METL Description

3 January 26, 1999

HL7 Version 3-Message Element Type Language 1 January 26, 1999

 1
2 Contents
3
4 Introduction............................................................................................................................................ 3
5 Introductions to Types and Components................................................................................................ 3
6 Context................................................................................................................................................. 3
7 Definitions............................................................................................................................................ 4
8 Message Element Type/Message Element Instance Model.................................................................... 5
9 The Message Element Type Model ....................................................................................................... 7
10 The Message Element Type Language ................................................................................................... 8
11 The 'MESSAGE' Message Element Type .............................................................................................. 8
12 The COMPOSITE Message Element Type.......................................................................................... 10
13 The PRIMITIVE Message Element Type ............................................................................................ 10
14 The LIST Message Element Type ....................................................................................................... 10
15 The CHOICE Message Element Type ................................................................................................. 11
16 METL Syntax..................................................................................................................................... 11
17 Relationship to the RIM...................................................................................................................... 12
18 An Ersatz Message Object Diagram ................................................................................................ 12
19 Mapping the METL to the XML DTD................................................................................................. 14
20 Name Collisions and the Indiana Dot Notation .................................................................................... 14
21 Representing 'Message' Message Element Types ................................................................................ 15
22 Representing Composite Message Element Types ............................................................................... 15
23 Representing List Message Element Types.......................................................................................... 16
24 Representing Choice Message Element Types ..................................................................................... 16
25 Representing Primitive Message Element Types................................................................................. 16
26 Use of XML Attributes ....................................................................................................................... 17
27 A Naming Anomaly............................................................................................................................ 17
28 Parameter Entities............................................................................................................................... 17
29 Full DTD and XML Instance Example for the Toy Message................................................................ 18
30
31 Figures
32
33 Figure 1. Version 3 process....................................................................................................................... 4
34 Figure 2. Message Element Type and Instance Object Models ................................................................... 6
35 Figure 3. Message Element Type Metamodel. ........................................................................................... 7
36 Figure 5. Toy example of MTL. ................................................................................................................ 9
37 Figure 6. MET Language Syntax. ........................................................................................................... 12
38 Figure 7. Ersatz MOD notation. .............................................................................................................. 13
39 Figure 8. DTD for the Toy Message........................................................................................................ 18
40 Figure 9. XML Instance Example for the Toy Message. .......................................................................... 21
41

HL7 Version 3-Message Element Type Language 2 January 26, 1999

 1 Introduction
2 The HL7 Message Element Type Language (METL) is a technology-neutral way of describing a version 3 message.
3 Its capabilities overlap that of the HMD. Indeed, it was conceived as an interim measure pending the availability of
4 HMD software. It is quite likely that it will cease to exist when the HMD software is available.
5 In the meantime, however, it has been used to express message content for the HL7 Version 3 Messaging prototype
6 to be demonstrated at the HIMSS trade show in February, 1999. A compiler has been written that accepts a message
7 definition in METL and produces an XML DTD along with a "skeleton" sample XML message instance. The
8 skeleton has instances of all the elements that the DTD will generate, given the message type the root. However the
9 data that is present in each message is either "XXXMANDATORY" or "XXXOPTIONAL". It is frequently easier to
10 build meaningful examples by editing the skeleton then by starting from scratch.
11 This is a first draft of the document. All caveats known to Man or conceivable by lawyers apply.

12 Introductions to Types and Components

13 Programming language-ish examples:
14 Type Point Contains
15 X of type Real
16 Y of Type Real
17
18 Type Line Contains
19 Start of Type Point
20 End of Type Point
21
22 Variable A of type Line
23
24 A.Start is a Point
25 A.Start.X is a Real.
26 A is a variable.
27 X, Y, Start, and End are not variables. They are Components. No memory is allocated anywhere
28 for an X until the declaration for variable A.
29 In general, types can be atomic or contain Components, each of which has a name and a type.
30 We must be careful with this analogy, because HL7 doesn’t have variables. HL7 has types and instances.
31 HMDs define message types. However, HMDs contain a lot more than simply the message type, and this additional
32 information is also a normative part of the standard. The additional information includes semantics and business
33 rules. More on this later.

34 Context
35 Figure 1, reproduced from MDF-98, helps to place this discussion in context. (As discussed below, the caption for
36 the gray area will change from “Defining a Message Structure” to “Defining a Message Type” in MDF-99). XML is
37 an ITS. There may be other ITSs. One of the primary benefits of XML is that the small boxes at the bottom labeled
38 HL7 Message Creation and HL7 Message Parsing can rely on ubiquitous standard programs when the message
39 instance is an XML document.

HL7 Version 3-Message Element Type Language 3 January 26, 1999

 Defining a Message Structure
Use Case
Reference Model
Domain
Information Information
Model Model Interaction
Model

Message
Object
Message Diagram
Information
Model

Common
Hierarchical
Message
Message
Element
Description
Definition

Sending a Message Instance

ITS
HL7 HL7
Message
Message Message
Data Data
Creation Instance Parsing
Implementation
Technology HL7-Conformant HL7-Conformant
Specifications Application Application
1
2 Figure 1. Version 3 process.

3 Definitions
4 An italicized term in the definitions is the subject of another definition. This section does not repeat the definition of
5 terms from MDF-98 that have not changed, unless important to the exposition.
choice message element A composite message element type for which only one of the components
type will be sent in an instance.
common message element Certain message element types are defined in Common Message Element
type Definitions. These are defined separately from their use as the type of a
Component in their HMD.
composite message A message element type that contains other message elements (components).
element type Each component message element has a name and a type. Each component
of an element must have a different name, although many may be of the
same type.
Hierarchical Message A metaobject that defines message types. It also defines the linkages of the
Definition (HMD) message types to Interactions and the linkages of certain message element
types to attributes of the Reference Information Model.
instance An utterance that conforms to a type. See message instance, message
element instance, etc.
MDF-98 The Message Development Framework for Version 3, published by HL7 in
January, 1998.

HL7 Version 3-Message Element Type Language 4 January 26, 1999

 message A message element that is the unit of information interchange among
information systems conforming to HL7 Application Roles.
message message element A particular composite message element type which expresses an entire
type message.
message element The basic unit of structure of a version 3 message. Message elements can
contain other message elements. Message elements may contain other
message elements.
message element instance An actual set of data that is part of an actual message.
Message Element Instance A graph of objects that represent a message instance. Each node represents a
Model message element instance.
message element type A specification for the values that a message element can take on in its
instances.
Message Element Type A graph of objects that represent a message type. Each node represents a
Model message element type.
message instance An actual message element instance corresponding to a message type.
message type The type of a message. A message type is always a single message element
type, although the type will contain many components.
pointy-bracket syntax A syntax that generates a subset of all XML productions. Instances in the
subset don’t contain any meta-information.
primitive message element A message element type that does not contain other message elements
type
public message element When defining a message element in an HMD, the type that is assigned to a
type component may be defined within the HMD or it may be defined externally.
A message element type that is defined externally to an HMD is an external
message element type. Public message element types include common
message element types and primitive message element types.
type A description that describes the formulation or allowable values for
numerous instances, which are not necessarily identical. For example the
type “integer” describes a number of instances including 1, 2, 1.235 x 2027,
and –379. See message type, message element type, etc.
1

2 Message Element Type/Message Element Instance Model

3 Conceptually, the dark gray portion of Figure 1 could be replaced with Figure 2. The HL7 Instance Object Model is
4 a collection of objects (instances) drawn here as a graph. The nodes are instances of message elements; each is an
5 instance of a message element type as defined in the HMD. The solid edges represent containment and the broken-
6 line edges represent pointers.
7

HL7 Version 3-Message Element Type Language 5 January 26, 1999

 HL7-Conformant Application Hierarchical
Msg Element Message
Instance
Definition
Msg Element HL7 Version
ITS-Specific Msg Element Instance HL7 Message 3.X
Software Instance
Processing Data Message
Agent Element
Sending a Message Instance
Msg Element
Instance
Type

Message Message Message

Element Element Element
Msg Element Msg Element Type Type
Type
Instance Instance
HL7 Message Message
Element Element
Instance Object Model Type Type

HL7 Type Object Model, v3.X

ITS-Specific
Transfer
Mechanism Message
Element
Type

Msg Element Message Message Message

Instance Element Element Element
Type Type Type
Msg Element Message Message
Msg Element Instance
Element Element
Instance Type Type
ITS-Specific
Software Msg Element HL7 Type Object Model, v3.Y
Instance
Agent Hierarchical
HL7 Message
Message
Msg Element Msg Element Processing Data
Instance Instance
Definition
HL7 HL7 Version
Instance Object Model 3.Y
HL7-Conformant Application
1
2
3 Figure 2. Message Element Type and Instance Object Models
4 The word “conceptually” is an important part of the preceding paragraph. HL7 has traditionally not seen fit to
5 standardize the design of software. Current ideas conformance testing in version 3 envision the entire “HL7-
6 Conformant Application” as a black box.
7 HL7 has, however, written recommendations for object models of messages. That is what SIGOBT had done and is
8 doing.
9 We also conceptually think of the portion of the HMD that represents type information as the message element type
10 model. We can further note that the type model that was used to create the message is that of the sender. The
11 message element instance model that is built in the receiver’s space may not correspond exactly to its message
12 element type model. These conceptual definitions allow us to define the matching process as an algorithm that
13 simultaneously steps between nodes of the Instance Object Model and makes matching steps among nodes of the
14 Type Object Model.
15 (Personal note: I visualize this as a “tree dance”. The tree dance is two tree-walks occurring together, with one foot
16 walking the nodes of the type model and the other walking the nodes of the instance model.)
17 An important principal is that the logic to do the tree dance, and to process the data that is retrieved from the
18 instance tree, is the same no matter what ITS was used to create the instance tree. In other words, the services
19 provided by the message element instance nodes are defined without regard to the ITS.
20 One can ponder the relationship between the Message Element Instance object and a node in the XML Document
21 Object Model. Our chosen use of XML permits the ITS-specific software agent to implement the Message Element

HL7 Version 3-Message Element Type Language 6 January 26, 1999

1 Instance object as a wrapper around XMLNode or some other important interface in the XML document object
2 model.

3 The Message Element Type Model

4 Figure 3 is the message element model.

Ve rsi o n 1 .3 -
Ja n u a ry 2 5 , 1 9 9 9

+Bra nc hTy pe
Me s s a ge_e lem e nt_ ty pe
+C om pon ent Ty pe 1 1
nam e : String
is _ c om m on_ ty p e : b oolean 1

is _o f_t y pe

C o m pos it eMET
Prim it iv eMET C h oic eMET Lis tMET
is _ s eg m e nt : bo ole an
dat a t y pe : I D m in_ c ard : Int ege r
1 m a x _c a rd : I nte ger

+Bra nc h 1.. *
C h oic eBranc hD es c ript or
1.. *
C o m pone ntD e s c rip tor
+C om pon ent tag _v alue : St ring
nam e : String is _ of _ty pe
is _ opt ional : boolea n
0.. *
is _o f_t y pe s equ enc e : int eger Me s s a geMet
loc ale : ID
5
6 Figure 3. Message Element Type Metamodel.

HL7 Version 3-Message Element Type Language 7 January 26, 1999

 1 The Message Element Type Language
2 The message element type language (METL) is an experiment at expressing HL7 version 3 message definitions
3 using a linear language rather than the HMD. At this point the METL does not begin to express all the notions that
4 could be expressed in the HMD. Some of the other HMD notions have been expressed as comments in the METL
5 source for the purpose of creating the demo.
6 Figure 4 is a toy example of a message definition in METL. It purports to be a query for patient information. They
7 system issuing the query must send primary_name_type_cd and primary_prsnm; in addition it may send a
8 Stakeholder_id or a list of phone numbers (phone_number_list ).
9 Remember from the Message Element Type model that all message element types are one of these metatypes.
10 • composite
11 • list
12 • choice
13 • primitive.
14
15 There should be a fifth metaype: message.
16 Each statement of the METL defines an instance of a type. Element Type metamodel, previous described in this
17 document.
18 The following is true for every message element type:
19 • it has a long name
20 • it has a short name (an abbreviation of the long name that is used in building the XML)
21 • it defines a type. The type may be used in other message element type definitions; if so it is used by
22 referring to the short name.
23 • it may be declared to be public. This means that it is intended to be shared broadly among different
24 message definitions.
25
26 There are statements in the METL to define message elements of each of the metatypes, plus a few others.

27 The 'MESSAGE' Message Element Type

28 Line 4 in the example defines a message (in this case the only message defined in this source file.)
29 MESSAGE TYPE QRYNam_Patient_Reg [QRgNamv3P00] CONTAINS {
30 Message_header [MSGH] MANDATORY OF TYPE MSGH
31 QryPatient_person_Nam [QPTNAM] MANDATORY OF TYPE QPTNAM
32 }
33
34 The long name is QRYNam_Patient_Reg, and the short name is QRgNamv3P00. As with any type definition, the short name is the name of
35 the type it defines.

36 The message comprises two components. Each has a name, a short name, and is "of a type". Note that in this
37 example the short name and the type name are the same. This is very common in HL7. There are not likely to be two
38 different components of a message, both of type MSGH (message header) so it doesn't make much sense to waste
39 brainpower trying to find an original name. As we will soon see, this is a common occurrence, but it does not
40 happen all the time.

HL7 Version 3-Message Element Type Language 8 January 26, 1999

 1 Figure 4. Toy example of MTL.
2 # Query by primary_prsnm message QRgNamv3P00
3
4 MESSAGE TYPE QRYNam_Patient_Reg [QRgNamv3P00] CONTAINS {
5 Message_header [MSGH] MANDATORY OF TYPE MSGH
6 QryPatient_person_Nam [QPTNAM] MANDATORY OF TYPE QPTNAM
7 }
8 COMPOSITE TYPE QryPatient_person_Nam [QPTNAM] CONTAINS {
9 primary_name_type_cd [primrNamType] MANDATORY OF TYPE CE
10 primary_prsnm [primrPrsnm] MANDATORY OF TYPE PN
11 Stakeholder_id [StkID] OPTIONAL OF TYPE StkID
12 phone_number_list [PhonNmbr_L] OPTIONAL OF TYPE PhonNmbr_L
13 }
14 COMPOSITE TYPE Stakeholder_ID [StkID] CONTAINS {
15 id [id] MANDATORY OF TYPE ST
16 identifier_type_cd [idType] MANDATORY OF TYPE ID # Values for demo:
17 # UPIN
18 # MRN
19 }
20 #-----------------------------------------------------------------------
21 # HL7 PUBLIC TYPE DEFINITIONS
22 #------------------------------------------------------------------------
23 PUBLIC COMPOSITE TYPE Message_header [MSGH] CONTAINS {
24 sending_application [sndApp] OPTIONAL OF TYPE ID
25 receiving_application [rcvgApp] OPTIONAL OF TYPE ID
26 date_time_message [msgDt] OPTIONAL OF TYPE DTM
27 message_type [msgTyp] MANDATORY OF TYPE MSGT
28 }
29 PUBLIC COMPOSITE TYPE Message_type [MSGT] CONTAINS {
30 message_id [msgID] MANDATORY OF TYPE ID
31 interaction_id [intrId] OPTIONAL OF TYPE ID
32 }
33 PUBLIC COMPOSITE TYPE Person_name [PN] CONTAINS {
34 family_name [fmn] MANDATORY OF TYPE ST
35 given_name [gvn] OPTIONAL OF TYPE ST
36 middle_initial_or_name [mdn] OPTIONAL OF TYPE ST
37 suffix [sfx] OPTIONAL OF TYPE ST # e.g., JR or III
38 }
39 PUBLIC COMPOSITE TYPE Coded_element [CE] CONTAINS {
40 identifier [cd] MANDATORY OF TYPE ST
41 identifier_text [tx] OPTIONAL OF TYPE ST
42 name_of_coding_system [cs] MANDATORY OF TYPE ST
43 alt_identifier [acd] OPTIONAL OF TYPE ST
44 alt_identifier_text [atx] OPTIONAL OF TYPE ST
45 alt_name_coding_system [acs] OPTIONAL OF TYPE ST
46 }
47 PUBLIC LIST TYPE Patient_Phone_Number_List [PhonNmbr_L] INCLUDES 1..N
48 OF TYPE XTN_C
49
50 CHOICE TYPE Electronic_contact_address [XTN_C] SELECTS
51 {
52 E: email_address [emailAddr] OF TYPE ST
53 T: Extended_telecomm_id [ExtndTelId] OF TYPE XTN
54 }
55 PUBLIC COMPOSITE TYPE Extended_telecomm_address [XTN] CONTAINS {
56 telecom_use_code [tlcmnUse] MANDATORY OF TYPE CE # Table 201
57 telecomm_equipment_type [tlcmnEqpTyp] MANDATORY OF TYPE CE # Table 202
58 country_code [cntryCode] OPTIONAL OF TYPE NM
59 area_city_code [areaCityCode] OPTIONAL OF TYPE NM
60 phone_number [phonNmbr] MANDATORY OF TYPE NM
61 extension [xtnsn] OPTIONAL OF TYPE NM
62 any_text [anytxt] OPTIONAL OF TYPE TX
63 }
64 PUBLIC PRIMITIVE TYPE text_for_humans_to_read [TX]
65 PUBLIC PRIMITIVE TYPE string [ST]
66 PUBLIC PRIMITIVE TYPE ID [ID]
67 PUBLIC PRIMITIVE TYPE numeric [NM]
68 PUBLIC PRIMITIVE TYPE date_time [DTM]
69

HL7 Version 3-Message Element Type Language 9 January 26, 1999

1 In this example, the keyword MANDATORY appears in for each component. That means that it must appear in each
2 message occurrence. It is also possible to sat OPTIONAL.

3 The COMPOSITE Message Element Type

4 The first component of the message is Message_header. It has the short name MSGH and it is also of type MSGH.
5 Let's drill down and look at the subcomponents of this component. To do that, we find a message element type
6 definition whose short name is MSGH. (Hint: look at line 23.)
7 PUBLIC COMPOSITE TYPE Message_header [MSGH] CONTAINS {
8 sending_application [sndApp] OPTIONAL OF TYPE ID
9 receiving_application [rcvgApp] OPTIONAL OF TYPE ID
10 date_time_message [msgDt] OPTIONAL OF TYPE DTM
11 message_type [msgTyp] MANDATORY OF TYPE MSGT
12 }
13 It is another composite, which itself has four components. The first component of MSGH is sending_application
14 short name sndApp which is of type ID.

15 The PRIMITIVE Message Element Type

16 Let's drill down again, by finding the definition of the type ID. (Line 66).
17 PUBLIC PRIMITIVE TYPE ID [ID]
18
19 In this example the long name and the short name are the same: ID.
20 Here we find an element type that is of a different metatype: primitive. METL doesn't tell us anything about the
21 syntax of an ID, except that there is no more type drilldown.
22 This drilldown is building a hierarchy of components within components. It is common to represent a hierarchy in
23 outline form. Here's what we have so far (just using short names)
24 QRgNamv3P00 contains {
25 MSGH OF TYPE MSGH, which contains (
26 sndApp OF TYPE ID
27
28 If we finish the components of MSGH, it looks like this
29 QRgNamv3P00 contains {
30 MSGH OF TYPE MSGH, which contains (
31 sndApp OF TYPE ID
32 rcvgApp OF TYPE ID
33 msgDt OF TYPE DTM
34 msgTyp OF TYPE MSGT contains {
35 msgID OF TYPE ID
36 intrId OF TYPE ID
37 }
38 }
39 QPTNAM etc,
40 }

41 The LIST Message Element Type

42 If we drill down into the QPTNAM message element we find a component named Patient_Phone_Number_List
43 [PhonNmbr_L] of type PhonNmbr_L. The definition of the PhonNmbr_L type (line 47) introduces a new metatype:
44 a list.
45 PUBLIC LIST TYPE Patient_Phone_Number_List [PhonNmbr_L] INCLUDES 1..N
46 OF TYPE XTN_C
47
48 Any element of type PhonNmbr_L will contain a repeating set of elements of type XTN_C, which will have at least
49 one entry.
50 The MET Language allows the cardinality to be 0..N, 1..N, or expressions like 0..5 or 4..7. If the lower limit is other
51 than 0 or 1, or if an integer is used for the upper limit, instead of N, this information is lost when the METL is

HL7 Version 3-Message Element Type Language 10 January 26, 1999

 1 translated into a DTD. The DTD only has the ability to express (0..N) or (1..N). The other values are rare. Where
2 they might exist, they constitute business rules, which might be expressed in an XML attribute.

3 The CHOICE Message Element Type

4 Drilling down further to the definition of XTN_C (line 50) we find an example of the last metatype: choice.
5 CHOICE TYPE Electronic_contact_address [XTN_C] SELECTS
6 {
7 E: email_address [emailAddr] OF TYPE ST
8 T: Extended_telecomm_id [ExtndTelId] OF TYPE XTN
9 }
10
11 This type definition says that some message instances will have an element of emailAddr of type ST, whereas others
12 will have an element of named ExtndTelId of type XTN. The letters E and T are tag values. Although these are
13 included in the XML representations of messages, they serve no real purpose. They will be required if we also have
14 an ER7 representation.
15 A CHOICE message element type is similar to a composite, in that it lists one or more components that may occur.
16 However, unlike a composite, only one of the listed components may occur. The keyword SELECTS is used instead
17 of CONTAINS to emphasize the distinction.
18 The choice message element type is used systematically to describe the information structure associated with
19 specialized instances in a message. It can also serve ad hoc to solve specific message design problems. For example,
20 the current definition of Clinical_observation includes many attributes that are only sensible for specific values of
21 value_type_cd. The responsible committee, however, has not chosen to model this with specializations of
22 Clinical_observation. The message designer has the option of making these optional (even though they may really
23 be required for specific values of value_type_cd) or constructing an ad hoc choice to correctly require certain
24 attributes based on the value type.

25 METL Syntax
26 Lexical notes: any white space is allowed between any syntax elements. This includes newlines. Newlines are
27 required, however, where they appear in the syntax.
28 “<include filepath>” appearing in column 1 (with the angle brackets) terminates processing of the current file and
29 continues with the file at filepath.

HL7 Version 3-Message Element Type Language 11 January 26, 1999

 1 Figure 5. MET Language Syntax.
2 <ROOT> ::= (<MsgMet> | <CompMet> | <PrimMet> | <ListMet> | <ChoiceMet> )+
3 endfile
4
5 <MsgMet> ::= ('MESSAGE' 'TYPE' <longName> '[' <shortName> ']' 'CONTAINS' '{'
6 ( <CompMetComp> newline )+ '}' newline
7
8 <CompMet> ::= ['PUBLIC'] 'COMPOSITE' 'TYPE' <longName> '[' <shortName> ']'
9 'CONTAINS' '{' ( <CompMetComp> )+ '}' newline
10
11 <CompMetComp>::= <longName> '[' <shortName> ']' (MANDATORY | OPTIONAL)
12 OF 'TYPE' <shortName> newline
13
14 <PrimMet> ::= ['PUBLIC'] 'PRIMITIVE' 'TYPE' <longName> '[' <shortName> ']' newline
15
16 <ListMet> ::= ['PUBLIC'] LIST 'TYPE' <longName> '[' <shortName> ']' 'INCLUDES'
17 <lowLimit> '..' <highLimit> OF 'TYPE' <shortName> newline
18
19 <ChoiceMet>::= ['PUBLIC'] 'CHOICE' 'TYPE' <longName> '[' <shortName> ']' SELECTS
20 '{' ( <ChoiceMetComp> )+ '}' newline
21
22 <ChoiceMetComp>::= <tagValue> ':' <longName> '[' <shortName> ']'
23 OF 'TYPE' <shortName> newline
24
25 <longName> ::= pattern "[A-Za-z0-9_]+"
26 <shortName>::= pattern "[A-Za-z0-9_]+"
27 <lowLimit> ::= pattern "[0-9]+"
28 <highLimit>::= ( 'N' | pattern "[0-9]+")
29 <tagValue> ::= pattern "[A-Za-z]"

30 Relationship to the RIM

31 Currently, the METL does not directly specify the relationship between message element types and RIM
32 metaobjects. Many element types do not have a direct counterpart in the RIM. These include
33 • element types that implement data types, and
34 • element types that implement information structures associated with the HL7 protocol rather than with the
35 functional data. (In this example, the MSGH message element is an example of a message element that is
36 required for HL7, but does is not represented in the RIM.)
37 Where message element types do have a relationship to the RIM this is usually shown by using long names for types
38 or components that correspond to class names, attributes or associations. Examples in the toy message type include
39 Stakeholder_ID at lines 14-19 and the component names within QryPatient_person_Nam at lines 8-13.

40 An Ersatz Message Object Diagram

41 As part of the prototype we have been trying to find a notation, comparable to the Message Object Diagram, that can
42 be represented in plain text. The following example, taken from the METL that was designed to send an XML
43 document within a version 3 message, is the best we have found. The right column consists of "objects" in the sense
44 of the message object diagram … specializations of classes based on distinctive semantics. The indentation of this
45 column indicates the hierarchical relationship of the message elements.
46 The left column presents the rationale for allowing the corresponding object to appear. It may be "root", "substitute
47 CMED", "specialize", "generalize", or the name of an association.
48 Special characters are used in the notation to denote recursion, to indicate the components of a choice and to
49 describe the cardinality of portions of the hierarchy.

HL7 Version 3-Message Element Type Language 12 January 26, 1999

 1
location symbol interpretation
left side of right column no symbol (1,1) cardinality
left side of right column ? (0,1) cardinality
left side of right column + (1,n) cardinality
left side of right column * (0,n) cardinality
left side of right column - choice component
left side of left column ** this is a recursion
2 Figure 6. Ersatz MOD notation.
3 root Patient
4 Substitute CMED Patient_person
5 is_target_of Target_participation
6 is_target_of +Service_intent_or_order
7 is_an_instance_of ?Master_service
8 has_as_active_participant +Active_participation
9 has_as_participant Stakeholder
10 specialize Person
11 substitute CMED Person_ID
12 is_fulfilled_by +Service_event
13 is_documented_by Clinical_document_header
14 **has_as_a_parent_document ?Clinical_document_header
15 has_been_originated_by ?Originator
16 substitute CMED Provider_Stakeholder
17 is_related_to *Authentication
18 is_related_to Healthcare_document_authenticator
19 substitute CMED Provider_Stakeholder
20 is_transcribed_by ?Transcriptionist
21 is_identified_as Person
22 is_performed_at Master_patient_service_location
23 **is_included_in ?Master_patient_service_location
24 is_assigned_to ?Patient_encounter
25 has_as_participant +Encounter_practitioner
26 is_participant_for Individual_healthcare_practitioner
27 has_as_active_participant Active_participation
28 has_as_participant Stakeholder
29 specialize Person
30 substitute CMED Person_ID

HL7 Version 3-Message Element Type Language 13 January 26, 1999

 1 Mapping the METL to the XML DTD
2 In the message style chosen for the HIMSS prototype, all message data is sent as #PCDATA. That is to say, it
3 appears between a start-tag and an end-tag. (An alternative strategy would be to send some or all data as the value of
4 attributes of elements.) Each message element that is of a primitive type (and can therefore contain data) has the
5 XML content model (#PCDATA).
6 The structure contained by composite, list, or choice message element types is implemented as a set of XML
7 element with other content models. For example, the DTD comparing to the toy message might have included the
8 following element definitions. (These are actually too simple, as will be explained below.) The XML comments
9 included in the contain the line numbers in Figure 4 of the corresponding METL.
10 <!-- 4--> <!ELEMENT QRgNamv3P00 (MSGH, QPTNAM)>
11 <!-- 23--> <!ELEMENT MSGH (sndApp?, rcvgApp?, msgDt?, msgTyp)>
12 <!-- 8--> <!ELEMENT QPTNAM (primrNamType, primrPrsnm, StkID?,
13 PhonNmbr_L?)>
14 <!-- 66--> <!ELEMENT sndApp (#PCDATA)>
15 <!-- 66--> <!ELEMENT rcvgApp (#PCDATA)>
16 <!-- 68--> <!ELEMENT msgDt (#PCDATA)>
17 <!-- 29--> <!ELEMENT msgTyp (msgID, intrId?)>
18
19 <!-- 66--> <!ELEMENT msgID (#PCDATA)>
20 <!-- 66--> <!ELEMENT intrId (#PCDATA)>
21

22 Name Collisions and the Indiana Dot Notation

23 Furthermore, there is an issue with names. Currently all element names in a DTD are global, but attribute names in
24 the RIM are implicitly qualified by class name and systematically repeated to indicate specific design patterns. In
25 order to avoid XML ELEMENT name collisions, the DTD compiler creates names by joining the name of an
26 element of a composite type with the name of its component. Compare the example below to lines 4-13 of the toy
27 example. The message element QPTNAM is a component of the MESSAGE message element QRgNamv3P00, so it
28 appears as QRgNamv3P00.QPTNAM. QPTNAM is also the name of a type that has, among others, a component
29 named primrPrsnm. The type QPTNAM defines the content model of QRgNamv3P00.QPTNAM. The component
30 names of the type are prepended with the type name. For example primrPrsnm becomes QPTNAM.primrNamType.
31 See the partial example below
32 <!ELEMENT QRgNamv3P00 (QRgNamv3P00.MSGH, QRgNamv3P00.QPTNAM)>
33 <!ELEMENT QRgNamv3P00.QPTNAM (QPTNAM.primrNamType, QPTNAM.primrPrsnm,
34 QPTNAM.StkID?, QPTNAM.PhonNmbr_L?)>
35
36 For historical reasons, this convention is called the Indiana Dot Notation. (Mark Tucker and Gunther thought it up.)
37 Currently, message element types that are declared PUBLIC receive different treatment with respect to the Indiana
38 Dot Notation. To demonstrate this we drill down further in QPTNAM:
39 <!ELEMENT QRgNamv3P00 (QRgNamv3P00.MSGH, QRgNamv3P00.QPTNAM)>
40 <!ELEMENT QRgNamv3P00.QPTNAM (QPTNAM.primrNamType, QPTNAM.primrPrsnm,
41 QPTNAM.StkID?, QPTNAM.PhonNmbr_L?)>
42
43 <!ELEMENT QPTNAM.primrNamType (cd, tx?, cs, acd?, atx?, acs?)>
44
45 <!ELEMENT cd (#PCDATA)>
46 <!ELEMENT tx (#PCDATA)>
47 <!ELEMENT cs (#PCDATA)>
48 <!ELEMENT acd (#PCDATA)>
49 <!ELEMENT atx (#PCDATA)>
50 <!ELEMENT acs (#PCDATA)>
51
52 <!ELEMENT QPTNAM.primrPrsnm (fmn, gvn?, mdn?, sfx?)>
53 <!ELEMENT fmn (#PCDATA)>
54 <!ELEMENT gvn (#PCDATA)>

HL7 Version 3-Message Element Type Language 14 January 26, 1999

 1 <!ELEMENT mdn (#PCDATA)>
2 <!ELEMENT sfx (#PCDATA)>
3
4 Because the message element type associated with the component QPTNAM.primrNamType is CE, the element has
5 six subcomponents (see lines 39-46 in the METL). Each of these subcomponents must have its own XML
6 ELEMENT definition.
7 If the Indiana dot notation had been used, the subcomponent names would have been qualified.
8 <!ELEMENT QPTNAM.primrNamType (CE.cd, CE.tx?, CE.cs, CE.acd?, CE.atx?,
9 CE.acs?)>
10
11 <!ELEMENT CE.cd (#PCDATA)>
12 <!ELEMENT CE.tx (#PCDATA)>
13 <!ELEMENT CE.cs (#PCDATA)>
14 <!ELEMENT CE.acd (#PCDATA)>
15 <!ELEMENT CE.atx (#PCDATA)>
16 <!ELEMENT CE.acs (#PCDATA)>
17
18 In a typical message, many elements will be of type CE. Skipping the Indiana dot notation was conceived as a way
19 to reduce the size of message instances.
20 In the current HIMSS demo I used the PUBLIC declaration quite frequently. In retrospect, I would have
21 done it far less, perhaps not at all.

22 Representing 'Message' Message Element Types

23 Each 'message' message element type is represented as an XML element which has a name that is the same as the
24 short name of the message element type. The content model for the XML element is the components of the message
25 element type. The keyword OPTIONAL is represented by a question mark in the content model.
26 Each of the components in the content model is then generated as a separate element.
27 This somewhat contrived METL …
28 MESSAGE TYPE QRYNam_Patient_Reg [QRgNamv3P00] CONTAINS {
29 Message_header [MSGH] MANDATORY OF TYPE MSGH
30 QryPatient_person_Nam [QPTNAM] OPIONAL OF TYPE QPTNAM
31 }
32
33 Would generate this DTD element.
34 <!ELEMENT QRgNamv3P00 (QRgNamv3P00.MSGH, QRgNamv3P00.QPTNAM?)>
35
36 Each ‘message’ message element type will be the root of a separate skeleton XML example message in the compiler
37 output. However a single DTD will contain the elements for all the messages.

38 Representing Composite Message Element Types

39 When a component or list item is generated that is of a composite message element type, the XML element is very
40 similar to that generated for the ‘message’ message element type.
41 The following message element type will generate an element in the DTD, as long as at least one element is
42 generated that has a component of type QPTNAM.
43 COMPOSITE TYPE QryPatient_person_Nam [QPTNAM] CONTAINS {
44 primary_name_type_cd [primrNamType] MANDATORY OF TYPE CE
45 primary_prsnm [primrPrsnm] MANDATORY OF TYPE PN
46 Stakeholder_id [StkID] OPTIONAL OF TYPE StkID
47 phone_number_list [PhonNmbr_L] OPTIONAL OF TYPE PhonNmbr_L
48 }
49

HL7 Version 3-Message Element Type Language 15 January 26, 1999

 1 The corresponding element would be.
2 <!ELEMENT QRgNamv3P00.QPTNAM (QPTNAM.primrNamType, QPTNAM.primrPrsnm,
3 QPTNAM.StkID?, QPTNAM.PhonNmbr_L?)>
4
5 Each of the components would also be generated as elements.

6 Representing List Message Element Types

7 When a component or list item is generated that is of a list message element type, the compiler creates a special
8 XML elementt, which has a content model that is the consists of a single element with the name <short name of
9 message element type>.item. A ‘*’ or ‘+’ is used into the content model according to the declaration in the METL.
10 For example:
11 PUBLIC LIST TYPE Patient_Phone_Number_List [PhonNmbr_L] INCLUDES 1..N
12 OF TYPE XTN_C
13
14 would generate:
15 <!ELEMENT QPTNAM.PhonNmbr_L (PhonNmbr_L.item+)>
16
17 An element is then generated for the “<short name of message element type>.item” entry, according to the type
18 specified in the OF TYPE clause of the METL.

19 Representing Choice Message Element Types

20 A choice is generated in the same way as a composite, except that “|” is used to separate the entries in the content
21 model. For example, this METL:
22 CHOICE TYPE Electronic_contact_address [XTN_C] SELECTS
23 {
24 E: email_address [emailAddr] OF TYPE ST
25 T: Extended_telecomm_id [ExtndTelId] OF TYPE XTN
26 }
27
28 would generate this XML element:
29 <!ELEMENT PhonNmbr_L.item (XTN_C.emailAddr| XTN_C.ExtndTelId)>
30
31 Each of the components is then generated. When the components are generated, the tag letters are generated as
32 attributes of the component elements, as will be described below.

33 Representing Primitive Message Element Types

34 When a component is generated that is of a primitive data type, the element that is generated for it always has the
35 content model:
36
37 For example, if a component is generate of type PN,
38 PUBLIC COMPOSITE TYPE Person_name [PN] CONTAINS {
39 family_name [fmn] MANDATORY OF TYPE ST
40 given_name [gvn] OPTIONAL OF TYPE ST
41 middle_initial_or_name [mdn] OPTIONAL OF TYPE ST
42 suffix [sfx] OPTIONAL OF TYPE ST # e.g., JR or III
43 }
44 PUBLIC PRIMITIVE TYPE string [ST]
45
46 After the component model for the composite is generated, the following elements would be added to the DTD.
47

HL7 Version 3-Message Element Type Language 16 January 26, 1999

 1 <!ELEMENT fmn (#PCDATA)>
2 <!ELEMENT gvn (#PCDATA)>
3 <!ELEMENT mdn (#PCDATA)>
4 <!ELEMENT sfx (#PCDATA)>
5

6 Use of XML Attributes

7 The current approach uses attributes in three ways:
8 • The T attribute conveys the data type associated with an XML ELEMENT
9 • The HL7_name attribute is a fixed attribute that conveys the long name associated with the element,
10 qualified using the Indiana dot notation. Because it is a "fixed" attribute, it does not actually appear in the
11 message instance. But a parser that uses the DTD will generate it in the parsed output data as if it had been
12 sent.
13 • The Choice attribute is used to convey thetag associated with a choice message element type.
14
15 Here are two examples:
16
17 <!ATTLIST QPTNAM.primrNamType
18 HL7_name CDATA #FIXED "QryPatient_person_Nam.primary_name_type_cd"
19 T CDATA "CE">
20
21 <!ATTLIST XTN_C.ExtndTelId
22 HL7_name CDATA #FIXED "Electronic_contact_address.Extended_telecomm_id"
23 T CDATA "XTN"
24 Choice CDATA "T">
25

26 A Naming Anomaly
27 Arguably, an XML element definition defines a type. The element so defined will be used in many message
28 instances where the contents will vary. It is surprising, then, that the names of XML elements do not correspond
29 with Message Element Types. Many XML element names are not the names of message element types: sndApp and
30 rcvgApp, above, are examples of this. Many message element types are not the names of XML elements. CE, XTN,
31 and ST are examples.
32 Most XML elements names are actually component names in METL. In fact, there are only three ways that the name
33 of a message element type becomes the name of an XML element:
34 • it is the name of a 'message' message element type
35 • it is the name of a list message element type
36 • it happens to have the same name as a component that is in the message.
37
38 Because of the Indiana dot notation, however, message element names frequently appear as the prefix for XML
39 element names.
40 For me, this was the hardest thing to grasp in the entire process: except for the message itself, it is only component
41 names that become the names of message elements.

42 Parameter Entities
43 The primary reflection of a message element type in a DTD is in the content model of an element. Whenever more
44 than one component in a message has the same type, each component will be generated with the same content
45 model. The DTD compiler generates a parameter entity for such types, and invokes it wherever it is used. The entity
46 name is DT_<short name of message element that defines the data type>.
47 For example, there are several elements in the toy message of type CE.
48

HL7 Version 3-Message Element Type Language 17 January 26, 1999

 1 <!ENTITY % DT_CE "cd, tx?, cs, acd?, atx?, acs?">
2 <!ELEMENT tlcmnUse (%DT_CE;)>
3 <!ELEMENT tlcmnEqpTyp (%DT_CE;)>

4 Full DTD and XML Instance Example for the Toy Message
5 Figure 7. DTD for the Toy Message
6 <!--=======================================================================
7 HL7 Version 3 Prototype Message: QRYNam_Patient_Reg [QRgNamv3P00]
8 =======================================================================-->
9
10 <!ENTITY % DT_CE "cd, tx?, cs, acd?, atx?, acs?">
11
12 <!ELEMENT QRgNamv3P00 (QRgNamv3P00.MSGH, QRgNamv3P00.QPTNAM)>
13
14 <!ELEMENT QRgNamv3P00.MSGH (sndApp?, rcvgApp?, msgDt?, msgTyp)>
15
16 <!ELEMENT QRgNamv3P00.QPTNAM (QPTNAM.primrNamType, QPTNAM.primrPrsnm,
17 QPTNAM.StkID?, QPTNAM.PhonNmbr_L?)>
18
19 <!ELEMENT QPTNAM.primrNamType (%DT_CE;)>
20
21 <!ELEMENT QPTNAM.primrPrsnm (fmn, gvn?, mdn?, sfx?)>
22
23 <!ELEMENT QPTNAM.StkID (StkID.id, StkID.idType)>
24
25 <!ELEMENT QPTNAM.PhonNmbr_L (PhonNmbr_L.item+)>
26
27 <!ELEMENT StkID.id (#PCDATA)>
28 <!ELEMENT StkID.idType (#PCDATA)>
29
30 <!ELEMENT sndApp (#PCDATA)>
31 <!ELEMENT rcvgApp (#PCDATA)>
32 <!ELEMENT msgDt (#PCDATA)>
33 <!ELEMENT msgTyp (msgID, intrId?)>
34
35 <!ELEMENT msgID (#PCDATA)>
36 <!ELEMENT intrId (#PCDATA)>
37
38 <!ELEMENT fmn (#PCDATA)>
39 <!ELEMENT gvn (#PCDATA)>
40 <!ELEMENT mdn (#PCDATA)>
41 <!ELEMENT sfx (#PCDATA)>
42
43 <!ELEMENT cd (#PCDATA)>
44 <!ELEMENT tx (#PCDATA)>
45 <!ELEMENT cs (#PCDATA)>
46 <!ELEMENT acd (#PCDATA)>
47 <!ELEMENT atx (#PCDATA)>
48 <!ELEMENT acs (#PCDATA)>
49
50 <!ELEMENT PhonNmbr_L.item (XTN_C.emailAddr| XTN_C.ExtndTelId)>
51 <!ELEMENT XTN_C.emailAddr (#PCDATA)>
52 <!ELEMENT XTN_C.ExtndTelId (tlcmnUse, tlcmnEqpTyp, cntryCode?, areaCityCode?,
53 phonNmbr, xtnsn?, anytxt?)>
54
55 <!ELEMENT tlcmnUse (%DT_CE;)>
56
57 <!ELEMENT tlcmnEqpTyp (%DT_CE;)>
58
59 <!ELEMENT cntryCode (#PCDATA)>
60 <!ELEMENT areaCityCode (#PCDATA)>

HL7 Version 3-Message Element Type Language 18 January 26, 1999

 1 <!ELEMENT phonNmbr (#PCDATA)>
2 <!ELEMENT xtnsn (#PCDATA)>
3 <!ELEMENT anytxt (#PCDATA)>
4
5 <!ATTLIST PhonNmbr_L.item
6 HL7_name CDATA #FIXED "Patient_Phone_Number_List.item"
7 T CDATA "XTN_C">
8 <!ATTLIST QPTNAM.PhonNmbr_L
9 HL7_name CDATA #FIXED "QryPatient_person_Nam.phone_number_list"
10 T CDATA "PhonNmbr_L">
11 <!ATTLIST QPTNAM.StkID
12 HL7_name CDATA #FIXED "QryPatient_person_Nam.Stakeholder_id"
13 T CDATA "StkID">
14 <!ATTLIST QPTNAM.primrNamType
15 HL7_name CDATA #FIXED "QryPatient_person_Nam.primary_name_type_cd"
16 T CDATA "CE">
17 <!ATTLIST QPTNAM.primrPrsnm
18 HL7_name CDATA #FIXED "QryPatient_person_Nam.primary_prsnm"
19 T CDATA "PN">
20 <!ATTLIST QRgNamv3P00
21 HL7_name CDATA #FIXED "QRYNam_Patient_Reg"
22 T CDATA "QRgNamv3P00">
23 <!ATTLIST QRgNamv3P00.MSGH
24 HL7_name CDATA #FIXED "QRYNam_Patient_Reg.Message_header"
25 T CDATA "MSGH">
26 <!ATTLIST QRgNamv3P00.QPTNAM
27 HL7_name CDATA #FIXED "QRYNam_Patient_Reg.QryPatient_person_Nam"
28 T CDATA "QPTNAM">
29 <!ATTLIST StkID.id
30 HL7_name CDATA #FIXED "Stakeholder_ID.id"
31 T CDATA "ST">
32 <!ATTLIST StkID.idType
33 HL7_name CDATA #FIXED "Stakeholder_ID.identifier_type_cd"
34 T CDATA "ID">
35 <!ATTLIST XTN_C.ExtndTelId
36 HL7_name CDATA #FIXED "Electronic_contact_address.Extended_telecomm_id"
37 T CDATA "XTN"
38 Choice CDATA "T">
39 <!ATTLIST XTN_C.emailAddr
40 HL7_name CDATA #FIXED "Electronic_contact_address.email_address"
41 T CDATA "ST"
42 Choice CDATA "E">
43 <!ATTLIST acd
44 HL7_name CDATA #FIXED "alt_identifier"
45 T CDATA "ST">
46 <!ATTLIST acs
47 HL7_name CDATA #FIXED "alt_name_coding_system"
48 T CDATA "ST">
49 <!ATTLIST anytxt
50 HL7_name CDATA #FIXED "any_text"
51 T CDATA "TX">
52 <!ATTLIST areaCityCode
53 HL7_name CDATA #FIXED "area_city_code"
54 T CDATA "NM">
55 <!ATTLIST atx
56 HL7_name CDATA #FIXED "alt_identifier_text"
57 T CDATA "ST">
58 <!ATTLIST cd
59 HL7_name CDATA #FIXED "identifier"
60 T CDATA "ST">
61 <!ATTLIST cntryCode
62 HL7_name CDATA #FIXED "country_code"
63 T CDATA "NM">

HL7 Version 3-Message Element Type Language 19 January 26, 1999

 1 <!ATTLIST cs
2 HL7_name CDATA #FIXED "name_of_coding_system"
3 T CDATA "ST">
4 <!ATTLIST fmn
5 HL7_name CDATA #FIXED "family_name"
6 T CDATA "ST">
7 <!ATTLIST gvn
8 HL7_name CDATA #FIXED "given_name"
9 T CDATA "ST">
10 <!ATTLIST intrId
11 HL7_name CDATA #FIXED "interaction_id"
12 T CDATA "ID">
13 <!ATTLIST mdn
14 HL7_name CDATA #FIXED "middle_initial_or_name"
15 T CDATA "ST">
16 <!ATTLIST msgDt
17 HL7_name CDATA #FIXED "date_time_message"
18 T CDATA "DTM">
19 <!ATTLIST msgID
20 HL7_name CDATA #FIXED "message_id"
21 T CDATA "ID">
22 <!ATTLIST msgTyp
23 HL7_name CDATA #FIXED "message_type"
24 T CDATA "MSGT">
25 <!ATTLIST phonNmbr
26 HL7_name CDATA #FIXED "phone_number"
27 T CDATA "NM">
28 <!ATTLIST rcvgApp
29 HL7_name CDATA #FIXED "receiving_application"
30 T CDATA "ID">
31 <!ATTLIST sfx
32 HL7_name CDATA #FIXED "suffix"
33 T CDATA "ST">
34 <!ATTLIST sndApp
35 HL7_name CDATA #FIXED "sending_application"
36 T CDATA "ID">
37 <!ATTLIST tlcmnEqpTyp
38 HL7_name CDATA #FIXED "telecomm_equipment_type"
39 T CDATA "CE">
40 <!ATTLIST tlcmnUse
41 HL7_name CDATA #FIXED "telecom_use_code"
42 T CDATA "CE">
43 <!ATTLIST tx
44 HL7_name CDATA #FIXED "identifier_text"
45 T CDATA "ST">
46 <!ATTLIST xtnsn
47 HL7_name CDATA #FIXED "extension"
48 T CDATA "NM">
49
50 <!--============== End HL7 Version 3 Prototype Message DTD ==============-->

HL7 Version 3-Message Element Type Language 20 January 26, 1999

 1

2 Figure 8. XML Instance Example for the Toy Message.

3 <?xml version = "1.0">
4 <!DOCTYPE QRgNamv3P00 SYSTEM "ToyMessage.dtd">
5 <QRgNamv3P00 T="QRgNamv3P00">
6 <QRgNamv3P00.MSGH T="MSGH">
7 <sndApp T="ID">INTRANET001</sndApp>
8 <rcvgApp T="ID">RGSIUIPI</rcvgApp>
9 <msgDt T="DTM">199808231123</msgDt>
10 <msgTyp T="MSGT">
11 <msgID T="ID">QRgNamv3P00</msgID>
12 </msgTyp>
13 </QRgNamv3P00.MSGH>
14 <QRgNamv3P00.QPTNAM T="QPTNAM">
15 <QPTNAM.primrNamType T="CE">
16 <cd T="ST">L</cd>
17 <tx T="ST">Local</tx>
18 <cs T="ST">HL79999</cs>
19 </QPTNAM.primrNamType>
20 <QPTNAM.primrPrsnm T="PN">
21 <fmn T="ST">Newman</fmn>
22 </QPTNAM.primrPrsnm>
23 <QPTNAM.PhonNmbr_L T="PhonNmbr_L">
24 <PhonNmbr_L.item T="XTN_C">
25 <XTN_C.emailAddr T="ST" Choice="E">[email protected]</XTN_C.emailAddr>
26 </PhonNmbr_L.item>
27 <PhonNmbr_L.item T="XTN_C">
28 <XTN_C.ExtndTelId T="XTN" Choice="T">
29 <tlcmnUse T="CE">
30 <cd T="ST">PRN</cd>
31 <tx T="ST">Primary Residence</tx>
32 <cs T="ST">HL79999</cs>
33 </tlcmnUse>
34 <tlcmnEqpTyp T="CE">
35 <cd T="ST">PH</cd>
36 <tx T="ST">Telephone</tx>
37 <cs T="ST">HL79999</cs>
38 </tlcmnEqpTyp>
39 <areaCityCode T="NM">555</areaCityCode>
40 <phonNmbr T="NM">7776666</phonNmbr>
41 </XTN_C.ExtndTelId>
42 </PhonNmbr_L.item>
43 </QPTNAM.PhonNmbr_L>
44 </QRgNamv3P00.QPTNAM>
45 </QRgNamv3P00>

HL7 Version 3-Message Element Type Language 21 January 26, 1999