Proposal for deconflation of enzyme deficiency and the resulting disorder

Following discussion on the proposal:

enzyme_deficiency_briefing_v3.docx.pdf (187.8 KB) we seek answers from the EAG members on the remaining questions:

  1. Does the EAG endorse the backwards-compatible deconflation pattern — retaining existing conflated concepts as disease concepts and creating new concepts for the deficiency states?
  2. Does the EAG endorse Orphanet (preferred) and OMIM (secondary) as the authoritative sources for preferred disease names in this content set, with the terminological normalisation conducted category by category as part of the phased project?
  3. Does the EAG endorse the Deficiency of [enzyme name] (disorder) FSN pattern for newly created deficiency state concepts, and as the target pattern for terminological consistency review of non-conflated deficiency state concepts already in the release?
  4. Does the EAG agree that congenital and genetic parents belong on disease concepts only, and should not be applied to deficiency state concepts?
  5. Does the EAG agree that implementers must be explicitly warned — via release notes — that ECL expressions using <<129456006 will change behaviour after deconflation?
  6. Does the EAG agree that duplicate description warnings arising from description redistribution between disease and deficiency state concepts are expected artefacts that should not block release?
  7. Does the EAG agree that text definitions for same-name concept pairs are strongly encouraged but not mandatory, and that the formal model carries the primary definitional distinction?
  1. Yes from me
  2. Yes from me, but I have a suggestion for the roll out methodology: consider a first pass to process the most commonly used deficiency codes first en bloc, before moving to a category-by-category partitioning of the workload.
  3. Not sure. Unless the FSN is clearer about that concepts within <<129456006 correspond ONLY to the state of being deficient in an enzyme and NOT to any phenotype or syndrome that may result from that deficiency, then I suspect that the codes below 129456006 |Specific enzyme deficiency (disorder)| will still often be misused to mean the conditions they cause, under 410053003 |Clinical manifestation of enzyme deficiency (disorder)|. Deconflation of the concepts in the reference terminology won’t automatically prevent conflation of the terms in actual use.
  4. Yes from me: rationale is sound…although I suspect some clinicians will still ask why the vanilla “deficiency of enzyme X” concept is not a subtype of 782964007 Genetic disease (disorder) if enzyme X deficiency is empirically always of genetic origin and nobody has ever seen one that was not.
  5. Yes from me.
  6. Yes from me, as long as both duplicate descriptions are not concurrently the preferred term on their respective underlying conceptIds
  7. Unsure. The relationship between the two codes in each pair is presumably already going to be explicitly modelled, so it does not need to be restated also in human readable text definition. I’m also not really sure who either can or does see text definitions in live applications…so adding them here in the hope that doing so will reduce future miscoding and reconflation may frankly be wishful thinking and a waste of authoring resource. Having said that, the example pair of text definitions given could in theory be automatically generated from that underlying modelling, so the authoring effort would be very low. But unfortunatly the gain may still also be negligible!

Some additional questions/points to consider:

  • Separating deficiency from the syndrome will cause quite a bit of confusion to end users, I fear, who are used to equating them.
  • The briefing note does not say why we require separate concepts for the enzyme deficiency. In fact, it says it would be unusual for a clinician to record the isolated biochemical state of reduced enzyme activity. So - why do we need them? Is it to support better modelling?
  • Are we certain the deficiency should be a disorder and not a finding?
  • Descriptions: what if clinical use for a syndrome is X deficiency? From the example, it looks as if the compound is retained as synonym of the syndrome and the verbose grammatical form as PT of the deficiency. How many end users are going to understand this, how do you resolve the confusion? Using reference sets?
  • What action do you recommend translating countries to take if they cannot find separate translations? To leave the deficiency untranslated, copy the English term, adopt identical synonyms after all?

And my provisional answers to your questions:

  1. Yes
  2. I hesitate to say yes to Orphanet, because their Dutch translation is dreadful - literal, with no attention paid to recognisability. How are their English terms? Should we not look at literature and WHO instead?
  3. Yes.
  4. Yes. Presumably that means we will see no concepts called ‘congenital deficiency of X’?
  5. Oh yes
  6. This appears to contradict your example, which contains no active duplicate terms. I think any duplicates that you intend to resolve, ought to be resolved prior to publishing. After all, they are warning signs. Also, they will affect any Managed Service user trying to translate the concept.
  7. No… I’d say that a same-name concept pair ought to be an exception and cries out for a text definition, if only to show that it was done on purpose rather than accidentally. Otherwise it’s a matter of (short) time before some NRC logs a CRS ticket to report it as a duplicate concept.
  1. Yes.
  2. Possibly yes.
  3. Yes. FSN must be unambiguous and unique.
  4. Yes.
  5. Yes, this should be mandatory.
  6. Yes. Duplicate descriptions should be fixed before release wherever possible.
  7. Yes. Implementers / users have limited use of text definitions.