Re: Versioning vs Temporal modeling of Patient State

Personally I don't see too much of a difference between versioning of 
models and versioning of instances. The former is needed to  bundle a 
couple of *updates* of our world model (stamped with a version number), 
the latter is needed because also instance data change and previous values 
still keep being important. You can discuss wether a new version of an 
instance is really a new version or a new instance (maybe with a link to 
the previous instance). To me it doesn't matter and looks like an 
implentation issue.
We have to realize that versioning is an artifact anyway. The real world 
keeps on going and doesn't hold its breath to take snapshots. It is our 
need to document the world at a certain point in time that creates the 
need of snapshots: for example documenting your assessment of a patient by 
giving a diagnosis. Keeping track of previous *versions* of instances is 
very important in medicin, not at least for legal issues.

When you look at implementations of electronic patient records you see 
that different approaches are chosen: the more simple (simplistic?) 
approach is to take each patient encounter as a container and put all your 
instances of clinical data in it (diagnoses, medication, procedures, etc 
...). This gives you an easy way of handling changes over time. In the 
next encounter the diagnosis is changed an you just add a new instance of 
the diagnosis in the new container. While escaping from the versioning 
problems you loose information. In the real world there is an *evolution* 
of the patient condition and you didn't capture that.
Other implementations consider a diagnosis as something pertaining to the 
patient and evolving. At a certain moment in time they link the current 
*version* of that diagnosis to the encounter. In a next encounter you can 
again link the - maybe changed- diagnosis to the new encounter. The result 
is that for any encounter you have captured the current state of the 
patient and you have a nice way of looking at the evolution of that state 
by looking at the different versions.

What do we learn from that?
In both ways you try to capture the ever changing world by introducing a 
time concept: the encounter. In the first approach you make time 
containers and put instances in it, in the second approach you make time 
stamped versions and link them to time containers. I perfer the second 
approach because of the added information.
The point is that versioning means: adding a temporal concept to the 
snapshots of the world. Because the history matters (both for models and 
instances) we better model that temporal aspect as well. It will enable us 
to reason about it.
As for the difference between *update* and *version*: my intuitive feeling 
is that an update means a atomic change and a version means a bundled and 
officially relleased collection of these changes. And indeed the latter 
will be more appropriate for models than for instances.

Dirk
______________________________________
Dr. Dirk Colaert MD
Advanced Clinical Application Research Manager
Agfa Healthcare               mobile: +32 497 470 871



Ora Lassila <ora.lassila@nokia.com> 
Sent by: public-semweb-lifesci-request@w3.org
12/01/2007 17:06

To
"Kashyap, Vipul" <VKASHYAP1@PARTNERS.ORG>, w3c semweb hcls 
<public-semweb-lifesci@w3.org>
cc
Trish Whetzel <whetzel@pcbi.upenn.edu>, kc28 <kei.cheung@yale.edu>, Alan 
Ruttenberg <alanruttenberg@gmail.com>, Nigam Haresh Shah 
<nigam@stanford.edu>
Subject
Re: Versioning vs Temporal modeling of Patient State








Vipul,


On 2007-01-12 10:21, "Kashyap, Vipul" <VKASHYAP1@PARTNERS.ORG> wrote:

>> my experience is that issues of versioning are quite different from the
>> issues of temporl modeling. Often in the former case, we don't have to
>> concern ourselves with what changes have taken place, whereas in the
>> latter
>> case, we often need to focus on the changes themselves (i.e., questions 
of
>> what changes, how, and *when* are critical).
> 
> [VK] That is a good way to distinguish the issues. Unfortunately, the 
few use
> cases that were provided to me suggested issues of versioning were 
confounded
> with issues of temporal data modeling.
> 
> The latter notion of versioning is from the content management 
perspective,
> where the notion of what.why,who changed it is important, i.e., 
provenance.
> 
> This underlines the need for a clear definition of versioning and 
provenance
> in
> the life sciences context.

[OL] Hmm... still, from the content management perspective, you may not
*reason* over the changes or (more generally) the temporal extent of 
things.
In a way, there is a different whether you are modeling the real world, or
modeling the documents that contain models that represent the real world.

Confusing the various (meta)levels can quickly mess up your head. :-) 
There
are multiple dimensions all of which may have to be represented: the
temporal dimension, the stack of metalevels (models, models of models,
etc.), perhaps others.

>> This is an old and difficult problem with systems employing complex
>> representations of the world. It is often not sufficient to operate 
within
>> a
>> mere snapshot of the world. One has to ask whether time (or the changes
>> over
>> time) matter, or whether at any moment it is sufficient to consider a
>> snapshot.
> 
> [VK] The key is how you support this functional requirement. Either you 
could
> create an appropriate temporal model that provides the framework 
acquisition
> and
> querying of this data; or
> you could fall back on versioning functionality to get this information.
> IMHO, there is more value in taking the former approach as it can be fed 
into
> versioning systems that compute the changes or "diffs"

[OL] Regardless of how you do this, you have to decide whether you really
are reasoning over/about the changes (in time). The information (about
changes) may be *acquired* from the versioning system, but then has to be
modeled *outside* the versioning system. Acquisition vs. processing is an
important distinction.

>> One might draw analogies to "compile-time vs. run-time" considerations
>> often
>> occurring in computer science... in fact, the question of "class 
changes
>> vs.
>> instance changes" is exactly that.
> 
> [VK] Agree. However whether an instance is actually changing or whether 
a
> particular property of the individual is naturally modeled as a dynamic 
time
> varying data type need to be identified.

[OL] This may or may not be a relevant distinction, depending on how you
implement thing, what tools you use, etc. But generally, I agree.

Regards,

    - Ora


>> BTW, there is a paper that points out that temporal modeling/reasoning 
is
>> re-invented/re-implemented over and over because of the lack of 
"built-in"
>> support for it in KR systems:
>> 
>> Thomas L. Dean and Drew McDermott. Temporal Data Base Management.
>> Artificial
>> Intelligence, 32(1):1­55, 1987.
> 
> [VK] Thanks for the above info.
> 
> ---Vipul
> 
> 
> 
> 
> THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED 
ONLY
> FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN 
CONFIDENTIAL
> AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION 
OR
> OTHER USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION 
BY
> PERSONS OR ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF 
YOU
> RECEIVED THIS INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE 
PRIVACY
> OFFICER, AND PROPERLY DISPOSE OF THIS INFORMATION.
> 
>