Screening archetypes and SNOMED mapping

[joostholslag]

What are your thoughts around snomed mappings for e.g. conditions in the screening archetypes?
We are using these archetypes to screen for specific conditions (e.g. diabetes mellitus) that relate to wound healing. It would be nice to do term bindings in the template and to record mappings in the data.
But we found it to risky in the end. Since mapping to the Diabetes Mellitus (disorder), other parties we integrate with, could (rightly) assume the default snomed context applies. And conclude the patient has an active diagnosis of DM, which is not the context of the screening. The context of the screening is a woundcare specialised nurse asks (or reviews the record) to screen for potential DM. And relevance to woundcare treatment is the most relevant decision criterium. This is not the same as a qualified persoon (MD) recording an active diagnosis and assuming it is is a clinical safety risk. It’s even worse for recording negative screening for diagnosis: “nurse: are you diabetic? patient: not that I know off” leading to a diagnosis of no diabetes. This is not the same as a test that ‘definitively’ proves absence of diabetes interpreted by a qualified and licensed clinician. And will lead to wrong clinical decision support recommendations.

The ‘history of DM’ snomed code is a better match. But even this has a temporal attribute of ‘in the past’ which I find confusing: it strictly says the disorder occurred in the past implying it’s not present anymore, but since DM is a chronic condition that rarely disappears, the practical implication could be the diagnosis was made in the past, but the problem is still present. But how to interpret:

Finding context → Known present

In the end we removed all term bindings from the template. But it is a pity though. Ideally I’d like to see the default context deprecated from SNOMED and leave contexts to the information model like openEHR. But maybe others have better ideas?

P.s. should we warn users in the misuse section of the screening archetypes against mapping snomed disorders and similar?

I’m especially curious for the thought of @mikael (a)

[mikael (Mikael Nyström)]

Hi,

@joostholslag

Since mapping to the Diabetes Mellitus (disorder), other parties we integrate with, could (rightly) assume the default snomed context applies. And conclude the patient has an active diagnosis of DM, which is not the context of the screening.

@joostholslag

Ideally I’d like to see the default context deprecated from SNOMED and leave contexts to the information model like openEHR.

SNOMED CT’s default context for the 404684003 |Clinical finding (finding)| and 71388002 |Procedure (procedure)| hierarchies are applied by default if it isn’t from the context obvious that another context is specified. As far as I know, there are no specifications about in what way the other context needs to be specified so the default context doesn’t apply. However, my understanding is that the other context needs to be specified in some kind of machine readable way.

I would therefore say that it would be too risky to in a long free text include “73211009 |Diabetes mellitus (disorder)|in the family” and assume that it is understood that the default context is not present and it is not the patient who has the diabetes mellitus disorder. On the other hand to include the concept "73211009 |Diabetes mellitus (disorder)| in a family history archetype would be enough to invalidate the default context and state that it is not (necessary) the patient who has the diabetes mellitus disorder.

@joostholslag

What are your thoughts around snomed mappings for e.g. conditions in the screening archetypes?
We are using these archetypes to screen for specific conditions (e.g. diabetes mellitus) that relate to wound healing. It would be nice to do term bindings in the template and to record mappings in the data.
But we found it to risky in the end. Since mapping to the Diabetes Mellitus (disorder), other parties we integrate with, could (rightly) assume the default snomed context applies. And conclude the patient has an active diagnosis of DM, which is not the context of the screening.

I have no doubts at all to use the 73211009 |Diabetes mellitus (disorder)| concept in the screening archetype. I assume that the screening archetype clearly states that it is a screening archetype and therefore states that the context is a screening and therefore SNOMED CT’s default context would not apply for the 73211009 |Diabetes mellitus (disorder)| concept. If any of the parties you integrate with understand the use of the 73211009 |Diabetes mellitus (disorder)| concept as a statement outside the screening, then there must be some error somewhere, like an incorrect mapping from your screening archetype to a FHIR profile or something similar.

(Do you intend to use the RM attribute provider to show that is is the patient and not the clinician that provides the information?)

@joostholslag

The ‘history of DM ’ snomed code is a better match

I would like to disagree here. It is true that the default context doesn’t apply to the concept 161445009 |History of diabetes mellitus (situation)|, since it doesn’t belong to the 404684003 |Clinical finding (finding)| nor the 71388002 |Procedure (procedure)| hierarchies. However, the formal definition of the concept is according to the graph below.

This imply that the only difference between the concepts 73211009 |Diabetes mellitus (disorder)| with the default context applied and 161445009 |History of diabetes mellitus (situation)| is that 73211009 |Diabetes mellitus (disorder)| is currently present and 161445009 |History of diabetes mellitus (situation)| was present in the past.

@joostholslag

The ‘history of DM ’ snomed code […] has a temporal attribute of ‘in the past’ which I find confusing: it strictly says the disorder occurred in the past implying it’s not present anymore […]

In this case you actually overestimate what the attribute 408731000 |Temporal context (attribute)| = 410513005 |In the past (qualifier value)| states. It states that the patient had diabetes mellitus in the past, but it doesn’t state anything at all about the current situation. This might look confusing, but (except for the default context) only information that is explicitly stated in SNOMED CT apply. This is in line with, for example, that the concept 11773411000119102 |Infected abrasion of skin of right thumb (disorder)| doesn’t say anything about if the left thumb is infected, uninfected or amputated.

(Of cause you can use your clinical knowledge to conclude that “diabetes mellitus in the past” makes it highly probable that the patient still has diabetes mellitus, but that “pregnancy in the past” does not necessary mean that the patient still is pregnant. However, that is another thing.)

@joostholslag

I’m especially curious for the thought of @mikael (a)

I am happy to answer.

[bna (Bjørn Næss)]

@joostholslag

What are your thoughts around snomed mappings for e.g. conditions in the screening archetypes?

Not sure if this is the same use-case. Anyway…

We have developed an application which supports the healthcare providers in their patient safety work. There are lots of focus areas like nutrition, risk of falling, decubitus and so on. For many of these there are OBSERVATION archetypes which defines the scoring or screening for the focus area.

To make the risk factors generic we translate the outcome from the specific screening measurements into a generic health risk. For this we use the health risk archetype combined with SNOMED-CT to define the risk domain and also the risk assessment.

One such template is the risk of falling. Here we use STRATIFY Falls Risk Assessment Tool as the assessment tool. The outcome is mapped in to a health risk of falling (SNOMED-CT::1912002) . The usage of SNOMED-CT here might be odd. What we want to express is that there is a risk for a fall event in the future for this patient. And the risk is graded into low, moderate or high. The grades use SCT qualifiers:

• Mild risk of
• Moderate risk of
• High risk of

The effect of this clinical modelling pattern is that the RISK is defined in a well known pattern. The clients doing AQL for specific risk areas do not need to know about all the specific assessment tools. And the health care provider might use different assessment tools. The risk is defined the same way across all applications.

Below I have attached two screenshots. Sorry for the labels being in Norwegian. But I guess you get the idea
Risk of falling on the desktop client:

RIsk of falling on a mobile device (screenshot from an emulator):

[joostholslag]

Thanks a lot for your quick and elaborate answer. It was the final push I needed to read the SNOMED data entry guide you referred me to before. If I had done that earlier, I wouldn’t have had to ask this question. Sorry about that, and thanks again for your patience.
I do now understand that snomed coding of disorders/findings/procedures in this screening archetype is fine:D

@mikael

(Do you intend to use the RM attribute provider to show that is is the patient and not the clinician that provides the information?)

No, since the information provider will vary (patient memory, his wife, EHR etc) and it’s meant as a quick data entry form, we don’t want to record it for now.

@mikael

concept as a statement outside the screening, then there must be some error somewhere, like an incorrect mapping from your screening archetype to a FHIR profile or something similar.

Yes, I now get that this mapping is the moment we should be careful. But since many parties (integrators, customers, consultants etc) have direct database (read) access in our software, this problem is bigger than FHIR. Since most are not experienced health informaticians. But this problem is not unique to snomed encoding.

You also convinced me on not using the ‘history of’ and thanks for explaining that the ‘history of’ only overrules the default context of occurring at present by specifing the finding occurred in the past. But not that it is now inactive, there can be no assumption of the present occurrence by computers, right?

I’m still interested in your thoughts around the grey area between openEHR and snomed.
Learning more now, I still believe the snomed default context, and the other snomed terms that add context (like history of) are better left to information models for snomed to focus on meaning of singular concepts. Because I dislike the mixture of layers of abstractions. Especially because of the problems described in snomed “Search and Data Entry Guide” 6.2.2.
Until most of the world is on shared information models (like openEHR CKM), there’s off course a lot of value for snomed to fill the void:)

[mikael (Mikael Nyström)]

@joostholslag

Yes, I now get that this mapping is the moment we should be careful. But since many parties (integrators, customers, consultants etc) have direct database (read) access in our software, this problem is bigger than FHIR. Since most are not experienced health informaticians. But this problem is not unique to snomed encoding.

Ok. That kind of read access seems quite risky.

@joostholslag

You also convinced me on not using the ‘history of’ and thanks for explaining that the ‘history of’ only overrules the default context of occurring at present by specifing the finding occurred in the past. But not that it is now inactive, there can be no assumption of the present occurrence by computers, right?

Well, in this case yes, but not exactly due to that reason. The default context for clinical findings is

408731000 |Temporal context (attribute)| = 410512000 |Current or specified time (qualifier value)|, 
408729009 |Finding context (attribute)| = 410515003 |Known present (qualifier value)|, 
408732007 |Subject relationship context (attribute)| = 410604004 |Subject of record (person)|

and therefore apply to the concept 73211009 |Diabetes mellitus (disorder)|.

If we then have a look at de definition of the concept 161445009 |History of diabetes mellitus (situation)|we see that the definition contains the statements

408731000 |Temporal context (attribute)| = 410513005 |In the past (qualifier value)|, 
408729009 |Finding context (attribute)| = 410515003 |Known present (qualifier value)|, 
408732007 |Subject relationship context (attribute)| = 410604004 |Subject of record (person)|

If we then compare the default context for the concept 73211009 |Diabetes mellitus (disorder)| with the definition of the concept 161445009 |History of diabetes mellitus (situation)|we see that the only thing that differ is the attribute value to the attribute type 408731000 |Temporal context (attribute)|. For the concept 73211009 |Diabetes mellitus (disorder)| the attribute value is 410512000 |Current or specified time (qualifier value)| and for the concept 161445009 |History of diabetes mellitus (situation)| the attribute value is 410513005 |In the past (qualifier value)|. That is why it is only the temporal context that differs between those two concepts.

@joostholslag

I’m still interested in your thoughts around the grey area between openEHR and snomed.
Learning more now, I still believe the snomed default context, and the other snomed terms that add context (like history of) are better left to information models for snomed to focus on meaning of singular concepts. Because I dislike the mixture of layers of abstractions. Especially because of the problems described in snomed “Search and Data Entry Guide” 6.2.2.
Until most of the world is on shared information models (like openEHR CKM), there’s off course a lot of value for snomed to fill the void:)

I agree with the view that we should try to avoid to use the 243796009 |Situation with explicit context (situation)| hierarchy in SNOMED CT when we bind concepts to archetypes. That hierarchy is mainly built for information systems with weaker information models than openEHR based information systems. And when we bind concepts directly to archetypes the default context probably never apply.

[mikael (Mikael Nyström)]

@joostholslag

You also convinced me on not using the ‘history of’ and thanks for explaining that the ‘history of’ only overrules the default context of occurring at present by specifing the finding occurred in the past. But not that it is now inactive, there can be no assumption of the present occurrence by computers, right?

Sorry, I forgot this one. Yes, if SNOMED CT says History of X, you only know that X had occurred in the past, but nothing about the current situation. It would be possible to extend SNOMED CT with a decision support system and a knowledge base that help the user to interpret that a History of diabetes mellitus probably mean that the patient still has diabetes mellitus, but that a History of pregnancy probably doesn’t say that much about the current situation. But that is beyond the scope of SNOMED CT.