Semantics in Reference Models, was Re: Link between goals and other clinical concepts

Bert Verhees bert.verhees at rosa.nl
Wed Jun 25 08:42:57 EDT 2014


Hi Ian,

As I come to think about it, it is a bit different, then I thought 
yesterday it was.

Because a Reference Model, HISA, or some HL7 document, or OpenEHR, they 
can be mimicked by a Reference Model without semantics.
But it is only the structure you mimic, and that works fine.

But is you also want to mimic the attribute-names, then a generic 
Reference Model will not do.

There are two ways of solving this

- Leave the attribute-names as they are in the generic Reference Model, 
and use the ontology-text to define the attribute-name from the 
information model to mimic.
In this case, one generic Reference Model, can mimic almost all possible 
Reference Model. The problem is when querying, people writing the query 
will use the wrong attribute-names and mapping needs to be done.

- Have your kernel processing more Reference Models simultaneously. A 
Reference Model mostly can be expressed in an XML Schema. Check 
archetypes against these XML Schema's In this way, you do not only mimic 
the structure of a required Reference Model, but also the attribute-names.

It is, of course, possible to query more Reference Models 
simultaneously. Not one to cover the complete medical field, but one for 
every field.

Bert

On 25-06-14 11:05, Ian McNicoll wrote:
> Hi Bert,
>
> As ever these are interesting discussions and the 'no semantics' in
> the reference model approach has some attractions. I happen to agree
> with Hugh that  it seems that one way or other, there are a set of
> generic semantic constructs which need to be broadly and tightly
> adhered to, and controlled at 'reference level' and whether this is
> done by using reference archetypes or hard-wired in to the ref. model
> is somewhat arbitrary. One of the advantages, for instance, of using a
> 'reference-level' observation date is that vendors can optimise their
> systems, knowing that this will be universally available. Whether this
> is an RM attribute or an element of a reference archetype does not
> much differ in terms of commitment to stability of that data point.
>
> There is actually very good alignment between Contsys and the openEHR
> RM. There are a few places where there is some degree of mismatch and
> where having a top-level extension to e.g COMPOSITION or INSTRUCTION
> would allow for Contsys-specific attributes to be handled more easily,
> but I think this can be simply achieved by adding a top-level CLUSTER
> slot to COMPOSITION and ENTRY classes. That way we can bridge the gaps
> between different source information models without compromising the
> overall approach.
>
> Having said all thta, I think the openEHR implementation and
> real-world use has reached a level of practical use where these kind
> of discussions are moot. It is going to be up to Industry and other
> real-world users to tell us if they want the kind of root-and-branch'
> reform that you are advocating. I think we all recognise that there
> are gaps in the current RM and things that we can do better but I am
> not hearing a major push from the implementer community for the kind
> of radical change in approach that you are advocating. For most
> people, my impression is that the existing RM is working pretty well.
> Certainly not perfect, but I am not sure that the use of reference
> archetypes necessarily solves these problem, it just moves them
> elsewhere.
>
> I agree re messaging, but again I am not sure that this is a
> significant issue for implementers (at least in your terms). openEHR
> systems are talking to a variety of messaging formats. If someone
> wanted to build a set of archetypes that mimiced CDISC or HISA or
> whatever, that could be done using the generic archetype but no-one
> has taken that approach so far to my knowledge because openEHR is not
> trying to build CDISC or HISA EHR systems internally. It is
> deliberately optimised for EHR use.
>
> I am also concious that we have hi-jacked Pablo's original discussion.
> Perhaps we should split this into two threads but I will leave that
> for Pabl / Bert to resolve!
>
> Ian
>
>
> On 24 June 2014 22:22, Hugh Leslie <hugh.leslie at oceaninformatics.com> wrote:
>> Hi Bert,
>>
>> I assume you are talking about those types of semantics that are currently in the openEHR reference model like observation and instruction.
>>
>> This argument has been around for a while.  My issue with this is that if you start to control some way of modelling generic archetypes for these types  of semantic structures, then you are in exactly the same space as doing it in the reference model but without the same level of governance or control.  CIMI have also suggested this approach.  This is likely to be more difficult for developers as there is a much higher likelihood of multiple types of instructions/actions/observations that will need to be dealt with rather than one reference model based way of doing it.
>>
>> I actually would contend that these structures are not domain specific, although they may have domain specific names.  We want the reference model to tell us how to construct compositions and entries as well as a consistent way of defining tables or tree structures so that software can be written once to handle all possibilities.  These openEHR constructs that seem to cause such controversy, just make explicit things that are going to be modelled over and over in the same way as these other things.  If we don't put these things in the reference model, then we will have to accept that there will be an increased variability in the way that they are modelled which is likely to make software more complex.
>>
>> Its an argument/discussion that we will continue to have I suspect.
>>
>> Regards Hugh
>>
>> . -----Original Message-----
>> From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of Bert Verhees
>> Sent: Tuesday, 24 June 2014 6:25 PM
>> To: openehr-clinical at lists.openehr.org
>> Subject: Re: Link between goals and other clinical concepts
>>
>> On 24-06-14 02:28, pablo pazos wrote:
>>> creating CLUSTERs for all the stuff than .....
>> I missed a part of the discussion, but maybe I get the point, or I see my hobbyhorse everywhere.  ;-)
>>
>> I have been thinking about this some time, and I started a few times a discussion about this subject. But I must say, there is not much enthusiasm for this idea on this list.
>> Let me explain compactly.
>>
>> Take a look at the EN13606 RM which is already much more generic then OpenEHR. You can model archetypes for it with the LinkEHR archetype-editor.
>>
>> For a developer, it is nice to have a generic reference model, it can help you create generic code in the application/kernel.
>> For a domain-modeler (a medical-information-specialist, f.e.) it is nice to have semantics in the reference model. It helps thinking about how to model an archetype for a specific purpose.
>>
>> There is a way in between, which can serve both groups:
>> You need to bring order in the chaos of generic CLUSTER_archetypes. You can do a lot with archetype-slots with defined reg-expressions, so in this way, the generic archetypebase canconsolidate in an information-model which can be used by the domain-modeler.
>> This information-model needs to be defined, controlled and documented.
>>
>> Then you reach the area of proprietary.
>> Domain-modelers need besides adapting the reference model, conforming to your defined proprietary information model.
>>
>> And, on second thought, anyway, you need to adapt a good message-model, because not the whole world will run OpenEHR.
>>
>> The nice thing about two level modeling is that, this is all possible.
>>
>> good luck
>> Bert
>>
>>
>> _______________________________________________
>> 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