Core Properties of V3 Models
- 1 Preface
- 2 Introduction and Scope
- 3 V3 Static Models: Overview and Principles
- 4 comments about constraints
- 5 Key Concepts
- 6 introduction to how RIM & datatypes fit together
- 7 todo
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
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
Properties Binding to concept domains and value sets Concept domains Value sets Code systems
HL7 shall establish an OID registry and assign OIDs in its branch for HL7 users and vendors upon their request. HL7 shall also assign 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 countries Social Security Administrations, Citizen ID registries, etc.). The HL7 registered OIDs must be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources.
When assigning OIDs to third parties or entities, HL7 shall investigate whether an OID is already assigned for such entities through other sources. It this is the case, HL7 shall record such OID in a catalog, but HL7 shall not assign a duplicate OID in the HL7 branch. If possible, HL7 shall notify a third party when an OID is being assigned for that party in the HL7 branch.
Though HL7 shall exercise diligence before assigning an OID in the HL7 branch to third parties, given the lack of a global OID registry mechanism, one cannot 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 dupplicate assignment become known to HL7, HL7 shall make efforts to resolve this situation. For continued interoperability in the meantime, the HL7 assigned OID shall be the preferred OID used.<footnote>
Where the context of use of an identifier allows multiple repetitions where additional non-preferred OIDs exist for an identifier or code, applications MAY send additional repetitions or translations which use the non-preferred OID as the root or code system provided that it also has a repetition or translation which uses the preferred OID. This approach may be used by applications that wish to communicate with a another application that requires the use of non-HL7-registered OIDs for Common identifiers or code systems.
HL7 shall assign a UID to each of its code tables as well as to external standard coding systems that are being used with HL7 and HL7 Affiliate specifications.
Under HL7's branch, 2.16.840.1.113883, the sub-branches 5 and 6 contain HL7 standard and external code system identifiers respectively. The HL7 Vocabulary Technical Committee maintains these two branches.
comments about constraints
Refinement, Constraint, and Localization
Comments about classes, associations, attributes, datatypes and controlled vocabularies
Cardinality & Optionality
- formerly known as "runtime"
- formerly known as design time
- value sets
- coding strength
- typing (typeId & flavorId & templates)
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:
- 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.
- 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.
- 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)
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.
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.
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:
|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.|
- Portions requiring harmonisation proposals in italics
- 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
- REF may only be applied to associations, not attributes.
- 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.
- 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.
- 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.
- 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.
- UpdateMode should not be enabled in Transmission or ControlAct wrappers.
- 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.
- 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.
- 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 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.
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)