Draft Website - For Review Purposes Only

4 Message Profiles

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.

Table 4.1: Summary of Constraint Types and Where They Apply

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.

4.1 Message Profile Identification

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.

Figure 4.1: Message Profile Identifier Mechanism
Figure 4.1: Message Profile Identifier Mechanism

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.

4.2 Message Level Profiling

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.

Table 4.2: Example of Base Standard Message Level 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.

Table 4.3: Example of Profiled Message Level Definition

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

Table 4.4: Example of Profiled Conformance Statement – Message Level

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’.

4.3 Segment Level Profiling

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.

Table 4.5: Example Base Segment Definition – RXA Segment

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.

4.4 Data Type Profiling

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.

Table 4.9: XON Data Type Definition in Base Standard

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).

Table 4.10: XON Data Type Definition Constrained in Profile

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.

Table 4.11: XON Data Type Definition Constrained in Profile

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.

4.5 Primitive Element Profiling

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:

4.6 Differential Profiles

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.

4.7 Extensions

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.