More generic reference model

Clinical (archive)
1

Hi,

I am just wondering if there are some opinions about this.

Do we still need the not so generic reference model which OpenEhr has, with archetypes denoting Observation, Evaluation etc?

Wouldn't a more generic reference model, like ISO13606 be sufficient, when the terminology, worldwide, is moving to SNOMED-CT?

Because the SNOMED-concepts already indicate in which hierarchy a data-item belongs (clinical finding, procedure, body structure, etc), and with much more detail then the OpenEHR reference model.

When using SNOMED in OpenEHR there will be redundant information created, and to not create redundant information is one of the main golden rules in system design.

I think the reference model design needs reconsideration. It comes from a time when there was no SNOMED-CT.

Thanks for any thoughts.

Bert

2

Main problem I see there is that Snomed focus usually differs of what
we look in the bindings, which makes binding process quite difficult
(e.g. binding a blood pressure archetype entry with the blood pressure
snomed ct term is wrong. It should be bound to something in the lines
of "report about blood pressure").

In the end, you can see the different classes of openEHR entries as
generic entries with a (kind of) meaning provided by openEHR. Think
something in the lines of 'openEHR::OBSERVATION'. I believe that
ISO13606 part 3 proposes something in the lines of this to deal with
different RM semantics

By the way, there are countries that are proposing a national
extension to Snomed to add that kind of "report about..." terms. This
way they assure that the meaning of the archetype and the term is
exactly the same.

Regards

3

Thank you for your reply, Diego.

But it does not solve the problem I see: the problem of redundant information.

We are stating in an archetype that we are doing an observation on blood pressure, and we state that again using SNOMED and LOINC. LOINC to define the observation and SNOMED to support the observation-result-definition.

As I am informed, that is the way interoperability is going. I don't understand the usefulness of the the observation-entry-type as defined in OpenEHR from this point of view.

Except from redundancy, there may also be a problem of not using the potential of SNOMED.

I am not sure about all this, but maybe there is also, when used a more generic solution, advantage when querying.
When knowing the path to a SNOMED or LOINC coding, then hierarchical querying over AQL becomes possible.

Bert

4

Sorry, this was a mix-up of two concerns

We are stating in an archetype that we are doing an observation on blood pressure, and we state that again using SNOMED and LOINC. LOINC to define the observation and SNOMED to support the observation-result-definition.

One is the redundancy. The problem with redundancy is that it can be error prone when there is a slight difference in meaning of the content and archetype ID. When the reference model suggest that the archetype clincial idea is a part of group of clinical idea's (f.e. Observations), and a internal coding suggest something which has difficulties fitting exact in the OpenEHR entry-types and suggest something slightly different. Which one is then to follow? Better, I think, would be to assign a generic structure, so there can be no misunderstanding and let a terminology-coding decide what the archetype is about. Notice that I do not specify the term "terminology-coding", so it does not have to be SNOMED if there are strong reasons to not use it. (f.e. a non-member-country)

Except from redundancy, there may also be a problem of not using the potential of SNOMED.

This one is a bit harder to explain, but the problem is that when you don't know the path to a terminology code, because it differs in different archetypes, you cannot query for that code.
The query consists of the archetype ID and the path inside the archetype. So there are two problem parts.

In the FROM part: The archetype ID is a representation of the clinical idea which is represented in the archetype. I understand it is possible to use regular expressions in a query in the FROM part, and in this way have a selection from more then one archetypes to query in one time. But regular expressions operate on series of characters, not on clinical hierarchies. So it is not possible to query in archetype ID's on hierarchy of clinical ideas.

In the WHERE part: When the path to a terminology coding is not known, and this is the case when there are more entry-types, and even in a generic entry-type this can be a problem. So there should be a fixed location which can be reached by AQL where coding occurs, so the potential of SNOMED in relations and hierarchies can be guaranteed successfully used in AQL queries. As it is now, we cannot be sure that we miss something in a query which is in a obscure archetype. This is especially the case when the number of used archetypes outreaches the human comprehension limits, for example the idea when more EPD's are queried in one time, or are compiled in regional cooperation of healthcare facilities or hospital mergers.

5

It is the generally accepted by CIMI that in name/value pairs:
- LOINC is used for the question part
- SNOMED for the Question

With respect to the co-use of both coding systems and the needed harmonisation between the two:
in the USA they started SOLOR (SnOmed LOinc, Rxnorm)
CIMI will rely on SOLOR.

This SOLOR might fulfill the needs of countries to extend SNOMED to be able to bind all items in a structure to a reference coding system..

Gerard

6

Dear All,

while there is, as you note, overlap and resulting redundancy, I believe this is hard to avoid. If the archetype is an information requirement specification and and the information requirements are different for observations, evaluations, instructions, ... (which I believe they are) then this level is needed. Terminologies typically do not specify which pieces of information are needed in a given situation. CIMI e.g. has drawn the line between the RM and archetypes differently compared to openEHR and introduced more layers (RM, reference archetypes, clinical patterns, etc.) but the overall idea with specific clinically motivated constraints for classes of information. Not-quite-as-similarly, FHIR has specified information requirements in a growing number of clinical resources.

So, I do not see a trend moving away from information model frameworks (together with terminologies) being central to interoperability.

This doesn't mean that openEHR shouldn't try hard to improve (the guidance for) use of archetypes together with more terminologies like SNOMED CT, but we still jointly have to identify the "sweet spot" (Heather's words) which gives the most usefulness.

Cheers,
Daniel

7

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?

Bert

8

Daniel,

I agree with your opinions.

And observe - like you - differences where boundaries are drawn.

To me it is logical that there are differences because the scope of Bert is not the same as the scope of OpenEHR or CIMI.
Bert’s scope is implementation in databases
OpenEHR -to me- is a mix of theory and implementation practicality creating archetypes serving clinicians
CIMI’s scope is to create standardised Logical Models that happen to be archetypes.
CIMI does not expect that CIMI Logical Models will be implemented as is, but implemented after a transformation.

Gerard

9

Bert,

if I understand your issue correctly, I believe that some sort of "code index" is needed in openEHR persistence implementations. This "code index" would link all codes used with the (full) path to the node where the code is used. There are several considerations to be made when implementing such an index, including making certain that the information context is clear (e.g. a code in an exclusion archetype vs. one in the problem archetype), which other pieces are needed to build the index, like archetypes and templates used in the path, which codes to index (archetype- and template-bound codes as well as coded values). I assume the brilliant people on the openEHR lists knows more about such things than I do :slight_smile:

Cheers,
Daniel

10

You are right, Daniel, that is exactly why I discuss it, to get an opinion from the brilliant people on the list. But even brilliant people can have blind spots or not so strong moments. So it is always good to keep thinking for yourself. :wink:

I don't know if such a "code index" is what I am looking for. What will you put in it? The SNOMED-code representing the clinical idea of the archetype? And what if the archetype only represents a part of the clinical idea?

Maybe I did not explain well my position. It is not that I am doing a proposal for a solution. Even the problem I have is not completely clear to me. Problem definition is often halfway the answer.

Part of the problem is that we are getting an enormous wealth of clinical information, also in the Netherlands this is available.

I don't see how the OpenEHR concepts help us using this potential. And that will become a serious problem. It just is not enough to have a concept ID for every clinical term.

best regards,

Bert

11

Actually SNOMED did exist when we designed the openEHR RM, and even if today's SNOMED CT had existed we would have done pretty much the same thing I think. The Observation model for example is a structural model of time series data, adapted to direct software use. Trying to use SNOMED to code all that would be painful, and contrary to what SNOMED is for.

There are other things we know we would change (AFAIK, all on the PR tracker somewhere), but I can't imagine wanting to throw out basic structures that make developers lives easier.

- thomas

12

I would be interested to see a) developer code for a 100 event time series of BP with no dedicated structures, just hierarchy + SNOMED and b) a query to find systolic BPs over 165 that persist for more than 10 mins in that same series. They're both doable, but they will be harder.

- thomas

13

Actually SNOMED did exist when we designed the openEHR RM, and even if today's SNOMED CT had existed we would have done pretty much the same thing I think. The Observation model for example is a structural model of time series data, adapted to direct software use. Trying to use SNOMED to code all that would be painful, and contrary to what SNOMED is for.

Blood pressure is not such a good example. Better examples are concepts with much hierarchy or other relationships/attributes connected.

I am not sure what you mean by using SNOMED for coding. Of course SNOMED can be used for expression constraints, for example, to create an expression which indicates a systolic higher then 165. The expressions could be embedded in AQL if it would be ready for that.

Another expression would constrain: Does the patient have a specific disease, or one of the twenty diseases which have an "is a" relation with that disease, and then with a specific attribute and a specific value, etc..
Also for datamining and population care this would be good.

An example is always dangerous, because, the wrong example does not mean that the argument is wrong, but the example can become argument of discussion. But I try anyway.

Find all patients which had a form of cancer with a specific attribute or one of the child forms of that cancer and a specific therapy or one of the twenty therapies which are a child-form of that therapy, this is maybe not easy to do in OpenEHR right now.

It might be possible that the archetype-structure in which different cancers are describes have a different structure for different cancers, so it is not on a steady path where you can find characteristics about that disease. Same counts for the therapies

And it would be nicer if the query could be embedded in AQL.

So, in my opinion, you need equally formed archetypes for different diseases, especially if they are in the same clinical hierarchy, so you can find clinical attributes of that disease-hierarchy and terminology codes on the same node-Id's and in the same structure.

Maybe a hospital thinks about that when designing archetypes, and is doing a good job, but the concept does not enforce this good job.
On the contrary to SNOMED which is well guarded by IHTSDO

OpenEHR could profit from that.

Maybe there are better ideas to integrate SNOMED better in OpenEHR?

best regards
Bert

14

It does various things, but this is not one of them, except by accident :wink:

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 either.

- thomas

15

Thomas,

I agree.

In the Semantic Stack various layers are orthogonal and intersect.
The intersection between SNOMED Reference Terminologies and structures (archetypes) is exactly at the righthand side of the ‘is’ relation.
Codes from SNOMED are ‘universals’, meaning definitions, like entries in a dictionary. They define generic truth’s.
Archetypes are Logical Models that define what will be documented about a specific patient by a specific author at a specific place and time, for a specific reason.
The nodes in the structure are needed to document the data in its context, the epistemology.
Archetypes are about ‘particulars’. They are the left-hand side of the ‘is’ relation.
This left-hand needs a different code from a different coding system. LOINC is the logical candidate.
Even without a filled right-hand side with a SNOMED code, there is the need to bind a code to the left-hand side in the archetype to disambiguate it.

Two kinds of coding systems intersect in the Semantic Stack layer that is the Archetype in well defined locations for well defined reasons.

Gerard

16

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 :wink:

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?

Best regards
Bert

17

Bert,

doing most of what you want should come in AQL, e.g. the following in a WHERE clause is already possible.

SELECT
e/ehr_status/subject/external_ref/id/value, diagnosis/data/items[at0002.1]/value
FROM
EHR e
CONTAINS Composition c[openEHR-EHR-COMPOSITION.problem_list.v1]
CONTAINS Evaluation diagnosis[openEHR-EHR-EVALUATION.problem-diagnosis.v1]
WHERE
c/name/value=‘Current Problems’
AND diagnosis/data/items[at0002.1]/value/defining_code matches { http://snomed.info/id/42570301000090487|cancer Dx refset|}

Where the final bit stands for a SNOMED refset containing all cancer diagnoses. Here the existing ‘matches’ operator to means ‘member of set’, i.e. in the ref-set. This query would return an EHR patient ref and a diagnosis for every EHR that contains a cancer diagnosis, i.e. all ‘cancer patients’ (obviously it would need to be refined to be useful, e.g. current in- plus out-patients or Dx in last 10 years etc)

As far as I know this syntax is covered by the current AQL specifiction. However the semantics may need refinement.

One interesting question is whether ‘inline’ refset definitions would be allowed, e.g. using the SNOMED constraint grammar. We probably should add this to AQL as a plug-in syntax, since IHTSDO standardised it. What the solution is for ICDx I don’t know.

The main thing to understand is that if a SNOMED or ICD code for say leukaemia is found in EHR data, the code alone doesn’t tell you the epistemic status, i.e. the kind of statement being made - i.e. current diagnosis, no risk of, risk of, fear of … etc. Querying properly means understanding where in the data you are looking, and the archetypes help with that.

  • thomas
18

That is a very OpenEHRish way to do it, is comparing the code. But what if you also want to find the subtypes, lungcancer (30 sub-types), etc, if you want to know about SNOMED attributes. For that purpose is the Expression Constraint language, and you need to query the terminology to know what you need to compare your data with. The best way to do it is not invent another way to do it, but embed that language. When that is done well, you have the full power in one move. I don know either. There is more then just a plugin which does some separate work. Because the ECL also works on subtypes and attributes, and the attributes are not available. AQL must deliver them to the SNOMED engine, because they are on another path. There is code infrastructure needed. For example: Find systolics higher then 165, in the archetype the type of the measurement can be in another element then the value of the measurement. This mapping between SNOEMD attributes and where they are in the archetypes must be done in some elegant way. That will be one of the added values of archetypes. Bert

19

I found this excellent document from GEHCO gehco.org. It refers mostly to FHIR but has some examples from openEHR, and I think the challenges and principals are pretty well identical.

http://www.gehco.org/wp1508/wp-content/uploads/2016/06/Powerpoint-FHIR-and-SNOMED-V0-92.pdf

I know CIMI has a key aim of trying to create the kind of iso-semantic models that Bert is advocating, and while this is a laudable objective, the challenge should not be under-estimated.

Ian

20

I’m not sure if it was clear from the above - the WHERE clause is testing for membership of a code in some EHR data in a SNOMED ref set, i.e. a value set of cancer diagnoses (or you could make it Lung cancer if you want). The (fake) concept code 42570301000090487 stands for an evaluated ref set, assumed to be known inside whatever terminology service the AQL service talks to. How the membership comparison is done may vary, with many possible implementations. the point is here that for already defined ref sets, we can just as the terminology service (or some cache) to determine membership. If we want inline ref set definitons then we need to potentially embed a ref set definition in the query, hence my reference to that IHTSDO spec. some of the needed ‘attributes’ can potentially derived from the SNOMED concept model and data might even be represented using SNOMED expressions. But, don’t forget, openEHR is for the whole world, not just the SNOMED world. Much of the world doesn’t use SNOMED CT. So such mappings have to be done in archetypes, and only directly represented in data for those locations that really do have SNOMED. We have not worked out all the tricks to make it work for both worlds. Indeed. Ideally we would work more closely with IHTSDO on this (I spent 4 y on standing committees there), but I think there is not yet the interest in this. There are still people who believe that a) SNOMED CT on its own, with only trivial data structures is all that is needed (that’s a categorical error of thinking) and/or b) that the whole world uses SNOMED CT and that therefore the only terminology approach is SNOMED CT (an error today, and I suspect for years to come). But there are certainly things we can do to improve on our side, including: