This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Core Properties of V3 Models"

From HL7Wiki
Jump to navigation Jump to search
Line 490: Line 490:
defined in Update Control, Referencing Objects, and Identifying Objects.  
defined in Update Control, Referencing Objects, and Identifying Objects.  
Note: a more appropriate name might be useCode, but the property name
'''Note''': a more appropriate name might be useCode, but the property name
is updateMode for backwards compatibility reasons.
is updateMode for backwards compatibility reasons.
Note: The updateMode property actually applies to associations and attributes,
'''Note''': The updateMode property actually applies to associations and attributes,
not to classes and datatypes, though it is formally defined on the types.
not to classes and datatypes, though it is formally defined on the types.
The value of the updateMode property identifies how the attribute or  
The value of the updateMode property identifies how the attribute or  

Revision as of 05:44, 22 February 2008


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.



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

V3 Static Models: Overview and Principles

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


Coded attributes

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

Key Concepts

Types of HL7 V3 Models


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

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.


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


  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.


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


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

Global Uniqueness

In particular, it is important that all identifiers are 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.

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:

oid table

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


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


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