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
 
(99 intermediate revisions by 5 users not shown)
Line 1: Line 1:
= Preface =
+
= Posting on Wiki WITHDRAWN in Its Entirety =
 +
This document was originally posted for dicussion prior to the first release of the COre Principles document.  Subsequently, this document has gone through four (soon to be five) ballots.  The content on this Wiki page has been entirely superseded and has, therefore been removed.
  
== Notes to Readers ==
+
The Ballot content [http://www.hl7.org/v3ballot/html/infrastructure/coreprinciples/v3modelcoreprinciples.html may be available here].
  
This is the first release of this document. It is intended to
+
[[User:Gwbeeler|GWBeeler]] 14:58, 4 April 2011 (UTC)
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.
 
 
 
= 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
 
 
 
== 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 ==
 
 
 
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
 
 
 
== OID Procedures ==
 
 
 
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.
 
 
 
 
 
=== 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.
 
 
 
= Key Concepts =
 
 
 
== 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
 
 
 
=== 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.
 
 
 
==== 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:
 
 
 
# 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.--[[User:GrahameGrieve|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:
 
 
 
{| class="wikitable"
 
|-
 
! 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:
 
 
 
# 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.
 
 
 
Notes:
 
 
 
# 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.
 
 
 
== 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.
 
 
 
= 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
 

Latest revision as of 15:00, 4 April 2011

Posting on Wiki WITHDRAWN in Its Entirety

This document was originally posted for dicussion prior to the first release of the COre Principles document. Subsequently, this document has gone through four (soon to be five) ballots. The content on this Wiki page has been entirely superseded and has, therefore been removed.

The Ballot content may be available here.

GWBeeler 14:58, 4 April 2011 (UTC)