Link between goals and other clinical concepts
thomas.beale at oceaninformatics.com
Wed Jun 25 08:48:16 EDT 2014
On 25/06/2014 00:53, Bert Verhees wrote:
> Hi Hugh,
> It is indeed a discussion which runs for several years.
> I mentioned 13606 but it can also be done in OpenEHR. OpenEHR also has
> lists, trees, clusters, elements, all derived from Locatable, thus
> So you can define (what I call) an information model, based on the
> generic structures in OpenEHR.
> Say you want to conform to HISA, is that possible in the
> Composition-package? I am not sure, I read it once, some years ago,
> and I saw some problems, say (imagine) HISA will conform more in
> direction of ContSys, how do you handle this in the OpenEHR
> composition-package, and we all know, it will not stop there. It is an
> illusion to think that an information model will last for ever.
> Maybe there are concurring information models, maybe you want a kernel
> to support more, simultaneously, maybe you want to write an API to a
> specific information model?
> Imagine HL7, for example, VMR, based on archetypes? I once did that,
> for a customer. I did not write an API for that, just the archetypes,
> but I could write an API for that.
> I am afraid you will find the composition package restrictive. It
> represents a good information-model, as far as I can judge (it is not
> my specialty), but is just AN information model. There can be more
> which are good too.
> That is why I think, semantics do not belong in the reference model,
> but in a constructed archetype/template-based information model.
well there are always 'semantics' in an information model, no matter how
generic. It's just a question of how specific. The DvQuantity class has
some very general semantics, which most people accept, and which can be
mostly converted in and out of PQ and other 'competing' types.
The Composition class is defined in 13606 and openEHR to do one job -
act as a container for data captured during the same health event. It
doesn't do all jobs. There is no reason we would not add other classes
in the future to openEHR to handle other general categories of data,
either at a similar level as Composition, or finer levels - just like we
would add a new data type if we need it.
> You could also model the OpenEHR information model, which now resides
> in the reference model, in such constructed archetype/template-based
> information model, using only structure-based archetypes.
well, you could get some way. Developers like the structures in
Observation and Action and Instruction, because they can be programmed
once in Java, Ruby, Python, C#, ... etc and they just work. No
archetypes to worry about there, and yet they take care of a lot of
quite complex data like differential time-series, multi-drug orders and
If you try to replicate all those details as reference archetypes,
you'll get some of it done, but since you can't create generic
(templated) types or use multiple inheritance (at this stage, at least)
in ADL/AOM, there are going to be limitations. Solving that means
upgrading ADL to have the power of a language like C++. I'm not sure if
that's what we should be doing.
Right now, displaying a time-series of heart rate v treadmill speed over
15 mins is dead simple in openEHR - the data structures are all there.
Doing that in even 13606 requires:
* defining reference archetypes for time-series data, where the events
can have secondary state i.e. each event has a primary datum like
heart rate, and 'state' data like exertion (treadmill speed)
* writing software that knows how to transpose the Cluster/Element
structures into a logical time-series, and figure out what is the
main datum, what is the state, what are the widths of every event
and so on
o remember, there won't be any Java / Ruby / Python /.. classes to
do this - you have to do it all manually.
How do you know whether a Cluster/Element structure is even representing
this kind of data? What if some data source has tried to generate a
Cluster/Element representation of time-series data, but in a different
way than what you have assumed? That means you having to have another
kind of code to deal with that way of arranging the data.
I can make the same argument for Instructions and Actions.
Now you might say: well, it's a job for 13606 to define reference
archetypes for all that, and force everyone to be the same. But then you
might as well add these classes to the RM (still preserving the generic
ENTRY class), and make life easier for everyone.
The one thing we did not do very successfully in openEHR is to preserve
the generic form of ENTRY; this is what let's the 'thousand flowers
bloom', but doesn't prevent proper reference structures being in the RM
either. In the near future we will fix this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical