A message profile is based on a message structure defined in the HL7 v2 standard and specifies refined requirements according to its intended context of use. The message profile identifies the message code (e.g., ADT), trigger event (e.g., A04), and message structure (e.g., ADT_A01) and other meta data as shown in Table 10.2. Constraints are placed at various levels and objects in the message template. Table 4.1 summaries the types of constraints and the message objects for which they apply. In the sub-sections to follow, the constraint types that apply at each level of profiling are explained. In Section 5 (Constraints), each constraint type is described in detail.
Constraint |
M |
SG |
S |
F |
C |
SC |
|||||
---|---|---|---|---|---|---|---|---|---|---|---|
Cx |
P |
Cx |
P |
P |
|||||||
Usage |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
||||
Cardinality |
✓ |
✓ |
✓ |
✓ |
|||||||
Data Type Specialization |
✓ |
✓* |
✓ |
✓* |
✓* |
||||||
Vocabulary |
✓ |
✓ |
✓ |
✓ |
✓ |
||||||
Length |
✓ |
✓ |
✓ |
||||||||
Conformance Length |
✓ |
✓ |
✓ |
||||||||
Content |
✓ |
✓ |
✓ |
||||||||
Conformance Statement |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
|||
Co-constraints |
✓ |
||||||||||
Slicing |
✓ |
||||||||||
Semantic Refinement |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
|||
Key |
M: Message |
SG: Segment Group |
S: Segment |
F: Field |
|||||||
C: Component |
SC: Sub-component |
Cx: Complex |
P: Primitive |
||||||||
*Typically (and in most cases) a data type specialization is not made for primitive elements (fields, components, sub-components). However, data types like DTM that have specialization "encoding" of the date/time format YYYYMMDDHHSS.SSSS+-ZZZZ are the exceptions. |
Although all elements allow for semantic refinement, caution should be used in certain circumstances. For example, components within a data type generally have very specific meaning and rarely should be a candidate for semantic refinement.
Components and sub-components are not directly constrained, rather, they are constrained within the context of a data type flavor. Vocabulary bindings to elements within a data type can be assigned in the context of use. Vocabulary constraints only apply to elements that have data types that have coded data types. Fields and components can be complex or primitive elements. Sub-components are always primitive elements. As shown in Table 4.1, some of the concepts are the same depending on the context. For example, fields and components in some circumstances are primitive elements.
Segments are profiled at the message level. Fields are profiled at the segment level. For data types, components and sub-components are profiled in the context of data type flavors.
To simplify profile references and claims of conformance, an identification mechanism for HL7 v2 is provided by the message profile identifier. The message profile identifier is referenced in two places that provide the bridge between the message profile and the message instance:
In the message profile meta data, indicated by the MessageProfileIdentifier element
In the message instance, indicated by the MSH-21 field (Message Profile Identifier)
The MessageProfileIdentifer element provides the identifier for the message profile that can be referenced in a message instance. This reference in the message instance is a claim by the sending system of conformance to the message profile it references. The receiver, via the conformance claim, is made aware of the expectant message content (as defined in the message profile). The receiver may validate the message content based on the requirements given in the message profile and make processing decisions based on the outcome of that validation. Additionally, validation tools conduct conformance testing based on the message instance and the conformance claim indicated by the message profile identifier. A receiver can publish its claim of conformance to the message profile in its interface documentation or other capability statement.
The left-hand side of Figure 4.1 shows the message profile identifier as meta data that models the Entity Identifier (EI) data type. The field definition for MSH-21 is contained in the body of the message profile; the definitions in the meta data and the field must be compatible. The right-hand side of Figure 4.1 shows a message instance in which MSH-21 is claiming conformance to the message profile definition on the left-hand side of Figure 4.1.
The message profile identifier is not limited to just the message profile; it can reference any of the following profile building blocks:
message profile (including a pre-coordinated profile identifier)
profile component (including the core profile and differential component)
composite profile
value set library
In principle, all of these items can be managed the same way. The message profile identifier can be a list of any of these profile building blocks. For example, the specifier may wish to separate the message profile and the value set library. The message profile identifier in this case will contain two occurrences. The totality of both occurrences indicates the claim of conformance. Likewise, a complete profile can be described as a collection of profile components. For example, three profile components can be indicated in which one of the components is the core profile and the others are profile components. See Section 7.1 for more details on how profiles can be constructed.
The EI data type consists of the four components. EI.1 indicates the identifier of the profile artifact. EI.2 or (EI.3 and EI.4) establish the assigning authority for the identifier given in EI.1. This scheme gives the identifier uniqueness. EI.2 describes the common name of what is defined by EI.3 and EI.4 (and vice-versa). EI.2 alone, or EI.3 and EI.4, or all three elements can be used to specify the assigning authority of the identifier. If all three are defined, then EI.2 and the combination of EI.3 and EI.4 must refer to an equivalent concept. Typically, EI.3 is an OID that defines the assigning authority of the identifier.
Below is an example that shows the message profile identifier definition for a profile that consists of a national level profile with a separate identifier for the value set library. Together the two identifiers indicate the national level requirements for a message. Additionally, the example shows that a state (local) entity further constrained the profile for their refined use case. Together, all three identifiers indicate the complete set of requirements. The example also shows how a system could value MSH-21 in the message instance to convey the content of the message.
Profile Definition:
<MessageProfile>
<CoreProfileID>
<EntityIdentifier>Profile_National_Level</EntityIdentifier>
<NamespaceID>Domain_XYZ</NamespaceID>
<UniversalID>1.2.3.4.5</UniversalID>
<UniversalIDType>ISO</UniversalIDType>
</CoreProfileID>
<ValueSetLibraryID>
<EntityIdentifier>VS_Library</EntityIdentifier>
<NamespaceID>Domain_XYZ</NamespaceID>
<UniversalID>1.2.3.4.5</UniversalID>
<UniversalIDType>ISO</UniversalIDType>
</ValueSetLibraryID>
<ProfileComponentID>
<EntityIdentifier>State_Profile _Component</EntityIdentifier>
<NamespaceID>Domain_ABC</NamespaceID>
<UniversalID>1.2.3.4.6</UniversalID>
<UniversalIDType>ISO</UniversalIDType>
</ProfileComponentID>
</MessageProfile>
Message Instance:
Profile_National_Level^Domain_XYZ^1.2.3.4.5^ISO~VS_Library^Domain_XYZ^1.2.3.4.5^ISO~State_Profile_Component^Domain_ABC^1.2.3.4.6^ISO
The above example illustrates the grouping of three profile building blocks with an implied AND connector. The message profile identifier mechanism also supports an implied OR connector with the PreCoordinatedProfile element. For example, the above illustration also could have defined a single pre-coordinated identifier that refers to these three profile building blocks. See the illustration below.
Profile Definition:
<MessageProfile>
<PreCoordinatedProfile>
<PreCoordinatedProfileID>
<EntityIdentifier>State_Profile</EntityIdentifier>
<NamespaceID>Domain_ABC</NamespaceID>
<UniversalID>1.2.3.4.6</UniversalID>
<UniversalIDType>ISO</UniversalIDType>
</PreCoordinatedProfileID>
<CoreProfileID>
<EntityIdentifier>Profile_National_Level</EntityIdentifier>
<NamespaceID>Domain_XYZ</NamespaceID>
<UniversalID>1.2.3.4.5</UniversalID>
<UniversalIDType>ISO</UniversalIDType>
</CoreProfileID>
<ValueSetLibraryID>
<EntityIdentifier>VS_Library</EntityIdentifier>
<NamespaceID>Domain_XYZ</NamespaceID>
<UniversalID>1.2.3.4.5</UniversalID>
<UniversalIDType>ISO</UniversalIDType>
</ValueSetLibraryID>
<ProfileComponentID>
<EntityIdentifier>State_Profile _Component</EntityIdentifier>
<NamespaceID>Domain_ABC</NamespaceID>
<UniversalID>1.2.3.4.6</UniversalID>
<UniversalIDType>ISO</UniversalIDType>
</ProfileComponentID>
<PreCoordinatedProfile>
</MessageProfile>
Message Instance:
State_Profile^Domain_ABC^1.2.3.4.6^ISO
OR
Profile_National_Level^Domain_XYZ^1.2.3.4.5^ISO~VS_Library^Domain_XYZ^1.2.3.4.5^ISO~State_Profile_Component^Domain_ABC^1.2.3.4.6^ISO
This example shows a definition of a pre-coordinated profile and its constituent parts. Systems can convey the message content in MSH-21 by either indicating the pre-coordinated identifier or the three identifiers for the parts of the profile. Combining profile parts can continue indefinitely to a practical limit. For example, a profile component can be added to the pre-coordinated profile in the previous example to address a different, but closely related, use case. The identifiers can be specified separately, or another pre-coordinated identifier could be created.
Table 4.2 illustrates an abbreviated specification of a message definition as given in the base standard. Table 4.3 shows an example of a profiled version of that message definition.
Segments |
Description |
Status |
Chapter |
---|---|---|---|
MSH |
Message Header Segment |
2 |
|
[{ SFT }] |
Software |
2 |
|
[ UAC ] |
User Authentication Credential |
2 |
|
PID |
Patient Identification Segment |
3 |
|
[ PD1 ] |
Additional Demographics |
3 |
|
[{ NK1 }] |
Next of Kin/Associated Parties |
3 |
|
... |
|||
[{ |
--- ORDER begin |
||
ORC |
Common Order |
4 |
|
[{PRT}] |
Participation (for ORC) |
7 |
|
[{ |
--- TIMING begin |
||
TQ1 |
Timing/Quantity |
4 |
|
[{ TQ2 }] |
Timing/Quantity Order Sequence |
4 |
|
}] |
--- TIMING end |
||
RXA |
Pharmacy Administration Segment |
4A |
|
[ RXR ] |
Pharmacy Route |
4A |
|
[{ |
--- OBSERVATION begin |
||
OBX |
Observation/Result |
7 |
|
[{ PRT }] |
Participation (for Observation) |
7 |
|
[{ NTE }] |
Notes (Regarding Immunization) |
2 |
|
}] |
--- OBSERVATION end |
||
}] |
--- ORDER end |
The Segment column represents the abstract message definition as defined in the base standard, not the profiled definition. Specifiers may choose to represent the segment columns differently but must maintain the original list of segments. A second segment column may be added to indicate that a segment flavor has been defined. The specifier may choose to mark segments that need to be supported in bold. A segment flavor indicates that the segment definition has been constrained. The segment-flavor identifier provides a convenient mechanism to manage and reference segments. If the segment was not constrained, then the base standard segment identifier is given.
The Usage column must be included and reflect the usage of the segment or segment group for this message-structured definition.
The Cardinality column must be included and reflect the minimum and maximum number of occurrences allowed for the segment or segment group for the message-structured definition.
Additional column headings, such as Referenced Chapter or Comments, may be specified. Conformance Statements and Condition Predicates (if any) also may be included as a column heading or be specified as separate tables immediately following the message-structured defintion table. Table 4.4 shows conformance statement defintions.
Segment |
Segment Flavor |
Description |
Usage |
Cardinality |
Chapter |
---|---|---|---|---|---|
MSH |
MSH_IZ |
Message Header Segment |
R |
[1..1] |
2 |
[{SFT}] |
SFT |
Software |
X |
[0..0] |
2 |
[UAC] |
UAC |
User Authentication Credential |
O |
[0..1] |
2 |
PID |
PID_IZ |
Patient Identification Segment |
R |
[1..1] |
3 |
[PD1] |
PD1_IZ_01 |
Additional Demographics |
RE |
[0..1] |
3 |
[{NK1}] |
NK1_IZ |
Next of Kin/Associated Parties |
RE |
[0..1] |
3 |
... |
|||||
[{ |
--- ORDER begin |
R |
[1..*] |
7 |
|
ORC |
ORC_IZ_01 |
Common Order |
R |
[1..1] |
2 |
[{PRT}] |
PRT |
Participation (for ORC) |
O |
[0..1] |
3 |
[{ |
--- TIMING begin |
O |
[0..1] |
3 |
|
TQ1 |
TQ1 |
Timing/Quantity |
R |
[1..1] |
7 |
[{TQ2}] |
TQ2 |
Timing/Quantity Order Sequence |
O |
[0..*] |
7 |
}] |
--- TIMING end |
||||
RXA |
RXA_IZ_01 |
Pharmacy Administration Segment |
R |
[1..1] |
4 |
[RXR] |
RXR_IZ |
Pharmacy Route |
RE |
[0..1] |
4 |
[{ |
--- OBSERVATION begin |
RE |
[0..*] |
||
OBX |
OBX_IZ_02 |
Observation/Result |
R |
[1..1] |
7 |
[{PRT}] |
PRT |
Participation (for Observation) |
O |
[0..*] |
7 |
[{NTE}] |
NTE |
Notes (Regarding Immunization) |
O |
[0..1] |
3 |
}] |
--- OBSERVATION end |
||||
}] |
--- ORDER end |
Message Level Conformance Statements |
|
---|---|
IZ-205 |
If OBX-3.1 (Identifier) contains the value β59785-6’ (Indication for Immunization) then RXA-20 (Completion Status) in the same Order group SHALL contain one of the values in the list: {CP, PA}. |
IZ-206 |
If OBX-3.1 (Identifier) contains the value β30945-0’ (Vaccination contraindication/precaution) then RXA-20 (Completion Status) in the same Order group SHALL contain the value βNA’. |
Table 4.5 shows the RXA segment definition as it appears in the HL7 v2.8.2 standard. Table 4.6 shows an example of how the profiled segment definition (RXA_IZ_01) can be displayed. The segment flavor (specialization) identifier (RXA_IZ_01) is used in the message definition to indicate that this specialization of the RXA segment is to be used.
SEQ |
LEN |
C.LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
---|---|---|---|---|---|---|---|---|
1 |
4= |
NM |
R |
00342 |
Give Sub-ID Counter |
|||
2 |
4= |
NM |
R |
00344 |
Administration Sub-ID Counter |
|||
3 |
DTM |
R |
00345 |
Date/Time Start of Administration |
||||
4 |
DTM |
R |
00346 |
Date/Time End of Administration |
||||
5 |
CWE |
R |
0292 |
00347 |
Administered Code |
|||
6 |
NM |
R |
00348 |
Administered Amount |
||||
7 |
CWE |
C |
9999 |
00349 |
Administered Units |
|||
8 |
CWE |
O |
9999 |
00350 |
Administered Dosage Form |
|||
9 |
CWE |
O |
Y |
9999 |
00351 |
Administration Notes |
||
10 |
XCN |
B |
Y |
00352 |
Administering Provider |
|||
11 |
W |
00353 |
Administered-at Location |
|||||
12 |
20= |
ST |
C |
00354 |
Administered Per (Time Unit) |
|||
13 |
NM |
O |
01134 |
Administered Strength |
||||
14 |
CWE |
O |
9999 |
01135 |
Administered Strength Units |
|||
15 |
20= |
ST |
O |
Y |
01129 |
Substance Lot Number |
||
16 |
DTM |
O |
Y |
01130 |
Substance Expiration Date |
|||
17 |
CWE |
O |
Y |
0227 |
01131 |
Substance Manufacturer Name |
||
18 |
CWE |
O |
Y |
9999 |
01136 |
Substance/Treatment Refusal Reason |
||
19 |
CWE |
O |
Y |
9999 |
01123 |
Indication |
||
20 |
2..2 |
ID |
O |
0322 |
01223 |
Completion Status |
||
21 |
1..1 |
ID |
O |
0206 |
01224 |
Action Code – RXA |
||
22 |
DTM |
O |
01225 |
System Entry Date/Time |
||||
23 |
5= |
NM |
O |
01696 |
Administered Drug Strength Volume |
|||
24 |
CWE |
O |
9999 |
01697 |
Administered Drug Strength Volume Units |
|||
25 |
CWE |
O |
9999 |
01698 |
Administered Barcode Identifier |
|||
26 |
1..1 |
ID |
O |
0480 |
01699 |
Pharmacy Order Type |
||
27 |
PL |
O |
02264 |
Administer-at |
||||
28 |
XAD |
O |
02265 |
Administered-at Address |
The specifier has chosen to present the segment flavor definition with a field sequence identifier, element name, data type (that includes any flavor), usage, cardinality, vocabulary binding (including concept domain, code system, or value set binding), minimum and maximum length, conformance length, and comments. If content constraints (e.g., fixed values) existed, a column for them could have been added.
Components and sub-components are constrained in the context of data type specializations; that is, a component or sub-component should not be constrained directly in their context of use. Rather, they are constrained in the context of a data type specialization, and that specialization is used in context, either at the field or complex data type level.
Data type profiling entails constraining the components of a data type. The two cases where this profiling applies are related to primitive components and complex components:
The data type specification is displayed in a table form. Table 4.9 shows a data type definition (XON) as given in the base standard. Table 4.10 shows an example of the data type specialization (XON_IZ01) of the XON data type.
XON DATA TYPE |
||||||||
---|---|---|---|---|---|---|---|---|
SEQ |
LEN |
C.LEN |
DT |
OPT |
TBL# |
Name |
Comments |
SEC.REF. |
1 |
50# |
ST |
O |
Organization Name |
2.A.76 |
|||
2 |
CWE |
O |
0204 |
Organization Name Type Code |
2.A.36 |
|||
3 |
W |
ID Number |
Withdrawn as of v2.7. |
|||||
4 |
W |
Identifier Check Digit |
Withdrawn as of v2.7. |
|||||
5 |
W |
Check Digit Scheme |
Withdrawn as of v2.7. |
|||||
6 |
HD |
O |
0363 |
Assigning Authority |
2.A.33 |
|||
7 |
2..5 |
ID |
O |
0203 |
Identifier Type Code |
2.A.35 |
||
8 |
HD |
O |
Assigning Facility |
2.A.33 |
||||
9 |
1..1 |
ID |
O |
0465 |
Name Representation Code |
2.A.35 |
||
10 |
ST |
O |
Organization Identifier |
2.A.76 |
As shown, the specifier did not include all columns as given in the base standard. If constraints are unspecified in the profile, then the requirements, or associated information of the profile from which it was derived, apply (in this case, the base standard).
XON_IZ01 DATA TYPE |
||||
---|---|---|---|---|
SEQ |
Name |
DT |
Usage |
Vocab |
1 |
Organization Name |
ST |
RE |
|
2 |
Organization Name Type Code |
CWE |
O |
|
3 |
ID Number |
X |
||
4 |
Identifier Check Digit |
X |
||
5 |
Check Digit Scheme |
X |
||
6 |
Assigning Authority |
HD_IZ01 |
C(R/X) |
|
7 |
Identifier Type Code |
ID |
C(R/X) |
0203_02 |
8 |
Assigning Facility |
HD |
O |
|
9 |
Name Representation Code |
ID |
O |
|
10 |
Organization Identifier |
ST |
C(R/RE) |
Table 4.11 shows the list of condition predicates for the data type specialization. The implementation guide and the message profile can define multiple data type specializations for the same data type.
Condition Predicates |
||
---|---|---|
Location |
Usage |
Predicate |
XON.6 |
C(R/X) |
If XON.10(Organization Identifier) is valued. |
XON.7 |
C(R/X) |
If XON.10(Organization Identifier) is valued. |
XON.10 |
C(R/RE) |
If XON.1(Organization Name) is not valued. |
Primitive elements are those elements that are leaf nodes (i.e., they carry the data). Primitive data elements that appear at a field, component, or sub-component level can apply the following constraints:
An alternative form of documenting a profile is to include only the differential between the constrained profile and a baseline (starting) profile. The baseline profile may be the HL7 v2 base standard or a message profile. For example, a local jurisdiction profile (e.g., state of Maryland) can be created from a national level profile (US Realm profile). The state of Maryland profile could be expressed as a differential to the US Realm profile. The same profiling mechanisms expressed in the earlier section can be used but would only express the elements that differ from the baseline profile. For example, if only two fields were modified in a segment definition, then only those two fields (rows) would be expressed in the segment table definition. A differential profile may be represented as a profile component. The complete, i.e., the composite profile, can be created by “overlaying” the differential profile “on” the baseline profile. Having tooling that the supports expressing both the differential and composite views is optimal for end users.
Extensions provide a mechanism for specifying a concept (e.g., a data element) that is not expressed in the base standard but is needed for a particular use case. This mechanism allows for new concepts to be specified in an “as needed” manner to support particular implementations. HL7 v2 supports extensions via the “Z” mechanism in which Z messages, Z segments, Z fields, and Z data types can be created. Creation of locally defined vocabulary is supported by the base standard natively. The use of Z elements in message profile definitions must be specified using the constraint mechanisms defined in this document.
When using extensions, the data elements should be described and documented sufficiently in a profile such that trading partners can reach a common understanding. Extensions should not be used in cases where a concept already exists in the base standard. The base standard provides a common method for defining extensions, thus ensuring consistent application of the mechanism; these rules must be adhered to in the message profile. If a given concept is found to be specified frequently as an extension in industry profiles, then such extensions should be proposed to become a formal HL7 construct in the base standard.