Comment on the rigidity of Editorial Policy / conflict with implementation requirements

SNOMED Groups Content Managers AG
1

Mid last year we submitted a concept to be promoted to core at the request of another NRC.

“Cervical screening test for human papillomavirus with specimen self-collected by patient (procedure)”

I’d like to have some open discussion on whether the editorial guidance adequately serves real-world clinical needs – especially those of members working with implementers.
We (AU NRC) still have this concept, so the rejection doesn’t really impact us. But I expect the NRC that requested will probably recreate it also now. With others sure to follow. And my concerns below aren’t specific to this concept, but it serves as a good example.

The request was rejected with a number of reasons.

  1. New additions are not accepted into the evaluation procedure concepts (see the “Observable entity vs Evaluation procedure” section of EG.
  2. Also this concept includes a description that describe processes that are not intrinsic to the “procedure”, i.e. who collected the specimen.
  3. Descriptions include past tense “collected” rather than “collection”.
  4. The PCP pattern “Screening for (procedure)” is not accepted.
  5. Descriptions includes “patient” rather than “subject”.
  6. The PCP pattern “Procedure on specimen” is temporarily not allowed.

Supporting links were provided (which are no longer valid post tooling changes – and I’m not denying there’s documented editorial guidance supporting these positions)

Regarding the specific reasons for rejection:

  1. I’ve previously expressed by disagreement with the future of “Observable entity vs Evaluation procedure” (but here it is again)

    • They are not the same. On OE is an inherent property (a person’s blood pressure) the EP is the action to measure something (perhaps an OE).
      I get that many look very similar - |Glucose measurement, blood (procedure) | & |Blood glucose concentration (observable entity)| - especially when the procedure is evaluating a single observable entity.
    • But many substances and products look similar too |Amoxicillin (substance)| & |Product containing amoxapine (medicinal product)|. Similarly, |Wound (morphologic abnormality)| & |Wound (disorder)| - they are different things within the ontology.
    • Many evaluation procedures are more complex e.g. |Wound microscopy, culture and sensitivities (procedure)| - is that an observable entity?
    • Imaging procedures, e.g. |Plain X-ray of neck of femur (procedure)| - I’m not sure how this could be perceived as an observable entity?
    • I know LOINC overloads things, and represents multiple things with the same id – but should SCT copy that approach?
    • I also understand there’s editorial challenges with knowing when to OE or EP for the 363714003 | Interprets (attribute) | attribute.

  2. This is not theoretical - it’s a distinct procedure now implemented in national screening programs across AU, UK, US, and EU

These differences are meaningful for clinical safety, not just billing. Self-collection vs clinician-collection has different clinical workflows, patient consent processes, and quality assurance requirements.

  1. Collection/collected – both can be valid. And in this case I think “self-collected” is used more as a future tense – the specimen will be collected by the patient.
    Either way, I don’t mind what the FSN is. Extensions will give it an appropriate PT. In this case the difference tense isn’t introducing ambiguity.

  2. I don’t understand why “Screening for (procedure)” would be prohibited.
    Screening vs diagnostic testing represents fundamentally different clinical contexts with different consent, risk-benefit calculations, and follow-up pathways.
    Similarly, the reason for doing test can sometimes be the only way to differentiate between very similar tests.
    Should this test just be “Cervical swab” ?

  3. “subject” in fine for the FSN (and modelling) - That might be what it is from a technical perspective, but words have impact – so “patient” is preferred for user interfaces. This is the language people use.
    This isn’t just preference - we have had stakeholder workshops where consumer representatives have objected to being called “subjects”.
    Patient-centred terminology improves health literacy and engagement with screening programs.

  4. Similar to 4. I’m not sure how you describe this test, without saying what sort of specimen is being collected and why?
    If there’s concern about combinatorial explosion with precoordination – there’s only so many types of specimens that can be collected for cervical HPV.
    If precoordination isn’t acceptable, what’s the recommended approach? There is a limit to what can be offloaded to Information models, and what impacts that might have on user experience when SNOMED is used as an interface terminology.

I’m concerned that there’s a growing tension between increasingly rigid editorial rules (and adherence to) that seem to be developed isolation (and often conflict with) the requirements of real-world implementations - clinically and technically.

Despite the well-meant intentions that I’m sure are behind these editorial positions - there’s a risk the core terminology becoming less useful, as things are excluded (and NRCs compensate with extensions).

Is SNOMED’s editorial framework keeping pace with implementation requirements? Is the editorial policy collaborative enough – do members have sufficient influence?

3 Likes
2

Thank you, @mcordell, for bringing up a complicated but very valid question.

It was myself, on behalf of the Norwegian NRC, who originally requested the lateral promotion of the Australian concepts regarding cervical HPV screening. We received a request from clinicians at a regional hospital for concepts representing cervical screening tests of different kinds. The clinicians are dependent on precise and correct concepts to ensure the proper billing, statistics and treatment route for the patients in question.

I want to add my support especially to the points you’ve made about OE vs. EP - the editorial advice for evaluation procedures has essentially been “don’t make or use them” for several years now, but they aren’t practically nor in principle the exact same as observable entities, in my opinion. We have several use cases, both in modeling new concepts and also representing procedures in EHRs, that aren’t really supported by the observable entity hierarchy design and logical definition.

We’ve felt the need to create several evaluation procedures in our national extension where we’ve deemed them necessary and appropriate. We still feel that the guidance for how end users (or even edition/extension managers) should practically use OEs rather than EPs is lacking. The current guidance thoroughly covers lab implementation, but we struggle with the needs of f.ex. the nursing community in describing nursing procedures.

Additionally, a lot of the evaluation procedures are, as you point out, complex and yet necessary in clinical practice. In a perfect world we could express all the components of how a clinician interprets information, but that would probably involve a combinatory explosion that most likely would do more harm than good. At the same time, we need to express the procedures in a way that is understandable and useful. I’d rather have primitive or minimally modeled concepts than nothing at all in the cases where “just using an observable entity” isn’t really an option.

Furthermore, I agree with the reflections regarding screening procedures. The contextual differences between a screening procedure and a diagnostic procedure are internationally aligned as far as I’ve been able to find, and the context of why a procedure/test was performed will impact the follow-up as well as inform registries and national programs in different ways.

In maintaining a terminology of this size, rules need to be stable and mostly quite strict. I completely understand and empathize with the need for logical models and adherence to principles and rules, and the burden that is already on the authoring team’s shoulders connected to this work. However, I hope that as both the people working with SNOMED CT and the terminology itself grows, we don’t immediately dismiss a discussion just because we’ve had it before.

The world around us is changing, the clinical needs change at a breakneck speed, and I hope we can ensure that our main focus is always to meet those needs to the best of our abilities and within the ontological principles deemed valid and appropriate at any given time.

1 Like