Core Properties of V3 Models

Preface

Notes to Readers

This is the first release of this document. It is intended to provide important background information for implementors trying to implement V3 Static Models, whether they are found in Messages, Documents, or Service Payloads.

Acknowledgements

Authors:

• George W Beeler
• Grahame Grieve
• Ted Klein

Introduction and Scope

• a description of the Document at a minimum sufficient for a person unfamiliar with the work to understand the document’s business, scope and relationship with HL7.

• the need for a Specification.

• This specification is a promise (actually, a covenant): what hl7 promises about v3 infrastructure that the implementers can rely on.
  • because of this, the document will occasionally specify internal procedural rules that are required to support these promises

Types of HL7 V3 Models

Instances

The fundamental notion of V3 is that in order to exchange data, systems exchange serialised streams of data that are an "instance" of a v3 model under a set of rules that describe why and when the data is exchanged.

All v3 models are valid of classes linked by associations. The classes and assocations are defined in the RIM. The classes have a series of named attributes which are assigned a type defined in the datatypes. Some attributes are associated with controlled vocabularies which provide clearly defined semantic meaning to the static models. Together, the structural vocabularies, the data types and the RIM classes constitute the reference model.

All v3 instances are instances of the reference model, and conform with the rules of the reference model. V3 models usually also conform to other additional constraint models that describe how the general reference model is used to describe particular administrative or clinical healthcare information.

Instance of v3 models may have any forms of expression and be used in many contexts, such as a message payload in a message associated with an HL7 defined interaction, a CDA document, or a payload as part of a service interaction, etc.

Instances of v3 models are exchanged in the context of a dynamic model that specifies why and when the data is exchanged.

Dynamic models are discussed further below.

Serialisation

In order for systems to exchange the instances of a v3 model, they need some particular form of representation. As a response to industry demand, HL7 offers a defined representation of the v3 instances in XML, known as the XML ITS. Other forms of representation could be imagined, such as XMI, HUTN, ASN.1 and so forth, but there has not been sufficient demand to justify the creation of alternatives to the standard XML form.

The ITS must define not only how the instance is serialised, but also how the links from the instance to the many models that contribute to defining the meaning of the instance are expressed and/or derived from the serialized representation.

RIM: Reference Information Model

The RIM defines all the classes that are used in v3 instances. The RIM itself is a UML class model; the classes are standard classes in the UML sense, and have associations and attributes as defined in the RIM models. All classes defined in the RIM are specialisations of the base class InfrastructureRoot which defines the attributes that support the core behaviour of V3 models as described in this specification.

The RIM makes extensive use of the two other parts of the V3 reference model, the structured vocabulary and the datatypes. Vocabulary and it's associated concepts are discussed below.

The datatypes define the set of types that may be used to define the value domains and associated semantics of the RIM class attribute. The semantics of the types are defined in the the abstract datatypes (the ITS describes how the datatypes are actually represented when serialized).

A paragraph about structural vocab and the class and mood codes.......

How the RIM is maintained

• where to find the content
  • structural vocabularies
  • datatypes
  • RIM
• that some parts are subject to retrospective change
  • pay attention to valueset definitions / how published
• harmonisation process
  • technical note about relationship between harmonisation and ballot

V3 Static Models

All other v3 Static Models are statements of constraint against the RIM to which instances of the V3 reference model may be required to conform in a particular context of use.

These models are expressed using a modeling formalism and language developed by HL7 for the purpose. This is fully defined in the HDF and MIF (references....). However this is only one possible form of expression. Other forms of expression have been imagined and proposed or are under development.

Static models may be considered or represented as a direct statement of constraint or as a class model (UML) or some form of typing model (i.e. schema) in their own right. The difference in these two is largely an implementation issue; the semantics are always clear: all instances are instances of the reference model, and all other satic models are constraints on the reference model. The degree of success at representing a static model as a typing model depends on the target platform.

DIM : Domain Information Model

The first level of constraint is a domain information model. This provides a solution to the information requirements of a particular problem domain. A DIM may have multiple entry points. As such, a DIM is not a directly implementable model, and is a fairly general statement of an domain with fairly general vocabulary bindings.

DIMs are not derived from the RIM, but are developed using constructs that are accessible to experts in the domain in question [(was) may be derived directly from the RIM or from other DIMs (such as the clinical statement pattern).] One stage of HL7 development, see HDF xxx, is to take a developed DIM and map it to the RIM to create a RIM based model that expresses the same content as the orginial DAM. Q: How does one decide on the scope of a domain? Q: Should a DAM reflect the needs of a particular realm? or be in the "universal realm"?

CIM : Constrained Information Model

CIMs represent a second level of constraint. CIMs must have single entry points, which makes them serialisable. CIMs are therefore suitable for use as implementation constructs on information systems and should be completely specified for this purpose. CIMs are generally focused on narrower problem domain that a DIM.

CIMs are either derived from a DIM directly, or from another CIM. Though technically, a CIM could also be derived from the RIM directly, this is prohibited as a matter of policy to encourage consistent design.

CIM cascades can be as deep as desired, but in most domains HL7 only defines a DIM and one layer of CIMs.

Only HL7 or it's affiliates may define and publish CIMs.

LIM : Local Information Model

Like CIMs, LIMs are a constraint model that has a single entry point. However LIMs differ from CIMs:

• LIMs may be derived from the RIM directly as well as DIMs or CIMs (though derivation from the appropriate DIM is recommended)
• LIMs may be defined and published by anyone (including HL7 and it's affiliates).
• LIMs may be incomplete models (refer to the static model definitions for further information about incomplete models).

LIMs are principally intended to be used as templates, but may be used in other fashion by site or realm agreement.

Dynamic Model

The dynamic model specifies who exchanges information and why, and refers to a set of static model to define the information that is exchanged for a particular scenario. The form of the dynamic model is variable in different uses of V3, and the full expression form is still a subject of further development.

Interoperability Paradigms!

Realms

rework - this should be a discussion about realms mean in vocab, not what they are.--GrahameGrieve 14:59, 23 February 2008 (CST)

begun the rework, please comment. --Tklein 18:07, 23 February 2008 (CST)

Realm (previously also referred to as Context of Use) refers to a named interoperability conformance space, meaning that all static models within a particular Realm share the same conformance binding. A Realm has a string name which is unique in the HL7 Standards space. In order to enable conformance, the name of a Realm is carried in a model instance.

In the interest of maximizing interoperability, and making the spaces within which interoperability is maximized as large as possible, Realms are preferred to be large-grained. The term 'Realm' used in different ways. In the context of HL7 Vocabulary, it is used to indicate a Binding Realm: this manages the bindings/substitutions of value sets to reflect local rules, and is a parameterization permitting internationalization of vocabulary – binding different value sets to the same message design being used in a different country.

There have been a number of Realms defined in HL7.

Defined Realms

Affiliate Realms

Each HL7 International Affiliate has control of a Realm bounded by the geographic scope of that International Affiliate.

Combination Realms

There is a need for some Realms that combine more than one country. North America represents a shared interoperability space for Cancer Registries for both the US and Canada. This Realm has been created as a combination of the US Realm and the Canadian Realm. Any Realms may be combined for such a purpose to make an interoperability space that extends beyond one country.

Sub-Realms

In some circumstances, a Realm has a requirement to make smaller interoperability spaces within its own borders. This is discouraged, as it impedes broader interoperability. However, the mechanisms exist for any Realm to create such a Sub-Realm for models that are used wholly within that smaller subdivision differ from the conformance requirements of models in other Sub-Realms.

Generic Realms

Four Generic Realms have been defined that are not specific to an International Affiliate or a geographic area. These generic realms should never appear in instances, they are only used in the standards creation process. All instances must declare a particular realm (or sub-realm) based on the jurisdiction from which they originate or for which they are destined or some third jurisdiction by site-specific agreement.

Universal Realm

The Universal Realm constitutes the core HL7 realm which by definition is invariable and fully inherited by all HL7 compliant implementations. I.e. If a Universal Realm binding exists for any domain, all implementations are expected to use the set of codes associated with that binding. No other bindings may exist. Structural elements and most datatypes are examples of contents in this realm. Contents from domain technical committees are not likely to be included in the Universal Realm and when introduced must go through special processes to ensure full international consensus on the constraint to a single binding.

Example Realm

The example realm is used for bindings to sets of codes that are known to provide incomplete or non-implementable coverage to the associated domain. They are used to fulfill the example requirement of Concept Domain definition. They may also be used in the construction of realm-independent example instances. Example realms are not needed when Representative Realms exist.

Representative Realm

Representative realm bindings are intended to be complete and implementable. However, unlike universal bindings, there is no expectation that all affiliates will choose to adopt the representative realm bound codes. Representative realm bindings provide both a starting point and as a focus for consensus, while recognizing that cultural and political variations between International Affiliates will result in alternative bindings. To qualify for Representative Realm designation, candidate content must be sufficiently comprehensive and internally consistent to be adoptable and implementable by specialized binding realms. A representative realm binding has no official force in an affiliate. The affiliate must explicitly choose to adopt the same set of codes with an Affiliate-specific binding for the representative set of codes to come into effect when determining conformance

Unclassified Realm

Since much proposed HL7 machinery will require the explicit specification of a realm, the creation of a realm that can accommodate content that is new and being created or legacy content that has not yet been promoted to one of the three main realms. The Unclassified Realm may also serve as a transition point for content contributed from Specialized Realms. Unclassified realms exist for HL7 administrative purposes and have no effect on implementations Sub-binding Realms

In some circumstances, an International Affiliate might choose to create additional binding realms narrower in scope than the affiliate-wide binding realm. The sub-binding realms might be constructed geographically (regions, states, provinces, etc.) or by type of implementation (e.g. human vs. veterinarian). Sub-binding realms can only be created by International Affiliates.

Note: Because the purpose of binding sub-realms is to allow the use of different code sets for the same message within an affiliate, they can cause interoperability issues within the Affiliate. They should therefore only be introduced after careful consideration of the interoperability consequences.

Vocabulary

Coded attributes in Static Models contain Vocabulary, ie they may contain one or more coded concepts drawn from Coding Systems. The process and mechanisms for assigning collections of these concepts to the coded attributes in the Static Models is described in the Conformance section below. This section will provide definitions required for the mechanisms implementing Conformance.

Code System

Within HL7, a code system is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-9 CM, SNOMED CT, LOINC, and CPT. To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each table in the HL7 Version 2 standard represents a different code system since codes are sometimes used in different tables to have different meanings. For example, “M” in the gender table means Male, while “M” in the marital status table means Married.

can we discus the difference between synonyms and codes and terms, and the notions of CUID and DUID in snomed? I'd prefer that we use ISO 714 notions like "term" rather than "code" but I accept that this is never going to happen.--GrahameGrieve 14:40, 23 February 2008 (CST)

can we also mention classification and terminology and possible reference/interface in this section?--GrahameGrieve 14:40, 23 February 2008 (CST)

Concept Domain

An HL7 Concept Domain is a named category of like concepts (semantic type) that will be bound to one or more coded elements.*

what's a coded element? And what's the *--GrahameGrieve 14:34, 23 February 2008 (CST)

A Concept Domain is documented by specifying a name, a narrative definition, and three or more examples of concepts that are members of the domain category. This can be accomplished by at least one of the following:

1. Including three example concepts as part of the narrative definition;
2. Binding the domain in the Example Realm to a value set containing at least three example concepts;
3. Binding the domain in either the Universal or Representative Realm to a value set deemed to contain a complete set of concepts.

The binding process and descriptions of the Universal, Representative, Unclassified and Example Realms are described later in this document.

Concept Domains exist because we want to constrain the intent of the coded element while deferring the association of the element to a specific coded terminology until later in the message development process. Thus, Concept Domains are independent of any specific vocabulary or code system.

todo: how to describe/define the message development process. and why "specific vocabulary" - it's not a predefined term. --GrahameGrieve 14:38, 23 February 2008 (CST)

Concept Domains are universal in nature (independent of any realm). The name for a Concept Domain should never contain any reference to a specific realm. Concept Domains are proposed as part of the HL7 standards development process and are approved by the RIM harmonization process. Any conflicts in proposed domains are resolved by the RIM harmonization process.

Examples of Concept Domains

The HL7 defined Concept Domain HumanLanguage, defines a category of like concepts specifying the “Codes for the representation of the names of human languages.” The HumanLanguage Concept Domain only defines the category for the concepts that represent the different human languages. The actual coded elements for the concepts comprising the content for the HumanLanguage Concept Domain will be defined by different code systems used by different entities.

For example, agencies in the United States may choose to use a code system containing codes that represent the Native American languages, while agencies in New Zealand may find such a Code System inappropriate.

Figure 1: RIM Attributes and Vocabulary Domains

• A coded element is any attribute from a v3 static model (RIM, DIM (D-MIM), CIM (R-MIM, HMD, Message Type), LIM (Template, Profile etc.)) or property from a V3 data type model where the type of that attribute or property can be specialized or generalized from the CD (concept descriptor) data type, and collections thereof. Thus, coded attributes are attributes that have a type of concept descriptor (CD), coded simple value (CS), coded value (CV), concept role (CR), coded with equivalents (CE), coded ordinal (CO), character string with code (SC), or physical quantity representation (PQR). Elements with a data type of any (ANY) are also categorized as coded elements because the ANY datatype can be constrained to CD or any of its specializations.

why do we have this a bullet point? I'm not even sure what it's trying to accomplish. and I think that while the comment about ANY is potentially true, most people would be confused by it? It's not like we allow a binding on ANY anywhere. Do we? --GrahameGrieve 14:58, 23 February 2008 (CST)

Sub-Domains

HL7 Concept Domains are defined as a named category of like concepts. The categorization of Concept Domains is hierarchical allowing for further constraint on the breadth of the semantic category covered by the Concept Domain. Such constrained domains are known as “sub-domains”.

Sub-domains allow for further specialization (constraint) on the intended values for a domain.

Value Sets

Introduction

A Value Set represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.

Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.

Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content, and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set. Sub-value Sets

A sub-value set is a sub-set of a ”parent” value set.

Value Set Specification

Value sets can be specified in two ways, either by enumeration (extension), or definition (intention).

Extensional Value Set Representation (Enumeration)

From ISO (http://www.tc215wg3.nhs.uk/pages/pdf/vote0204.pdf), an extensional definition is a description of a concept by enumerating all of its subordinate concepts under one criterion of subdivision.

Value sets defined by extension are comprised of an explicitly enumerated set of codes. The simplest case is when the value set consists of only one code.

Code Value	Description
M	Male
F	Female
U	Unspecified

More complex variations might relate to hierarchical coding systems such as the following fictitious example:

Code Value	Level	Description
1123123	1	Education
1343434	2	Diabetic Education
1445455	2	Stroke Education
2135534	1	Counseling
2344566	2	Emotional
3456663	2	Daily Living

Intensional Value Set Definition (Definition)

From ISO (http://www.tc215wg3.nhs.uk/pages/pdf/vote0204.pdf), an intensional definition describes the intension of a concept by stating the superordinate concept and the delimiting characteristics.

Value sets defined by intension are value sets that are defined by a computable expression that can be resolved to an exact list of codes.

For example, an intensional value set definition might be defined as, “All SNOMED CT concepts that are children of the SNOMED CT concept ‘Diabetes Mellitus.’”

Some common strategies used to define intensional values sets include:

1. 1. 1. Reference a head concept and its subordinate concepts in a hierarchy.
      2. Reference only the concepts subordinate to a head code (and not the head code itself).
      3. Create arbitrarily complex unions, intersections, and exclusions of the two previously described types of value sets.
      4. Other mechanisms, including statements created using a rich expression language.

Nested Value Sets

When a Value Set Entry references another Value Set, the child value set is referred to as a Nested Value Set. There is no preset limit to the level of nesting allowed within value sets. Value sets cannot contain themselves, or any of their ancestors (i.e. they cannot be defined recursively).

Intensional Value Sets can be defined by either fixing the Value Set definition to a specific version of the Code System (when the Code System supports versioning), or by decoupling the Value Set definition from the version of the code system. This seemingly subtle variation can have very significant impact on the final list of concepts which the Value Set ultimately resolves to.

When the Value Set definition is tied to the version of the Code System, the value set content will remain fixed when instantiated. When the Value Set definition is independent of Code System version, the content of the Value Set can vary as the Value Set is resolved against different versions of the Code System.

Value Set / Code System Relationship

Whether specified extensionally, intensionally or both, a Value Set can contain concepts from one or more code systems. While drawing concepts from multiple code systems in many cases is desirable, care must be taken to ensure that a given meaning is only represented by a code or codes from a single code system. For example, it would be inappropriate to create value set where a given orderable item like a hematocrit could be represented by a CPT code and also by a LOINC code. If a single concept (meaning) ends up being represented by more than one code in a Value Set in this manner, it allows for the possibility that the same information can be recorded in two different ways. This can lead to confusion and error in analyzing the recored data.

On the other hand, a value set is allowed to contain more than one code for a given concept as long as both codes are drawn from the same code system. For example, in the UCUM coding system “l” and “L” are both codes for liter. While this is undesirable, it is permitted for a value set to have both codes as members of the set. When this occurs, the codes are referred to as synonyms.

Value Set Versioning

Value sets are versioned. The version of a value set changes when:

1. For enumerated value sets
   1. Any allowed values are added or deleted
2. For intensionaly defined value sets
   1. If the logic of the defining expression changes

Changes that correct the spelling of terms, or additions of terms that do not add new codes to the value set, do not cause the version to change.

There are multiple strategies for tracking value set versions. Two of the most common are:

1. Increment the version number each time a change is made to the value set.
2. Track add/modification dates for each change to the value set.

By a vote of the Vocabulary TC on September 15, 2006 at the Boca Raton meetings, it was decided that HL7 will reference all value set versions based on effective date and not by available date or by a version number. This policy has the following implications:

1. For enumerated value sets maintained by HL7, the activation date and inactivation date for individual codes in the value set must be maintained as part of the value set database.
2. For intensionally defined value sets in the HL7 value set database, the activation date and superceded date must be recorded (tracked) each time the logic of the definition is changed.
3. For externally maintained terminologies that have named/numbered releases, a table must be maintained that shows the modification dates for the named/numbered release.
4. For externally maintained terminologies that maintain modification dates for each individual code change, no additional information is needed.

Items left to do [tk]: more complete description/definition of Coded attributes in static models

  Properties of these coded attributes
  Binding to concept domains in the static models
  links to the conformance section

Type Representation

All HL7 models are constraints on a reference model built from the classes defined in the RIM and the datatypes defined in the abstract datatypes.

This reference model is further constrained by additional constraint models that associate new names for particular constraints on the associations and classes. These constraint models may come from a linear sequence of constraints where each model is an additional constraint on another model (and when the instance conforms to a model it also conforms to the models on which that model is derived), or an instance may conform to multiple different constraints that are not related to each other.

So any given type is an instance of the class or datatype as specified in the reference model, while at the same time conforming to multiple other different design specifications within this cascading hierarchy of models.

All classes and datatypes SHALL declare conformance to a single master type. This requirement exists to ease the path of implementations in common target technologies. The type as a duple: the name of the model, and the name of the type/constraint definition in the model. Both the name of the model and the name of the type may be defined by some applicable design contract rather than expressed directly as an attribute of the class.

ITSs that describe how to represent V3 models SHALL make clear how the both parts of the type may be determined from examination of the instance, and what other resources are required at design and/or runtime to unambiguously resolve the type of the class or datatype.

Note: The InfrastructureRoot class in the RIM defines the notional attribute typeId to represent the type of the class. ITSs are not required to represent this attribute directly; some other method of representation may be chosen that is more appropriate with the base technology and consistent with the way the ITS specifies that the type information is determined from the instance.

For classes, the type need not be the type from a reference model; the context may specify that the expressed type is a name taken from one of the applicable constraining model. As a consequence, there are three types of models applicable to classes:

Expressed Models

The expressed model is the model that contains the type expressed by the class.

Note: The existing XML ITS fixes the expressed model throughout the instance to be the static model associated with the interaction identifier specified in the root element of the interaction (or from "ClinicalDocument" for CDA). The type of a class is not usually represented directly; instead the names of the associations in the expressed model are used, and the type is determined by implication from the association name. For choices, elements of the type name may be pre-coordinated with the association name in the instance.

Note: Only complete, implementable models with one entry point (CIMs and some LIMs) may be used as expressed models.

Implied Models

The implied models are specified by the derivations contained in the definition of the expressed model. All expressed models SHALL specify derivations from the RIM. Additional derivations from other models may also be specified.

Note: this means that the RIM is always an expressed or applied model.

Implementation Note: A processor can correlate the instance data against an implied model by reading the full static model for the expressed model and tracing the derivations from the expressed model to the implied model of choice. This can also be done by the developer by hard coding the derivations in the application. HL7 XML ITS schemas also provide a partial link to the RIM level definition. The implied RIM model is of such consequence that a separate pattern for identifying the RIM classes in the instance exists, using structural codes.

Applied Models

Are other models to which the class conforms to but are not explicit or implicit in the type the the class conforms to. These models are usually known as templates. The applied model may be invoked explicitly in in the instance, or by specifying it in some form of design contract (e.g. interaction profile). Note that it is not necessary to declare all the constraint models that a class conforms to.

Note: The InfrastructureRoot class defines an attribute called templateId which is used to represent the set of applied models that a class conforms to. Like the typeId attribute, the templateId is notional; ITSs may define alternate methods for representation of the applied models.

ITSs that describe how to represent V3 models SHALL make clear how the applied models may be determined from examination of the instance, and what other resources are required at design and/or runtime to unambiguously resolve the applied models.

Note: If an applied model specifies derivations, then the models specified in the derivations are also implied models.

Reference: The templates specification should be consulted for further template related information.

Datatype Flavors

For datatypes, the type must be the type from the reference model; the expressed model is always that specified in the abstract datatypes. This policy exists to ensure that implementations of the datatypes are robust for use in all the environments that V3 is used.

Datatypes may also have additional constraints associated with them. These constraints are referred to as datatype flavors. Datatype flavors are very similar to applied models, but only one flavor can be specified.

Reference: The Refinement, Constraint and Localisation should be consulted for further information about datatypes flavors.

Null Flavor

It is common to encounter missing or incomplete information in healthcare. In some circumstances, why, how, or in what way the information is missing or incomplete may have some semantic significance that may make a difference to the workflow or clinical management the depends on the information.

For this reason all datatypes and RIM classes have a property called "nullFlavor" which specifies why the information does not exist, is not known or available, or cannot be expressed in the allowed value domain.

This table summarises the currently accepted values that the nullFlavor property may have it is not null:

-- insert null flavor table here --

A datatype or a class is known as a "null" class if it has a value for it's nullFlavor property. Null values are also known as "exceptional values". Null values are improper values that do not conform to the proper or expected value domain as described by the applicable specification (usually any model that the type claims conformance too - see typing below). The information may either be missing or partially present, or even completely present but not valid with respect to the constraints imposed by the models it conforms to. While null values may not conform to the "proper or expected value domain" as described by the specification, they must nevertheless conform to all the rules specified by the specifications to which they conform, null values SHALL only be used as specified by the models, both in regard to where and how they are used.

In this sense, null is used to create a two level conformance strategy. In some cases, a properly acceptable value domain is defined, and only information that completely conforms to the specified value domain may be provided. In other cases, a properly acceptable value domain is defined, and some information must be provided, but it may not conform to the narrow value domain if it explicitly declares that it does not conform. See the conformance section for further details.

Note about the name nullFlavor

The property is named nullFlavor because of the similarities between the concept of a null value and the concept and behaviour of null in implementation technologies, particularly SQL and OCL. As in SQL and OCL, the value null is in the value domain of the all the types, and nulFlavors will generally propagate through operations such as comparison (i.e. the result of a comparison operation between a null value and some other value is null).

However there are some important differences between the implementation of nulls in such technologies and the HL7 nullFlavor. Most notably, in most implementation technologies, a null instance has no further information associated with it (some variation of the concept of a null pointer). This is not true of the HL7 concept of null; if a datatype or class is null, the nullFlavor property is not null, and any of the other properties might not be null.

Note: the nullFlavor property functions in a reverse sense to the data type or class; if the value is not null the nullFlavor will be null, and if the value is null, then the nullFlavor is not null - it will specify an actual nullFlavor that provides more detail as to in what way or why no proper value is supplied.

Note: In OCL, null is an instance of OclVoid which is a super type of all types. nullFlavor is not modelled the same way in HL7: a null value is still a valid instance of a particular type (see types below). If a true null is encountered in an implementation environment (i.e. the class is not represented in the XML when using the XML ITS, or is present with an xsi:nil="true" attribute), it is semantically equivalent to a null-value of NI, and all other properties not related to nullFlavor will also have nullFlavor NI.

Implementation Considerations

When performing operations upon null values, the semantic meaning of the nullFlavor SHALL be considered. This is particularly important for equality. The only case where non-proper (NULL) values may be equal is where both values have a nullFlavor of NA and all other properties equal. In all most other cases, the outcome of comparing NULL values is also null. However, there are exceptions based on the semantic meaning of nullFlavor. For instance, in the datatypes, although direct comparison of two values with nullFlavor PINF is always null (NI), two intervals with the equal low bounds and high bounds of PINF will return true, since they specify the same set. Similarly, comparison of NINF and PINF is always False.

The "actual value" refers to the value of the information itself, rather than the information as represented in the type itself. These two may diverge when the information provided is incomplete, such as when an expression is provided. The null flavor "other" is used whenever the actual value is not in the required value domain: this may occur, for example, when the value exceeds some constraints that are defined in too restrictive a manner. For example, if the value for age is 100 yrs, but the constraining model specifies that the age must be less than 100 years, the age may still be specified, provided that the model does not make the attribute mandatory.

<value nullFlavor="OTH" value="120" unit="yr"/>

Some of the null flavors are not generally applicable to all circumstances. The nullFlavors NINF, PINF, QS, and TRC SHALL only be used in associated with datatypes that are a specialisation of the QTY type. The nullFlavor UNC SHALL only be used with any data type that has an originalText, and when UNC is used the originalText property SHALL be populated. The nullFlavor DER SHALL only be used with the EXPR type, and an expression SHALL be provided.

NOTE: NULL-flavors are potentially applicable to any class, any data type, and any property of a data value. Where the difference of null flavors is not semantically significant, ITS are not required to represent them. (this is usually appropriate for structural attributes in the RIM classes, and simple properties of the datatypes).

Update control

HL7 Static models are used to represent information about the real world when it is exchanged between systems. The objects in the instance represent real world concepts about which a certain amount of information is known.

Snapshot: A methodology in which the sending system includes all the data it has into the message with no specific indications of which data items were added, replaced, or removed. The term was chosen because the source system sends a “snapshot” of the objects as it knows them.

Snapshot is typically used when information is exchanged between systems where the destination system is not known, or where it is not clear how much information the destination system already has about the real world concept.

When a receiving application processes an object that is represented using a snap shot, and it already has information about the real world concept that matches this object, the application should match objects in the instance with the information it already has, and then appropriately process the information from the message to the information it has on file (for instance, in some cases it would make sense to merge all the attributes and associations of the objects).

Potential Advantages:

• Can be easier for senders to implement
• Many sending systems implement Version 2 messages in this fashion

Potential Disadvantages:

• Typically more complicated for receivers to process appropriately
• Easier for relevant data to be deleted

Update mode: A methodology in which the message designer specifies the allowable update mode values for items within the message and the message sender specifies the specific update mode value for items for items within the message.

However in some contexts, the destination system is well known and there is an implicit or explicit contract between the source and destination systems that ensures the information the destination system holds is well known to the source system. In such contexts, it is possible to only send the changes that have occurred on the source system or should occur on the destination system. These changes may be additions, deletions, and revisions to existing data. This practice is known as "update" mode.

Another use for update mode is where the source application includes all the same data items in the message specification as it would for snapshot node, but marks each value for each data item in the message specification that indicates whether it is added, replaces another item, or has not changed.

Where update mode can be used, it offers several advantages. Potential Advantages (depending how it is used):

• reduced instance size
• The receiver does not need to compare data to determine what changes the sender has made
• Where the receiver gathers data from multiple sources, it does not need to store ‘images’ of data received from a particular sender to ensure that it can adequately compare to the previously sent data when determining changes
• reduced processing time
• simpler implementation decision making
• Conveys important information for how the sending system has processed the information
• Query responses are able to document accountability information in terms of what changes were performed (see accountability below).

Potential Disadvantages:

• update mode offers the opportunity for two systems to get information out of sync, so modellers and implementors should always be careful.
• Typically requires for effort for the source system

The normal mode for V3 instances is snapshot; update mode is only allowed when the constraining model design specifically allows update mode.

Update Control interpretation depends on the context of the message type:

1. When used in a message driven by a state-transition notification or a state-transition fulfillment request trigger event (where the focal class is an object owned by the sending system), the update control represents the change that occurred on the sending system as a result of the state change associated with the trigger event. The recipient is not bound to make the same changes as those done on the sending system.
2. When used in a message driven by a state-transition request trigger event (where the focal class is an object owned by the receiving system), the update control represents the change that is desired by the sending system as a result of that trigger event. If the recipient accepts the request, they must make the requested changes.
3. When used in a query response message, the update control represents the most recent change that has occurred to the sender’s object within back to a specified time. The committee may allow the time from which changes are reported to be specified by a query parameter or fixed by the query definition. If not otherwise specified, the start time is the first time the system became aware of the object.

Referencing Objects

When the destination system is well known and there is an implicit or explicit contract between the source and destination systems that ensures the information the destination system holds is well known to the source system, the destination system may simply wish to refer to an object rather than providing full details of the object. Rather than updating the object in either snapshot or update mode, the destination system should use the information provided to identify an existing instance of data.

It is not necessary for the destination system to already have information, only for the system or the appropriate users to know how to locate the information that the reference pertains to.

For this reason the concept of referencing objects is more widespread than the use of update mode. Nevertheless, the concept of reference is tightly related to the concept of update mode - an object will either be passed in as a snapshot, an update, or a reference.

Although complex scenarios involve mixes of these modes can be envisaged, HL7 does not support mixing these in order to keep the processing complexity from getting out of control. If an object is passed a reference, there SHALL be no expectation that any updates to the object may occur. If an object is represented using update Mode, any information provided as part of the object that has no associated update instructions SHALL be ignored.

Identifying Objects

Whether an object is being conveyed using snapshot mode, update mode, or as a reference, the key first step for most processing systems is to correctly locate an existing record for the concept that the object represents, if one exists.

In order to accomplish this, the system must correctly identify the object. In most cases, the identification will be implicit or explicit in the contracts that control the system communication. However in some cases it will be necessary for the source system to clearly identify the attributes that should be used to identify the object.

For example, a source system may wish to indicate which of several identifiers associated with an object should be used to identify the object. In this case, the semantic properties of the identifier itself - scope and reliability - are generally preferred as the criteria for choosing which identifier should be used, but in a few cases it may be necessary to clearly identify a particular information.

Another case is where the source systems does not know the relevant identifiers for the object, but is able to define some key criteria for identification of the concept. For instance, the source system may know that the patient had an episode of care on a given date, but not the identifier assigned to the episode of care by any relevant system.

Source systems are able to clearly identify the attributes of an object that it expects should be used to identify the object correctly.

The general implication of these rules is that when an object is sent using update mode or as a reference, only the information that is required in order to correctly identify the object is sent, along with any specific updates for update mode, and that all the information provided should be clearly labelled. However it isn't always clear how much information is required to correctly identify the reference, so additional useful information is always allowed. Generally it would be expected that this additional information would be of use in some human intervention procedure if automated resolution of the reference failed.

Data types are not subject to identification - the full value of the datatype is itself the identity of the value.

In the absence of any explicit agreement or information in the instance, the default method for resolving identity is that all of identifiers in the objects id field must match the record on the destination system.

Update Mode

HL7 provides a single property called updateMode to support the concepts defined in Update Control, Referencing Objects, and Identifying Objects.

Note: a more appropriate name might be useCode, but the property name is updateMode for backwards compatibility reasons.

Note: The updateMode property actually applies to associations and attributes, not to classes and datatypes, though it is formally defined on the types.

The value of the updateMode property identifies how the attribute or association contributes to the processing of the instance. HL7 models strictly control the use of the updateMode attribute; it may only be populated with a value that the constraining model (internal reference) allows. If there is no value, then the constraining model should be consulted for guidance on how the instance should be processed.

The updateMode property can have one of the following values:

Code	Name	Description
A	Add	The item was (or is to be) added, having not been present immediately before. (If it is already present, this may be treated as an error condition.)
D	Delete	The item was (or is to be) removed (sometimes referred to as deleted). If the item is part of a collection, delete any matching items.
R	Replace	The item existed previously and has (or is to be) revised. (If an item does not already exist, this may be treated as an error condition.)
AR	Add or Replace	The item was (or is to be) either added or replaced. --[Delete: (This option is included to support one specific case, discussed below. Its general use is discouraged, the preferred methodology is to use the combination of the individual Add and Replace values.)]--
N	No Change	There was (or is to be) no change to the item. This is primarily used when this element has not changed, but other attributes in the instance have changed.
U	Unknown	It is not specified whether or what kind of change has occurred to the item, or whether the item is present as a reference or identifying property. (replaces: It’s not specified whether the item was (or is to be) added, revised, or not changed.)
REF	reference	This item provides enough information to allow a processing system to locate the full applicable record by identifying the object.
K	Key	This item is part of the identifying information for this object.

Notes:

1. Portions requiring harmonisation proposals in italics
2. R and AR may not be applied to multiple attribute values within a DSET, BAG or LIST. If a single attribute value is marked with a R is used to update a collection, the single value replaces all the items in the collection
3. REF may only be applied to associations, not attributes.
4. U is semantically equivalent to a nullFlavor of NI. However due to some methodological issues in V3, a specific code is required to in some circumstances.
5. If an item is deleted from a collection, all matching items should be deleted from the collection

Model Designer Guidance

This section is intended for people designing static models, typically HL7 domain committees.

When designing a model, a committee may allow UpdateMode to be used on attributes and associations identified by the committee. To enable UpdateMode, the committee must select the set of permitted updateMode values.

In addition to identifying the allowed set of values, the committee may also choose to identify a ‘default’ updateMode for the attribute or association. This is the updateMode that will be assumed by the receiver if none is specified in the instance.

updateMode of “Replace” is not permitted on Entity.id, Role.id, Participation.id and Act.id attribute. If an identifier was captured erroneously, the incorrect submission should be nullified and the record resubmitted with the correct identifier. If a new identifier has been issued, replacing the old identifier, this should be handled as a supersedes or replaces relationship between the class with the old identifier and the class with the new identifier.

If no UpdateMode set is enabled for an attribute or association, it is the same as if the UpdateMode were set to ‘Unknown’. The effective behavior is that of ‘Snapshot’. I.e. the current element value is specified with no indication of whether it was changed or not.

The allowed UpdateMode set available for RIM attributes is empty by default. This means that committees must specifically enable UpdateMode by declaring an allowed set of Update Modes within their design for each attribute or association in their DIM where they want them to be used. Once an UpdateMode set has been defined in the DIM, any derived models (CIM, serialized static models or serialized message models). I.e. Update Modes may be removed from the allowed set, but never added.

If a committee defines update modes for a particular attribute or association, implementers must support the allowed update mode set to be conformant. (Failure to support the complete set defined by the committee may result in interoperability problems.) Implementers should be able to document what update modes they support in their conformance profile, but failure to support those identified by the committee that defined the artifact is considered non-conformant.

The committee does not need to define a default update mode, and may define a default at any derived model. Once a default is defined, it may not be removed or changed in any subsequently derived models. I.e. if a default is defined in an R-MIM, it may not be changed or removed in serialized static models or Message Types derived from that R-MIM. Because of this restriction, committees are discouraged from defining a default UpdateMode at the DIM level.

Update modes should not be specified in templates, as they are intended to be used across multiple different static models that make their own rules about use of updateMode.

Notes:

1. UpdateMode is not a concept that should appear in all, or even in most models developed by committees. It should be treated as an ‘advanced modeling concept’, and only employed in models where the facilitator is certain that the concept is needed to adequately reflect the needs identified by their committee. Furthermore it should only be enabled on those attributes or associations where there is an identified need. When a facilitator has identified a perceived requirement for UpdateMode in their model, they are encouraged to bring the requirement to the Modeling and Methodology Technical Committee for review.
2. UpdateMode will primarily be used for trigger events where the state transition is “revise” and for query responses; however, it may be appropriate in other circumstances. Committees are encouraged to discuss additional patterns for usage so that they may be reflected in this document.
3. UpdateMode should not be enabled in Transmission or ControlAct wrappers.
4. There is no way to Remove a single element from a BAG where there are multiple matching elements because there is no means to indicate which occurrence within the bag is to be removed.
5. Id attributes should never be sent with an UpdateMode of Replace. If such a use-case arises, it will addressed as a future methodology change.
6. Classes that do not carry an id attribute cannot be identified at all.

Accountability

In addition to using update Mode to describe the changes that have happened or should happen, instances can also carry accountability information relating to the information in the message, both associations and attributes. The accountability information can include the time range during which the information was or is valid, and a link to the control act associated with the value. The control act can describe who made the change, when the change was made, what application made the change, and some context for the change in the overall dynamic model.

GG: is that last bit true - can you infer anything about the dynamic model from the controlAct?

Generally, this form of accountability history is used in registry-type systems where there is a strong need for the receiver to establish the authority on which a particular piece of data is being changed. Understanding the details can be important in helping a receiver make the determination whether they wish to adopt the change.

Accountability information will be handled by using the HXIT generic type extension. This extension will be applicable to both attributes and to associations. To provide support for accountability information in addition to a time stamps, the HXIT extension will be modified to allow for the presence of either a simple time stamps or a ControlAct.id reference. The reference will allow the changes to an individual attribute or association to be associated with the ControlAct that changed it. The ControlAct can be used to convey such information as event time, author, authoring organization, data-enterer, reason, and any other accountability information deemed to be important.

When working with interactions triggered by a state-transition notification, a state-transition request or a state-transition fulfillment request, the individual ControlAct classes associated with the changes to each attribute or association will be sent as ‘Components’ of the ControlAct in the ControlAct wrapper. When working with query response interactions, the ControlAct classes will be attached to the focal class of the query response via a subject association.

Multiple associations and attributes may reference a single ControlAct, or each may reference a separate one.

Committees must explicitly enable exposing the Accountability History link for a given attribute or association.

Identification

One of the founding principles of V3 models is the importance or properly identifying objects and concepts correctly.

Global Uniqueness

All identifiers must be globally unique to prevent false positive comparisons between identifiers.

Globally unique identifiers may be achieved by use of either UUIDs or OIDs. UUIDs are globally unique by virtue of the method of their generation. OIDs are globally unique if the OID registration procedures defined by ISO are followed. A series of local identifiers may be made globally unique by prefixing them with a common global identifier.

The II type has a root, which must be populated, and an extension, which is optional. Together, the root and extension must be globally unique following the logic described above.

Note: there are few specific situations where only a local identifier is available. A typical example is on a point of care device. In these cases, either the context of use assigns a global identifier root, or the identifier is incomplete (some flavor of null).

OID registry

For some concepts, it is not enough that they must be globally unique; the identification must be consistent between a group of systems exchanging v3 instances. Some concepts must be consistently identified within a realm, such as SSN in USA. Some concepts, notably HL7 defined concepts and some key global things such as ISO standards and ICD-N and SNOMED terminologies need to be consistently identified by pretty much all systems producing and consuming V3 instances.

The only way to produce common consistent identification of these various kinds of objects is to maintain a central system where these identification concepts are registered. HL7 maintains an OID registry for this exact purpose. Any identifiers of interest to HL7 implementers may be registered on the HL7 OID registry, which include:

• those issued by HL7 that refer to objects or concepts defined by HL7
• those issued by HL7 that refer to externally defined objects or concepts
• externally issued identifiers that refer to externally defined objects or concepts

Note: The presence of an OID on the HL7 OID registry does not mean that HL7 claims responsibility for the concept of object identified, only that it is of interest to some HL7 customer. If the OID is in the HL7 OID branch then HL7 has issued the OID, and accepts responsibility for working with the owner of the object or concept to maintain the identification of the concept.

HL7 assigns an OID to each of its code systems, as well as to external standard coding systems that are being used with HL7 and HL7 Affiliate specifications. In addition, HL7 assigns OIDs in its branch for HL7 users and vendors upon their request. HL7 also assigns OIDs to public identifier-assigning authorities both U.S. nationally (e.g., the U.S. State driver license bureaus, U.S. Social Security Administration, HIPAA Provider ID registry, etc.) and internationally (e.g., other country's Social Security Administrations, Citizen ID registries, etc.).

The HL7 registered OIDs SHALL be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources.

This needs revision consistent with a recent email exchange between Ted and Grahame to describe a deprecation lifecycle to be used in the conflict resolution procedures discussed below. --Grahame Grieve 23:42, 21 February 2008 (CST)

OID Conflict Resolution

When assigning OIDs to third parties or entities, HL7 investigates whether an OID is already assigned for such entities through other sources. It this is the case, HL7 records the OID in the registry, but HL7 does not assign a duplicate OID in the HL7 branch. If possible, HL7 notifies a third party when an OID is being assigned for that party in the HL7 branch.

Though HL7 exercises considerable diligence before assigning an OID in the HL7 branch to third parties, given the lack of a global OID registry mechanism, it's not possible to make absolutely certain that there is no preexisting OID assignment for such third-party entity. Also, a duplicate assignment can happen in the future through another source. If such cases of duplicate assignment become known to HL7, HL7 works to resolve this situation.

HL7 OID branch

The HL7 root OID is 2.16.840.1.113883. All OIDs that HL7 assigns are issued within the space defined by this OID. This OID has immediate sub-spaces as summarised in this table:

Identity	Use
0	HL7 Root OID
1	HL7 registered internal objects (other than published documents and organizational bodies)
2	HL7 organizational bodies and groups HL7 Groups
3	External groups that have been issued an HL7 OID root for their own use
4	Registered externally maintained identifier systems
5	HL7 Internal Coding Systems
6	Registered external coding systems (with an HL7 issued OID)
7	HL7 published documents (standards, tutorial slides, implementation guides, databases, published RIM graphic billboards, etc)
8	HL7 OID registered documentation products and artifacts
9	HL7 Registered conformance profiles
10	HL7 Registered Templates
11	HL7 defined and registered Value Sets
12	HL7 Version 2.x tables as code systems
13	HL7 Imported value set Coding Systems (imported tables)
19	HL7 Examples Root used for published examples; meaningless identifier, not to be used for any actual entities

V3 Conformance

what goes here? what goes in RCL?

What goes here is foundational material: what is the notion of conformance, and what is it's architecture. How to use it, further considerations etc, belong in RCL. (so RCL has same relationship to this spec as templates, RIM, and datatypes)

Vocabulary Conformance

note this is the first set of pasted material, and is now all of the material from the value set binding document. I have not yet cleaned it up, nor put in the changes from San Antonio. --Tklein 18:32, 23 February 2008 (CST)

Vocabulary Conformance consists of defining collections of vocabulary that must be used in coded attributes, identifying the coded attributes and models in which they are located, and declaring the circumstances under which those collections must be used. Collectively, these are called Vocabulary Binding.

Vocabulary Binding

In order to be implemented and meet conformance, static models containing components intended to contain a coded element must be associated with a value set that can be resolved to all legal values that may be carried in that model component. Such an association is referred to as a vocabulary binding.

Value Set / Concept Domain Relationship

There are two mechanisms of binding an attribute or data type property to a value set that HL7 has agreed to support:

Model Binding: this is binding a coded attribute or data type property in a static model directly to a value set. In this case, the concept domain of the ancestor model governs the semantics of the binding. That is, the contents of the value set bound in the child model must be consistent with the concept domain definition in the parent model. Where the corresponding attribute or property in the parent model is a value-set or is a domain which has been bound to a value-set, the value-set bound to the child model attribute or property must be the same or a proper constraint of the parent model value-set.

Context Binding: this is binding a coded attribute or data type property to a collection of data including concept domain and realm that is resolved at runtime to a specific value set by a terminology server. In this case the concept domain and realm are used as keys by a terminology server to resolve the concept domain reference to a single version of a value set. This type of binding is used primarily when the precise desired value set to be bound is not knowable at message design time. Because the realm associated with the instance is identified within the instance, it is possible for a receiver who knows the message specification (and thus the concept domain) to determine the appropriate value-set to validate against.

Static and Dynamic Binding

Value set binding can be static or dynamic. Static binding means that the allowed values of the value set do not change automatically as new values are added to a value set. That is, the binding is to a single version of a value set. Dynamic binding means that the intent is to have the allowed values for a coded item automatically change (expand or contract) as the value set is maintained over time. This means that for dynamic binding, the binding is to the most current version of the value set in the terminology server at a given point in time.

A static binding is fully specified when the binding references a specific version (date) as well as the value-set OID/unique name

Dynamic binding is fully specified when the binding only references the value-set OID/unique name and does not specify a version date.

Un-bound domains

In some situations, a Concept Domain referenced in an implementable HL7 static model might not have an applicable binding for the affiliate making use of the model (no universal binding and no Affiliate binding for that affiliate). In that case, the domain is considered to be un-bound. The determination of the set of codes to use remains subject to site-specific negotiation until such time as an applicable binding is created for that affiliate or universally.

Additional notes on domains and value-sets

Concept Domain and Value Set Naming Conventions

HL7 concept domains, and value sets will be named according to the following rules:

• All concept domains and value sets will use “camel back” style names.
• The name will be restricted to the basic 26-character alphabet and the digits 0-9 using ASCII characters. White space (tabs, spaces), punctuation (periods, commas, colons, semicolons, parentheses, quotes, etc.), underscore, hyphens or other separators are not allowed in the name.
• The leading character must be upper-case alpha
• Concept domain and concept sub-domain names should be accurate labels for the virtual concepts that they contain. Concept domain and concept sub-domain names should never include realm or code-system specific information. The concept domain name should also be independent of the RIM attribute where possible, so that the concept domain can be re-used with different attributes. For example, a concept domain should be called “HumanGender” rather than “PatientGender” so that the same domain could be bound to the “GuarantorGender” attribute.
• Value sets should be named by combining the name of the concept domain and/or other use context that will uniquely identify the value set.

--66.18.217.179 23:13, 13 April 2007 (PDT)Question - can't a value-set be bound to multiple concept domains? If so, wouldn't it be appropriate to name the value-set independent of the concept domain?

• For example, the following would be appropriate names:

Concept Domain: HumanGender Value Set: HumanGenderUSRealm

Concept Domain: Country Value Set: CountryFIPS

HL7’s Implementation of value sets

Value Set can be referenced as either Abstract or Specializable. If a value set is referenced as abstract, the “navigational concept" - the root concept of which all other concepts in the value set are specializations - is not selectable. If specializable, the root concept (head code) is selectable, meaning that highest level concept can be selected without further refinement.

NOTE: Being Abstract or Specializable is not a property of Value Set itself, but is an indication that for any specified context, the Value Set should be referenced as either Abstract or Specializable. --66.18.217.179 23:13, 13 April 2007 (PDT)Question: If Abstract or Specializable isn't a characteristic of the value-set, and it's not declarable as part of the binding, how is it established? Fundamentally, I think this IS a construct of the value-set definition. Two value-sets defined by referencing the same concept and all specializations, one defined as abstract and the other as specializable would be two distinct value-set definitions

Figure 2 Value Sets

X-Domain (X-Value Set) [Deprecated]

“X-Domain” is a misnomer. A more proper name would be “X-Value Sets”, since they are really HL7 defined value sets or sub Value Sets. X-Domains came into existence to address a muddling between the Code System hierarchy and Value Sets. Earlier versions of the vocabulary maintenance tools didn’t distinguish between a Value Set that referenced concepts X, Y and Z and a concept code with subtypes X, Y and Z. The prefix “X-” was added to Value Sets that were intended to represent simple collections, not conceptual hierarchies. A rule was established that new concept codes couldn’t be introduced within an “X-” domain. They first had to be entered elsewhere in the coding scheme hierarchy and then added separately to the “X-” domain. As time permits, all X-Domains will be replaced by Value Sets. --66.18.217.179 23:13, 13 April 2007 (PDT)Comment: Guidance is required on names. At the moment, we continue to use the lower-case x prefix when creating value-sets for structural code systems

Value Set Binding in Implementation Guides

Assumptions

1. All value sets shall be defined in the HL7 value set database and/or a realm specific value set database that conforms to the HL7 value set design and structure. Value set definitions created by realm affiliates will be kept in the HL7 value set database. Value sets are not defined directly in an implementation guide, they are identified in the implementation guide by reference to the definition of the value set that exists in a value set database.

2. The person or organization that creates and adds the value set to the HL7 value set database shall be responsible for insuring that the content of the value set is maintained.

3. An OID shall be assigned to every value set. OIDs for value sets in the HL7 owned Realms (Universal, Example, and Representative) should be registered in the HL7 OID registry. A value set can optionally be assigned a name. If a value set is maintained in the HL7 value set database and has a name, the name shall be globally unique within the value set namespace, and the name shall be chosen in such a manner as to be descriptive in a globally unique namespace. The value set name shall be different from the name of the Vocabulary Domain. (E.g. “Human Language” would not be an appropriate value-set name, while “USRecognizedIsoHumanLanguages1993” would be an appropriately descriptive name. Value set OIDs and names are unchanging (static) over time.

4. An implementation guide shall identify a value set by reference to its OID. The globally unique name can be included for readability.

5. The creators of an implementation guide may make local names for value sets. If the implementation guide uses local names for value sets, then the implementation guide shall include a table that shows the cross reference from the local name to the OID. Where possible, the globally unique name of the value set from the HL7 value set database will be used as the local name. Local names for the value sets must be unique only within the implementation guide.

6. The implementation guide may contain a copy of the value set definition to facilitate easy review and balloting. The value set definition could be the expression for an intensionally defined value set, or all or part of an enumerated value set. The definition included in the implementation guide is a copy for documentation purposes only, and is not the source of truth for the definition of the value set.

7. For purposes of this discussion, if any part of a value set is intensionally defined, the whole value set is considered to be intensional.

8. A new value set shall be created when the construction policy or versioning policy needs to be different. If, for a similar set of codes, one group needs an enumerated value set and another group needs an intensionally defined value set, two value sets shall be created. The two needs cannot be met by a single value set. This situation might occur if one group wants to control orderable drugs by creating their own formulary list, and a different group wants drugs to be orderable as soon as they become part of a nationally maintained database. These divergent needs can only be met by defining two separate value sets, even though both value sets would contain codes for orderable drugs.

9. Traceability of value set contents over time means that one can determine for a given coded attribute or data type property in a message the exact set of codes that constituted the value set at the time the data was created. Traceability can only be accomplished if, for each coded attribute in the data, the effective date of the value set that was used in data creation is known. (Note: There is currently no field in current message or coded data type specifications to allow communication of the identity and version of the value set in messages. The requirement for traceability needs to be discussed further and the use case for traceability confirmed with the membership of HL7. We may want to add the value set and value set effective date as optional elements of coded data types.)

10. In situations where old and new data are sent using the same message definition and the value set bindings are different in the different eras, the terminology server will use the creation date of the data as one of the parameters for selecting the correct value set for a given message. (Note: There is currently no field in current messages that requires the communication of data creation date in messages. In most cases, Act.author.time would work as a valid surrogate for data creation date.)

11. A degenerate case of Model Constrained static binding exists where there is a need for binding a particular coded attribute to a specific single code. Rather than creating a value set consisting of a single code value, and developing all the supporting administrative machinery, this binding may be accomplished as Single-code binding, which is Model Constrained static binding to a specific code drawn from a specific code system, with optional inclusion of the version date.

12. There are many kinds of static models that can or will exist in the future, including R-MIMs, CMETs, templates and profiles. All of these models may include binding to concept domains and/or value sets. A given attribute value must conform to all of the value set bindings expressed in all static models or to run time bindings that are applicable for that instance of data. Note that it is possible that different translations present within the attribute may be used to satisfy the binding expectations of different static models.

Binding Strategies and Syntax

Strategy for Model Constrained Dynamic Binding of Value sets

This method is used when dynamically binding a value set to a coded attribute or data type property in a static model at design time. Model Constrained dynamic binding for both extensionally and intensionally defined value sets (native or imported) is accomplished by referencing the OID or the name (or both) of the value set in the binding statement.

Strategy for Model Constrained Static Binding of Value Sets

This method is used when statically binding a value set to a coded attribute or data type property in a static model at design time. Model Constrained static binding for both extensionally and intensionally defined value sets (native or imported) is accomplished by referencing the value set OID or name (or both) and the effective date of the value set in the binding statement.

Strategy for Model Constrained Static Binding to a Single Code

This method is used when statically binding a single code to a coded attribute or data type property in a static model at design time. The binding is accomplished by stating the code, the code system OID or name (or both) and optionally the effective date of the code system version. --66.18.217.179 23:13, 13 April 2007 (PDT)Question:What's the point of referencing the code system version. When you reference a code, you reference the code independent of version. In an instance, there's no guarantee you'll ever know the version. The semantics of a code are not allowed to change from version to version

Strategy for Situation Constrained Binding to a Single Code

This method is used when a concept domain is bound to a coded attribute or data type property in a static model and the reference is to be resolved to a single code in a code set by a terminology server at runtime. The following elements must be known in order for the terminology server to resolve the domain name to a specific coded value:

• The identity of the static model
• The unique identity of the coded attribute or data type property in the static model (ClassName.attributeName[.datatypePropertyName]+)
• The concept domain that is bound to the coded attribute or data type property

--66.18.217.179 23:13, 13 April 2007 (PDT)Question:What's the point of repeating the concept domain? It's not needed to achieve the binding, and could be FAR broader than the code you're constraining to.

• The binding-realm within which the data exchange is to occur
• The code, the code system OID or name (or both) and optionally the effective date of the code system version

--66.18.217.179 23:13, 13 April 2007 (PDT)Question: As above

Strategy for Situation Constrained Binding of Value Sets

This method is used when a concept domain is bound to a coded attribute or data type property in a static model and the reference is to be resolved to a dynamic value set by a terminology server at runtime. The following elements must be known in order for the terminology server to resolve the domain name to a specific value set:

The identity of the static model The unique identity of the coded attribute or data type property in the static model (ClassName.attributeName[.datatypePropertyName]+) The concept domain that is bound to the coded attribute or data type property --66.18.217.179 23:13, 13 April 2007 (PDT)Question: as above The binding-realm within which the data exchange is to occur The OID or name (or both) of the value set

The first three properties are part of the model binding statement for the model. The last two properties are part of the Situation Constrained statement contained in the terminology server. The Binding-Realm is passed in a message instance wrapper (RealmCode); the concept domain, the realm, and the value set must be available to the terminology server, and may be included in an implementation guide. --66.18.217.179 23:13, 13 April 2007 (PDT)RealmCode may be asserted at more than just the root wrapper. There are use-cases where a single message instance will contain content drawn from multiple binding-realms. At the moment, it can be asserted for any class, though MnM has discussed restricting its assertion to model boundaries only (e.g. start of a payload wrapper or CMET).

Strategy for Situation Constrained Binding of Value Sets

This method is used when a concept domain is bound to a coded attribute or data type property in a static model and the reference is to be resolved to a static value set by a terminology server at runtime. The following elements must be known in order for the terminology server to resolve the domain name to a specific value set:

The identity of the static model The unique identity of the coded attribute or data type property in the static model (ClassName.attributeName[.datatypePropertyName]+) The concept domain that is bound to the coded attribute or data type property --66.18.217.179 23:13, 13 April 2007 (PDT)Question: as above The binding-realm within which the data exchange is to occur The OID or name (or both) of the value set The effective date of the value set

The first three properties are part of the model binding statement for the model. The last three properties are part of the Situation Constrained statement. The Binding-Realm is passed in a message instance wrapper (RealmCode); the concept domain, the realm, the value set, and the effective date must be available to the terminology server, and may be included in an implementation guide Syntax for Model Constrained Binding of Value Sets to Attributes in Static Models General description of the syntax and reserved words

The key words "SHALL", "SHOULD", and “MAY” in this syntax are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide. Furthermore,

SHALL equates to CNE as defined in other HL7 documents SHOULD equates to CWE as defined in other HL7 documents

The keywords "DYNAMIC" and "STATIC" shall be interpreted as defined above. For CDA, pathName is a standard XPath statement. The name of the immediate containing structure is assumed to be known and is not explicitly stated in the pathName.

For V3 messaging, pathname should be a fully qualified reference to an attribute in the static model. [Note: We need a standard syntax for making a fully qualified pathName.] --66.18.217.179 23:13, 13 April 2007 (PDT) Suggest (ClassName.attributeName[.datatypePropertyName]+) :> Narrative Syntax for Model Constrained dynamic binding:

The value for (“pathName of coded element”) (SHALL | SHOULD) be selected from ValueSet ([valueSetOID] | [valueSetName] [OR ([valueSetOID] | [valueSetName]]) DYNAMIC

ValueSetOID or valueSetName must be present. No value set name can be named “DYNAMIC” or “OR”.

If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.

Examples of Model Constrained dynamic binding:

The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode DYNAMIC.

Or

The value for “ClinicalDocument/code” SHOULD be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode OR ValueSet 1.2.34.1.26 SnomedCtDocumentTypeCode DYNAMIC.

Or

The value for “ClinicalDocument/code” SHOULD be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode DYNAMIC.

Or

The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 DYNAMIC.

Or

The value for “ClinicalDocument/code” SHOULD be selected from ValueSet LoincDocumentTypeCode DYNAMIC.

Table form for Model Constrained dynamic binding

ELEMENT IDENTIFICATION	STRENGTH	VALUE SET OID	VALUESETNAME	FLEXIBILITY
CLINICALDOCUMENT/CODE	SHALL	2.16.840.1.113883.11.217892	LOINCDOCUMENTTYPECODE	DYNAMIC
CLINICALDOCUMENT/CODE	SHALL	2.16.840.1.113883.11.XXXXX	SNOMEDCTDOCUMENTTYPE CODE	DYNAMIC
CLINICALDOCUMENT/CODE	SHOULD	2.16.840.1.113883.11.217892	LOINCDOCUMENTTYPECODE	DYNAMIC
CLINICALDOCUMENT/CODE	SHALL	2.16.840.1.113883.11.217892		DYNAMIC
CLINICALDOCUMENT/CODE	SHOULD		LOINCDOCUMENTTYPECODE	DYNAMIC

'Narrative Syntax for Model Constrained static binding:'

The value for (“pathName of coded element”) (SHALL | SHOULD) be selected from ValueSet ([valueSetOID] | [valueSetName] [OR ([valueSetOID] | [valueSetName]]) STATIC (valueSetEffectiveDate)

ValueSetOID or valueSetName must be present. No value set name can be named “STATIC” or “OR”.

If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.

ValueSetEffectiveDate will be specified with the literal syntax for the XML ITS of the HL7 Version 3 Point in Time (TS) data type.

Examples of Model Constrained static binding:

The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode STATIC 20061017.

Or

The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode OR ValueSet 1.2.34.1.26 SnomedCtDocumentTypeCode STATIC 20061017.

Or

The value for “ClinicalDocument/code” SHOULD be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode STATIC 20061017.

Or

The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 STATIC 20061017.

Or

The value for “ClinicalDocument/code” SHOULD be selected from ValueSet LoincDocumentTypeCode STATIC 20061017.

Table form for Model Constrained static binding

Path	Strength	Value Set OID	Name	Flexibility	Effective Date
ClinicalDocument/code	shall	2.16.840.1.113883.11.217892	LoincDocumentTypeCode	static	20061017
ClinicalDocument/code	shall	2.16.840.1.113883.11.XXXXX	SnomedCtDocumentTypeCode	static	20061017
ClinicalDocument/code	should	2.16.840.1.113883.11.217892	LoincDocumentTypeCode	static	20061017
ClinicalDocument/code	shall	2.16.840.1.113883.11.217892		static	20061017
ClinicalDocument/code	should	1.2.34.1.25	LoincDocumentTypeCode	static	20061017

'Narrative Syntax for Single-code binding (Model Constrained static binding to one exact code) '

The value for (“pathName of coded element”) SHALL be (code [“displayName”] codeSystemOID [codeSystemName] STATIC [effective date]

The effective date SHALL be specified when it is necessary for distinguishing the proper meaning of the code.

No code system name can be “STATIC”.

Example for design-time static binding to one exact code

The value for “ClinicalDocument/code” SHALL be 42134-7 “DischargeSummary” 2.16.840.1.113883.6.1 LOINC STATIC 20061017.

Table form for design-time static binding to one exact code

Path	Strength	code	codeSystemOID	codeSystemName	Flexibility	Effective Date
ClinicalDocument/code	shall	42134-7	2.16.840.1.113883.6.1	LOINC	static	20061017

Syntax for Situation Constrained Binding of Value Sets to Concept Domains in Static Models

'General description of the syntax and reserved words'

Situation constrained binding involves splitting the binding operation into a step that is done at design time, and a step that is done later, at message instance generation time. At design time, a coded attribute or datatype property is bound to a concept domain. There is no flexibility to this binding, but subdomains may be created and attributes bound accordingly as the design is further constrained as described in the V3 Vocabulary Conformance section of the HL7 V3 Standard. At the time of message instance generation, all coded attributes or datatype properties are either design time bound to value sets, or runtime bound to an explicit concept domain.

Part of the implementation statement for a particular model will describe the Realm-specific binding of a concept domain to a value set, in much the same way that a coded attribute is bound to a value set in design-time binding. Therefore, in the situation constrained binding syntax there are two statements: the first is the binding of a code attribute or datatype property to a concept domain, and the second is the binding of the concept domain to a value set. The statements must be separate as they are defined at different times and generally by different stakeholders.

The key words "SHALL", "SHOULD", and “MAY” in this syntax are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide. Furthermore

SHALL equates to CNE as defined in other HL7 documents SHOULD equates to CWE as defined in other HL7 documents

The keywords "DYNAMIC" and "STATIC" shall be interpreted as defined above.

'Narrative Syntax for concept domain runtime dynamic binding:'

The VocabularyDomain for (“pathName of coded element”) (SHALL ) be (DomainName) The ValueSet for (DomainName) in (RealmName) (SHALL | SHOULD) be ([valueSetOID] | [valueSetName] | [OR ([valueSetOID] | [valueSetName]]) DYNAMIC.

If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.

Example for concept domain binding:

The ConceptDomain for “DocumentType/code” SHALL be MyDocumentType The ValueSet for MyDocumentType in NorthAmerica SHALL be 2.16.840.1.113883.11.217892 LoincDocumentTypeCode DYNAMIC.

Or

The ConceptDomain for “DocumentType/code” SHALL be MyDocumentType The ValueSet for MyDocumentType in NorthAmerica SHALL be 2.16.840.1.113883.11.217892 LoincDocumentTypeCode Or 2.16.840.1.113883.11.XXXXX SnomedCtDocumentTypeCode DYNAMIC.

Table representation of runtime dynamic binding information in the terminology server:

Model	Path	Domain	Realm	Value Set OID	ValueSetName	Flexibility
TPLTCD3	DocumentType/code	MyDocumentType	NorthAmerica	2.16.840.1.113883.11.217892	LoincDocumentTypeCode	Dynamic

Note that the leftmost three columns are the design-time binding elements, and the rightmost five columns are the situation constrained binding elements (the concept domain is the common element)

'Narrative Syntax for concept domain runtime static binding:'

The VocabularyDomain for (“pathName of coded element”) (SHALL) be (DomainName) The ValueSet for (DomainName) in (RealmName) (SHALL | SHOULD) be ([valueSetOID] | [valueSetName] | [OR ([valueSetOID] | [valueSetName]]) STATIC (valueSetEffectiveDate).

If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.

Example for concept domain dynamic binding:

The VocabularyDomain for “DocumentType/code” SHALL be MyDocumentType. The value set for MyDocumentType in NorthAmerica is 2.16.840.1.113883.11.217892 LoincDocumentTypeCode STATIC 20061017

Or

The VocabularyDomain for “DocumentType/code” SHALL be MyDocumentType. The value set for MyDocumentType in NorthAmerica is 2.16.840.1.113883.11.217892 LoincDocumentTypeCode OR 2.16.840.1.113883.11.XXXXX SnomedCtDocumentTypeCode STATIC 20061017

Table representation of runtime static binding information in the terminology server:

Model	Path	Domain	Realm	Value Set OID	ValueSetName	Effective Date || Flexibility
TPLTCD3	DocumentType/code	MyDocumentType	US	2.16.840.1.113883.11.217892	LoincDocumentTypeCode	20061017	Static

Note that the leftmost three columns are the design-time binding elements, and the rightmost six columns are the situation constrained binding elements (the concept domain is the common element).

Other items to be covered:

• coding strength

   :  should the section on Domains be here rather that up in the vocabulary section?  --Tklein 18:21, 23 February 2008 (CST)

todo

from dt ballot: Explain to people how to avoid having non-null empty bags when desired. (same for list and set)