Systematic Review of Object Identity, Status, Updating, Versioning, and Related Functions

Systematic Review of Object Identity, Status, Updating, Versioning, and Related Functions

PRELIMINARY, UNRELEASED DRAFT. PLEASE DO NOT YET BOTHER TRYING TO DIGEST. Gschadow 11:27, 19 January 2007 (CST)

Co-Authors

• Gunther Schadow (Gschadow)

Introduction

There has been continuing debate about issues involving status codes, updating and versioning of acts, and, by extension, other objects, such as Entities, Roles, and even (Managed)Participations since the inception of the RIM. Shakes and moves have happened around 1997 (nested states, 1999 (USAMP), and since around 2005 (talking about "versioning"). These subjects are discussed many places and without one place of reference. This evolving document is started as an attempt to discuss the subject succinctly at one place. At the time of launching this document as a project, there may at the same time be another document already out there as over the years different people have certainly taken assignments to tackle the issue (although, I suspect, with a limited scope). The intended future of this document is to (a) either dissolve into another far advanced work of the same kind, or, (b) to become a collaboratively edited compendium discussing and hopefully in the end clarifying these matters.

The personal motivation which I (Gschadow) have in starting this is that I am involved in the implementation of a 100% RIM based information system (involving among others the Java SIG) and in this context I am discovering amazing possibilities for a ubiquitous application of RIM design principles spanning a range from lowest technical implementation phenomena to the highest business processes which we all are trying to support. However, in an attempt to implement common, general functions once properly and then reuse these ubiquitously, I am finding myself in need for clarifications, harmonization of these functions accross different domains of use, and finally, perhaps, some corrections necessary to simplify and secure the simplest most powerful common understanding of these functions.

The topic is vast, as it quickly spills over the "Dynamic Modeling" discussion, and while I hope that clarification on these matters might inform and assist a long outstanding resolution of the "Dynamic Modeling Problem", I believe that this subject under discussion here is actually less difficult and therefore should be looked at without dragging in all possible aspects of dynamic behaviours that go with the larger discussion.

Finally, while I start this document, I would like to invite other co-authors to join in the list above and make contributions. Gschadow 11:27, 19 January 2007 (CST)

Principles

This section is to summarize, under a neutral point of view, without reference to HL7 specifica, the general understanding on the subject matter. This is placed up front in order to clarify what it even is we need to talk about and before we get into a discussion if and how HL7 appropriately realizes these principles.

An Object is a particular computational unit which combines aspects of data (properties) and operations (methods). Usually an object is a particular data structure and a set of operations which, when invoked may

• return a value,
• have a side effect,

or both of the above. This definition is held purposefully in terms of actual computation rather than abstractly speaking of a representation of particular real world items of interest, or even of the real-world items themselves independent of their representation in information systems.

A Class of an object is a universal computational unit, which has particular Objects as instances, hence which defines the objects which are said to be of that Class. Notions of Abstract and Concrete Classes, Inheritance, Substitution, Class vs. Type, Interface (API) vs. Implementation of Classes may be mentioned in passing without further expanding on the specifics as this may not be needed for the discussion.

An Entity Object is an object which has identity and state. This is distinguished from a Value Object which only stands for a (constant, immutable) value without regards for identity and without the Value Object being capable of substantially changing, hence without the Value Object having a state. The notions of identity and state are entirely dependent on each other. The identity of an object is what allows us to determine whether we have "the same" object in two (or more) subsequent interactions with that object (where an interaction with the object means something as simple as invoking a operation of the object, which may return a value.) The state of an object, then, is what appears as differences in return value or side-effects upon two or more subsequent interactions with the same Object (where "the same" object) necessary involves the notion of identity, as we have said that identity and state are notions fully dependent on each other). Hence, we say, an Entity Object is an Object for which we distinguish identity and state, whereas a Value Object is an Object for which we do not.

(Note: do not confuse "Entity Object" with the HL7 RIM notion of "Entity" meaning "Physical Entity".)

When an Entity Object can change state as side-effects of other instances' interacting with said Object, we can then recognize a sequence of states for the same identical Object. We might say that the Object "changes state over time", however, we would like to use time only as an aid to intuition without formally depening on time yet as a part of the discussion. It is sufficient to say that a sequence of interactions with Objects can be recognized and along the steps of this sequence, the Entity Object's state may change. Keep in mind that change of state is recognized by interacting with the Object and observing a different behavior in response to the same interaction. In the simplest case, again, the interaction may be invocing an operation which returns a value, and observing that value to be non-equal between two subsequent invocations. (Speaking of non-equal begs for a definition of equality, which has to be seen as distinguished from identity, however, we try to not get into this yet.)

Entity Objects exist in order to represent matters of importance to the business of the application domain. There are many use cases, for which the change of state of these Objects is relevant to recognize. These range from quite low-level processes such as managing concurrent interactions in databases to providing legal records of change effected by business transactions. Hence, these use cases require not only know that there is a sequence of state-changes of an Entity Object, but to also to recall what exactly this sequence of state-changes is, or at a minimum in certain situations regard two states of an Entity Object at the same time.

If we are to consider any state of an identical Entity Object which was effective prior to the present state of said object, we must create at least one temporary second Object, which represents our Entity Object of interest in a state prior to the present state of the Entity Object. There is no other way. One may then call the Object representing the Entity Object in its prior state, a snapshot of the Entity Object. Such a snapshot object need not be of the same nature as the Entity Object whose states we like to compare, all it needs to reflect is those properties which we use in comparing.

Status Quo in HL7

The sources to establish the status quo of present thinking are:

• Message Development Framework (MDF) 1999 Edition
• Reference Information Model (RIM)
• HL7 Development Framework (HDF) (unsure how much detail it contains)
• HL7 Balloted Specification (establishing a "case law" of sorts)
• Earlier white papers and proposal documents (e.g. the 1999/2000 USAMP proposal document, or associated slides of meeting presentations and tutorials)
• Harmonization meeting documents and discussion (not systematically recorded)
• MnM "Hot Topic" resolutions (documented where?)
• Oral tradition developed in committees perhaps at best unsystematically described in minutes.

This section should preferrably quote the salient pieces of the sources listed above. Short of doing any acribic research on the subject, I will begin by throwing out some facts of the RIM design from memory. This may serve as a skeletton to add references and quotations to the effect of morphing that skeletton till it represents the present status which is to serve as the basis of any summarization, clarification, and, if necessary, revision and correction or adding of features.