On examination and Complaining of Content Information

CMAG advised 9 August 2016- no further updates to information provided here. Paged transferred to resolved topics at this point in time. 

Hi Cathy,

What could potential user requirements be to postpone inactivation? After the new release is published, they have half an year to update to the new version, it will come anyway as far as I understood?  

Thanks Elaine .

Johannes let me know if you've further questions.

Cheers,

Cathy. 

We are looking into this one actively now in NZ and obtaining feedback.

Elaine - may have to swap notes with you regarding the status of the UK Read to SNOMED mapping and your thinking on the way forward...

Cheers

John

Thank you Elaine for the clarification.

For Switzerland we do not have such timing requirements then.

Cheers

Johannes 

No timing requirement at this point in time from Norway.

Regards, Jostein

Hi All, After a wide polling within NZ there appear to be no immediate concerns regarding the proposed changes. Users will review how they are using SNOMED for issues related to O/E and C/O, including the biggest user of the UK Read to SNOMED map  (our Accident Compensation Corporation). Therefore no additional timing requirements beyond what the UK has proposed.

Cheers

John

Hi Cathy, Is there any indication of what exactly is planned for this content? Will it be retired? How?

E.g. 164530001 On examination - joint movement (finding)
Might be replaced with 
298179002|Finding of joint movement (finding)| OR 364563006|Joint movement (observable entity)|
(Depending on what it's supposed to mean?) 

As far as I can tell these are all findings, precoordinated with either "as reported by the patient" or "as seen by clinician".

If we know the destiny of these concepts extensions might be able to do something about them (so that they don't start getting used).

Matt Cordell -sorry for the delay here. The plan is to inactivate the concepts after checking the base finding concept exists. If the base concept does not exist it will be created. The inactivated O/E or C/O concept would have a historical association to the base finding concept. The one you've noted here 164530001 On examination - joint movement (finding) is a grouper. Where a base concept for those grouping concepts does not exist, the value of creating a "base" concept for those as well as editorial guidance would need to be considered The timing of this work is currently being discussed.

Cathy Richardson - can you please add CTR-3 to the agenda and update that ticket - Thanks

Just to confirm the UK have requested if this could be delayed until the July 19 release as it has significant impact on the Primary Care migration so we would be very grateful if this can be accommodated. 

Is there any update on this Cathy Richardson?
I'm keen to get rid of this content from our release but also take into consideration SI's eventual action?
It doesn't look like there's anything in the July19 release (daily build). Do you know what the reason for inactivation value will be? (outdated? ambiguous?)

Matt Cordell I'll be raising this at a meeting next week and will provide a response following this. Kind regards, Cathy

Matt Cordell Just advising that I am still following up on this. Given a UK public holiday the meeting did not proceed. I will come back to you shortly. Kind regards, Cathy

I looked for O/E and C/O in the value sets used in Clinical Quality Measures in the US. (Cursory inspection rather than detailed analysis),

A small number of O/E codes (50 or less) are used in value sets, primarily related to gait and respiratory issues. These codes are often used "in parallel" with similar finding codes not showing "O/E". For example 

163685000 | On examination - gait spastic (finding) |

vs.

9447003 | Spastic gait (finding) |

Arguably, the O/E codes are unnecessary in this context (and might not be listed if they were not children of the corresponding "regular" code).

Similar issue with C/O, but much fewer codes used in value sets (a small handful), also listed together with the corresponding "regular" codes.

In summary, the use of O/E and C/O codes in value sets seems redundant (and potentially accidental). Not essential in this context.

To answer Sheree's query about what our alternative is, such detail is generally captured in the information model.
So a "Presenting problem" field populated by the value 271807003|Rash| - would indicate the patient is complaining of (presenting with/complaining of/Reason for presenting) a rash.

Whereas a "Diagnosis" or "Observations" field populated by the value 271807003|Rash| - would indicate the clinician has observed a rash.

This for any use cases where making a distinction between patient or clinician reported findings - one would query the appropriate field.

Similarly to Olivier's observations - some of our reports on SNOMED usage in the wild include both O/E and "regular" concepts. But this is generally because both have been available, and clinicians will just pick whatever.

I know this discussion is from a couple of years ago, but we've just started updating our extension with the January 2021 release, and I'm seeing a few of these simply retired as "moved to extension". There's at least 60

I was expecting the change to be "to inactivate the concepts ...(and)... have a historical association to the base finding concept."

There's 2112, so it seems very intentional...

Hi Matt Cordell,

All these concepts (O/E and C/O) were returned to the UK extension. At this point in time we can not add a second relationship when moving them to an extension but where necessary a new base concept had been previously added.

By the way the inactivation working group material is going to be discussed at the EAG which runs later today (or tomorrow early for us):2021-02-24 Editorial Advisory Group Conference call

Cathy

Hi Matt Cordell,

The briefing paper on our proposals for updating the concept inactivation process will be available later today and I will include you in the circulation for feedback.

We have proposed that all MOVED_TO concepts should include an optional historical association to an "ALTERNATIVE" concept.

"The identified “ALTERNATIVE” substitute(s) are offered as semantically "sufficiently similar" to the original inactive concept, for certain unspecified use cases.

They may or may not be semantically equivalent to that moved, inactivated concept.

Best wishes, Paul

Thanks Paul Amos and Cathy Richardson,

The "Alternative" association sounds great. It's just unfortunate all these concepts were inactivated without using it.

Any users and records having the inactivated codes have find a replacement from scratch, possibly manually one at a time.
I'll just try identify the last parent for the concepts, which I'm hoping will give me a decent alternative for the majority.

I'd forgotten this discussion happened... but just had another customer asking us how to handle the inactivated codes in their data..
The "Moved to" association isn't at all helpful to them.
Is there any update? I can find anything on confluence about this topic beyond this page and associated discussion.

Hi Matt Cordell 

Are you referring to situations where the "moved to" association was used in general or the O/E and C/O content used this association? 

Cathy

Yes. Above it's mentioned twice that there'd be a historical association from the retired O/E and C/O concepts to useful "Alternative"
Since January 2021, there's been over 5000 concepts retired as "Component moved elsewhere". None of these have an accompanying "Alternative" association.

(Looks like about 2000 of these were O/E and C/O concepts, the others were mostly part of the 'breeds' project )

The historical associations are extremely useful for users (who usually aren't SNOMED experts) to find candidate replacements in their reference sets, value sets and historical data.