Inactivation Finding without replacement

Hi Katrien Scheerlinck I will look into this for you. Would you send the list you have concerns with to info@snomed.org and mark it attention to me. Kind regards, Cathy

Hi Cathy Richardson , we do not have a particular list. But this example was the one that always comes up. This illustrates also one of the following issues we have:

We are starting with an implementation of Snomed CT in Belgian primary care. At this moment, we struggle with the registration of the differences between a symptom, a disorder, a complain (patient perspective), ... Do you have any suggestions or help on this topic? 

thank you, Katrien

Hi Katrien Scheerlinck ,

Inactivations are not intended to be temporary. When inactivating a concept we following the guidelines here:Concept Inactivation. At times the value(s) used for the historical association will not have the semantic tag. The reason for this will depend on the specific scenario. 

The boundary between a finding and disorder is not always clear cut though we have the guiding principles to assist in determining:Clinical Finding and Disorder

In looking at the specific example you have provided dry skin concepts currently use a disorder tag and this may be something that needs investigation. Xeroderma means dry skin, which is why the inactivation occurred. 

In relation to your second question, some further information would assist us determining how best to help you. Is your question coming from a purely content perspective or are you looking for implementation guidance? Would you submit a ticket via info@snomed.org with a more detailed explanation please. 

Kind regards,

Cathy

Hi Cathy Richardson 

I would be interested to follow this discussion as we have had issues where General Practice have need to record non-specific things (pre further investigation) and require concepts like this.

It would be great if interested parties can be involved in the discussion as i'm sure it will be affecting others.

Thanks

Kylynn

There's two issues here..

1) In reality, clinicians (especially primary care) use non-specific language. Especially when describing presenting problems (often patient reported). I couldn't find a good example, so this probably needs collaboration with active implementation projects to identify problem concepts.

2) The whole Finding v Disorder issue... I think the different semantic tags are more confusing than they are helpful. If defining a constraints for "symptoms" "reason for presenting" or "diagnosis" etc - I'm not convinced the tags add much value so am inclined to ignore such circumstances.

283070004|Scratch of ear region (finding)|
283069000|Scratch of eye region (disorder)|
283067003|Scratch of face (finding)|
210987008|Abrasion of face (disorder)|
865918002|Edema of esophagus (finding)
51599000|Edema of larynx (disorder)|

There's a few things like 

24184005|Finding of increased blood pressure (finding)|
38341003|Hypertensive disorder, systemic arterial (disorder)|

where the tag might be helpful... But the information model is going to be better at making 'finding' vs 'diagnosis' distinctions.

Also, "Reason for presenting" usually also requires concepts from the "situation" and "event" hierarchies too..

So... to bring it back around... I think "Xeroderma" is probably an OK replacement for "Dry skin". But user experience is potentially a challenge depending on how it's implemented.

283069000|Scratch of eye region (disorder)| has a Due to attribute which makes it differ in its definition from the finding with a similar name. In this case its due to.. trauma and the traumas tend to be disorders. But both are fully/sufficiently defined so needs tidying up I agree. Agree with the thrust of Matt's examples but would point out that at the end of the day disorders and findings are both (clinical) findings. Keeping the subhierarchy does help as symptoms are often findings and then when a clinical diagnostic process (and the subsequent speech act) obtains, then work is done and the disorder subhierachy can be populated and defined and accessed eg for inferencing.

I note 16386004 | droge huid (finding)| or 16386004 | sècheresse cutanée (finding)| is still there on the snomed browser Belg edition, but prob not updated there yet. It is not fully/sufficiently defined. Katrien, If we are interested in secondary data use to not be precluding of clinical usability (and even worse data)we might allow fairly wide ranges/domains and hierarchies as Matt suggests.

Another example is 386661006|fever (finding)| which I have seen used as an example of the Emergency Room setting, where this finding can be the reason for presentation/complaint, triage term, ED working diagnosis and discharge/admit 'diagnosis'. Its not just GPs who deal in vagueness. Disorder concepts can take a while to become uttered.

Previous work in the UK was done in the past on a GP subset/refset. It may be an idea to peruse that to see how the hierarchies and subhierarchies are used. Are you mapping from ICPC or is that not used much?

Hi Peter, 

in fact, 16386004 | droge huid (finding)| or 16386004 | sècheresse cutanée (finding)| is included in an already updated version of the Belgian extension. We asked Snomed International to keep this concept active in our extension so we could still use it in our gp refset. This is also why it isn't fully/sufficiently defined anymore.

I find Matt's comment and reasoning interesting about defining meaning using the data model, instead of the terminology itself. We had the same discussion in our team over the past few weeks, but it is not entirely clear to us what the impact will be on data reuse (for example, in research) if we go against the principles of the terminology/ontological model via the data model. Or perhaps there are no implications? At this point, how to bind the terminology to the patient data model in the best possible way stays a question mark for us. 

I know that a lot of work has already happened in the UK in relation to SNOMED CT in GP settings, but if I remember correctly a lot of READ terms have also been kept active to deal with this vagueness. Or perhaps this was only an interim solution.

About ICPC: A selection of relevant GP terms in the Belgian GP subset is currently based on the registration frequencies of ICPC2 codes and local GP interface term use. The GP's want to keep using ICPC 2 for statistics in the future (SNOMED CT to ICPC2). But there is also a question to evolve to ICPC-3 in the future.

Kind regards, Katrien

Hi Katrien

yes to terminology deferring to the data model. So let the data model have elements called 'Complaint', and 'Diagnosis' and lightly constrain the value domain; as happy clinicians are (in general) the source of the universe of discourse of the data model.[But don't forget contingent truths such as those in clinical inferencing systems which can help us decide on grey areas such as Family history of..; laterality and Situations. ]

I think we may be in agreement about not splitting too finely between findings and disorders. It's a clinician's prerogative to use both, or neither; eg GPs will use procedure terms in problem lists , past history lists and in reason for encounter. GPs will prob want their ICPC2Plus-like interface for some time as clinical users just see the preferred terms in front of them. There is a balance between over-constrainting within ISO:11179-like value domains and losing the hearts and minds of your clinical user base. I like your term frequency bottom-up approach thus far. I hope your terminologists and data modellers communicate well and also that the GPs can see some clinical benefits for their terming efforts. 

From the secondary data use view, poor quality clinical terming data entry remains a prominent and ongoing concern for health information managers. There is a need to provide some context-aware guidance such as perhaps prompting for "acute" or "chronic" if the term is to be "bronchitis (disorder)" as these are different disorders not simply qualifiers on a bronchitis concept; but some data element refset scaffolding is required at the very least.

Metrics around what is a good level of data cleaning necessary for an appropriately constrained value domain; may exist to put some numbers on this balance. I'm thinking of precision and recall which are data science metrics in this regard.

In Australia there are multiple terming systems in GP software due to historical reasons whereby the GPs computerised first which is why I was wondering about UK experience. Sounds like Belgium has implemented SNOMED interfaces at the community level - congrats!

On meaning, data models have a kind of meaning-in-use, but it's implicit and we are ever-beguiled by names.  (?data dictionary anyone..)

The "reference" in a reference terminology/mathematical ontology such as SNOMED comes from reference theories of meaning. According to adherents such as Bertrand Russell, names are simply abbreviated descriptions and meaning comes from multiple true statements about unique existent objects. This is formal and fundamental and its why description logics work.

But why bother? Before we had computers we went from commonly used free text terms and phrases and a full free text clinical narrative to classifications. If robust communications evolved amongst subcultural parts of the health system, implicit meanings were mostly shared.

Now we might start with an assumption that computers are both everywhere and remain dumb, and while syntactical algorithms such as NLP gets us some of the way, that words possess meaning which is "URU" (Understandable, Reproducible and Useful) becomes formalised so that the maths works when computers use SNOMED. (That SNOMED is a UMLS-like hub on a wheel that other systems can map to is to demote SNOMED to just another hub candidate.)

Semantic messaging, terminology binding to detailed clinical models such as with FHIR or ISO:13606 or openEHR archetypes and clinical decision support need computers and their algorithms to be able to "look up" meaning.

cheers

Peter