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
 
(142 intermediate revisions by 6 users not shown)
Line 1: Line 1:
= Core Properties of V3 Models =
+
= 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.
  
= Preface =
+
The Ballot content [http://www.hl7.org/v3ballot/html/infrastructure/coreprinciples/v3modelcoreprinciples.html may be available here].
  
== Notes to Readers ==
+
[[User:Gwbeeler|GWBeeler]] 14:58, 4 April 2011 (UTC)
 
 
This is the first release of this document. It is intended to
 
provide important background information for implementors
 
trying to implement V3 Static Models, whether they are found
 
in Messages, Documents, or Service Payloads.
 
 
 
== Acknowledgements ==
 
 
 
Authors:
 
* George W Beeler
 
* Grahame Grieve
 
 
 
= 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
 
 
 
= comments about constraints =
 
 
 
== Refinement, Constraint, and Localization ==
 
== Templates ==
 
 
 
Comments about classes, associations, attributes, datatypes and controlled vocabularies
 
 
 
= Key Concepts =
 
 
 
== Null Flavor ==
 
 
 
== Cardinality & Optionality ==
 
 
 
== Conformance ==
 
 
 
=== Testing Considerations ===
 
 
 
== Vocabulary Conformance ==
 
* binding
 
**  formerly known as "runtime"
 
** formerly known as design time
 
* domains
 
* value sets
 
* coding strength
 
 
 
== Type Representation ==
 
 
 
**typing (typeId & flavorId & templates)
 
 
 
== 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 static model design specifically allows
 
update mode.
 
 
 
== 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.
 
 
 
== Referencing Acts ==
 
 
 
== Update Mode ==
 
 
 
 
 
=== UpdateMode Methodology ===
 
 
 
The Update Mode values are:
 
 
 
{| class="wikitable"
 
|-
 
! Code
 
! Name
 
! Description
 
|-
 
| A
 
| Add
 
| The item was (or is to be) added, having not been present immediately before.
 
|-
 
| D
 
| Delete
 
| The item was (or is to be) removed (sometimes referred to as deleted)
 
|-
 
| R
 
| Replace
 
| The item existed previously and has (or is to be) revised.
 
|-
 
| AR
 
| Add or Replace
 
| The item was (or is to be) either added or replaced. (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’s not specified whether the item was (or is to be) added, revised, or not changed.
 
 
 
|}
 
 
 
The meaning of UpdateMode depends on the circumstances in which it is used:
 
 
 
# 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), UpdateMode 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), UpdateMode 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 UpdateMode 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.
 
# When an Replace or Add or Replace update mode is used on a set the receiver may have no way of knowing what the original set of data being replaced was. It is up to the receiver to determine whether they want to replace their existing set of data, add to their set of data, etc. If the sender wishes to be explicit, they should send discrete add and remove repetitions.
 
 
 
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.)
 
 
 
=== Message Designer Guidance ===
 
 
 
This section is intended for people designing message, typically HL7 domain committees.
 
 
 
When designing a model, a committee may allow UpdateMode to be used on attributes and associations identified by the committee1 To enable UpdateMode, the committee must select the set of permitted Update Modes.
 
 
 
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.
 
 
 
Update mode 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.
 
 
 
When the upper cardinality of an attribute or an association using UpdateMode is greater than 1, the Update Modes are categorized into ‘set’ Update Modes and ‘item’ Update Modes. ‘Item’ Update Modes may be applied to any item within the collection. ‘Set’ Update Modes only apply to the set as a whole.
 
 
 
The following table specifies the allowable Update Modes in message specifications for each of these three cases.
 
 
 
{| class="wikitable"
 
|-
 
! Update Mode Value
 
! Upper cardinality of 1
 
! ’Set’ Update Modes
 
! ‘Item’ Update Modes
 
|-
 
| Add
 
| Y  
 
|
 
| Y
 
|-
 
| Remove
 
| Y  
 
|
 
| Y
 
|-
 
| Replace
 
| Y
 
| Y
 
|-
 
| Add or Replace
 
| Y  
 
|
 
| Y
 
|-
 
| No change
 
| Y  
 
|
 
| Y
 
|-
 
| Unknown
 
| Y  
 
|
 
| Y
 
|}
 
 
 
When the UpdateMode of ‘Remove’ is specified for an attribute, the ‘key’ of the attribute that was deleted or is to be deleted is the value of the attribute . 2 When it is specified for an association, the association must point to an element with a populated id attribute, (or in circumstances where the association is to an ‘arrow’ class, the target of the arrow must have a populated id attribute. The id (potentially combined with the typeCode of the ‘arrow’ class) determines the identity of the item to be deleted. If a committee finds a use-case for using update modes for an association without an identifier attribute, they should contact the Modeling and Methodology Technical Committee.
 
 
 
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.
 
 
 
=== UpdateMode Usage Guidelines ===
 
 
 
# 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.
 
 
 
 
 
*doco
 
**use cases
 
**data types
 
**classes
 
 
 
=introduction to how RIM & datatypes fit together=
 

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)