This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Core Properties of V3 Models"

From HL7Wiki
Jump to navigation Jump to search
Line 21: Line 21:
 
* the need for a Specification.
 
* the need for a Specification.
  
= V3 Static Models: Overview and Principles=
 
  
All V3 Static Models are comprised of [[#RIM]] classes linked by associations.
+
= Types of HL7 V3 Models =
The classes have attributes which are assigned [[#datatypes]]. Some attributes
 
are associated with controlled [[#vocabularies]] which provide clearly defined
 
semantic meaning to the static models.
 
 
 
models vs instances, classes vs objects
 
 
 
== RIM ==
 
 
 
The [[RIM]] defines all the classes that are used in static models. The classes
 
are standard classes in the UML sense, and have associations and attributes
 
as defined in the RIM models.
 
  
== Datatypes ==
+
== Instances ==
 
 
The datatypes define the types that may be used for the attributes
 
of the RIM classes. The semantics of the types are defined in the 
 
[[abstract datatypes]], while the [[ITS datatypes] define an XML
 
implementation of the datatypes
 
 
 
== Vocabulary ==
 
 
 
Coded attributes
 
  Properties
 
  Binding to concept domains and value sets
 
  Concept domains
 
  Value sets
 
  Code systems
 
 
 
= Key Concepts =
 
 
 
== Types of HL7 V3 Models ==
 
 
 
=== Instances ===
 
  
 
The fundamental notion of V3 is that in order to exchange data,
 
The fundamental notion of V3 is that in order to exchange data,
Line 73: Line 41:
 
:: more about serialisation
 
:: more about serialisation
  
=== RIM: Reference Information Model ===
+
All V3 Static Models are comprised of [[#RIM]] classes linked by associations.
 +
The classes have attributes which are assigned [[#datatypes]]. Some attributes
 +
are associated with controlled [[#vocabularies]] which provide clearly defined
 +
semantic meaning to the static models.
 +
 
 +
models vs instances, classes vs objects
 +
 
 +
The [[RIM]] defines all the classes that are used in static models. The classes
 +
are standard classes in the UML sense, and have associations and attributes
 +
as defined in the RIM models.
 +
 
 +
The datatypes define the types that may be used for the attributes
 +
of the RIM classes. The semantics of the types are defined in the 
 +
[[abstract datatypes]], while the [[ITS datatypes] define an XML
 +
implementation of the datatypes
 +
 
 +
== RIM: Reference Information Model ==
  
 
All v3 instances are valid instances against the v3 reference model,
 
All v3 instances are valid instances against the v3 reference model,
Line 84: Line 68:
 
All instances must be valid against the RIM.
 
All instances must be valid against the RIM.
  
All other models are constraints against the RIM, and may be viewed as  
+
All other models are constraints against the RIM, and may be viewed as
either a constraining model or as a typing model. The difference in  
+
either a constraining model or as a typing model. The difference in
 
these two is largely an implementation issue; the semantics are always
 
these two is largely an implementation issue; the semantics are always
 
clear: all instances are instances of the reference model, and all other
 
clear: all instances are instances of the reference model, and all other
Line 95: Line 79:
 
expression have been imagined and proposed or are under development.
 
expression have been imagined and proposed or are under development.
  
=== DIM : Domain Information Model ===
+
== DIM : Domain Information Model ==
  
The first level of constraint is a domain information model. This  
+
The first level of constraint is a domain information model. This
provides a solution to the information requirements of a particular  
+
provides a solution to the information requirements of a particular
problem domain. A DIM may have multiple entry points. As such, a  
+
problem domain. A DIM may have multiple entry points. As such, a
 
DIM is not a directly implementable model, and is a fairly general
 
DIM is not a directly implementable model, and is a fairly general
 
statement of an domain with fairly general vocabulary bindings.
 
statement of an domain with fairly general vocabulary bindings.
  
DIMs may be derived directly from the RIM or from other DIMs (such as  
+
DIMs may be derived directly from the RIM or from other DIMs (such as
 
the clinical statement pattern).
 
the clinical statement pattern).
  
=== CIM : Constrained Information Model ===
+
== CIM : Constrained Information Model ==
  
CIMs represent a second level of constraint. CIMs must have single  
+
CIMs represent a second level of constraint. CIMs must have single
entry points, which makes them serialisable. CIMs are therefore  
+
entry points, which makes them serialisable. CIMs are therefore
 
suitable for use as implementation constructs on information
 
suitable for use as implementation constructs on information
 
systems and should be completely specified for this purpose.
 
systems and should be completely specified for this purpose.
Line 115: Line 99:
  
 
CIMs are either derived from a DIM directly, or from another CIM.
 
CIMs are either derived from a DIM directly, or from another CIM.
Though technically, a CIM could also be derived from the RIM  
+
Though technically, a CIM could also be derived from the RIM
directly, this is prohibited as a matter of policy to encourage  
+
directly, this is prohibited as a matter of policy to encourage
 
consistent design.
 
consistent design.
  
Line 124: Line 108:
 
Only HL7 or it's affiliates may define and publish CIMs.
 
Only HL7 or it's affiliates may define and publish CIMs.
  
=== LIM : Local Information Model ===
+
== LIM : Local Information Model ==
  
 
Like CIMs, LIMs are a constraint model that has a single entry point.
 
Like CIMs, LIMs are a constraint model that has a single entry point.
Line 135: Line 119:
 
by site or realm agreement.
 
by site or realm agreement.
  
== Type Representation ==
+
= Type Representation =
  
All HL7 models are constraints on a reference model built from  
+
All HL7 models are constraints on a reference model built from
the classes defined in the RIM and the datatypes defined in the  
+
the classes defined in the RIM and the datatypes defined in the
abstract datatypes.  
+
abstract datatypes.
  
This reference model is further constrained by additional  
+
This reference model is further constrained by additional
 
constraint models that associate new names for particular
 
constraint models that associate new names for particular
 
constraints on the associations and classes. These constraint
 
constraints on the associations and classes. These constraint
 
models may come from a linear sequence of constraints where
 
models may come from a linear sequence of constraints where
 
each model is an additional constraint on another model (and
 
each model is an additional constraint on another model (and
when the instance conforms to a model it also conforms to the  
+
when the instance conforms to a model it also conforms to the
 
models on which that model is derived), or an instance may
 
models on which that model is derived), or an instance may
 
conform to multiple different constraints that are not related
 
conform to multiple different constraints that are not related
Line 153: Line 137:
 
So any given type is an instance of the class or datatype
 
So any given type is an instance of the class or datatype
 
as specified in the reference model, while at the same time
 
as specified in the reference model, while at the same time
conforming to multiple other different design specifications  
+
conforming to multiple other different design specifications
within this cascading hierarchy of models.  
+
within this cascading hierarchy of models.
  
All classes and datatypes SHALL declare conformance to a single  
+
All classes and datatypes SHALL declare conformance to a single
master type. This requirement exists to ease the path  
+
master type. This requirement exists to ease the path
 
of implementations in common target technologies. The
 
of implementations in common target technologies. The
type as a duple: the name of the model, and the name of 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  
+
type/constraint definition in the model. Both the name of
the model and the name of the type may be defined by some  
+
the model and the name of the type may be defined by some
applicable design contract rather than expressed directly  
+
applicable design contract rather than expressed directly
as an attribute of the class.  
+
as an attribute of the class.
  
 
ITSs that describe how to represent V3 models SHALL make clear
 
ITSs that describe how to represent V3 models SHALL make clear
Line 173: Line 157:
 
'''Note''': The InfrastructureRoot class in the RIM defines
 
'''Note''': The InfrastructureRoot class in the RIM defines
 
the notional attribute typeId to represent the type of the
 
the notional attribute typeId to represent the type of the
class. ITSs are not required to represent this attribute  
+
class. ITSs are not required to represent this attribute
 
directly; some other method of representation may be chosen
 
directly; some other method of representation may be chosen
that is more appropriate with the base technology and consistent  
+
that is more appropriate with the base technology and consistent
with the way the ITS specifies that the type information is  
+
with the way the ITS specifies that the type information is
 
determined from the instance.
 
determined from the instance.
  
For classes, the type need not be the type from a reference model;  
+
For classes, the type need not be the type from a reference model;
the context may specify that the expressed type is a name  
+
the context may specify that the expressed type is a name
taken from one of the applicable constraining model. As a consequence,  
+
taken from one of the applicable constraining model. As a consequence,
 
there are three types of models applicable to classes:
 
there are three types of models applicable to classes:
  
====  Expressed Models ====
+
===  Expressed Models ===
  
 
The expressed model is the model that contains the type expressed
 
The expressed model is the model that contains the type expressed
by the class.  
+
by the class.
  
'''Note''': The existing XML ITS fixes the expressed model throughout the  
+
'''Note''': The existing XML ITS fixes the expressed model throughout the
 
instance to be the static model associated with the interaction identifier
 
instance to be the static model associated with the interaction identifier
 
specified in the root element of the interaction (or from "ClinicalDocument"
 
specified in the root element of the interaction (or from "ClinicalDocument"
for CDA). The type of a class is not usually represented directly; instead  
+
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  
+
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  
+
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.
 
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  
+
'''Note''': Only complete, implementable models with one entry point (CIMs and some LIMs) may be
 
used as expressed models.
 
used as expressed models.
  
==== Implied Models ====
+
=== Implied Models ===
  
 
The implied models are specified by the derivations contained in the definition of  
 
The implied models are specified by the derivations contained in the definition of  
Line 216: Line 200:
 
the RIM classes in the instance exists, using structural codes.
 
the RIM classes in the instance exists, using structural codes.
  
==== Applied Models ====
+
=== Applied Models ===
  
 
Are other models to which the class conforms to but are not explicit or implicit
 
Are other models to which the class conforms to but are not explicit or implicit
Line 240: Line 224:
 
template related information.
 
template related information.
  
=== Datatype Flavors ===
+
== Datatype Flavors ==
  
 
For datatypes, the type must be the type from the reference model; the expressed  
 
For datatypes, the type must be the type from the reference model; the expressed  
Line 253: Line 237:
 
consulted for further information about datatypes flavors.
 
consulted for further information about datatypes flavors.
  
== Null Flavor ==
+
= Null Flavor =
  
 
It is common to encounter missing or incomplete information in healthcare. In some
 
It is common to encounter missing or incomplete information in healthcare. In some
Line 288: Line 272:
 
declares that it does not conform. See the conformance section for further details.
 
declares that it does not conform. See the conformance section for further details.
  
=== Note about the name nullFlavor ===
+
== Note about the name nullFlavor ==
  
 
The property is named nullFlavor because of the similarities between the concept  
 
The property is named nullFlavor because of the similarities between the concept  
Line 317: Line 301:
 
related to nullFlavor will also have nullFlavor NI.  
 
related to nullFlavor will also have nullFlavor NI.  
  
=== Implementation Considerations ===
+
== Implementation Considerations ==
  
 
When performing operations upon null values, the semantic meaning of the nullFlavor  
 
When performing operations upon null values, the semantic meaning of the nullFlavor  
Line 354: Line 338:
 
of the datatypes).
 
of the datatypes).
  
== Update control ==
+
= Update control =
  
 
HL7 Static models are used to represent information about  
 
HL7 Static models are used to represent information about  
Line 410: Line 394:
 
:: this seems like crap to me. I cannot think that it's reasonable to even think of the concept of "removal of the name for the purposes of the encounter". Either we allow the operation or ban the concept.--[[User:GrahameGrieve|GrahameGrieve]] 21:06, 28 January 2008 (CST)
 
:: this seems like crap to me. I cannot think that it's reasonable to even think of the concept of "removal of the name for the purposes of the encounter". Either we allow the operation or ban the concept.--[[User:GrahameGrieve|GrahameGrieve]] 21:06, 28 January 2008 (CST)
  
== Referencing Objects ==
+
= Referencing Objects =
  
 
When the destination system is well known and there is an implicit or explicit  
 
When the destination system is well known and there is an implicit or explicit  
Line 436: Line 420:
 
associated update instructions SHALL be ignored.
 
associated update instructions SHALL be ignored.
  
== Identifying Objects ==
+
= Identifying Objects =
  
 
Whether an object is being conveyed using snapshot mode, update mode,  
 
Whether an object is being conveyed using snapshot mode, update mode,  
Line 485: Line 469:
 
destination system.
 
destination system.
  
== Update Mode ==
+
= Update Mode =
  
 
HL7 provides a single property called updateMode to support the concepts
 
HL7 provides a single property called updateMode to support the concepts
Line 555: Line 539:
 
# If an item is deleted from a collection, all matching items should be deleted from the collection
 
# If an item is deleted from a collection, all matching items should be deleted from the collection
  
=== Model Designer Guidance ===
+
== Model Designer Guidance ==
  
 
This section is intended for people designing static models, typically HL7 domain committees.
 
This section is intended for people designing static models, typically HL7 domain committees.
Line 584: Line 568:
 
# Classes that do not carry an id attribute cannot be identified at all.
 
# Classes that do not carry an id attribute cannot be identified at all.
  
== Accountability ==
+
= Accountability =
  
 
In addition to using update Mode to describe the changes  
 
In addition to using update Mode to describe the changes  
Line 615: Line 599:
 
Committees must explicitly enable exposing the Accountability History link for a given attribute or association.
 
Committees must explicitly enable exposing the Accountability History link for a given attribute or association.
  
== Identification ==
+
= Identification =
  
 
One of the founding principles of V3 models is the importance  
 
One of the founding principles of V3 models is the importance  
 
or properly identifying objects and concepts correctly.  
 
or properly identifying objects and concepts correctly.  
  
=== Global Uniqueness ===
+
== Global Uniqueness ==
  
 
All identifiers must be globally unique to prevent false  
 
All identifiers must be globally unique to prevent false  
Line 642: Line 626:
 
null).
 
null).
  
=== OID registry ===
+
== OID registry ==
  
 
For some concepts, it is not enough that they must be globally
 
For some concepts, it is not enough that they must be globally
Line 681: Line 665:
 
:: 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. --[[User:GrahameGrieve|GrahameGrieve]] 23:42, 21 February 2008 (CST)
 
:: 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. --[[User:GrahameGrieve|GrahameGrieve]] 23:42, 21 February 2008 (CST)
  
==== OID Conflict Resolution ====
+
=== OID Conflict Resolution ===
  
 
When assigning OIDs to third parties or entities, HL7 investigates whether an OID is  
 
When assigning OIDs to third parties or entities, HL7 investigates whether an OID is  
Line 696: Line 680:
 
to resolve this situation.  
 
to resolve this situation.  
  
=== HL7 OID branch ===
+
== HL7 OID branch ==
  
 
The HL7 root OID is 2.16.840.1.113883. All OIDs that HL7 assigns are  
 
The HL7 root OID is 2.16.840.1.113883. All OIDs that HL7 assigns are  
Line 803: Line 787:
  
 
Comments about classes, associations, attributes, datatypes and controlled vocabularies
 
Comments about classes, associations, attributes, datatypes and controlled vocabularies
 +
 +
== Vocabulary ==
 +
 +
Coded attributes
 +
  Properties
 +
  Binding to concept domains and value sets
 +
  Concept domains
 +
  Value sets
 +
  Code systems

Revision as of 06:02, 22 February 2008

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.


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.

All v3 instances conform in some defined fashion with the semantics defined in the reference model, and possibly with semantics defined in a series of other models.

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.

more about serialisation

All V3 Static Models are comprised of #RIM classes linked by associations. The classes have attributes which are assigned #datatypes. Some attributes are associated with controlled #vocabularies which provide clearly defined semantic meaning to the static models.

models vs instances, classes vs objects

The RIM defines all the classes that are used in static models. The classes are standard classes in the UML sense, and have associations and attributes as defined in the RIM models.

The datatypes define the types that may be used for the attributes of the RIM classes. The semantics of the types are defined in the abstract datatypes, while the [[ITS datatypes] define an XML implementation of the datatypes

RIM: Reference Information Model

All v3 instances are valid instances against the v3 reference model, which consists of the RIM, the datatypes, and the structural vocabulary.

The datatypes are specified in the abstract data types, and the structural vocabulary in the xxxxx. The RIM itself is a proper UML class model.

The RIM defines the core classes from which the instances are constructed. All instances must be valid against the RIM.

All other models are constraints against the RIM, and may be viewed as either a constraining model or as a typing model. 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 models are constraints on it.

All the other models are expressed using a modeling language called the HL7 Static Model, which 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.

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 may be derived directly from the RIM or from other DIMs (such as the clinical statement pattern).

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.

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.

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, it is generally best for the system that constructs the instance to put all the information that it has concerning the real world concept in the instance. This practice is known as "snapshot" - the source system sends a snapshot of the object as it knows it.

When an 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 merge all the attributes and associations of the objects.

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.

Where update mode can be used, it offers several advantages:

  • 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
  • Query responses are able to document accountability information in terms of what changes were performed (see accountability below).

On the other hand, update mode offers the opportunity for two systems to get information out of sync, so modellers and implementors should always be careful.

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

Update Control may be used for several different reasons:

  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.

As per general methodology rules, data elements are always considered to apply only in the context of their association with the focal class. Thus deleting a name from a patient associated with an encounter should only be interpreted as a removal of the name for the purposes of the encounter. It is not an instruction to update the patient record within the system’s patient registry. (To update the patient registry, a message with a focal class of patient must be used.)

this seems like crap to me. I cannot think that it's reasonable to even think of the concept of "removal of the name for the purposes of the encounter". Either we allow the operation or ban the concept.--GrahameGrieve 21:06, 28 January 2008 (CST)

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 shared 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 identification where these 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. --GrahameGrieve 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)

Cardinality & Optionality

Testing Considerations

Vocabulary Conformance

  • binding
    • formerly known as "runtime"
    • formerly known as design time
  • domains
  • value sets
  • coding strength


introduction to how RIM & datatypes fit together

todo

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


Refinement, Constraint, and Localization

Templates

Comments about classes, associations, attributes, datatypes and controlled vocabularies

Vocabulary

Coded attributes

  Properties
  Binding to concept domains and value sets
  Concept domains
  Value sets
  Code systems