More generic reference model
bert.verhees at rosa.nl
Sat Sep 3 12:14:29 EDT 2016
On 03-09-16 08:51, Thomas Beale wrote:
> On 02/09/2016 04:04, Bert Verhees wrote:
>> On 02-09-16 11:18, Daniel Karlsson wrote:
>>> Terminologies typically do not specify which pieces of information
>>> are needed in a given situation.
>> Hi Daniel, I don't have at the moment opportunity to reply to all you
>> write, so excuse me for cherrypicking one idea of your message.
>> I thought SNOMED specifies which information is needed in a given
>> situation, but maybe I misunderstand you?
> It does various things, but this is not one of them, except by
> accident ;-)
OK Thomas, SNOMED has attributes, those attributes pinpoint to other
concepts, in the end there might sometimes be data-values, concepts from
the qualifier value-hierarchy, and build in that way an information
structure. I don't think if every trace inside SNOMED ends up at a
qualifier value, not even half or less. A good example is how the
mapping to LOINC is preferred on the market. LOINC orders the
lab-research, and SNOMED gives the answer. It think it must be over
attributes, one (or one group) defining what the answer means, and the
other a qualifier value which points to a datavalue.
I don't say that SNOMED can replace archetypes, I suggested that a few
months ago, but I came back from that thought. But SNOMED has a lot of
information, which is more then just a concept ID for every clinical idea.
So maybe we can leave that subject, as we both agree largely on this.
More important, therefore is the following subject.
There are problems in using SNOMED in combination of OpenEHR, that is
what I want to discuss, you can give a conceptID to a clinical term, but
that is about it. When OpenEHR wants to be a success it needs to be able
to do more. But I do not know what more.
I think, embedding expression constraints in AQL will be a good one.
This is not an easy one, but it is very powerful. The potential of
SNOMED comes alive in AQL. That will be a major drive to use OpenEHR.
On the other side, if in OpenEHR the SNOMED integration will not be
enhanced, there will be work done outside OpenEHR, because clinicians
and governments want to use the power of SNOMED, with or without
OpenEHR. So it is an urgent matter.
And does the OpenEHR-use create difficulties doing SNOMED work outside
OpenEHR, while using archetyped data?
I think this can happen, that could be a showstopper. Sorry for the
strong language, but that is what I think.
But on the other hand, OpenEHR has it in it to support SNOMED, it can be
used the right way. This also needs to be discussed, what is the right
way, and is it really necessary to do it in that way? Are there no escapes?
I asked a question in my previous email to this list. I ask it again.
Besides embedding SNOMED expression constraints in AQL, are there other
ways to integrate SNOMED in openEHR?
> SNOMED is on the right-hand (ontological) side of the is-about
> relation, EHR information (defined by archetypes) is on the left
> (epistemological) side.
> So terminology codes within EHR information can indicate what the
> items 'are about' (in terms of real world categories) but the
> structures and data types of information items are not generally known
> within the terminology. Terminology doesn't say why pulse is a good
> surrogate for heart rate, or in what circumstances MAP BP would be
> used, or the structure of data in a liver function test. These are
> generally contingent relations and substitutions, based on cultural,
> economic and other factors. Terminologies (if well defined) mostly
> deal in necessary / invariant relations between entities. At the next
> level out, EHR data relates to situations, which are full of
> accidental relationships; terminology doesn't easily deal with these
> - thomas
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
More information about the openEHR-clinical