Link between goals and other clinical concepts

Bert Verhees bert.verhees at rosa.nl
Fri Jun 27 06:09:58 EDT 2014


On 26-06-14 10:16, Diego Boscá wrote:
> Well, I would say that deciding what's in and what's out of the
> reference model can be tricky sometimes. If we assume that clinical
> knowledge evolves (one of the basis of dual model approach) isn't safe
> to say that the less clinical knowledge we put in the reference model
> the better?

Hi Diego, I tend to agree on this. Because if you want a stable 
data-definition, you must be prepared for changes in thinking.
There will, however, always be some basic structures left.

A medical information model must be patient/EHR centric. All data must 
belong to a patient.
This is typical for an information system for storing medical data.

13606 was not such a system. 13606 is, in my opinion, in fact 
Composition-centric
(and a not archetypeable demographic section, I don't understand the 
purpose of that).

13606 was a message format, and demographic data (if medical relevant to 
a specific Composition) should be an entry of a Composition.
The patient, a number in the EHR-Extract was just a carrier of related 
medical circumstances.
An EHR-message was, per definition limited in scope.
The scope was a medical circumstance that was wished to communicate, 
together with the patientID in which this circumstance lived.

I believe, I have heard, this is going to change. 13606 will become an 
information system for storing medical data with a minimalistic structure.

Since quite some time, I implemented a multiple RM-kernel.
Now I see, it is also because it can be used to serve several different 
medical information structure philosophies, as long as they are Patient 
Centric.

13606 will have a more important role because of its minimalistic 
structure.
Organizations which want to implement information-standards now have 
tooling and a minimalistic Reference Model to do so.
For some ideas, 13606 will not fit, and a new Reference Model will need 
to be written.

I think that the Reference Model will loose some of its status.
Was it before the foundation of a software-structure, with a lot of 
classes to support, it now becomes more and more just an interchangeable 
information definition.

Now the LinkEHR editor change to RM-pluggable editor, and we have a 
complete new medical information use.
The customer, not depending on the vendor, can create or choose an 
information model.

We'll see if this is true, and if, where it ends.

Bert

>
> You can always define reusable patterns to be applied over the
> archetypes, but these patterns itself can be evolved (just in case you
> feel that some day event series could be represented in any other way,
> for example). At the end, an Observation is an specialization of Entry
> class with some structures already available for you to use.
>
>
> 2014-06-26 9:57 GMT+02:00 Thomas Beale <thomas.beale at oceaninformatics.com>:
>> On 26/06/2014 08:33, Bert Verhees wrote:
>>
>>
>>
>>
>> You can use multiple in archetypes-based reference models to validate and
>> store and query data. You can allow certain parts of an healthcare
>> organization, without any technical provision, to implement new ideas about
>> medical data structures, maybe necessary for specific treatment.
>>
>>
>> sure, but like I said, this is just the same problem moved up one level. At
>> some point, you still have to write classes with the semantics of things
>> like Observation or Composition or whatever.  Otherwise you can't get the
>> data on the screen, or compute with it in any meaningful way.
>>
>>
>> I think this can be solved with templates and information which can be in
>> the archetype-meta-data. Don't you agree? What am I missing?
>>
>>
>> example: this structure is inside an openEHR OBSERVATION, and most
>> implementations use full Java/C#/other implementations of these classes.
>> That enables you to do things like handle openEHR OBSERVATION data
>> representing time series from a device natively, including varying
>> periodicity, varying sample widths, and varying math functions (max, min,
>> ave etc). This makes it very easy for an implementer to get time-based data
>> from an EHR and populate a screen graph widget.
>>
>> Without any of this built in, e.g. as in 13606, CDA, or other models, you
>> have no guarantee that this kind of data (very common you will appreciate)
>> is even represented in a standard way, nor do you have any classes to
>> process it with. You have to assume that each CDA or 13606 data source has
>> its own representation of such data, and build N implementations to deal
>> with it. For openEHR implementers, openEHR is the target data, so we convert
>> data into openEHR, which is a higher-fidelity format, and the problems go
>> away. You could potentially convert them into a sort of standardised 13606,
>> representing the same thing but then you'd still have to build your own
>> classes to implement time-based data rather than re-use the standard classes
>> everyone else uses. I don't see the point. Especially as openEHR has AQL.
>>
>> Now, there are things that are not actually in openEHR, that you might want.
>> So you can take the 'reference archetype' approach to that, and build local
>> classes. But you might as well still use openEHR as 13606 or CDA as the
>> basis, since you will get more for free - if you make your local native
>> format something completely custom, then there is no community or software
>> you can use - you have to build everything yourself.
>>
>> - thomas
>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org





More information about the openEHR-clinical mailing list