2 .B Control (continued)

Chapter Chair

Frank Oemig Agfa HealthCare GmbH

Chapter Chair

Robert Snelick

National Institute of Standards and Technology (NIST)

Chapter Chair

Wendy HuangCanada Health Infoway

Chapter Chair

Ioana SingureanuEversolve, LLC

Sponsoring Work Group:

Conformance and Guidance for Implementation/Testing

List Server:

cgit@lists.hl7.org

2.B CONFORMANCE USING MESSAGE PROFILES

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

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

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:

1. one use case analysis,

2. one or more dynamic definitions,

3. one or more static definitions, and

4. one table (vocabulary) definition.

The use case analysis may be documented as a use case diagram (supported with text) or just a textual description (See section 2.B.2, "Use case model".)

The dynamic definition is an interaction specification for a conversation between 2 or more systems (See Section.2.B.3, "Dynamic definition".)

The static definition is an exhaustive specification for a single message structure (see Section 2.B.4, "Static definition"). 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 document").

The table (vocabulary)definition is an exhaustive specification for a single message structure (see Section 2.B.5, "Table definition"). 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 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.

Message Profile Example

2.B.1 Message profile

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

2.B.1.0 Message profile identifier

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

2.B.1.1 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

An example of message profile publish/subscribe topics:

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

2.B.2 Use case model

Definition: A use case model documents the scope and requirements for an HL7 message profile or set of message profiles.

The use case model must:

1. Provide a name that clearly and concisely defines the exchange

2. Document the purpose for each message exchange

3. Define the actors, including the sending and receiving applications

4. Define the flow of events between these actors including, where appropriate, derived events

5. Document the situations in which the exchange of a particular HL7 message profile is required

Refer to the HL7 V3.0 Message Development Framework (MDF 99) for further information on use case models and their uses within HL7.

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 to many static definitions. The dynamic definition may include an interaction model in addition to the acknowledgement responsibilities.

2.B.3.0 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 diagram. Example activity diagrams are shown here for the original and enhanced acknowledgement modes.

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

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

2.B.3.1 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:

1. Always

2. Never

3. Only on success

4. 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 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:

1. Segments, segment groups, fields and components usage rules

2. Cardinalities

3. Length information

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

Static Definition Illustration

2.B.4.0 Static definition identifier

Each static definition must have a unique identifier when registered (See section 2.B.10, "Message 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.1 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 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.

Static Definition Publish/Subscribe Topics Components

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

Table definitions will include statements of table conformance and, if available, the actual table elements supported.

2.B.5.0 Statements of table conformance

Statements of table conformance will consist of the definition of the table and its constituent elements. To the maximum extent practical it should be possible to objectively validate the content of a given message instance against the table definition in the profile.

2.B.5.1 Table values

The table definition can specify tables supported and the usage of values in those tables. The source of the tables will be HL7, User, Local, External, or Imported. For each table, the identifier, description and code system will be supplied. The table identifier and version may also be supplied.

For each element identified in the table, the code, display name, source, and usage (Refer to 2.B.7.5, "Usage") will be supplied. The source of the individual element will be HL7, User, Redefined, or SDO.

2.B.6 Profile type

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

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

2. constrainable profile (with "Optional" elements which must be further constrained in order to create implementation profiles), and

3. implementation profile (no "Optional" parts, fully implementable).

This model allows vendors 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 minimal constraints on the application behavior of the receiver.

Due to the HL7 principle of not specifying application behavior, this message profile section will not address use cases where explicit constraints on the expected behavior of the receiver application (e.g., whether the receiver must process information, ignore it or generate an error) are required.

2.B.6.0 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.1 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:

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

2. 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.2 Implementation profiles

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

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

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

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

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

2.B.7 Static definition concepts

2.B.7.0 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 field or 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 are 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

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 min and max 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 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 min and max 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 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, or O, the associated cardinality is [0..1]; for all elements with a usage code of C(a/b), the associated cardinality is determined by the resultant usage based on the evaluation of the condition predicate, 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

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 implementation and operational 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 conformant. In fact, the usage codes specified in a message profile place strict conformance requirements on the behavior of the application.

2.B.7.5.1 Definition of Conditional Usage

The conditional usage is defined as follows:

C(a/b) - "a" and "b" in the expression are placeholders for usage codes representing the true ("a") predicate outcome and the false ("b") predicate outcome of the condition. The condition is expressed by a conditional predicate associated with the element ("See section 2.B.7.9, "Condition predicate"). "a" and "b" shall be one of "R", "RE", "O" and/or "X". The values of "a" and "b" can be the same.

Usage Rules for a Sending Application

Usage Rules for a Receiving Application

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

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:

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

2. 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:

3. 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 occurrences greater than one, this may be indicated by specifying the non-required Usage code with the minimum cardinality representing the minimum number of occurrences when the element is present. This is accomplished, as in UML, with an expression of the form as (m..n), indicating that permitted occurrences are either zero, or the range of n through m.

Example combinations:

Example Usage-Cardinality Combinations

As part of the conformance framework, there is an additional rule for determining whether a particular 'element' is present. The rule is as follows: For an element to be considered present, it must have content. This means that simple elements (fields, components or sub-components with simple data types such as NM, ST, ID) must have at least one character. Complex elements (those composed of other elements, e.g., Messages, Segment Groups, Segments, Fields with complex data types such as CNE, XPN, etc.), must contain at least one component that is present. Elements that do not meet these conditions are not considered to be present.

For example, if a segment is made up of 10 optional fields, at least one of the fields must be present in order for the segment to be considered present. Thus, if the segment is marked as Required, an instance message would only be conformant if the segment contained at least one field. The reason for this rule is to ensure that the intent of the profile is met. The rule is necessary because the traditional 'vertical bar' encoding allows for a bare segment identifier with no fields (e.g., a line containing just "NTE|" would be considered valid under the standard rules, but would be considered not present as far as testing against a conformance specification). The XML encoding also allows this, as well as fields without their components, components without their sub-components, etc. (e.g., <PID.3/>).

2.B.7.9 Condition predicate

If the usage code of an element is C, then a conditionality predicate must be associated with this element that identifies the conditions under which the element must be or is allowed to be present. The predicate must be testable and based on other values within the message. This predicate may be expressed as a mathematical expression or in text and may utilize operators such as equivalence, logical AND, logical OR and NOT. The conforming sending and receiving applications shall both evaluate the predicate. When the Usage is not 'C', the conditionality predicate will not be valued.

2.B.7.10 Annotation

Annotations provide further explanations to educate prospective users and/or implementers. These are usually used to enhance the descriptions of the elements of the base specification in order to relate them to a particular Context.

Types of annotations supported:

Definition: An explanation of the meaning of the element.

Description: An explanation of the associated element. This may contain formatting markup.

Design Comment: Internal development note about why particular design decisions were made, outstanding issues and remaining work. They may contain formatting markup. Not intended for external publication.

Implementation Note: Implementation Notes provide a general description about how the element is intended to be used, as well as hints on using or interpreting the it.

Other Annotation: Additional content related to the element.

Example: An example instance

Added ability to communicate pattern matching and element relationships. These, as well as condition predicate, will allow for text and formal testable constraints.

2.B.8 Static definition - message level

The message level static definition shall be documented using the HL7 abstract message syntax, with the addition of specifying cardinality and usage for each of the segments contained within the message structure.

The usage column shall be updated to reflect the usage of the segment or group within this particular static definition.

The cardinality column shall accurately reflect the minimum and maximum number of repetitions of the field allowed for the segment or group within this particular static definition.

Sample Static Definition - Message Level

The set of segments and segment groups included within the message shall be defined. Any segments or segment groups that are required by HL7 shall be included.

2.B.8.1 Segment usage

The usage of the segment or group within a message shall be defined using one of the codes in the previously defined usage table.

2.B.8.2 Segment cardinality

Some segments and segment groups within the HL7 message are allowed to repeat. The cardinality of all the segments and groups within the message shall be defined.

Static definition - segment level

The segment level static definition shall be documented using the HL7 segment attribute table format with the addition of specifying length, usage and cardinality for each of the fields contained within the segment.

• The length column shall be updated to accurately reflect the maximum allowed length for the field within this segment definition.

• The usage column shall accurately reflect the usage of the field within this segment definition.

• The cardinality column shall accurately reflect the minimum and maximum number of repetitions of the field allowed for this segment definition.

Sample Segment Level Definition - PID (Patient Identification) Segment

The set of fields of each segment within the message level definition shall be specified.

If a segment occurs multiple times within a message profile, it may be represented by different segment profiles. This shall be explicitly defined within the message level definition.

2.B.8.4 Field cardinality

Some fields within a segment are allowed to repeat. The cardinality of all the fields within the segment shall be defined.

2.B.8.5 Field usage

The usage of the field within a segment shall be defined consistent with the profile type, and using one of codes identified in the previously defined Usage tables.

2.B.8.6 Data type

The data type of the field within a segment shall be updated to accurately reflect the data type for the field within this segment definition.

2.B.8.7 Length

The length of the field within a segment shall be updated to accurately reflect the correct length for the field within this segment definition. Here two information items shall be provided representing the required minimum length a data constituent must have and the maximum length this constituent must not exceed.

2.B.8.8 Conformance Length

This length represents the number of characters that a conformant application must be able to handle. For further information please see Chapter 2, section 2.5.5.3, "Conformance Length".

2.B.8.9 Table reference

The name of the table of the field within a segment shall be updated to accurately reflect the table used for the field within this segment definition.

2.B.9 Static definition - field level

2.B.9.0 Field Definitions

Each individual field within a segment shall be completely defined to eliminate any possible ambiguity.

In cases where HL7 2.x field descriptions are not sufficient, a precise semantic definition shall be specified.

2.B.9.1 User-defined and suggested field values

The allowed code sets (table) for many fields within the HL7 Standard are specified as user-defined (data type IS) or HL7-defined (data type ID) values.

In these cases, the exact allowed code set shall be specified. These values shall be defined according to the specified scope of use for the message profile by vendors, provider, or within a realm.

Coded Entry (CE, CF, CWE, and CNE) type fields are specified as being populated based on coding systems. For each of these fields, the specific coding system used shall be identified. Compliant applications are required to use the specified coding system, but may also use an alternate coding system as supported by the data type (See the example within each data type definition).

2.B.9.2 Constant values

If an element will always have a constant value, this shall be specified. Constant values may only be specified for elements that represent primitive data types, i.e., they have no components or sub-components.

2.B.9.3 Data values

A list of example data values for the element may be specified. Data values may only be specified for elements that represent primitive data types i.e. they no components or sub-components.

2.B.9.4 Pattern Matching

Constraints for matching patterns within fields may be specified. In addition to textual description of the constraint, formal expressions may be specified. These formal expressions can be Object Constraint Language (OCL), regular expressions (RegEx), and XML Path Language (XPath)

2.B.9.5 Element Relationships

Element relationships may be may be specified. In addition to textual description of these constraints, formal expressions may be specified. These formal expressions can be Object Constraint Language (OCL), regular expressions (RegEx), and XML Path Language (XPath)

2.B.9.6 Components and subcomponents

Many fields and components in versions of HL7 prior to 2.5 were defined to be Composite Data (CM) data types. As of 2.5, all field instances will reference a valid data type other than CM. Addenda for versions 2.3.1 and 2.4 are available that define more precise names for the CM data types. These names allow a more precise data type name for each of the fields using the former CM data type to be more easily used for XML encoding of message instances. Although message profiling is not limited to a specific version of HL7, it is strongly encouraged that these new data types be used to increase interoperability between versions.

Each component within composite fields shall be profiled. This requires defining the usage, length, data type, and data values of each of the components. Where there are sub-components of a component, each of the sub-components shall also be profiled using the same method. With the exception of cardinality, the rules for these definitions follow those for fields (See section 2.B.9, "Static definition - field level").

2.B.10 Message profile document

HL7 Headquarters will provide a utility, hereafter called registry, on the Members' Only Web site (http://www.hl7.org) where the message profile can be registered.

Messages profiles in the registry are all catalogued with a set of metadata. Those entities submitting message profiles into the registry will need to fill out a form that captures the required metadata information. The registry and the metadata will be documented in an informative document and will not be discussed further in this document.

2.B.10.0 Message profile document format

The Implementation/Conformance Work Group researched the best approach to standardize the format of a message profile to facilitate comparison and measurement. XML (eXtensible Markup Language XML W3C XML 1.0 2nd Ed) documents appeared to be the best tool for this.

This use of XML is not, in any way, related to the HL7 2.xml encoding specification that describes the XML encoding of message instances. The message profile document format provides structure to the documentation of the message profile and does not limit the encoding of an actual message instance.

2.B.10.1 Message profile document definition

A message profile document will be a valid HL7 message profiles if it conforms to the constraints expressed in the message profile document definition (See section 2.B.12, "Message profile document definition"), and the additional rules described in this document.

2.B.11 Tools

The tools used for creation, sharing, re-use, reporting, analyzing, and comparing message profiles are outside the scope of the HL7 standard. Refer to the Implementation/Conformance Work Group web site for useful links that are of widespread interest to, and in support of, message profiles and the Implementation/Conformance Work Group.

2.B.12 Message profile document definition

The Implementation/Conformance WG researched the various ways to express the structure of the message profile document. The Document Type Definition (DTD) allows for declaring constraints on the use of markup. XML Schema Language provides a more rigorous and comprehensive framework for automated processing of XML documents.

The message profile DTD and schema are both included here. The message profile schema is normative in order to express the rules by which the registry will validate (see section 2.B, "Conformance Using Message Profiles").

2.B.12.0 Message profile schema

The following items are being discussed in the Implementation/Conformance Work Group for addition to future versions of HL7:

1. Conformance Based Queries use of the Message Profiles. Current status of this can be found on the Implementation/Conformance Work Group web page on the HL7 web site. (http://www.hl7.org).