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
 
(163 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.
  
 +
The Ballot content [http://www.hl7.org/v3ballot/html/infrastructure/coreprinciples/v3modelcoreprinciples.html may be available here].
  
= Preface =
+
[[User:Gwbeeler|GWBeeler]] 14:58, 4 April 2011 (UTC)
 
 
== Notes to Readers ==
 
 
 
This is the first release of this document. It is intended to
 
provide important background information for implementors
 
trying to implement V3 Static Models, whether they are found
 
in Messages, Documents, or Service Payloads.
 
 
 
== Acknowledgements ==
 
 
 
Authors:
 
* George W Beeler
 
* Grahame Grieve
 
 
 
= 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 =
 
 
 
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.
 
 
 
== 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 ==
 
 
 
comments about constraints
 
 
 
== Refinement, Constraint, and Localization ==
 
== Templates ==
 
 
 
Comments about classes, associations, attributes, datatypes and controlled vocabularies
 
 
 
= Key Concepts =
 
 
 
== Null Flavor ==
 
 
 
=== Background and History ===
 
 
 
 
 
 
 
In version 2, the initial set of messages supported a means of communication known as ‘snapshot’ mode. Essentially, whenever data was revised, the sender sent a message containing all the data they knew about an item. All of the data was sent regardless of whether only one item had changed or whether all the data had changed. If the receiver wished to know what specific information had changed they were required to perform a comparison between the data sent in a previous message and the current message.
 
 
 
As the version 2 specification evolved, several segments added fields called ‘Action code’ or something similar that permitted an indication of whether the data in the segment were being added, modified, deleted, or were unchanged. This action code was frequently accompanied by additional fields which identified the user responsible for the change, the time at which the change occurred and the reason for the change. The use of ‘action code’ and its associated attributes allowed more fine-grained control of the data exchange, and eliminated the need for comparisons and for sending all of the data all the time.
 
 
 
When version 3 was conceived, the idea of ‘action codes’ was reflected in the concept of ‘UpdateMode’, which was proposed to be a generic concept present on all data elements. As included in MDF 99, it provided the same functionality as ‘Action Code’ as well as new features specific to controlling items within a list and the use of data as a key or verification in determining the match for a modification.
 
 
 
As v3 moved from practice to theory in 2000-2001, questions arose about exactly how it was intended to be used, appropriate default values, its use in CMETs, how to manage the verification and ‘key’ features and other concerns. To allow work on v3 development to proceed, the Modeling and Methodology Technical Committee decided that the use of UpdateMode would be excluded from artifacts until such time as it was found to be necessary and was sufficiently understood. While UpdateMode was always available for use in RoseTree, it was not supported as part of the R-MIM Designer or Schema Generator.
 
 
 
In 2003, RCRIM sought and received special permission to allow UpdateMode to be used for one of the associations in their model. Modifications were made to the Schema Generator tool, but the R-MIM designer was left unchanged.
 
 
 
There have recently been several use-cases identified that necessitate the broader application of UpdateMode. The issue was discussed on the Control Query (now Infrastructure and Messaging) list beginning around January 2004 and was also discussed at the January and May 2004 WG meetings. Norman Daoust moderated and documented the discussions. This discussion surfaced and attempted to resolve the numerous issues related to the use of UpdateMode.
 
 
 
Final decisions on most of the outstanding issues were made at the September 2004 WG meeting in Atlanta. This document describes the resulting guidelines for UpdateMode use, including issue resolutions from previous discussions.
 
 
 
=== Rationale ===
 
 
 
The principle purpose of UpdateMode is to allow a sending system to identify to a receiving system:
 
 
 
* the changes that have occurred in an object controlled by the sending system; or
 
* the changes that the sender desires to be made in an object controlled by the receiving system
 
 
 
Identifying such changes provides several benefits:
 
 
 
# 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
 
# Query responses are able to document accountability information in terms of what changes were performed.
 
 
 
The broader question of accountability history is principally incorporated 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 who made the change, when the change was made and why the change was made can all be important in helping the receiver make the determination whether they wish to adopt the change.
 
 
 
=== 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.)
 
 
 
== Cardinality & Optionality ==
 
 
 
== Conformance ==
 
 
 
=== Testing Considerations ===
 
 
 
== Vocabulary Conformance ==
 
 
 
* domains
 
* coding strength
 
 
 
== Type Representation ==
 
 
 
**typing (typeId & flavorId & templates)
 
 
 
== Update control ==
 
 
 
== Referencing Acts ==
 
 
 
== Update Mode ==
 
 
 
*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)