Attachment 3 HL7 Version 2.8 Conformance Document.pdf

Health Level Seven, Version 2.82.8 ©20112011. All rights reserved. Page 2-205 Membership BallotMembership Ballot SeptemberSeptember 20112011

2.B

Control: Conformance

(continued)

Chapter Chair Frank Oemig

Agfa HealthCare GmbH

Chapter Chair Robert Snelick

National Institute of Standards and Technology (NIST)

Chapter Chair Wendy Huang

Canada Health Infoway

Sponsoring Work Group: Conformance and Guidance for Implementation/Testing

List Server: cgit@lists.hl7.org

Notes to Balloters

This is the 1st Normative Ballot for v2.8.

HL7 HQ, the TC Chairs and the International Affiliates thank you for your consideration!

Section Section Name Change Type Proposal # Subst. Line Item

TOC added (ease of use, convienence) headline changed

2.B.11

Documentation added: concept of conformance documentation hierarchy

2.B

Changed chapter title to Conformance

(removed ―using Message Profiles‖);

clarify the dinstinction between implementation guides and message profiles

2.B.13

Conformity Assessment Added section to clarify the meaning of the conformance usage codes by providing a context in which they can be

Chapter 2: Control – Conformance

Page 2-206 Health Level Seven, Version 2.82.8 © 20112011. All rights reserved.

SeptemberSeptember 20112011 Membership BallotMembership Ballot.

Section Section Name Change Type Proposal # Subst. Line Item assessed

2.B.5

Table Defintion Clarification of table definition concepts.

Added the concept of a table library.

2.B.9.7

Profiling multiple element occurrences Allows for individual profiling of elements that repeat

Removed message profile DTD Removed the non-normative message profile DTD

2.B.7.5

Usage Clarified the definitions of Usage;

separated into sending/receiving roles and implementation/operational requiresments. Made a technical correction and removed the clause that stated receiving application can ignore required elements.

2.B.7.5

Usage Replaced the C and CE usage codes with

C(a/b) to generalize the conditional concept.

CHAPTER 2.B CONTENTS

2.B CONFORMANCE

Previous sections in this chapter define the rules and conventions for constructing and communicating a message including the parts of a message structure. Messages that adhere to those rules of a specific version of a standard are compliant to that version of the standard.

Compliance to the HL7 Standard has historically been impossible to define and measure in a meaningful way. To compensate for this shortcoming, vendors and sites have used various methods of specifying boundary conditions such as optionality and cardinality. Frequently, specifications have given little guidance beyond the often-indefinite constraints provided in the HL7 Standard.

This section presents the methodology for producing a precise and unambiguous specification of a single interaction called a message profile. Messages that adhere to the constraints of a message profile are said to be conformant to the profile. For conformance to be measurable, the message profile must specify the following types of information:

What data will be passed in a message.

The format in which the data will be passed.

The acknowledgement responsibilities of the sender and receiver.

A conformance statement is a claim that the behavior of an application or application module agrees with the constraints stated in one or more message profiles. This section defines the message profile; however, the conformance statement will not be discussed further in this document.

An implementation guide is often created to organize a collection of message profiles for specifying a set of related

HL7 V2.x interactions described in a use case. Implementation guides typically describe broader conformance requirements such as application behavior. Such requirements may include how a set of messages are to be used to inact a certain application functionality. Implementation guides have broad scope have been introduced in this

Health Level Seven, Version 2.82.8 ©20112011. All rights reserved. Page 2-207 section to provide context of message profiles and will not be discussed further in this document. A message profile provides a mechanism for specifying a single message definition.

Definition: An HL7 message profile is an unambiguous specification of one standard HL7 message that have been analyzed for a particular interaction. It prescribes a set of precise constraints upon one standard HL7 message.

An HL7 message profile is compliant, in all aspects, with the HL7 defined message(s) used in the profile. It may specify constraints on the standard HL7 message definition.

A message profile fully describes a conversation between two or more systems through the combination of the following:

a) one interaction analysis,

b) one or more dynamic definitions,

c) one static definition, and

d) one table (vocabulary) definition.

The interaction analysis may be documented as a sequence diagram (supported with text) or just a textual description (See section 2.B.2, "Interaction Definition".)

The dynamic definition is an interaction specification for a conversation between 2 or more systems (See

Section.2.B.3, "Dynamic definitionDynamic definition".)

The static definition is a specification that defines the constraints for a single message structure (see Section 2.B.4, "Static definitionStatic definition").

The table (vocabulary) definition is a specification of the tables referenced in the static definition. (see Section

2.B.5, "Table definitionTable definition").

The message profile is normatively expressed as an XML document validated against the normative message profile

Schema, it may be registered on the HL7 web site (see Section 2.B.10, "Message profile documentMessage profile document"). The normative table definition can partly or wholly be contained in the message profile XML document. The table definition can also be partly or wholly defined in a table library. The table library is normatively expressed as an XML document validated against the normative table library Schema, it may be registered on the HL7 web site; (see SectionX.X.X, "Message profile documentMessage profile document").

For detailed background information regarding message profiles, the reader is referred to the

Implementation/Conformance Work Group balloted informative document, "Message Profiling Specification, Version 2.2", published November 30, 2000, upon which this section is based. This document is available from the

HL7 Resources Web site (http://www.hl7.org).

A sample message profile is shown on the next page to assist in illustrating the constituents of a message profile and how they work together.

Formatted: Hyperlink Text, Check spelling and grammar

Formatted: Hyperlink Text, Check spelling and grammar

Formatted: Hyperlink Text, Check spelling and grammar

Formatted: Hyperlink Text, Check spelling and grammar

Formatted: Hyperlink Text, Check spelling and http://www.hl7.org/

Page 2-208 Health Level Seven, Version 2.82.8 © 20112011. All rights reserved.

Message Profile Example

Static Definition – Field Level

Vocabulary

SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAME

1 4 SI X 00104 Set ID - PID

2 20 CX RE [1..1] 00105 Patient ID

3 20 CX R [1..*] 00106 Patient Identifier List

4 20 CX X 00107 Alternate Patient ID - PID

5 48 XPN R [1..*] 00108 Patient Name

6 48 XPN RE [1..*] 00109 Mother’s Maiden Name

7 26 TS RE 00110 Date/Time of Birth

8 1 IS RE 0001 00111 Sex

9 48 XPN X 00112 Patient Alias

10 80 CE X 0005 00113 Race

11 106 XAD RE [1..3] 00114 Patient Address

12 4 IS X 0289 00115 County Code

13 40 XTN RE [1..3] 00116 Phone Number - Home

14 40 XTN RE [1..3] 00117 Phone Number - Business

15 60 CE X 0296 00118 Primary Language

16 80 CE X 0002 00119 Marital Status

17 80 CE X 0006 00120 Religion

18 20 CX X 00121 Patient Account Number

19 16 ST RE 00122 SSN Number - Patient

20 25 DLN X 00123 Driver's License Number - Patient

21 20 CX X 00124 Mother's Identifier

22 80 CE X 0189 00125 Ethnic Group

23 60 ST RE 00126 Birth Place

24 1 ID X 0136 00127 Multiple Birth Indicator

25 2 NM X 00128 Birth Order

26 80 CE X 0171 00129 Citizenship

27 60 CE X 0172 00130 Veterans Military Status

28 80 CE X 0212 00739 Nationality

29 26 TS X 00740 Patient Death Date and Time

30 1 ID X 0136 00741 Patient Death Indicator

Interaction Model

Segment ADT Message Usage Cardinality Chapter

MSH Message Header R [1..1] 2

EVN Event Type R [1..1] 3

PID Patient Identification R [1..1] 3

[ PD1 ] Additional Demographics X [0..0] 3

[{ ROL }] Role X [0..0] 12

[{ NK1 }] Next of Kin / Associated

Parties

RE [0..3] 3

PV1 Patient Visit R [1..1] 3

[ PV2 ] Patient Visit - Additional

Info.

RE [0..1] 3

[{ ROL }] Role X [0..0] 12

[{ DB1 }] Disability Information X [0..0] 3

[{ OBX }] Observation/Result X [0..0] 7

[{ AL1 }] Allergy Information RE [0..*] 3

[{ DG1 }] Diagnosis Information X [0..0] 6

[ DRG ] Diagnosis Related Group X [0..0] 6

[{ X [0..0]

PR1 Procedures X [0..0] 6

[{ ROL

Role X [0..0] 12

[{ GT1 }] Guarantor X [0..0] 6

[{ X [0..0]

IN1 Insurance X [0..0] 6

[ IN2 ] Insurance Additional Info. X [0..0] 6

[{ IN3

Insurance Additional Info -

Cert.

X [0..0] 6

[{ ROL

Role X [0..0] 12

[ ACC ] Accident Information X [0..0] 6

[ UB1 ] Universal Bill Information X [0..0] 6

[ UB2 ] Universal Bill 92 Information X [0..0] 6

[ PDA ] Patient Death and Autopsy X [0..0] 3

Dynamic Definition

Static Definition – Segment Level

Static Definition – Message Level

1 Interaction Definition

2 Dynamic Definition: ADT/ACK (Event A01)

2.1 ADT^A01

2.2 ACK^A01

3 Static Definition: - Message Level -

ADT/ACK (event A01)

3.1 ADT^A01

3.2 ACK^A01

4 Static Defintiion - Segment Level

4.1 MSH – Message Header Segment Definition

4.2 EVN - Event Type Segment Definition

4.3 PID (Y) - Patient Demographics Segment

Definition

4.4 PD1 – Patient Additional Demographic

Segment Definition

4.5 NK1 - Next of kin Segment Definition

4.6 PV1 (2) - Admit Visit Info Segment

Definition

4.7 AL1 - Allergy Segment Definition

4.8 MSA - Message Acknowledgment Segment

Definition

4.9 ERR - Error Segment Definition

5 Static Definition - Field Level

5.1 Table 0001 – Sex

5.2 Table 0002 – Marital Status

5.3 Table 0003 – Event Type Code

5.4 Table 0004 – Patient Class

5.5 Table 0005 – Race

5.6 Table 0006 – Religion

5.7 Table 0007 – Admission Type

5.8 Table 0008 – Acknowledgement Code

5.9 Table 0009 – Ambulatory Status

: ADT System : ADT Notification

Recipient

ADT^A01

Interaction Definition

2.B.1 Message profile

Definition: An HL7 message profile is an unambiguous specification of one standard HL7 message that have been analyzed for a particular interaction. Each message profile may have a unique identifier as well as publish/subscribe topics.

2.B.1.1 Message profile identifier

Each message profile may have a unique identifier to facilitate reference.

Health Level Seven, Version 2.82.8 ©20112011. All rights reserved. Page 2-209

2.B.1.2 Message profile publish/subscribe topics

The message profile publish/subscribe topics is not required to be unique but might be used by publish/subscribe systems to convey aspects of the message profile (see MSH-21 Message Profile Identifier in the opening section of chapter 2).

The topics are not a normative constituent of the message profile but, if provided as part of the metadata, should be in the format described below. The topic elements will be separated by the dash (-). Any element that does not have a value should use null. As this information may be used in a message instance; it should not contain any HL7 message delimiters.

Message Profile Publish/Subscribe Topics Elements

Seq Topic Element Name Value

1 Implementation/Conformance

Work Group ID confsig

2 An organization identifier Abbreviated version of the organization name

3 The HL7 version Refer to HL7 Table 0104 - Version ID for valid values

4 Topic Type profile

5 Accept Acknowledgement The accept acknowledgement responsibilities.(refer to HL7 Table 0155 –

Accept/application Acknowledgment Conditions for valid values)

6 Application Acknowledgement The application acknowledgement responsibilities (refer to HL7 Table

0155 – Accept/application Acknowledgment Conditions for valid values)

7 Acknowledgement Mode Deferred or Immediate

An example of message profile publish/subscribe topics:

confSig-MyOrganization-2.4-profile-AL-NE-Immediate

2.B.2 Interaction Definition

Definition: An interaction definition documents the scope and requirements for an HL7 message profile.

The interaction definition must:

a) Provide a name that clearly and concisely defines the exchange

b) Document the purpose for the message exchange

c) Define the actors, including the sending and receiving applications

d) Define the flow of events between these actors including, where appropriate, derived events

e) Document the situations in which the exchange of a particular HL7 message profile is required

2.B.3 Dynamic definition

Definition: The dynamic definition is an interaction specification for a conversation between 2 or more systems. It may reference one static definition. The dynamic definition may include an interaction model in addition to the acknowledgement responsibilities.

2.B.3.1 Interaction model

Definition: The Interaction Model illustrates the sequence of trigger events and resulting message flows between 2 or more systems. It may be in literal or graphical form. Graphical form should be a UML activity file:///C:/Users/Oemig/AppData/Local/Temp/V27_CH02C_CodeTables.doc%23HL70104 file:///C:/Users/Oemig/AppData/Local/Temp/V27_CH02C_CodeTables.doc%23HL70155 file:///C:/Users/Oemig/AppData/Local/Temp/V27_CH02C_CodeTables.doc%23HL70155 file:///C:/Users/Oemig/AppData/Local/Temp/V27_CH02C_CodeTables.doc%23HL70155 file:///C:/Users/Oemig/AppData/Local/Temp/V27_CH02C_CodeTables.doc%23HL70155

Page 2-210 Health Level Seven, Version 2.82.8 © 20112011. All rights reserved.

diagram. Example activity diagrams are shown here for the original and enhanced acknowledgement modes.

Interaction Model Example – ADT^A01/ACK^A01 (Original Acknowledgement Mode)

Health Level Seven, Version 2.82.8 ©20112011. All rights reserved. Page 2-211

Interaction Model Example – ADT^A01/ACK^A01 (Enhanced Acknowledgement Mode)

2.B.3.2 Acknowledgements

The specific HL7 acknowledgements required and/or allowed for use with the specified static definition of the HL7 message profile shall be defined. Specifically, the dynamic definition shall identify whether an accept and/or application level acknowledgement is allowed or required.

For any one static definition there may be one or more dynamic definition.

The dynamic definition shall define the conditions under which an accept and/or application level acknowledgement is expected.

Allowed conditions include:

a) Always

Page 2-212 Health Level Seven, Version 2.82.8 © 20112011. All rights reserved.

b) Never

c) Only on success

d) Only on error.

2.B.4 Static definition

Definition: The static definition is an exhaustive specification for a single message. Normatively expressed in XML, it may be registered on the HL7 web site (See Section 2.B.10, "Message profile documentMessage profile document"). The static definition is based on a message structure defined in the HL7 Standard. The message code, trigger event, event description, role (Sender or Receiver) and, if applicable, the order control code will be provided. A complete static definition shall be defined at the message, segment, and field levels. A static definition is compliant in all aspects with the HL7-defined message it profiles.

However, the static definition may define additional constraints on the standard HL7 message.

A static definition identifies only those specific elements of a standard HL7 message that are used in the exchange.

A static definition explicitly defines:

a) Segments, segment groups, fields and components usage rules

b) Cardinalities

c) Length information

d) Value sets and coding systems.

The following figure depicts, in a graphical way, the concept that the static definition is an overlay of the

HL7 message structure further constraining it. For example, where the HL7 message structure shows unlimited number of NK1 Segments, the static definition allows for only three repetitions. Additionally, fields that are optional in the HL7 message structure may be required within the HL7 static definitions.

Formatted: Hyperlink Text, Check spelling and grammar

Health Level Seven, Version 2.82.8 ©20112011. All rights reserved. Page 2-213

Static Definition Illustration

MSH

ADT^A01

Fields/Components:

- Field Usage (Optionality)

- Cardinality (min, max)

- Value Sets/Coding system

- Descriptions

Segments/Segment Groups:

- Segment Usage (Optionality)

- Cardinality (min, max)

HL7 Message Profile HL7 Message Structure

EVN

PID

NK1 NK1 NK1 NK1 NK1

PV1

PV2

OBX

AL1

MSH

EVN

PID

PV1

NK1 NK1 NK1 NK1 NK1

PV2

OBX

AL1

2.B.4.1 Static definition identifier

Each static definition must have a unique identifier when registered (See section 2.B.10, "Message profile documentMessage profile document"). An authority other than the registry may define this identifier. If, at the time of registration, the static profile does not have an identifier assigned by the submitter’s authority, the registry authority will assign one. The static definition identifier would be the identifier used if a system asserts a strict conformance claim (see MSH-21 Message Profile Identifier in the first section of chapter 2).

2.B.4.2 Static definition publish/subscribe topics

Static definition publish/subscribe topics convey the static definition aspects of the message profile. These topics may be used by publish/subscribe systems (see MSH-21 Message Profile Identifier in the first section of chapter 2).

The topics are not a normative constituent of the message profile but, if provided as part of the metadata

(see section 2.B.10, "Message profile documentMessage profile document"), should be in the format described below. The topic elements will be separated by the dash (-). Any element that does not have a value should be null (nothing between the dashes). As this information may be used in a message instance, it should not contain any HL7 message delimiters.

Formatted: Hyperlink Text, Check spelling and grammar

Comment [RDS1]: Now that we clarified that a message profile is not a collection of "message profiles" should we remove the static identifier and use the message profile identifier only. That is, now that there is a true 1-to-1 relantionship is there a need for the static ID now?

FO: yes.

Formatted: Hyperlink Text, Check spelling and

Page 2-214 Health Level Seven, Version 2.82.8 © 20112011. All rights reserved.

Static Definition Publish/Subscribe Topics Components

Seq Topic element name Value(s)

1 Implementation/Conformance

Work Group ID confsig

2 An organization identifier Abbreviated version of the organization name

3 The HL7 version Refer to HL7 Table 0104 – Version ID for valid values

4 Topic Type static

5 Message Type Code Refer to HL7 Table 0076 - Message type for valid values

6 Event Type Refer to HL7 Table 0003 - Event Type for valid values (this table may be extended by locally defined Z trigger events)

7 Order Control Code Refer to HL7 Table 0119 - Order Control Codes for valid values

8 Structure Type Refer to HL7 Table 0354 - Message Structure for valid values (this table may extended by locally defined message structures)

9 Specification Version Version number of the application, interface, or specification

10 Specification Status Status of the application, interface, or specification

11 Role Sender or Receiver

An example of static definition publish/subscribe topics:

confsig-MyOrganization-2.4-static-ADT-A04--ADT_A01-v2-draft-Sender

2.B.5 Table definition

The table definition (or vocabulary) is a specification of a collection of tables used to constrain coded message element content. The table definition is an independent specification that can be embedded in a message profile or referenced by one or more message profiles. Each table definition consists of meta data and code/description pairs. A coded message element is associated with a table in the static definition with the ―table‖ attribute for fields, components, and sub-components. Elements that use coded data types (e.g., CNE, CWE, etc.) are also associated with a table. For the latter, the message includes the code, drawn from

HL7 0396, that uniquely defines the table resp. coding system, as well as the coded value itself.

2.B.5.0 Table Library

The table definition defines a vocabulary that can be bound to a message profile. The table library specifies a standardized format to organize the vocabulary and provides support to reference it (See section X.X.X).

In short, the table library is a container for a collection of tables. Note that the table definition may also be embedded in the XML message profile. A table library is organized as follows:

1) Table library meta data

2) Collection of tables and their values

The table library supports references to tables and instances of tables.

2.B.5.0.1 Table Library Meta Data

The following table describes the table library meta data. Definitions for each attribute are given.

Attributes Definition Example/Enumerations

Name The name of the table library. AdminMessagesVocabulary

OrganizationName The organization that created the library. ABC Medical Group

TableLibraryVersion The version of the table library. 1.2

Status The status of the table library. D (Development), A (Active), I (Inactive)

Comment [FO2]: this is problematic: Table 0396 identifies coding systems like ICD10, but the v2 tables are not codesystems. This part of the current work.

Comment [FO3]: must be referenced file:///C:/Users/Oemig/AppData/Local/Temp/V27_CH02C_CodeTables.doc%23HL70104 file:///C:/Users/Oemig/AppData/Local/Temp/V27_CH02C_CodeTables.doc%23HL70076 file:///C:/Users/Oemig/AppData/Local/Temp/V27_CH02C_CodeTables.doc%23HL70003 file:///C:/Users/Oemig/AppData/Local/Temp/V27_CH02C_CodeTables.doc%23HL70354

Health Level Seven, Version 2.82.8 ©20112011. All rights reserved. Page 2-215

Attributes Definition Example/Enumerations

TableLibraryIdentifier A unique identifier for the table library. 2.16.840.1.113883.3.72.4.2.134

Description A text description of the table library. The Admin Table library provides the vocabulary for our patient registration application (supporting the following message profile events: ADT^A01, ADT^A04, ADT^A08, and ADT^A40).

2.B.5.0.2 Table Definition

A table definition consists of metadata describing the table and specifies a list of code/value pairs. The table definition metadata consists of a table identifier, OID, name, type, version, and code system. Table elements express code/description pairs. Table XXX gives a summary of each table definition attribute along with an example. The table type is a recognized HL7 table as described in section 2.6.3.6. Valid identifiers for a table type are HL7, User, Local, External, and Imported.

Table Attribute Definition Example

Identifier The table identifier 0001

OID An OID that identify the table, not the codesystem 2.16.840.1.113883.12.1

Name A descriptive name of the table Administrative Sex

Type The type of the table as described in section 2.6.3.6 HL7

Version The version of the table 1.0

Code System A code system as specified in the HL7 table 0396 2.5.1

A table element consists of a code, display name (value), and source . Table XXX gives a summary of each table element attribute along with an example. Valid identifiers for the table element source are HL7, Local, Redefined, or Standard Development Organization (SDO). Redefined means the code/display name has been changed from its original value.

Element Attribute Definition Example

Code The code for the data value M

Display Name The long description of the code Make

Source The source of the code/value pair HL7

2.B.5.2 Conformance Requirements

The content of a table definition is used to express conformance requirements of coded message elements defined in a message profile. If the content of a message element matches that of a table element defined in the table definition identified with the Table attribute, the content of the message element is said to be conformant with respect to the message profile. If the content of a message element does not match a table element defined in the table definition identified with the Table attribute, the content of the message element is said to be non-conformant with respect to the message profile.

2.B.6 Profile type

There are three basic profile types used in documenting standard conformance:

a) HL7 Standard profile (represents a specific HL7 published standard, creation and publication limited to HL7 use),

b) constrainable profile (with ―Optional‖ elements which must be further constrained in order to

Page 2-216 Health Level Seven, Version 2.82.8 © 20112011. All rights reserved.

create implementation profiles), and

c) implementation profile (no ―Optional‖ parts, fully implementable).

This model allows vendors, SDOs, PEOs or providers to publish generic profiles from which fully constrained implementation profiles can be created.

In comparison with the HL7 standard, separate constrainable and implementation profiles may exist for the receiving and the sending role.

Both constrainable profiles and implementation profiles focus primarily on the expectations of the sending application, with fewer constraints on the application behavior of the receiver.

2.B.6.1 Vendor constrainable profiles

A vendor might develop a message profile to which all their software products must comply but, in itself, is not an implementation profile. The different products serve potentially different domains and might be implemented with products from other vendors. The vendor profile constrains the HL7 Standard by defining agreed-to vocabularies, conditionality rules, supported items, and local extensions that are shared across all products. The profile is not necessarily fully constrained. For example, the vendor profile might allow the usage code of optional as, across different products, an element may be required in some use cases, be optional or conditional in others, and not be supported at all in still others. Furthermore, at this level, providing exact length definition is optional as well.

The vendor's individual software products might themselves have profiles that would build on, and further constrain, their vendor profile. The product profile would specifically define the information model and the elements contained within. The product profile might still be a constrainable profile as elements might result in different HL7 messages based on configuration settings and customizations. Only once all configuration settings and customizations have been taken into account can you have a fully-constrained

'Implementation' profile.

Constrainable profiles can be useful for interface engine applications which must be flexible enough to allow for receipt of messages based on a variety of message profiles. The desire of the application would be to validate message instances against one constrainable profile.

2.B.6.2 Realm constrainable profiles

Realms, national and regional, profiles represent localization and restrictions placed on the appropriate standard, while providing enough optionality for basing the more specific implementation profiles. Some examples of realm constrainable profiles are:

a) AS4700.1-2001 Implementation of HL7 v2.3.1 Part 1:Patient Administration (constrainable profile for Australian Standards, constrains HL7 2.3.1, Chapter 3).

b) AS/NZS 4700.3-1999 Implementation of HL7 v2.3 Part 3: Electronic messages for exchange of information on Drug Prescription (constrainable profile for Australian Standards, constrains HL7

2.3, various Chapters).

2.B.6.3 Implementation profiles

Implementation profiles represent the lowest level of specification required for unambiguous implementation. Examples of some implementation profiles are:

a) Adverse Drug Reaction Implementers Specification, 2001, TGA (implementation profile, constrains Australian Standards and HL7 v2.3.1 constrainable profiles for Therapeutic Goods

Administration ADRAC Messaging Implementation Project),

b) Diabetes Reporting Implementers Specification, 2001, UNSW (implementation profile, constrains

Australian Standards and HL7 v2.3.1 constrainable profiles for University of NSW Diabetes

Messaging Implementation Project), Comment [FO4]: we should remove this paragraph

Health Level Seven, Version 2.82.8 ©20112011. All rights reserved. Page 2-217

c) Specific version of a product, as implemented, at a specific provider.

Within an implementation profile the exact length definition must be provided.

2.B.7 Static definition concepts

This section discusses concepts common to each level of the static definition (message, segment and field).

It uses the generic term 'element' to refer to segment groups, segments, fields, components and sub-components.

2.B.7.1 Length

An unambiguous definition of length requires a clear understanding of what it applies to and how it is measured. Length is defined to be a constraint on the number of characters that may be present in one occurrence of a message element. This definition satisfies both requirements; it applies (strictly) to an element’s data value—i.e., the set of characters present in the message representing a value of the element’s predefined data type—and it is measured in characters as defined by the rules in chapter 2. The definition is system independent. For example, a system that encodes characters using one byte and a system that uses two-byte encoding would use the same value for length to impose the same length constraint. Length does not count the HL7 characters used to represent the value, only the number of characters in the value itself is counted. If the null character is represented by transmitting "", length conforms to any minimum and maximum length specification.

Length shall be interpreted as a restriction on an element’s data value, not on the presence or absence of the element. A length value of zero is appropriate when the null character is transmitted, but this does not imply the element is not present; clearly two characters will be present if null is transmitted. Restricting the applicability of length to data values present in the message is necessary. Not only does it keep the concept simple and eliminate the need to address special cases, it also allows for the transmission of null values for required elements. A required element can have a null value, since this still clearly means there is a data value encoded for the element in the message. If an element is empty or not present in the message, i.e., there is no data value encoded for the element in the message, then length restrictions do not apply since there is nothing to restrict and no length constraint that can be violated.

Length shall be specified using the following syntax: "m..n", where m and n are non-negative integers designating the minimum and maximum number of characters the element may have, respectively, where n

m. When an upper bound for length cannot be determined in advance, the use of the asterisk character, "*", may be used as a place holder for the maximum value, so that, in addition, to the above syntax, where m and n are integer values, a constraint of the form "m..*" may be used to indicate the maximum length constraint is unknown.

Example length constraints are shown in the Minimum and Maximum Length Examples table.

Minimum and Maximum Length Examples

Value Description Comment

For constrainable profile: no length defined, i.e. no requirements on the length are given.

Leaving this information empty is not allowed for implementable profiles.

0..0 For withdrawn elements: minimum and maximum set to 0.

1..1 Element must have exactly one character

1..n Element may have up to n characters n..n Element must have exactly ―n‖ characters

1..* Element may have any length.

n..* Element may have any length which is greater than or equal to ―n‖, where ―n‖ is greater than or equal to 1.

Page 2-218 Health Level Seven, Version 2.82.8 © 20112011. All rights reserved.

Value Description Comment m..n Element must have a minimum length of ―m‖ and a maximum length of ―n‖ where

―m‖ is less than or equal to ―n‖ and ―m‖ is greater than or equal to 1.

Note: Whether or not an element is populated is controlled by cardinality. But if the element is populated with a non null value, the minimum and maximum length definition must hold. The null information representation (two double quotes) is not considered to be a value with applicable length information.

Length should not be specified for composite elements. In these cases, the actual minimum and maximum lengths can be very difficult to determine due to the interdependencies on the component content, and the specification of actual lengths is not useful either. For example, if an overall length of 4..20 is assigned to a data element with a type CWE, what does this mean in practice? However if a length is specified, the vertical bar representation of the data must conform to the stated length, allowing for an additional character for each HL7 separator character.

2.B.7.2 Conformance Length

Constrainable profile specifications may also specify a conformance length. This is the number of characters that any conformant application must be able to correctly handle. For example, a constrainable profile may declare that the minimum and maximum lengths of a specific field are 3 and 2500. An implementation profile may further constrain this length to specify what is actually supported by an application. However an application could declare a length of 3..4, which may not be useful within the context of the constrainable profile. A constrainable profile may specify conformance lengths to establish a minimum expectation. In the example case, if the constrainable profile specifies a conformance length of

200, no other profile may assert conformance to the constrainable profile unless its maximum length is 200 or greater.

Conformance length is a redundant concept in implementation profiles that will not be further constrained, and should not be specified.

2.B.7.3 Truncation Flag

As of 2.7, a truncation pattern is defined which can be used to assist applications to manage the existence of data that exceeds the maximum number of characters that can be properly handled. The truncation pattern is described in Chapter 2, section 2.5.5.2, "Truncation Pattern". Note that the actual truncation behavior of the pattern is data type dependent. Applications shall not use truncation if the profile prohibits it.

Applications may support truncation if the profile permits it. Message Profiles may specify the truncation behaviour.

The truncation flag is a simple boolean. In a constrainable profile, the value may be true or false. False signifies that the element may not be truncated, while true means that the value may be truncated. If a profile fixes truncation to false, no other further constraining profile may mark this value as true. If the value is fixed to true, other further constraining profiles may mark it as true or false.

In an implementation profile, a value of true for the truncation flag signifies that the application supports the defined truncation behaviour for the appropriate type. A value of false indicates that the application does not support data truncation for this element.

Although the truncation pattern was only defined in v2.7, the bahaviour may be adopted for previous versions of HL7, and the truncation flag may be used with previous version. Note that in these cases, the truncation character cannot be specified in the message, and some other arrangement must exist.

2.B.7.4 Cardinality

In order to separate message content requirements from application behavior requirements, cardinality is used to control message content, and usage is used to define application requirements. Cardinality controls the number of occurrences of an element appearing in a message. Some elements shall always be present

(e.g., cardinality [1..1], [1..n]). Others shall never be present (i.e., cardinality [0..0]). Others may be optional with zero or more occurrences (e.g., cardinality [0..n]). Cardinality identifies the minimum and maximum number of occurrences that a message element must have in a conformant message. Cardinalities

Comment [FO5]: in which way? We haven’t specified this, or did we?

Comment [RDS6]: Does this mean the total character without regard to the min/max? If so, how is this specified--is this in the schema?

FO: to my understanding, you either specify a conformance length OR min/max. It does not make sense to have both.

AND: It is just a guidance. Or is it a real requirement to have a maximum length being greater thatn that?

Comment [RDS7]: Need to confirm this attribute is in the message profile schema.

Health Level Seven, Version 2.82.8 ©20112011. All rights reserved. Page 2-219 are expressed as a minimum-maximum pair of non-negative integers. A conformant message must always contain at least the minimum number of occurrences, and shall not contain more than the maximum number of occurrences.

An explicit cardinality range is required for segment group, segment, and field elements. Component and sub-component elements do not explicitly include a cardinality range, but a cardinality range is implicitly associated with each component and sub-component element. The associated cardinality depends on the element’s usage code. For components and sub-components with a usage code of R, the associated cardinality range is [1..1]; for all elements with a usage code of RE, C, CE, or O, the associated cardinality is [0..1]; and for all elements with an X usage code, the associated cardinality is [0..0].

There are two special values for cardinality. If the minimum number of occurrences is 0, the element may be omitted from a message. In certain circumstances, the maximum number of occurrences may have no specified limit. In this case, it is identified with "*" (e.g., [n..*]).

Valid cardinality values are shown in the Cardinality table; combinations not designated in the table are invalid. In particular usage code RE is not allowed with cardinalities [1..1], [1..n], and [1..*]. Cardinality

[m..n], where m is greater than 1, is allowed with usage codes R and RE. If an element with this cardinality range has a usage code RE, the element may be omitted from the message but if present, it must have at least m occurrences and may not have more than n occurrences.

Cardinality

Value Description Valid Usage

Codes

Comment

[0..0] Element never present X

[0..1] Element may be omitted and it can have at most one occurrence RE, O, C

, CE

[1..1] Element must have exactly one occurrence R

[0..n] Element may be omitted or may have up to n occurrences RE, O, C

, CE

[1..n] Element must appear at least once, and may have up to n occurrences R

[0..*] Element may be omitted or may have an unlimited number of occurrences RE, O, C

, CE

[1..*] Element must appear at least once, and may have an unlimited number of occurrences

R

[m..n]

Element must have at least "m" occurrences and may have at most "n" occurrences. Except that in the case where the usage code is RE, the element may also be omitted or have zero occurrences

R and RE

[m..*] Element must have at least "m" occurrences and may have an unlimited number of occurrences. Except that in the case where the usage code is RE, the element may also be omitted or have zero occurrences.

R and RE

2.B.7.5 Usage

Message content is governed by the cardinality specification associated (explicitly or implicitly) with each element of an HL7 message. Usage rules govern the expected behavior of the sending application and receiving application with respect to the element. The usage codes expand/clarify the optionality codes defined in the HL7 standard. Usage codes are employed in a message profile to constrain the use of elements defined in the standard. The usage code definitions are given from a sender and receiver perspective and specify operational and implementaiton requirements.

The standard allows broad flexibility for the message structures that HL7 applications must be able to receive without failing. But while the standard allows that messages may be missing data elements or may contain extra data elements, it should not be inferred from this requirement that such messages are

If the usage code is C, then the element must be present if the associated condition predicate evaluates to true.

m must be greater than 1 and n must be greater than or equal to m; the case where m equals 1 is addressed separately.

Comment [RDS8]: {This is Frank's Comment}I am not sure whether we can and should rename this section and all related stuff!?

I do not like the destinction between optionality and usage.

Comment [RDS9]: {This is Frank's comment}

For me, both are identical in the end. The only difference is the ―use‖: optionality is used in the standard, usage in derived profiles. In principle there is no need to have both! I rather recommend to use one for both.

The inclusion of ―RE‖ in the standard is an indication therefore.

Page 2-220 Health Level Seven, Version 2.82.8 © 20112011. All rights reserved.

conformant. In fact, the usage codes specified in a message profile place strict conformance requirements on the behavior of the application.

Usage Rules for a Sending Application

Optionality/

Usage

Indicator

Description Implementation Requirement Operational Requirement

R Required The application shall implement ―R‖ elements.

The application shall populate ―R‖ elements with a non-empty value.

RE Required but may be empty

The application shall implement

―RE‖ elements.

The application shall populate ―RE‖ elements with a non-empty value if there is relevant data. The term ―relevant‖ has a confounding interpretation in this definition

C Conditional The application shall implement ―C‖ elements.

The application shall populate ―C‖ elements with a non-empty value if the condition predicate associated with the element is true (See section 2.B.7.92.B.7.9, "Condition predicateCondition predicate"). The application shall NOT populate ―C‖ elements if the condition associated with the element is false.

(NOTE: If the condition predicate is satisfied, C and R are equivalent from an operational viewpoint. If the predicate is

NOT satisfied, C and X are equivalent from an operational viewpoint).

CE Conditional but it may be empty

The application shall implement

―CE‖ elements.

The application shall populate ―CE‖ elements with a non-empty value if the condition predicate associated with the element is true and if there is relevant data (See section

2.B.7.92.B.7.9, "Condition predicateCondition predicate").

The application shall NOT populate ―CE‖ elements if the condition associated with the element is false.

(NOTE: If the condition predicate is satisfied, CE and RE are equivalent from an operational viewpoint. If the predicate is NOT satisfied, CE and X are equivalent from an operational viewpoint).

X Not supported

The application shall not implement

―X‖ elements.

The application shall not populate ―X‖ elements.

O Optional None. The usage indicator for this element has not yet been defined.

For an implementation profile all optional elements must be profiled to

R, RE, C, CE, or X.

Not Applicable.

Usage Rules for a Receiving Application

Optionality/

Usage

Indicator

Description Implementation Requirement Operational Requirement

R Required The application shall implement ―R‖ elements.

The receiving application shall process

(save/print/archive/etc.) the information conveyed by a required element.

A receiving application shall raise an exception due to the absence of a required element. A receiving application shall

There are multiple interpretations of ―RE‖ when a value is known. One is ―the capability must always be supported and a value is sent if known‖, the other is ―the capability must always be supported and a value may or may not be sent even when known based on a condition external to the profile specification. The condition may be noted in the profile but cannot be processed automatically‖. This is what can be interpreted from the ―relevant‖ part of the definition. Regardless of the interpretation the ―RE‖ usage code, a set of test circumstances can be developed to sufficiently test the ―RE‖ element. See the ―Conformity Assessment of Conformance Constructs‖ section for more details.

Formatted: Hyperlink Text

Formatted: Check spelling and grammar

Formatted: Hyperlink Text

Formatted: Check spelling and grammar

Health Level Seven, Version 2.82.8 ©20112011. All rights reserved. Page 2-221

Optionality/

Usage

Indicator

Description Implementation Requirement Operational Requirement not raise an error due to the presence of a required element, RE Required but may be empty

The application shall implement

―RE‖ elements.

The receiving application shall process

(save/print/archive/etc.) the information conveyed by a required but may be empty element. The receiving application shall process the message if the element is omitted (that is, an exception shall not be raised because the element is missing).

C Conditional The application shall implement ―C‖ elements.

The receiving application shall process

(save/print/archive/etc.) the information conveyed by a conditional element if the condition predicate associated with the element is true (See section 2.B.7.92.B.7.9, "Condition predicateCondition predicate").

A receiving application shall raise an exception due to the absence of a conditional element if the condition predicate associated with the element is true.

A receiving application shall not raise an error due to the presence of a conditional element if the condition predicate associated with the element is true, If the condition predicate associated with the conditional element is false and the element is sent the receiving application may process the message, shall ignore the element, and may raise an exception. The receiving application shall not process (save/print/archive/etc.) the information conveyed by a conditional element if the predicate evaluates to false.

CE Conditional but it may be empty

The application shall implement

―CE‖ elements.

The receiving application shall process

(save/print/archive/etc.) the information conveyed by a conditional but may be empty element if the condition predicate associated with the element is true. The receiving application shall process the message if the element is omitted (that is, an exception shall not be raised because the element is missing).

If the condition predicate associated with the conditional but may be empty element is false and the element is sent the receiving application may process the message, shall ignore the element, and may raise an exception. The receiving application shall not process (save/print/archive/etc.) the information conveyed by a conditional but may be empty element if the predicate evaluates to false.

X Not supported

The application shall not implement

―X‖ elements.

None, if the element is not sent.

If the element is sent the receiving application may process the message, shall ignore the element, and may raise an exception. The receiving application shall not process

(save/print/archive/etc.) the information conveyed by a not-supported element.

O Optional None. The usage indicator for this element has not yet been defined.

For an implementation profile all optional elements must be profiled to

R, RE, C, CE, or X.

None.

2.B.7.6 Relationship between HL7 optionality and conformance usage

Conformance usage codes are more specific than HL7 Optionality codes. Because of the requirement that conformance statements must be compliant with the HL7 message definition it is derived from, there are

Formatted: Hyperlink Text

Formatted: Check spelling and grammar

Page 2-222 Health Level Seven, Version 2.82.8 © 20112011. All rights reserved.

restrictions on what usage codes may be assigned to an element based on the HL7 Optionality. For example, any element designated as required in a standard HL7 message definition shall also be required in all HL7 message profiles of that standard message.

HL7 Optionality and Conformance Usage

Base Optionality/Usage Derived (Constrained)

Optionality/ Usage

Comment

R - Required R

RE - Required but may be empty

RE, R

O - Optional R, RE, O, C, CE, X O is only permitted for constrainable profiles

C - Conditional C, CE, R Note that in the ―Base‖ column ―C‖ refers to the standard definition of ―C‖. In the ―Derived‖ column

―C‖ refers to the conformance usage definition of

―C‖.

X – Not Supported X

B – Backward Compatibility R, RE, O, C, CE, X B is only permitted for constrainable definitions

W - Withdrawn X

Conformance usage codes can also be further constrained in subsequence constrainable or implementation profiles. The allowed conformance usage profiling table indicates the how the conformance usage codes can be further constrained.

Allowed Conformance Usage Profiling

Conformance Usage Constrained Possibilities Comment

R - Required R

RE - Required but may be empty RE, R

C - Conditional R, RE, C, Note this is the profiled definition of ―C‖ not the standard definition of ―C‖

CE – Conditional but may be empty

R, RE, C, CE

X – Not Supported X

2.B.7.7 Relationship between usage and cardinality

Cardinality governs the appearance of a field, and usage governs the expected behavior of applications.

Nevertheless, a relationship exists between them that must be maintained. The valid combinations of the two are defined in the Cardinality table. For purposes of message profiles, selected cardinality and usage combinations are examined here. The constraints on allowed combinations are:

a) If the usage of an element is Required (R), the minimum cardinality for the element shall always be greater than or equal to 1.

b) If the usage of an element is not Required (R) (i.e., any code other than 'R'), the minimum cardinality shall be 0 except in the following condition:

c) If the profile author wishes to express a circumstance where an element will not always be present, but when present must have a minimum number of repetitions greater than one, this may be

This is an optionality added with 2.7. The meaning is slightly different from the message profile usage code of RE.

Comment [FO10]: in chapter 2 they refer to the condition details in the field definitions. Therefore it is not fixed to ―R/X‖ for ―C‖.

Therefore, we should also go into that direction. Right now, we are currently moving into a dead end.

But if we loosen…