Refinement, Constraint and Localization, Release 2

Thank you for reviewing Refinement, Constraint, and Localization, Version 3, Release 2, Committee 3 Ballot

The aim of this release is to remove ambiguity regarding some of the "rules" expressed the Version 3, Release 1 material. This chapter is balloted as a third Committee Ballot in response to serious concerns raised in the negative ballot responses received at the Membership Level Ballot.

One serious issue that is still pending resolution is the allowance for CMET substitution by Affiliates. (CMETs (§ 5.4.2 ))The language for this allowance has been updated based on input from the International Commiteee.

A number of comments were received from the last ballot regarding the synchronization of the concepts and terms of this chapter with the same concepts and terms as discussed in the HDF. This issue was discussed in both the Conformance SIG and MnM meetings. An agreement was reached that the normative 'source of truth' for any given concept will reside in only one document. All other documents will reference the normative language. No attempt has been made to do this during this ballot. The Conformance SIG will focus on getting this chapter, the HDF and other relevant documents sync'd for the next ballot of this chapter.

Summary of Changes from Version 3, Release 2, Membership Ballot 1

Typographical corrections

Summary of Changes from Version 3, Release 1

Clarified the definition for default values and the rules for assigning and using. (Default value (§ 2.6.1 ))
Added a definition for the concept of defining a ‘fixed’ value for an attribute and the rules for using. (Fixed Declaration (§ 2.6.2 ))
Removed the sentence regarding the HL7 adoption of OCL. (Co-occurance Constraints (§ 2.6.3 ))
Clarified the need to submit informal extensions to an HL7 Committee. Informal extensions of the type ‘implementation-specific’ extensions shall not be subject to submittal to an HL7 Committee for possible standardization. (Informal Extensions (§ 5.1.2 ))
Clarified that the registration process for localizations is currently not supported by HL7 and therefore is not required in this release. (Approval Processes (§ 5.1.3 ))
Clarified the meaning of conformance statement and conformance profile. (Conformance Profiles, Conformance Statements and Conformance Claims (§ 4.2 ))
Provided an initial listing for the contents of a conformance profile (Conformance Profiles, Conformance Statements and Conformance Claims (§ 4.2 ))

The Version 3 Messaging standard provides a rich set of messages to support communications in a variety of clinical and other health related endeavors. Moreover, HL7 Version 3 messages will be specific enough to permit strong conformance claims to be asserted and verified. Refer to Conformance Statements (§ 4 ) for more details. Nevertheless, any standard faces two challenges. First, it can always be made more specific in order to provide a more precise solution to a particular requirement. Second, it will not contain all of the data needed in every environment, particularly when international requirements are considered. These challenges lead to a pair of complementary requirements: the ability to constrain the standard in more detail, and the ability to extend the standard in a controlled fashion.

The Constraints and Annotations (§ 2 ) section documents, in a normative fashion, what the HL7 Technical Committees are permitted to do as part of the Version 3 Refinement process (§ 1.2 ).

Intertwined with the notions of constraining and extending the standard are two critical capabilities – the ability to establish a testable statement of conformance to the standard, and the ability to create a "profile" of the standard that formally defines how the standard will be implemented in a particular setting.

A profile is a set of information used to document system requirements or capabilities from an information exchange perspective. The documentation is expressed in terms of constraints, extensions, or other alterations to a referenced standard or base profile.

Profiles of the HL7 Version 3 standard must be derived from a Version 3 specification, as balloted by either HL7 or one of its international affiliates. An International Affiliate Member is a group of at least five individuals representing a country, group of countries, or geographic area, approved by the Board of Directors as a result of a petition espousing HL7’s mission and objectives in their national or geopolitical venue. The International Affiliate Agreement entered into jointly by the petitioning body and HL7 shall be the sole instrument governing the member relationship. As defined in the HL7 Policies and Procedures Manual, Affiliates will have decision-making authority.

HL7 Affiliates control Context of Use(previously called realms). The term Context will be used for the remainder of this document. Contexts do not have decision-making authority. Contexts simply represent a partition of the solution space. Affiliates choose how the solution space is to be partitioned by authorizing the creation of zero to many (0..*) Contexts.

The categories and use of profiles include:

Annotation profiles document; it is exactly the standard but with more information (these profiles will not be discussed further here).

An annotation profile is used to further explain the base document to educate prospective users and/or implementers. An annotation profile will usually enhance the descriptions of the elements of the base specification in order to relate them to a particular context.
Constraint profiles may contain unchanged and constrained elements.

A constraint profile reduces the optionality and uncertainty of the base specification (i.e., the HL7 V3 standard) in order to make the specification more exact and to approach "plug-and-play" interoperability.
Implementable profiles are further constrained than constraint profiles.

An implementable profile eliminates optionality and uncertainty of the base specification (i.e., the HL7 V3 standard) in order to make the specification exact and to approach "plug-and-play" interoperability.
Conformance profiles are used to articulate a system's conformance claim to a set of interactions (or optionally application roles).

A conformance profile can be either a constrained profile or an implementable profile.
Localization profiles may contain unchanged, constrained, or extended elements.

A localization profile is usually designed to meet the same objectives as a constraint profile, except that the demands of the intended implementation context mandate additional elements, as represented in the extensions. Normally, extensions will represent the minimum changes to the base specification (i.e., the HL7 V3 standard) needed to meet the requirements of an affiliate's domain.
Conflicting profiles may contain unchanged, constrained, or extended elements as well as elements that violate the HL7 refinement, constraint, and localization rules (these profiles will not be discussed further here).

By definition, a conflicting profile represents an implementation that cannot reliably interoperate with other implementations of the same base standard or base profile. The reason for creating such a profile is to document the incompatibilities.

This document specifies the rules and principles that govern the definition of profiles, but does not state how to represent these profiles. A formal representation of profiles is required in order to allow the creation of tooling to assist in development, documentation, comparison, and testing. Such representation is outside the scope of this standard.

A Conformance Statement is documentation of the degree to which a particular application conforms to the specification. Part of that document will be a conformance profile expressing the system's capabilities relevant to a particular standard.

This section of the standard addresses:

the "rules" and processes for refining the standard through constraint and extension, including which standard artifacts are subject to constraint or extension
the definition of constraint and localization profiles
the criteria for establishing a conformance statement
the principles guiding who may define extensions to the standards and under what circumstances

The strategy for development of Version 3 messages and related information structures, as discussed in the Version 3 Guide, is based upon the consistent application of constraints to a pair of base specifications – the HL7 Reference Information Model (RIM) and the HL7 Vocabulary Domains – and upon the extension of those specifications to create representations constrained to address a specific health care requirement. The processes described are precisely the processes that the HL7 Technical Committees followed in developing Version 3 standards. Thus, this section also serves as a reference work for the core standard.

Just as the standard is developed using a series of constraints and targeted extensions, the design of applications to implement these messages, the definition of conformance claims, and the definition of localization specifications, will all require further constraint and extension of the base standard.

The HL7 methodology uses the Reference Information Model (RIM) and the HL7-specified Vocabulary Domains as its starting point. It then establishes the rules for refining these base standards to arrive at the information structures that specify Message Types and equivalent structures in Version 3.

The following figure shows the refinement process specified in the methodology. Each red arrow in the diagram represents an application of the processes detailed in this section of the ballot. As diagrammed, the processes are used to derive one or more Domain Message Information Models (D-MIM) from the RIM. Each such model represents the set of concepts applicable to a particular health care domain of interest.

Refinement Process for defining messages based on the HL7 RIM

Within the domain, the Technical Committees use the same constraint process to derive one or more Refined Message Information Models (R-MIM) from the D-MIM for their domain.

Finally, the committee applies the same constraints, coupled with a traversal of the information model graph, to arrive at the specification for an Hierarchical Message Descriptions (HMD) and its resulting Message Types. In reality, as discussed in the Version 3 Guide, some of the Message Types derived from a single HMD may represent a further constraint on the common, or base, Message Type for that HMD. Although this is not shown in the diagram above, this constraint also follows the rules outlined in this section.

The fundamental rules of constraint, cloning and extension remain the same at each stage. This is true even though: the documentation of the constraints may vary stage to stage; the results may be documented in different forms; and the constraint process may be coupled with other processes, such as those for generating an HMD, and its resulting Message Type, from an R-MIM. Refer to section 1.1 of the HDF which replaces section 10.3.3 of the Message Development Framework (MDF) v3.3 document, published December 1999.

The Refinement Process Diagram also shows a recursive loop whereby the constraint process can be used to further refine an R-MIM to arrive at a new R-MIM to be used to define alternative messages. All of these processes will be used by implementers of the Version 3 messaging standards to define profiles of messages to be implemented. These profiles have a variety of anticipated uses. They may be:

Created by an HL7 International Affiliate organization to specify the localization of the Version 3 standards to be used in the affiliate’s region
Used by an application vendor to document the conformance of their application to the Version 3 specifications.
Created by a user to document the specific implementation of communications between the user’s systems.

Constraints are the central feature of the refinement process, as they reduce the generality of the specification and focus it on a particular requirement. The constraints that may be asserted against a model element , e.g., attribute or association, fall into six broad categories:

Appearance constraints determine whether a particular element must appear in models or messages derived from the base model, and/or whether the element is precluded from appearing therein.

Cardinality constraints define the number of repetitions that may occur for a given element.

Type constraints limit the structure or "type" of the element in question. These are constraints placed upon the data types for attributes and upon the use of Common Message Element Types (CMET) for associations.

Vocabulary constraints limit the set of concepts that can be taken as valid values in an instance of a coded attribute or field.

Other value constraints provide for the declaration of constraints stated as text and, optionally, as testable expressions to establish "business rules", and for the assertion of default or fixed values.

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.

Appearance constraints apply to attributes and associations. The presence of a model element in a constrained model depends upon the appearance constraints that are asserted or implied for that element in the source model, other constraints that are declared or implied in the constrained model, and upon the rules for "cloning" elements from a source model to a target model.

There are two forms of appearance constraints that may be set in a model: the declaration that an element is mandatory for HL7 messaging; and the assertion of a conformance indicator.

The mandatory inclusion flag indicates whether or not a particular element must be present in each instance of an HL7 message. In HL7 designs this constraint is applied primarily to structural attributes – those attributes whose coded values are needed to fully interpret the classes that they classify. Every attribute and association element in a model has an explicit or implicit mandatory inclusion flag. According to the HL7 Methodology standard, if an attribute is described as mandatory in a model, then all message elements that are derived from this element must contain a non-null value. In some explicitly allowed situations, a sending application may omit a mandatory attribute if the default value is not null. To avoid default ambiguities, only HL7 technical committees and International Affiliates are permitted to declare default values for RIM structural attributes.

Values
The constraint is formally a Boolean selection. If selection is true, the element is mandatory. If the selection is any other value, the element is not mandatory.

Invoking the constraint
If an element is declared to be Mandatory, then all elements that derive from it, in more deeply constrained models, must also be Mandatory.

Alternatively, a non-Mandatory element may be referenced for inclusion in a constrained model without necessarily becoming Mandatory in that model.

The conformance indicator constraint specifies how a model element must be handled by sending or receiving applications. Every attribute and association element in a model has an explicit or implicit conformance indicator constraint. The constraint has one of three values: Required, Not Permitted, or Not Required.

Values
Required - The element must appear in all instances of derived models and must be declared as "Required" in derived models. In messages, the element must be communicated if its minimum cardinality is one, although it may be communicated with a null value, unless it is also "mandatory". Note that any element declared to be "Mandatory" must also be "Required" and have a minimum cardinality of one. If the minimum cardinality is zero, and the element is "Required", conforming applications must demonstrate their ability to communicate this element when the application holds data for this element.

If a model element is required, then it may or may not appear in messages from a sending application. In general, if the data exists, the sending application is required to send it as a non-null value or a non-empty element. If the data does not exist, then the sending application is required to send an appropirate null value or null association instance . In all cases, if a required element is present in a message received by an application claiming conformance, then it shall be correctly processed by the receiving application. A receiving application shall not raise an error due to the absence of a required element with a cardinality of 0, although it may issue a warning that required information is missing.

Note that any element declared to be "Mandatory" must also be "Required" and have a minimum cardinality of one. If the minimum cardinality is zero, and the element is "Required", conforming applications must demonstrate their ability to communicate this element when the application holds data for this element, and conforming receiving applications must process the message fully and correctly.

Any element designated as required in a standard HL7 message definition shall also be required in all HL7 message profiles of that standard message.

Note that the allowance for the omission of a null instance for the association places a derived requirement on all ITSs to be able to represent a null association.

Not Permitted - This element shall not appear in instances of derived models or messages and must also be "Not permitted" in derived models.

Any element designated as ‘not permitted’ in a standard HL7 message definition shall also be ‘not permitted’ in all HL7 message profiles of that standard message.

Not Required - The appearance of this element in instances of derived models or messages is unconstrained. In instances of derived models or messages, an element may retain "Not Required" status, or it may be declared "Required" or "Not Permitted". "Not Required" is the default value for this constraint.

Note:If an application adheres to an implementation profile declaring that the application supports an attribute or association, the application must be able to send or receive that attribute or association if the application has a value for it.

Invoking the constraint
If an element is declared or inferred to be Required, then all elements that derive from it, in more deeply constrained models, must also be Required.

If an element is declared or inferred to be Not Permitted, then all elements that derive from it, in more deeply constrained models, must also be Not Permitted.

The "Not Permitted" value may also be expressed in a derived model by simply omitting that element from the model. Thus, an attribute or association that is not "Required" in a source model may be omitted from a derived model, thereby creating a de facto declaration of "Not Permitted."

Whenever an information model is derived by constraining another information model, it is permissible to "clone" the classes of the base model. This is true whether one is deriving a D-MIM from the RIM, an R-MIM from a D-MIM, or an R-MIM from another R-MIM.

Class cloning is the creation in the new model of one or more copies of a base class contained in the source model. The clone classes may have a new name to assure that they have unique names within the derived model.

Cloning is the only form of model "extension" permitted under the terms of this section. In order to qualify as a valid clone of a source class, the clone must obey the following rules:

The clone may contain only attributes that are also part of the source class
The clone may only participate in associations that are valid for the source class
The cardinality and mandatory constraints for elements in the clone class must be at least as rigid as the constraints for the equivalent elements in the source class
The vocabulary domains declared for any coded attributes in the clone must be identical to, or a subset of, the domain asserted in the source class, and if the coded attribute is "CNE" the cloned attribute must also be "CNE"
The clone need not include attributes or associations unless they are "Required" or "Mandatory" in the source model, regardless of their cardinality
The clone may not include attributes or associations that are listed as "Not Permitted" in the source model

Cardinality constraints apply only to attributes and associations. Every attribute or association element in a model has an explicit or implicit cardinality. The cardinality expresses the number of times an attribute or association may appear in a derived model or message. Since associations in HL7 models are directional, the cardinality constraint of an association is equal to its destination multiplicity, i.e. the minimum and maximum number of times instances of the target class may be referenced.

Cardinality constraints are constraints on the cardinality of a model element. Attributes may be constrained by more specific minimum and maximum multiplicity values and associations may be constrained by more specific source and destination multiplicities. The rules for applying such constraints are articulated in the following section.

Values
Cardinality is expressed as a minimum and a maximum value separated by ‘..’, e.g., ‘0..1’.

The minimum cardinality is expressed as an integer that is equal to or greater than zero. If the minimum cardinality is zero, the element need only appear in message instances when the sending application has data with which to value the element. Mandatory elements must have a minimum cardinality greater than zero.

The maximum cardinality is expressed either as a positive integer (greater than zero and greater than or equal to the minimum cardinality) or as unlimited using an asterisk ("*"). If the maximum cardinality is greater than one, the type for the associated message element must include one of the "collection types" – SET, LIST, or BAG.

Invoking the constraint
Both the minimum and maximum cardinality may be constrained in a way that narrows the range of possible occurrences. Thus, either end of the cardinality range may be set to a new value within the closed range defined by the minimum and maximum values in the source model's range. Two rules further constrain a cardinality change: (a) the minimum cardinality of the resulting range must be less than or equal to the maximum cardinality; and (b) the maximum cardinality must be greater than zero.

Mandatory	Conformance	Minimum Cardinality	Null O.K?	Comment
M	R	1	No	(default ok)
	R	0	Yes	If 'NI', just don't send it!
	R	1	Yes	Flavor shall be other 'NI'
	NP	n/a	No
	(not specified)	0	Yes	be present and valued in a message.

Type constraints apply to attributes and associations. Each of these model elements has a type explicitly or implicitly derived from information in the model specification. The type of a class or class clone is the name of the RIM class it is derived from. The RIM class can be determined either from the classCode or typeCode attribute of the class. The type of an attribute is the datatype declared for that attribute in the model. Since associations in HL7 models are directional, the type of an association is defined to be the type of its target element. If the target element is a Choice of classes, then the type of the association is Choice.

Type constraints are constraints on the type of a model element. Classes may be constrained by more specific classes or class clones, attributes may be constrained by more specific data types, and associations may be constrained by more specific target classes. If the target class of an association is a Common Message Element Types (CMETs), then the association can be constrained by a CMET that is a constrained version of the current CMET. The following sections address allowed datatype or CMET hierarchies that can be used for determining more specific type constraints.

Each attribute of the RIM is assigned a base data type that represents the values the attribute may assume. If model B is defined as a refinement of model A, and if model A specifies a data type for an attribute, then model B may keep the same data type for that attribute and possibly constrain its values and properties, or model B may make a type substitution to a more specialized data type. In either case the data type for model B may be further constrained by applying additional constraints expressed in some constraint language. Such constraints may be applied to the values of the data type or to its properties.

The Version 3 Data Type Specification defines all HL7 data types and their properties. It also defines a specialization hierarchy of data types with the understanding that any specialized data type in the hierarchy may be substituted for its more general parent data type in the refinement process. The following table represents the data type specialization hierarchy defined in the current version (Nov 2004) of the V3 Data Type Specification.

Level	Mnemonic	DataTypeName
1	ANY	DataValue (ANY)
2	BAG	Bag (BAG)
2	BL	Boolean (BL)
3	BN	BooleanNonNull (BN)
2	CD	Concept Descriptor (CD)
3	CE	Coded With Equivalents (CE)
4	CV	Coded Value (CV)
5	CO	Coded Ordinal (CO)
5	CS	Coded Simple Value (CS)
5	PQR	Physical Quantity Representation (PQR)
2	CLCY	Calendar Cycle (CLCY)
2	CR	Concept Role (CR)
2	HXIT	History Item (HXIT)
2	II	Instance Identifier (II)
2	LIST	Sequence (LIST)
3	GLIST	GeneratedSequence (GLIST)
3	LIST<ADXP>	List of Address Part (LIST<ADXP>)
4	AD	Postal Address (AD)
3	LIST<BN>	List of BooleanNonNull (LIST<BN>)
4	BIN	Binary Data (BIN)
5	ED	Encapsulated Data (ED)
6	ST	Character String (ST)
7	ADXP	Address Part (ADXP)
7	ENXP	Entity Name Part (ENXP)
7	SC	Character String with Code (SC)
7	UID	Unique Identifier String (UID)
8	OID	ISO Object Identifier (OID)
8	RUID	HL7 Reserved Identifier Scheme (RUID)
8	UUID	DCE Universal Unique Identifier (UUID)
3	LIST<ENXP>	List of Entity Name Part (LIST<ENXP>)
4	EN	Entity Name (EN)
5	ON	Organization Name (ON)
5	PN	Person Name (PN)
5	TN	Trivial Name (TN)
3	SLIST	SampledSequence (SLIST)
2	PPD	Parametric Probability Distribution (PPD)
3	PPD<PQ>	Parametric Probability Distributions over Physical Quantities (PPD<PQ>)
3	PPD<REAL>	Probability Distribution over Real Numbers (PPD<REAL>)
3	PPD<TS>	Probability Distribution over Time Points (PPD<TS>)
2	QTY	Abstract Type Quantity (QTY)
3	INT	Integer Number (INT)
3	MO	Monetary Amount (MO)
3	PQ	Physical Quantity (PQ)
3	REAL	Real Number (REAL)
3	RTO	Ratio (RTO)
3	TS	Point in Time (TS)
2	SET	Set (SET)
3	EIVL	Event-Related Periodic Interval of Time (EIVL)
3	IVL	Interval (IVL)
4	IVL<PQ>	Interval of Physical Quantity (IVL<PQ>)
4	IVL<TS>	Interval of Point in Time (IVL<TS>)
3	PIVL	Periodic Interval of Time (PIVL)
3	SET<CLCY>	Set of Calendar Cycle (SET<CLCY>)
4	CAL	Calendar (CAL)
3	SET<HXIT>	Set of History Item (SET<HXIT>)
4	HIST	History (HIST)
3	SET<TS>	Set of Point in Time (SET<TS>)
4	GTS	General Timing Specification (GTS)
3	SET<UVP>	Set of Uncertain Value - Prob (SET<UVP>)
4	NPPD	Non-Parametric Probability Distribution (NPPD)
2	TYPE	Data Type Name (TYPE)
2	URL	Universal Resource Locator (URL)
3	TEL	Telecommunication Address (TEL)
2	UVP	Uncertain Value - Probabilistic (UVP)

Some of the data types in this hierarchy are abstract types (e.g. ANY, QTY) and would normally not appear in a refinement intended for direct implementation. Others are constructor types (e.g. BAG, LIST, SET, RTO) and would normally not appear in a model without indication of the specific types T involved in the construction (e.g. LIST<PQ>, RTO<PQ,PQ>). Others (e.g. CS) have specific usage rules that may preclude their substitution for any other data type.

In addition, the Data Type Specification defines a number of promotion and demotion expressions for casting the values of one data type into the values of another data type. The following table lists the promotions and demotions defined by the current V3 Data Type Specification.

Child Type	Cast Effect	Parent Type	Condition
T	Promotes To	SET<T>	T any type
T	Promotes To	BAG<T>	T any type
T	Promotes To	LIST<T>	T any type
PQ	Promotes To	IVL<PQ>
TS	Promotes To	IVL<TS>
ST	Promotes To	TN
INT	Promotes To	REAL
T	Promotes To	IVL<T>	T any linearly ordered type
REAL	Promotes To	PQ
REAL	Promotes To	RTO
INT	Promotes To	REAL
LIST<IVL<TS>>	Demotes From	GTS
ST	Demotes From	TN
INT	Demotes From	REAL
QTY	Demotes From	IVL
ED	Demotes From	CD
REAL	Demotes From	RTO
PQ	Demotes From	RTO
REAL	Demotes From	PQ
T	Demotes From	IVL<T>
HXIT<T>	Demotes From	HIST<T>

In general, if X and Y are concrete data types, then X can be substituted for Y in the refinement process if there exists a promotion that casts values of X to values of Y, or if there exists a demotion from Y to X that does not lose any information. Typically, demotions lose information unless the parent type to be demoted already has constraints that would effectively reduce it to the child type intended to be substituted.

Data type substitution is intended to be transitive, so if X can be substituted for Y, and if Y can be substituted for Z, then X can be substituted for Z.

The above potential substitutions do not cover all cases. In particular, there are no promotions or demotions defined in the Data Type Specification for casting among SET, BAG, and LIST. The following table gives examples of potential substitutions that cannot be derived directly from the above specialization hierarchy, promotions and demotions, or the transitivity rule.

Data type in source model	Allowed constraints in derived model
General Timing Spec (GTS)	Set of time stamp (SET<TS>)
General Timing Spec (GTS)	Interval of time (IVL<TS>)
Bag of type T (BAG<T>)	List of type T (LIST<T>)
Bag of type T (BAG<T>)	Set of type T (SET<T>)

In addition to the normative datatypes, further datatype specialisations may be defined and used to express further constraints on the permitted content of HL7 attributes. The way that such specialisations are defined and used is discussed in the Data Types Specialization Constraints (§ 5.3 ) section below.

When an information model is converted to a serialized information structure such as a message, each association in the information model will be assigned a type based upon the class or clone to which the association connects. This is analogous to the assignment of data types to attributes of the information model.

Although the type for an association may be defined solely from the R-MIM that is the source for the HMD, it is also possible to constrain the association by assigning it a formally-defined type. These formally-defined types are the Common Message Element Types or CMETs. Refer to Common Message Element Types (CMETs) for more information.

Each CMET is based on a specific RIM class and a particular set of codes for the structural attributes (classCode, moodCode, and/or determinerCode) that characterize the class. The CMETs themselves are defined using a restriction hierarchy allowing CMETs to be constrained as part of the overall model refinement process.

CMET substitution
When a model is being refined, a CMET may be substituted for a class or a class clone, provided that (a) the CMET is based on either the same class as the class being substituted or on a sub-type of that class, and (b) the values for the structural codes for the CMET fall within the vocabulary domains specified for those attributes in the source model.
CMET constraint hierarchy
When a model or Message Type is constrained, the CMETs within that model may be further constrained along the defined restriction hierarchy for CMETs. The hierarchy is based on a general to specific refinement. The hierarchy begins with the general Universal CMET and ends with the Identified CMET.
A Universal CMET is the basis for the CMET restriction hierarchy. Each other level of constraint is a proper sub-set of "Universal". Thus "Universal" may be constrained to any of the other CMET types.
A Detailed CMET provides sufficient information to recognize and manage a new instance of an item by loosely coupled systems. The "Identified" CMET is a proper sub-set of "Detailed". Thus "Detailed" may be constrained to "Identified".
An Identified CMET provides only enough information to allow identification of the instances between tightly coupled systems. An "Identified" CMET may not be further constrained.

Beside this hierarchy defining the least to most constrained CMETs, an Abstract CMET may be used as a modeling tool, but must be substituted with a Universal, Detailed or Identified type in the final model. It can be used when only the class and structural codes for the CMET are known.

Other CMET types have been defined as restrictions on the "Universal" type as well. These other types may also be further constrained.

Vocabulary constraints limit the values that coded attributes or datatype properties may take on. In the following paragraphs the term attribute means either a class attribute or a datatype property. If an attribute is derived from datatype CD, or if the declared datatype can be constrained to CD, then it is a potential coded attribute and is subject to vocabulary constraints. Vocabulary constraints depend upon vocabulary terminology defined by the Vocabulary TC, and include terms such as vocabulary domain, code system and value-set.

In general, a potential coded attribute will be bound to a vocabulary domain at the time of first definition. A vocabulary domain is like a semantic type that abstractly identifies the type of concepts that will be included in the domain. It does not itself define specific coded concepts. At some point in the refinement process, an attribute may be bound to a sub-domain of a vocabulary domain or to a value-set. A value-set is a collection of specific codes from one or more code systems, where the codes within a value-set each have a distinct meaning defined by the code system. If an attribute is bound to a value-set, then further constraints on an attribute by sub-domains is not useful.

An attribute has a coding strength that determines whether or not a user of the HL7 v3 standard may communicate a coded value that is not of the defined domain or from the defined value-set. The HL7 RIM and datatype documents define coding strengths of Coded with Exceptions (CWE) and Coded, No Exceptions (CNE). CWE allows the end user to send a term from an arbitrary coding system in place of a term from the specified value-set, whereas CNE requires that the primary code in a message instance be from the specified value-set. Each coded attribute will carry one of these two coding strengths. By default, datatype properties are of coding strength CNE [Check this out!].

Some vocabulary domains may be associated with value-sets on a realm-specific basis. Such domains are said to be realm-specializable. A realm is a specific context of use under the control of HL7 or of an HL7 Affiliate. Some vocabulary domains are classified as universal , which means that a single universal value-set is assigned to the domain at domain definition. Some domains are defined as non-realm-specializable which means that only one value-set can be bound to that domain. A realm is not then permitted to define additional or alternative value-set bindings for that domain. A non-realm-specializable domain will have a universal value-set binding defined by an HL7 or Affiliate technical committee somewhere in the refinement process. Non-balloted user-defined templates and profiles will not define such bindings. All vocabulary domains associated with RIM structural attributes are universal.

During the refinement process, a child model may be defined with certain vocabulary constraints enforced on a parent model. Such vocabulary constraints may be applied to a vocabulary domain, a value-set, or a coding strength, with some limitations.

A vocabulary domain may be constrained by defining a sub-domain that includes only some of the semantic concepts defined by the parent domain. As for the domain, a sub-domain is a semantic type that does not define specific coded concepts.

Invoking the constraint
If the parent model coded attribute is already bound to a value-set, then the child model may not bind the attribute to a vocabulary domain. If the parent model coded attribute is bound to a vocabulary domain, but is not yet bound to a value set, then the designer of the child model has the following options:

Leave the child vocabulary domain the same as the parent model vocabulary domain,
Constrain the child vocabulary domain to a sub-domain that represents a narrower concept than the parent vocabulary domain. If the parent domain is non-realm-specializable, then the child domain will also be non-realm-specializable.
Constrain the vocabulary domain to a specific value-set subject to the following rules:
- If the parent vocabulary domain is non-realm-specializable, then the bound value-set becomes the unique value-set bound to that domain. Such bindings may only be defined by technical committees and are subject to HL7 ballot.
- A realm-specializable domain in the parent model can only be constrained to a value-set if the child model is itself bound to a single realm and that realm has bound the parent vocabulary domain to a value-set.
- The value-set bound to a child whose parent is a domain must either be the same as the value-set tied to the parent based on realm, or a subset thereof.

A value-set may be constrained by defining a new value set that is a narrower collection than the parent value set. A value-set may also be constrained by using a formal constraint language as specified by the emerging HL7 constraint language project ((Co-occurance Constraints (§ 2.6.3 ))). The Vocabulary TC defines the process for defining new value-sets. A new value-set may be derived directly as a collection of coded concepts from a code system, or by a collection of codes from one or more existing value sets, or by a combination of these methods.

Invoking the constraint
If the parent model coded attribute is bound to a value-set, then the designer of the child model may leave the child value-set the same as the parent value-set, or may use the new value-set definition process, or the constraint process referenced in Section 2.6.3, to produce a new value-set that is strictly a subset of the parent value-set.

The coding strength constraint is always expressed as one of two values, CWE or CNE. For CWE coding strength, an exception value may be sent if the specified domain/value-set does not include the concept being encoded. Depending on the underlying datatype, additional codes (not substitutions) may be sent to supplement the standard code, even for CNE coding strength.

Invoking the constraint
If the coding strength of an attribute in the parent model is CNE, then the coding strength of the attribute in the child must also be CNE. If the coding strength of the parent is CWE, then the child may have a coding strength of CWE or CNE.

In some circumstances, vocabulary domains and/or value-sets may be asserted as free-hand constraints [NEED DEFINITION/EXAMPLE] rather than as a direct binding of a single domain or value-set to the attribute. If so, then each vocabulary domain and/or value-set that is asserted by the constraint must follow the restrictions for invoking the constraint identified in Sections 2.5.1 or 2.5.2. [Could this Freehand constraints section be dropped in favor of references to constraint languages, e.g. in Section 2.6.3?].

When validating an attribute instance, the value-set to be bound against is determined as follows:

The allowed value-set is the intersection of the value-sets of the balloted static model for the interaction transmitted as well as any profiles or templates that apply to the scope of the attribute being validated.
If a balloted static model or template/profile binds to a domain, then the value-set is determined by the realm that is effective at that point in the instance (either as declared within the instance, or as inferred from the jurisdiction of the sending system).

For attributes bound to realm-specializable vocabulary domains, designers are encouraged to avoid constraining the attribute to a value-set as long as possible to encourage the general application/use of the artifacts so constrained.

This group is made up of constraints that limit the value for an attribute or association in ways not covered above. These are the assertion of a default value, the declaration that an attribute is Fixed, and the textual expression of a business rule constraint.

A default value may be declared for an attribute of an HL7 class. The default is a single value that the receiver shall use when it receives a message instance that does not contain the attribute. If the default is unspecified, the 'default default' is the simple form of null (NI). The meaning of a default value is that in the absence of any explicit value for an attribute in a message instance, the default value is assumed. A Default value has no impact on what explicit values may be assigned to the attribute in a message instance.

The value asserted may be any value that is valid for the data type and, if applicable, for the vocabulary domain of that attribute. Once a default is assigned to an attribute, a different default cannot be assigned for the same attribute in a derived model. For example, if a default is assigned in a D-MIM, a different default shall not be assigned in a derived D-MIM, R-MIM or Message Type.

Invoking the constraint
To avoid the ambiguity of receivers having to choose from among multiple defaults, the assertion of default values may only be done by an HL7 Technical Committee as it prepares a ballot or by an HL7 International Affiliate that is preparing a region-specific profile. For example, a declaration of Act.classCode DEFAULT OBS means that any Act class code can be inserted into a message instance, including one not below OBS in the class code hierarchy, but that the absence of the attribute message element implies that the assumed value is OBS.

An attribute of an HL7 class may be declared as Fixed, and optionally, a value or a constraint may be specified for a Fixed attribute. The meaning of Fixed is that the attribute value, once set at model message instance creation, remains unchanged for the life of the model instance. Unlike a default value, there are no assumptions about default meaning when the attribute is missing.

A fixed value, if specified, may be any value that is valid for the data type and, if applicable, for the vocabulary domain of that attribute.

Invoking the constraint
In most situations there will be no difference between a textual constraint (Co-occurance Constraints (§ 2.6.3 )) that constrains an attribute to a single value and a Fixed declaration for that attribute that specifies a single fixed value. In either case, the value is always the same and it cannot be changed to a different value in the refinement process. However, when Fixed is applied to an attribute along with a constraint that allows multiple values, e.g. Act.classCode FIXED <= Act, the meaning is that the creator of a refinement may choose any value out of this set that satisfies the constraint, but the value is then fixed both for the refined model and any subsequent refinement.

Statements of constraints may be made in a textual form that expresses the business rule being applied. For example, if attribute A has the value X, then attribute B must have the value Y or Z. Translation to other languages may be provided. A formal constraint language may be adopted by HL7 in a future version of this standard based on the HL7 Informative DRAFT Document "HL7 Version 3 Constraints Applied in Designs and Profiles"

Invoking the constraint
If an attribute or association has no textual constraint, a new constraint may be asserted as the model is refined. If the source model includes a textual constraint, this constraint may be altered to a form that is more restrictive than the previous entry.

The final group is made up of 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. Note to reviewers: The list of annotations below is taken directly from the Model Interchange Format. These will most likely change as the MIF is evolved.

Values

Annotation Type Description

Definition An explanation of the meaning of the element.

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

Usage Notes Advice to designers on how to make use of an element and/or how *not* to make use of an element.

Rationale An explanation of why the element is necessary or potentially useful within this Context.

Requirements Documents the requirements which drove the specification of the artifact. May include references to other standards or literature describing the appropriate data elements and constraints.

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

Walkthrough An overview of the primary and most important contents of the element. Used to provide broad understanding of the content without detailed review. It may contain formatting markup.

Open Issues Notes to designers, balloters and implementers about outstanding concerns that remain to be resolved.

Other Annotation Additional content related to the element that may include such as items as the context, realm, or business name associated with the element.

Appendix Documentation that supports or relates to the current element.

App Info Supporting programmatic information related to the model element and can include mappings, constraints, a static example in a particular ITS and change requests.

Annotation Type	Description
Definition	An explanation of the meaning of the element.
Description	An explanation of the associated element. This may contain formatting markup.
Usage Notes	Advice to designers on how to make use of an element and/or how not to make use of an element.
Rationale	An explanation of why the element is necessary or potentially useful within this Context.
Requirements	Documents the requirements which drove the specification of the artifact. May include references to other standards or literature describing the appropriate data elements and constraints.
Design Comments	Internal development notes about why particular design decisions were made, outstanding issues and remaining work. They may contain formatting markup. Not intended for external publication.
Walkthrough	An overview of the primary and most important contents of the element. Used to provide broad understanding of the content without detailed review. It may contain formatting markup.
Open Issues	Notes to designers, balloters and implementers about outstanding concerns that remain to be resolved.
Other Annotation	Additional content related to the element that may include such as items as the context, realm, or business name associated with the element.
Appendix	Documentation that supports or relates to the current element.
App Info	Supporting programmatic information related to the model element and can include mappings, constraints, a static example in a particular ITS and change requests.

Invoking the constraint
These annotations are placed in the models and Message Types utilizing the available tools.

Note to TC: Not all these annotations are presently available in the tools.

Section 1 and Section 2 of this Chapter have discussed the rules whereby information models (RIM, D-MIM and R-MIM) and message designs in HMDs may be successively constrained to define more specific designs. This process of refinement from RIM to D-MIM to R-MIM to HMD to Message Type is the primary development process followed by the HL7 Technical Committees in defining the artifacts that are balloted as HL7 Version 3 specifications.

Once an HL7 specification has been balloted and formally published, it may be further constrained for a variety of purposes, including:

region-specific localizations by an HL7 International Affiliate
for use in communities of interest (for example, a set of collaborating health care institutions, a community of vendors or an external standards organization)
for a specific project
to define a vendor's capability or a consumer's requirements
to define content templates to be used when communicating HL7 messages

The constraints derived from the purposes listed above, and for all other purposes are documented using a constraint profile.

A constraint profile is an expression of local constraints applied to an HL7 standard RMIM, HMD, or Message Type or to another constraint profile. Every instance message that is valid for the Message Type defined by the profile must also be valid for the base Message Type.

These profile types are described below. Each uses the constraint mechanisms described previously, but with varying limitations on which constraints they may invoke.

The constraint profile design process starts with the lowest-level R-MIM or the HMD that defines the profile's base Message Type. The process then uses the constraint refinement rules detailed previously to define a new Message Type.

A constraint profile is to be documented as a Message Type derived from an HMD. A simple constraint profile may be derived from the same HMD from which the base Message Type is derived. More complex constraint profiles will be based on a new R-MIM. In that case, the profile will be documented as a new Message Type derived from a new HMD which, in turn, is derived from the refined R-MIM.

The previous discussion of Cloning classes (§ 2.1.3 ) introduced the notion of creating additional constrained copies (clones) of the classes that are present in the RIM, a D-MIM or an R-MIM.

Cloning may occur wherever there is an association with maximum cardinality greater than one. This includes both recursive associations, such as an act relationship "component" association and other repeats such as SET<Participation>.

Instance validation
To be a conformant message instance, a message instance based on the refinement must be valid according to the original (base) specification from which the refinement was derived, even if the use of cloning requires that a translation or transformation is necessary. In order for an application to be conformant, it must only send conformant message instances.

Any message instance that can be validated against a more constrained static model should still validate against the base model. In an XML ITS, ensuring that the instance can be validated against the base model involves transforming the XML element tag names to be those of the parent model – the semantics do not change, just the labels.

Documentation
The refined R-MIM should be documented with a new R-MIM diagram that explicitly displays the new clones derived from the R-MIM clones of the base diagram, and a new HMD from which one or more new, restrictive, Message Types can be derived.

A constraint profile can be used to define the capability of a specific application – either one that is sold by a vendor, or one that is sought by a potential buyer. This profile is defined against a balloted HL7 message type, and involves only three of the constraint discussed previously.

The primary constraint asserted within this profile is the conformance indicator. For a vendor statement of application capability, the profile shall have the conformance indicator values as either "Required" or "Not Permitted" for every element in the message. User-defined profiles may leave some elements declared as "Not Required."

The data type constraint may be asserted in this profile. When asserted by a vendor, it indicates which data types the application can support for each attribute. When asserted by a user, it indicates the minimum level of data type support required.

This profile may not declare a CMET type for an association unless that association is represented by a CMET in the base message. The assertion of CMET constraints for associations is analogous to the data type constraints. A vendor assertion indicates the form of CMETs the application supports, while a buyer assertion expresses the minimum desired capability for the application.

Declaring the implementation of an application role(s) is the basis for claiming conformance to the HL7 V3 standard. Despite the fact that the application roles are documented in the normative domain specifications, the HL7 Technical Steering Committee has declared that applications roles shall be informative, not normative, in this release of Version 3. The reason for this declaration is that HL7 wishes to see a number of Version 3 implementations before it specifies the content and granularity of application roles. Because application roles are informative in this release, the focus of declaring conformance rests with the declaration of the interaction(s) supported by an implementation. Optionally application roles may be declared.

The parties that need to communicate about conformance are the sponsors and users. The sponsor of an information system is the vendor, in-house developer, or provider of public domain software. The user of a health care information system is the organization that buys, leases or employs an information system for which the software was developed.

With respect to messaging, the specifications created by the HL7 Technical Committees are informatively bundled by application roles. These application roles (i.e., the set of interactions) can be the basis for users stating requirements and sponsors declaring implementation capabilities. The common mechanism both parties may use is the profile. Users can create a profile to articulate their proposed system requirements. Sponsors can create a profile to describe its systems’ implementation of application roles (i.e., the set of interactions). With both parties using the same profile mechanism, the profile can become the common ‘language’ used between parties to articulate requirements, articulate the capabilities of an implementation, and measure conformance. The profile used by sponsors to describe their capabilities for conformance purposes is called a conformance profile. The conformance profile, used in conjunction with the appropriate HL7 application role specifications, may be used as conformance criteria.

The definition of formal conformance specification rules and the requirement for using a formal V3 conformance registry process will appear in the same release declaring application roles normative.

When certification methods are developed for V3, conformance tests will be used to determine whether a sponsor’s system has correctly implemented the specification. These will not be available until application roles are declared normative.

A conformance statement is a document that shall contain a conformance profile and may contain declarative statements asserting a conformance claim. The conformance profile may be either a constraint profile or an implementable profile. A declarative statement asserting a conformance claim may be made against a third-party developed profile (e.g., vendor, provider, Affiliate), thus linking the conformance profile to the third-party’s profile. If an explicit declarative conformance claim does not exist in the conformance statement, then the sponsor is making an implicit conformance claim against the HL7 V3 specification included in the conformance profile.

For this release of V3, the author of the conformance profile and conformance statement determines the formal structure of the document. In future releases, a formal structure for a conformance statement and a conformance profile will be defined.

A conformance profile shall indicate the set of interactions (and optionally the set of informative application roles) that the system supports. When HL7 declares application roles normative, a conformance profile shall indicate the set of application roles that the system supports.

The conformance profile implies a commitment to fulfill the responsibilities of the set of interactions specified, faithfully implement the artifacts that constitute the interactions, and any further constraints or extensions. Specifically the conformance profile shall include:

the interactions that the system will send based upon identified trigger events;
the interactions that the system is capable of receiving;
for each interaction, the subset of attributes and associations the system supports;
for each domain, the supporting value set the system supports;
data type restrictions and flavors the system supports;
any extensions - conformant and conflicting – the system supports;

The conformance profile shall identify for each message type:

Whether the application can send or receive the message element;
Which of the media types the application supports if the message element is of data type multimedia-enabled free text;
Which level of attribution is supported for each of the CMETs in the message and for the base Message Types. Refer to section Common Message Element Types (CMETs) (&2.3.2) Common Message Element Types (CMETs) (§ 2.4.2 )for details.
A conformance indicator value of either “Required” or “Not Permitted” for every element in the message; and
The data types the application supports for each attribute.

The conformance profile shall identify:

a description of the user-based trigger events (environment trigger events?) and state-based trigger events associated with the interactions and how the events are bound to the system;
the transport mechanism(s) supported;
a storyboard or use-case;
the realm(s) in which the application is intended to be used; and
the ITS(s) supported. The conditions under which a particular ITS is used if multiple ITSs are supported.

A sponsor of a system shall create a Statement of Vocabulary Conformance. The format and structure of the Statement of Vocabulary Conformance shall be determined by the author of the document. Future releases will provide a formal format and structure for the Statement of Vocabulary Conformance. The Statement of Vocabulary Conformance shall declare the vocabulary domain extensions supported by the system, using the following principles suggested by the Vocabulary Technical Committee. .

The organization shall use standard codes if they exist in the version of the RIM corresponding to the standard. If the concept to be sent exists in the domain specification for the field, a code from the domain shall be sent. If the attribute has a coding strenght of CWE (Coding Strength (§ 2.5.3 )) and the domain does not contain the concept to be encoded, a local code May be sent. A local code shall not be sent as a replacement for a standard code. An equivalent local code May be sent in addition to the standard code. Usage of local codes will be specified in the Statement of Vocabulary Conformance

Only domains of the Coded Simple (CS) data type are being balloted for inclusion in the standard. By definition, the allowable values are limited to what is included in the standard. Changes to a CS value set require another ballot of the standard. Constraints that refer to CS value sets are bound to the vocabulary release that was in effect when the artifact in which the constraint is contained was ballot approved. Regarding domains using the Coded with Equivalent (CE) data type where the coding strength is CWE, they will grow/change more frequently than ballots via a harmonization process by the Vocabulary Technical Committee. After each harmonization, these domains will be published with a version number. An organization will document the vocabulary version in their statement of vocabulary conformance.
The organization will not use a code from a standard set and give it a new meaning.
Where the organization uses a local code, it will use one that is consistent with the semantic type of the standard codes and consistent with the semantic type or types covered by the Vocabulary Domain of the attribute carrying the coded value assigned to the same data field. In other words, if the field is "Eye Color" with values of "blue," "hazel", and "brown, it would be inappropriate to send a code meaning "Arm." Note: A violation of this principle can only be detected by human review.
Where the organization finds the necessity to use local codes, it shall submit them to HL7 for review and addition. HL7 will share these proposed concept additions with HL7 vocabulary source providers. Usage of local codes will be specified in the Statement of Vocabulary Conformance.
An organization shouldl promptly begin using new codes when it upgrades its systems.
When an organization has submitted a local code requesting that it be added to the set of standard codes, and the responsible standards organization denies the creation of a new standard code, and the denial provides an alternative method to meet the need, the organization should promptly begin using the alternative method when it upgrades its systems.
An organization will identify the coding system in any coded data type other than coded simple (CS) using the registered OID (Object Identifier) for that coding system as published in the HL7 OID registry. If an OID does not exist for a coding system defining codes that an organization wishes to use in a message, the organization will develop an OID as needed. It is expected that the organization will undertake to have the OID for the coding system registered in the HL7 OID registry.
An organization will populate a coded field in a message from the subset of codes from the defined vocabulary domain defined by the Value Set indicated by the Context for the message, as registered and published as part of HL7 Vocabulary. There is a Universal Context that does not restrict the codes in a Vocabulary Domain; other Contexts may restrict the set of permissible codes used in a particular Realm (eg US, Japan, Australia, UK, etc) or a particular using community (eg Public Health, Veterinary Medicine, etc.).
If an appropriate Context does not exist to restrict the codes for a coded attribute in the way that an organization wishes them to be restricted, the organization will submit a new Context for registration with HL7 so that the appropriate restrictions are available to all.

The Statement of Vocabulary Conformance may be used to objectively measure whether a system adheres to the vocabulary domain extensions declared. It will also provide information on areas where local codes or other extensions to the published HL7 domains and value sets are being supported.

Localization is the process of defining new HL7 Version 3 Message Types by a process that includes both the constraint process listed previously, and an extension process that adds new concepts to the base, balloted Message Type. This section covers the rules that govern localization of the Version 3 Standards by conformant applications.

The HL7 Affiliate Organizations, working through the International Committee, studied localization and produced a report entitled "Localizing the HL7 Version 3 Standard." This report, which has been reviewed and adopted by the HL7 Board of Directors for use by the affiliate organizations, was used as the starting point for this section.

HL7 anticipates that localization will be undertaken by a variety of constituents, including the HL7 International Affiliates, system purchasers, system vendors, and end users. HL7 International Affiliate organizations are permitted to use several forms of localization that are precluded to the other constituent groups because they have formal, consensus-based approval processes within their membership. In the following paragraphs, when localization capabilities are expressly permitted for use by the HL7 International Affiliates, they are implicitly prohibited from use by the other constituencies that claim conformance to HL7.

While constituencies other than HL7 International Affiliates are prohibited from formal localization, it is recognized that these other constituencies may encounter functional requirements that can only be supported by the extension processes of localization. These requirements may reflect:

Extensions of general utility within healthcare messaging that should be brought forward to HL7 for consideration within the next version of the standard
Extensions that are meaningful and relevant only to the specific implementation

Extensions with general utility should be proposed to HL7, or an HL7 International Affiliate, for inclusion in the next version of the standard. For example, if during the development of a laboratory interface it was determined that some tests require information that is not contained within the defined messages (such as the last menstrual period relative to a hormone assay), then it would be reasonable to develop an extension to support this requirement. As a generally useful concept, this extension should be proposed for consideration. Even if the proposal is not accepted, consideration of the concept(s) may be a path for continued evolution of the standard.

Implementation-specific extensions that are not relevant to the general healthcare community might not benefit the standard as a proposal. For example, extensions may be necessary if an interface message needed to include display-positioning terms so that the receiving application can emulate a prior display layout. Such display-positioning terms may not be relevant beyond the specific implementation. Implementation-specific extensions shall not be subject to submittal to an HL7 Committee for possible standardization.

Informal extensions can be employed to address implementation-specific requirements as long as such extensions can be isolated within the message. This isolation provides a means for a receiving system to ignore all non-standard content. "Isolation" of informal extensions is accomplished on an Implementation Technology Specific (ITS) basis and is described in the relevant ITS.

The informal extension cannot alter the intent of the standard message. For example, a local extension in an order message cannot be used to indicate that the order should not be performed.
The informal extensions are meaningless unless there exists a site-specific agreement to utilize that extension. Thus, the sender cannot assume that the receiver will understand or act upon informal extensions. Receiver actions and responsibilities relative to local extensions must be defined on a site-specific basis.
While registration of informal extensions may not seem necessary, it is encouraged as a means to share operational solutions even when those solutions are not formally introduced into the standard.
The receiver cannot require an informal extension and claim conformance with the V3 standard.
The receiver must ignore informal extensions it does not support. This may mean the receiver will need to pre-process a message to remove non-supported extensions before performing message validation.

When a committee accepts a proposal to introduce an informal extension into the standard, that extension is subject to the ballot and publication process before it is included in the standard. Implementers may choose to incorporate these extensions into their interface development prior to publication within the standard. This approach should be taken with caution as these extensions may undergo some changes during the ballot resolution process. If the resulting standard meets the local requirements of the implementor, the implementor shall use the standard in lieu of the informal extension. However if the standard does not meet the local requirements of the implementor, the implementor May continue to use the informal extension.

If the committee does not have the resources and/or does not want to take on the work associated with the proposal, the proposal may be presented to the appropriate affiliate committee or may stay an informal extension.

If the outcome of the HL7 committee process does not result in a standard that meets the local requirements of the submitter or the proposed informal extension, the submitter may choose to re-define the general utility informal extension as an implementation-specific information extension.

Once a registration process is in place, any informal extension encountered in a message that has not been registered is, by definition, a non-conformant extension. Implementers may choose to review non-conformant extensions as possible solutions to non-standard requirements. While using non-conformant extensions is not part of the standard, they may provide a consistent means to address non-standard requirements.

The rules appearing in this section pertaining to localization presuppose the existence of several formal approval processes.

Registration

Registration is intended to assure that all of the HL7 constituents are aware of localizations that are being developed, and have access to the definitions thereof. In this release, HL7 does not support a formal registration process. Future releases of HL7 V3 will require, and HL7 will support, a formal registration process. The registration process shall:

be facilitated via an on-line resource
result in the automatic notification of the registration
require the provision of data to support subsequent harmonization
include an obligation to consult on the most closely relevant listserver prior to proceeding
be subject to review by the relevant Technical Committee for potential subsequent submission in an HL7 ballot (the status of a registration entry shall accordingly be marked as pending decision, approved or rejected).

Affiliate Ballot
Each HL7 International Affiliate maintains a consensus voting procedure for approval of HL7 specifications. These processes are specified by the Affiliates in their own bylaws (or equivalent documents). Several of the localization items listed below are subject to an affiliate consensus ballot.

Harmonization
Harmonization is a set of processes adopted by the Methodology & Modeling Technical Committee and the Vocabulary Technical Committee to provide for the review and adoption of the HL7 Vocabulary Domains and changes to the HL7 Reference Information Model.

Context
Some localization practices permitted for affiliates may negatively affect (break) interoperability between Contexts and other Affiliates. For example, specifying different default values for different Contexts may cause issues when communicating between Contexts.

One message can contain content from multiple Contexts. For example, HL7 Canada might have Contexts for different regions in Canada. A message containing Electronic Health Record (EHR) extracts from different regions could well make use of the different Contexts.

A sending application communicates, as part of a conformance statement, what Contexts they support for each interaction. If they receive something from a Context they don't support, they can reject it.

The presentation of concepts in this section is organized according to the HL7 Version 3 design artifacts being localized. These are organized as: Information models, including the RIM and R-MIMs; type structures, including data types, Message Types and CMETs; vocabulary; and interaction design elements, including interactions, trigger events and application roles.

Localization may not add new classes, associations or attributes to the RIM. This may only be done through the established RIM harmonization process.

The HL7 International Affiliates may undertake localization of R-MIMs by the addition of RIM-derived classes, attributes or associations between ballot cycles. Such localization shall be subject to registration and international ballot. This form of localization is restricted to the affiliates.

It shall never be possible to change or create new data types, except through the formal HL7 ballot processes. However it is possible to define data type specializations that can be referenced in profiles and instances. The way that this is done is described in this section.

HL7 Version 3 data type specializations are localized constraints that restrict data types, resulting in data types which are applicable to a specific region, project or other localization. This section documents the requirements for these constraints, and discusses methods to assert their use in models and instances.

HL7v3 data type specialisations represent "re-usable" constraints, which is something v2 did not support. At the same time, HL7v3 data types have behaviours which makes the drill-down constraint process unmanagable. With many v3 data types you can drill down to infinite depth rather than being limited to "sub-components" as you are with HL7v2.

Data type Specializations are localized constraints that can be used to restrict HL7 data type definitions in specific HL7 Contexts. For example, AD.UK.BSI7766 might be a constrained subset (specialization) of the HL7 address data type (AD) that applies the rules defined in BSI standard 7766 to localize addresses that are to be used within the UK. Such a specialization may be defined within a package balloted by the HL7UK affiliate, and referenced by specifications approved by that affiliate, and message profiles produced for use in the UK.

Data type Specializations may be flagged as ‘abstract’ and where this is the case they cannot be used in message instances. Abstract data type specializations refine an HL7 data type for use within a specific application and/or context. Abstract data type specializations are always based on one normative HL7 data type. An abstract data type specialization can be used to group a set of choices based on different data types, providing that all of the choices are valid refinements of the grouping specialization ( The grouping specialization can be a refinement of the general purpose HL7 ANY data type that identifies the full set of HL7 data types). While abstract data type specializations may not be referenced in the instances, they may be included in model specifications to constraint the type of a RIM attribute.

A concrete data type specialization identifies a model that can be used to validate instance of a localized model. A concrete data type is a refinement of a single HL7 data type. A concrete data type may be, but need not be, a refinement of an abstract data type specialization. Where a concrete data type specialization is a refinement of an abstract data type specialization it identifies which member of the set of choices permitted by the abstract data type has been/should be used to validate the component. Only concrete data types can be referenced in the specializations attribute of an instance.

It must be possible to express in a message instance that a named data type specialization MAY be used by the receiver to validate the contents of the RM attribute.

To ensure international interoperability the names of specializations which are not defined in the abstract data types specification should not replace the base data type for a RIM attribute where this is communicated in an instance, but may be sent in addition to this. The base data type is communicated in a way that is determined by the ITS , and for the XML ITS , this is achieved using the XML attribute “xsi:type”.
Example: xsi:type=”AD”; DatatypeFlavor=”AD.UK.BSI7766”;
It must be possible to package sets of related data type specializations.

Data type specializations can be defined at different levels, such as:
- By HL7 (within the Abstract Data Type Specification)
- National/regional HL7 Organizations
- Specific national/regional projects.
Packages which contain data type specializations should be able to clearly identify the relationship between data type specializations they define and those defined by a higher-level body.

Example: In UK, addresses used in the healthcare context could be defined using a specialization identified as AD.UK.BSI7766 while in the Australian addresses could be defined as AS4819address, both being specializations of the HL7 defined data type AD
It must be possible to maintain packages of data type specializations for each HL7 context.

Where two or more contexts define data type specializations with matching sets of constraints then the creation of a standard data type specialization within the abstract data types specification, a universal context package, or an affiliate balloted package should be considered.

Example: If CS.UK.UserTypes and CS.FI.UserTypes were identical the appropriate HL7 committee would create a UserTypes specialization and, after a suitable period for the retirement of the context-specific types, should deprecate the use of the context-specific specializations.
It must be possible to define more than one data type specialization for each underlying HL7 data type.

Example: See multiple specializations of the AD data type illustrated above.
A datatype specialization may be defined as a choice of other specializations and/or base data types. All options within the choice must be valid refinements of the parent data type of the specialization.

Example: ShortString and ResultCodes could be defined as speciaizations of ST and CV respectively, with LabResult (a specialization of ANY) being defined as a choice of ShortString, ResultCodes, and INT.
Where a static model allows more than one data type specialization to be used for a particular RIM attribute, the data type specialization against which the value could be validated by the receiver may be expressed in the instance. This is done by supplying the data type specialization name in the “typeSpecialization” property of the datatype ANY.
More than one data type specialization may be asserted in the instance for each RIM attribute. The ”typeSpecialization” property can take a list of values, which must be the names of concrete data type specializations.
Data type specializations may be defined as restrictions of basic types, generic types, or fully expanded generic types. not be independently parameterized and all generic types shall be fully expanded in the specialization definition.

Example: If an interval needs to be constrained through a specialization, it may be fully specified as IVL_TSComplete, rather than a specialization of the generic type IVL being defined. Alternatively a specialization IVLcomplete may be defined that requires a high and low component, and the type IVLcomplete<TS> be used in the model specification.
It must be possible to use a named data type specialization as specified in the static model or the instance with a standard validation tool to validate conformance. This is a design principle for this specification, and a criteria that should be followed when evaluating changes for future versions of the document, as well as by authors of data type specialization specifications.. The requirement applies to instance validation in any approved ITS at the time that a specification is produced.
The following table contains the information items to be included in a data type specialization specification. It does not mandate the format of such a specification, which is to be determined elsewhere, and in the abense of other direction from HL7 is at the discretion of the pulishers of such specifications.

name/title	A name expressed as a plain text human readable title.	M
Formal name	The formal name must be unique within the context of the package that contains the definition of the data type specialization. It is the responsibility of the author of the package to ensure that unique formal names are assigned to data type specializations defined within the package. Tooling support for this may be available.	M
Description	A textual description of the content and usage of this data type specialization.	M
Specification	Tabular specification covering each sub-element as a row with cardinality, value refinements etc.	M
Schema	Schema fragment for this specialization. NOTE: In practice this is required if the data type specialization is to be used with the XML ITS because the data types schemas published by HL7 alongside the XML ITS are not generated directly from the abstract data types specification.	O
Example	An instance example using the XML ITS conforming to the schema fragment.	M
Rationale	Description of the reason for specifying this as a separate data type specialization. For example, to conform to UK NHS Data Dictionary.	O
HL7 derivation	The base balloted HL7 data type with which all instances of this specialization conform.	M
Specialization derivation	Other data type specializations of which this is known to be a valid refinement. For example, a coded specialization that requires a single translation may be a refinement of one that allows one or two translations.	O
Other derivation	References to other sources or specifications that this (e.g. in the UK the relevant NHS Data Standard).	O
Substitutability	Specific indication of other data type specializations that can be used in substitution for this one.	O
Version	A version number. It is assumed that versioning will apply to a package of data type specializations rather than individually. Thus the formal name will not change but the version number and unique ID will change. Propagation to data type schemas and message specifications will be based on a given version of a package of data type specializations.	M
History	A log of changes to this data type. Until and unless changes are made this will just be its creation date.	M
Is abstract?	A flag indicating whether the specialization may not be referenced within an instance	M

Issues
Should the use of Generic types in specializations be supported in the same way as regular types, so that specializations of the generics can be defined and used in combination with specializations of the base types. This specification assumes so, but it was not clear what the intention of the draft for comment document was in this area.

Using the processes detailed in section Refinement process (§ 1.2 ) and Appearance constraints and cloning (§ 2.1 ) processes, it shall be possible to identify a new message type based on an existing R-MIM or HMD between ballot cycles. Each such identification shall be subject to Ballot and Registration.

Using the processes detailed in section Refinement process (§ 1.2 ), it shall be possible to identify a new message type based on an existing R-MIM or HMD between ballot cycles. Each such identification shall be subject to Registration.

An HL7 International Affiliate may substitute the standard message constraints to accommodate affiliate-specific needs.

Note: By substituting the standard message constraints, the affiliate introduces compatibility issues when communicating outside their affiliate.

Substitution
An HL7 International Affiliate may substitute CMETS developed to meet realm-specific requirements provided that these changes are derived from CMET being substituted using the constraint and extension rules described in this document for RMIMs in general. Such substitution is subject to Registration under the authority of HL7 or the HL7 International Affiliate that owns the realm. A CMET which is substituted will apply in every circumstance where the original CMET appears in a universal model for that realm.

Note: By substituting the standard CMET, the affiliate introduces compatibility issues when communicating outside their affiliate.

At implementation, any user may choose from a family of registered CMETs relating to the same concept, as outlined in section Common Message Element Types (CMETs) (§ 2.4.2 ).

Constraint
Since CMETs are simply shared Message Types, the localization of CMETs may be undertaken following the rules listed for Message Types (§ 5.4.1 ).

Extension
CMETs are defined from an R-MIM. Thus extending CMETs by adding attributes and classes from the RIM are subject to rules for R-MIM (§ 5.2.2 ) extension, of which this is a special case.

HL7 will maintain its vocabulary domain specifications following a harmonization process that is not subject to ballot cycle limitations. Vendors and users should follow Vocabulary Conformance (§ 4.2.1 ).

HL7 International Affiliates will establish their own procedures to define and maintain region-specific variations for vocabulary domains.

HL7 International Affiliates may identify new interactions, trigger events and application roles. Each such identification shall be subject both to registration and subsequent international ballot.

Modeling & Methodology Co-Chair	George Beeler Jr PhD. Beeler Consulting LLC
Conformance Co-Chair	Lisa Carnahan National Institute of Standards & Technology
Primary Contributor	Len Gallagher National Institute of Standards & Technology
Conformance Co-Chair	John Lyons Siemens Medical Solutions Health Services
Modeling & Methodology Co-Chair	Lloyd McKenzie Lloyd McKenzie & Assoc. Consulting Ltd.
Modeling & Methodology Co-Chair	Dale Nelson Zed-Logic Informatics
Conformance Co-Chair	Frank Oemig HL7 Germany
Modeling & Methodology Co-Chair	Craig Parker Intermountain Health Care
Primary Contributor	Jennifer Puyenbroek McKesson Information Solutions
Conformance Co-Chair	Peter Rontey U.S. Department of Veterans Affairs
Modeling & Methodology Co-Chair	Iona Singureanu Eversolve, LLC
Primary Contributor	Bas Van Poppel iSOFT Nederland

Refinement, Constraint and Localization, Release 2

Table of Contents

Preface