Time:
0100 - 0430 PST
0900-1230 UTC
Zoom Meeting Details
Topic: SNOMED CT Editorial AG (Open to Observers) (09:00-12:30 BST)
Time: Apr 4, 2023 09:00 London
Join from PC, Mac, Linux, iOS or Android:
https://snomed.zoom.us/j/82859206599?pwd=d1lmVDUyMm9odDlJeFBmeU1td0h4QT09
Password: 128420
Meeting ID: 828 5920 6599
Password: 128420
International numbers available: https://snomed.zoom.us/u/kk2fCQHDg
Or Skype for Business (Lync):
https://snomed.zoom.us/skype/82859206599
Attendees
Chair:
AG Members:
- John Snyder
- Feikje Hielkema-Raadsveld
- Matt Cordell
- Monique van Berkum
- James R. Campbell
- Jeff Pierson
- Monique van Berkum
Invitees:
Observers
Apologies:
Meeting Files:
View file | ||||
---|---|---|---|---|
|
View file | ||||
---|---|---|---|---|
|
View file | ||||
---|---|---|---|---|
|
Apologies:
Meeting Files:
View file | ||||
---|---|---|---|---|
|
View file | ||||
---|---|---|---|---|
|
View file | ||||
---|---|---|---|---|
|
View file | ||||
---|---|---|---|---|
|
Objectives
- Obtain consensus on agenda items
Discussion items
Item | Description | Owner | Notes | Action |
---|---|---|---|---|
1 | Call to order and role call | This meeting is being recorded to ensure that |
Meeting minutes:
The call recording is located here.
Objectives
- Obtain consensus on agenda items
Discussion items
important discussion points are not missed in the minutes. The recording will be available to the SNOMED International community. Joining the meeting by accepting the Zoom prompt declares that you have no objection to your comments being recorded |
| |||
2 | Conflicts of interest and agenda review | None noted. | ||
3 | Dose forms Briefing Note | A Briefing Note has been written to inform the community of practice about changes to the dose form modeling to include the use of newly published concentrate dose forms (added as required by the EDQM mapping project) in the modeling of clinical drugs in the International Edition of SNOMED CT. The intent is to gather feedback on a change to Editorial Guidance for clinical drug concepts with dose form of drops or spray (feedback to be received by 22th April). The document is attached to the meeting agenda above. |
DIscussion: The briefing note was presented and we have requested input on the proposal by April 22, 2023 | |
4 | Inactivation of Navigational concept hierarchy briefing note |
At risk concept modeling
updateBased on input from Monique van Berkum (document attached to agenda above) and the Gravity project, 13 "at risk" concepts submitted by the Gravity project were inactivated. Additionally, a recommendation to create the necessary pre-coordinated concepts for use in the HAS REALIZATION relationship for the At risk model has mitigated the current need to extend the range of HAS INTERPRETATION, for the purposes of modeling risk findings.
This remodeling has been performed and should be available in the May 2023 release.
The full model currently being used for "At risk" concepts is defined in the template located at: At [qualifier] risk of [finding/event] (finding) - Ready for review
High vs. increased and Low vs. decreased
Based on discussion at previous conference call, 1144845004 |Risk of suicide decreased (finding)| has been inactivated and replaced by 394687007 |At low risk for suicide (finding)|. A new concept grouper 1279548003 |Finding of low risk level (finding)| has been created to aggregate low risk concepts. Decreased risk are no longer accepted due to ambiguity as to relative decrease vs. below an established normal level.
Many vague risk concepts have been inactivated and replaced with more explicit and specific concepts (e.g. 409046006 |Perinatal risk (finding)| replaced by 1269553009 |At increased risk for perinatal disorder (finding)|
Discussion:
- Jim Case to continue modeling based on revised editorial guidance.
Document by James R. Campbell related to risk calculators is attached to the agenda.
The primary premise is that the "proper use of HAS_INTERPRETATION when INTERPRETATION has value of an Observable entity is that the valueset must adhere rigorously to datatype restrictions specified by the SCALE_TYPE defining the Observable concept." Additionally, the following extensions to the concept model are proposed:
1) Expand the valueset constraints for 719722006|Has realization (attribute)|
Note: Range for this attribute is currently << 272379006 |Event (event)| OR << 404684003 |Clinical finding (finding)| OR << 71388002 |Procedure (procedure)| OR << 719982003 |Process (qualifier value)|
2) Add a Risk property to <<118598001|Property (qualifier value)|3) Create a role hierarchy for 363713009|Has interpretation (attribute)| to support additional attributes including concrete domains and ordered refsets that are needed
for Quantitative and Ordinal or quantitative Scale types
4) Aligning with the editorial principles of LOINC, a policy for employing refsets defining the valuesets for observable entity concepts with scale type of Nominal, Ordinal and
Ordinal or quantitative. These refsets would
At the 2023-02-27 EAG conference call, the EAG approved the inactivation of the Navigational concept hierarchy. The EAG members requested a Briefing Note for the Community of Practice outlining the rationale and steps for inactivation. The briefing note is attached for review. Update 4/4/2023: In discussions with the UK, it was discovered that the current use of Navigational concepts are the result of maps from Read version 2 to SNOMED provided to primary care vendors. The erroneous nature of the maps may be a result of the movement of concepts from their original location in the taxonomy to the Navigational concept hierarchy at variable times in the past. Examples: Concept Original hierarchy Moved to Navigation hierarchy 160237006 History/symptoms (navigational concept) Context-dependent category 2006-01-31 309157004 Normal laboratory finding (navigational concept) Findings 2009-07-31 267368005 Endocrine, nutritional, metabolic and immunity disorders Disorders 2003-01-31 243800003 Test categorized by action status (navigational concept) Context-dependent category 2010-01-31 250541005 Biochemical finding (navigational concept) Findings 2009-07-31 The UK will provide SNOMED International with a list of mappings to navigational concepts and their current use cases. SNOMED will provide replacement concepts for these prior to inactivation of the navigational concept. Briefing note will be revised to reflect this new information. Discussion: Review of the proposed inactivation based on the new information from the UK. Decision: SI will update the briefing note to reflect the new information and distribute it to the EAG, CMAG and Clinical leads groups. |
| |||
5 | At risk concept modeling update | Based on input from Monique van Berkum (document attached to agenda above) and the Gravity project, 13 "at risk" concepts submitted by the Gravity project were inactivated. Additionally, a recommendation to create the necessary pre-coordinated concepts for use in the HAS REALIZATION relationship for the At risk model has mitigated the current need to extend the range of HAS INTERPRETATION, for the purposes of modeling risk findings as well as eliminated the need for a DUE TO relationship that resulted in inconsistent modeling patterns. This remodeling has been performed and should be available in the May 2023 release. The full model currently being used for "At risk" concepts is defined in the template located at: At [qualifier] risk of [finding/event] (finding) - Ready for review High vs. increased and Low vs. decreased Based on the discussion at previous conference call, 1144845004 |Risk of suicide decreased (finding)| has been inactivated and replaced by 394687007 |At low risk for suicide (finding)|. A new concept grouper 1279548003 |Finding of low risk level (finding)| has been created to aggregate low risk concepts. Decreased risk concepts are no longer accepted due to ambiguity as to relative decrease vs. below an established normal level. Many vague risk concepts have been inactivated and replaced with more explicit and specific concepts (e.g. 409046006 |Perinatal risk (finding)| replaced by 1269553009 |At increased risk for perinatal disorder (finding)| Discussion: Jim Case updated the group on the changes to "At risk" findings based on previous discussions with the EAG. Decision: It was determined that for this use case, there is no need to consider changing the range of the HAS INTERPRETATION attribute to support Clinical findings or Procedures. |
| |
6 | Expansion of the range of HAS INTERPRETATION | James R. Campbell | Document by James R. Campbell related to risk calculators is attached to the agenda. The primary premise is that the "proper use of HAS_INTERPRETATION when INTERPRETATION has value of an Observable entity is that the valueset must adhere rigorously to datatype restrictions specified by the SCALE_TYPE defining the Observable concept." Additionally, the following extensions to the concept model are proposed: 1) Expand the valueset constraints for 719722006|Has realization (attribute)| Note: Range for this attribute is currently << 272379006 |Event (event)| OR << 404684003 |Clinical finding (finding)| OR << 71388002 |Procedure (procedure)| OR << 719982003 |Process (qualifier value)|
In reference to content development in the International release, the following must be considered:
Discussion: James R. Campbell described the use of risk calculators at UNMC. One question that had arisen was the editorial decision to not include a value for the SCALE attribute to Observable entities in the international release. This was due to the fact that the "expected" scale was adequately described by the PROPERTY attribute value, and the TECHNIQUE attribute value as well as the observation that many of these risk calculators allowed for either a Ordinal or quantitative value. However, the Regenstrief/SNOMED agreement obviates much of this as the LOINC extension will necessarily contain SCALE TYPE as that is a required LOINC part in the definition of a LOINC term. A discussion ensued on the need to create clinical findings that represented the combined observable-value that is represented by the INTERPRETS/HAS INTERPRETATION relationship group. This did not seem to be the way that the data are collected in the EHR. However, it was recognized that there is a need for clinical findings to be used as members of a value set bound to an observable to support assessments. Decision: The discussion ended with consensus that there is no compelling use case at this time to expand the range of HAS INTERPRETATION at this time. The need to revise the editorial policy related to the inclusion of SCALE TYPE in modeling observable entities in the International release will be re-evaluated by the SNOMED content team. | |
7 | Mechanical Complication of device | Jim Case | Should "Mechanical complication of device" be a disorder or a finding? Current situation: 111746009 |Mechanical complication of device (disorder)| has 215 subtypes, all of which refer to a failure of a device without specifying a deleterious effect on the patient. e.g. 285961000119107 |Mechanical breakdown of prosthetic heart valve (disorder)| We also have disorder concepts that refer to a patient condition due to mechanical failure of a device e.g. 5053004 |Cardiac insufficiency due to prosthesis (disorder)| Without specifying the resultant condition associated with device mechanical issues, is it appropriate that these are represented as patient disorders, or should they be findings that may be related to disorders in the patient? A briefing note using "Leakage of device as an example is located here. Discussion: Without an associated condition in the patient it is unclear whether there is an adverse impact on the patient. In general, if the device is implanted, it can be assumed that there is a negative impact. These should be retained as disorders. Each of the subtypes would need to be evaluated as to the potential impact on the patient. 2023-04-04 Additional issues and questions:
Definition provided by John Snyder - "Medically implanted devices refer to any manufactured device, prosthesis, or biological construct that is surgically implanted into or physically attached to the body to aid in the diagnosis, treatment, or monitoring of a medical condition". Discussion: Implantable devices might be considered as a type of body part, thus a disorder of the device would of necessity cause a problem in the patient and should be a disorder. While there may not be a morphological abnormality, there is an abnormality of the device. Is a new attribute needed to represent device abnormality? This discussion is restricted to medical devices and not transplanted tissues and organs. Some implantable devices are not prostheses. With reference to a proposed definition, what does physically attached mean? Look at how FHIR has addressed this. Should imply some introduction method, rather than just an attachment to the body. The top level concept could be moved to clinical findings. There is an issue with the term "complication". Subtypes would be individually reassessed. Propose that the disorder boundary start with mechanical complication of implanted device. Kin Wah will provide documents related to a discussion on implantable devices. Update 2023-04-10: Upon investigation, as expected, these concepts (i.e. Mechanical complication) are classification derived (ICD-9, ICD-10, and ICD-11) and refer to injury or harm to a patient caused by a failure, breakdown, or malfunction of a device. Coding guidance indicated that (for ICD-11) the disorder caused by the mechanical complication should be coded first and then associated with the device. Thus, the intended meaning of these concepts imply a disorder in the patient due to some issue with the device. The actual terms are index terms in the ICD. Example: PK91.22 Cardiovascular devices associated with injury or harm, mechanical or bioprosthetic valves (ICD-11) Index term: Mechanical complication of heart valve prosthesis This would suggest that these concepts are correctly placed in the taxonomy, and they are currently mapped to ICD disorders (i.e. injury or harm to patient) but are possibly not modeled sufficiently to express the implied meaning. A new approach to modeling these concepts will be undertaken to clean up this sub-hierarchy. Definition of device malfunction from the US Code of Federal Regulations TITLE 21--FOOD AND DRUGS, CHAPTER I--FOOD AND DRUG ADMINISTRATION, SUBCHAPTER H - MEDICAL DEVICES | |
8 | Intermediate primitive parent and definition status of subtype | Review of Glossary definition for "Sufficiently defined concept". See sufficiently defined concept Additional information on Necessary and sufficient conditions: D.2 Necessary and Sufficient - Examples Can a concept be sufficiently defined if part of the meaning of the FSN is captured only in the wording of a stated primitive parent, not in defining attribute-value relationships? For example: Joint laxity (finding) is primitive since it has no defining relationship(s) that capture the "laxity" aspect of the FSN meaning. Many of its subtypes (e.g. Elbow joint laxity (finding), Hand joint laxity (finding) etc.) are modeled as sufficiently defined based on the stated parent Joint laxity plus the finding site relationship specifying the joint involved? Inconsistency between the Editorial Guide and the SNOMED Glossary: Current Editorial guide states "A concept is sufficiently defined if its defining characteristics are adequate to define it relative to its immediate supertypes". It is not clear whether "defining characteristics" here refers to defining attribute-value relationships specifically or to the logical definition as a whole.
The SNOMED Glossary states: ""A sufficiently defined concept has at least one sufficient definition that distinguishes it from any concepts or expressions that are neither equivalent to, nor subtypes of, the defined concept".
The Glossary also states "Prior to July 2018, SNOMED CT could only support one sufficient definition for each concept could not represent the 8801005 | Secondary diabetes mellitus (disorder)| example above(Note: this example is no longer valid and needs updating in the glossary). A further limitation, that also prevented formal representation of that example was the stated relationship file was only able to represent necessary conditions.".
Lastly, there is a statement: "Following these changes a concept will only be marked as sufficiently defined if it is sufficiently defined by relationships. However, the OWL axioms may provide a sufficient definition that cannot be fully represented as relationships."
Discussion: Concepts with identical definitions aside from the Definition status may be classified as supertype/subtypes, due to the limitations of the concept model to allow for more robust definitions. This is being left with the EAG for additional comments to be reviewed at the April meeting. There is a question about whether the browser can be modified to show an icon that can identify a concept as having GCIs. A question will be forwarded to the tech team. Update 2023-03-26: The current SNOMED Browser displays concepts with GCIs in the stated diagram view; e.g.: Discussion (2023-04-04): The implied or explicit meaning of a primitive FSN can be used as part of the definition of a concept, regardless of whether it has defining relationships. Similarly, the definition status is also part of the sufficient definition as it implies that the definitional relationships are enough to distinguish a concept from all other concepts in the terminology. However, the current definitions do not take into account the move to axioms, i.e. a sufficiently defined concept would have an equivalence axiom. The axioms (equivalence or subclass) determine whether a concept is sufficiently defined or primitive. Concepts with GCIs usually represent sufficient definitions, but not necessary. Sufficiently defined concepts have at least two characteristics:
Concepts with GCIs represent a partial definitions which may or may not cover all of the possible meanings of a concept, but these are not equivalent class axioms and all of the GCIs are not inherited by the subtypes. A straightforward definition may be a concept that is defined is sufficiently defined by necessary conditions. 'Primitive' concepts only have necessary conditions, specified by subclass axioms. We still need better guidance on when to use GCIs and when to use additional axioms. |
| |
9 | Inspection vs. exploration actions | Jim Case | A query was posed as to the difference between 129433002 |Inspection - action (qualifier value)| and 281615006 |Exploration - action (qualifier value)|, both subtypes of 302199004 |Examination - action (qualifier value)|. The internal consensus was that these are clinically different with the former limited to visual evaluation and the latter implying an active examination. Various medical dictionary definitions concur with this view: e.g. Exploration - "An active examination, usually involving endoscopy or a surgical procedure, to ascertain conditions present as an aid in diagnosis. - Inspection - "The visual examination of the body using the eyes and a lighted instrument if needed. The sense of smell may also be used. - Gale Encyclopedia of Medicine. Copyright 2008 The Gale Group, Inc. All rights reserved." This would imply that surgical procedures would more frequently use exploration as the METHOD than inspection; however, this does not appear to be the case <<387713003 |Surgical procedure|:260686004 |Method| = 129433002 |Inspection - action| = 306 <<387713003 |Surgical procedure|:260686004 |Method| = 281615006 |Exploration - action| = 150 For non-surgical procedures the difference is more extreme (<<71388002 |Procedure| MINUS <<387713003 |Surgical procedure|):260686004 |Method| = 129433002 |Inspection - action| = 710 (<<71388002 |Procedure| MINUS <<387713003 |Surgical procedure|):260686004 |Method| = 281615006 |Exploration - action| = 220 Many of the non-surgical procedures modeled using inspection are some form of endoscopy. Given the definitions above and the consensus of the internal content development team, should SI undertake a project replacing Inspection with Exploration for surgical and endoscopic procedures? It is anticipated that much of this can be done automatically. Discussion: Need to review the definition associated with Inspection procedure and Exploration procedure. General consensus is that we do not change the modeling unless there is a clear distinction that can be applied other than what is expressed in the FSN. Explorations can be performed without visualization, but Inspections do require visualization. The current definitions on both need clarification as they imply a supertype/subtype relationship: 122458006 |Exploration procedure (procedure)| - An observation of the body or a body part done by inspection and/or palpation. 32750006 |Inspection (procedure)| - An exploration using the sense of sight, done with the eyes. Endoscopy/laparoscopy etc. all use a scope of some sort to visualize the body structures, so should use Inspection as the action. Almost all concepts that use Exploration - action have the word Exploration in the FSN. An associated question, based on the current definition in SNOMED of Exploratory procedure, should Palpation -action be a subtype of Exploration - action? |
In reference to content development in the International release, the following must be considered:
- On 2020-04-29 the EAG approved an editorial policy: When defining observable entities for the international release, the SCALE TYPE attribute will not be used. If extensions would like to add specific subtypes of observable entities that include the SCALE TYPE, they are free to do so.
When using observable entities to define clinical findings, international concepts that do not include a SCALE TYPE relationship would be used a values for the INTERPRETS relationship. The exception to this guidance are existing "vital sign" observable entities that have been defined with the SCALE TYPE of "Quantitiative". - The majority of Observable entities in the International release of SNOMED CT are not modeled, so Scale Type is not available.
- There are currently no International concepts that require concrete values for HAS INTERPRETATION
- It is not possible to support both concept based values and concrete values in the same range for a scale type such as "Quantitative or Ordinal"
Discussion:
Should "Mechanical complication of device" be a disorder or a finding?
Current situation:
111746009 |Mechanical complication of device (disorder)| has 215 subtypes, all of which refer to a failure of a device without specifying a deleterious effect on the patient.
e.g. 285961000119107 |Mechanical breakdown of prosthetic heart valve (disorder)|
We also have disorder concepts that refer to a patient condition due to mechanical failure of a device
e.g. 5053004 |Cardiac insufficiency due to prosthesis (disorder)|
Without specifying the resultant condition associated with device mechanical issues, is it appropriate that these are represented as patient disorders, or should they be findings that may be related to disorders in the patient?
A briefing note using "Leakage of device as an example is located here.
Discussion:
Without an associated condition in the patient it is unclear whether there is an adverse impact on the patient. In general, if the device is implanted, it can be assumed that there is a negative impact. These should be retained as disorders. Each of the subtypes would need to be evaluated as to the potential impact on the patient.
It was suggested at a recent Modeling Advisory Group meeting that SNOMED should consider inactivating the 363743006 |Navigational concept (navigational concept)| hierarchy. A list of 635 primitive concepts that are unable to be defined due to their highly contextual use. The concern is that because they are more or less "orphan" concepts, and provide no analytical advantage, they would be discouraged from use in medical records. However, because many of these descriptions are those that are commonly used in clinical records, with organizationally specific meaning, they are being entered into EHRs.
UK has high usage of a few of these:
CONCEPTID FSN USAGE 2011-2022
394617004 Result (navigational concept) 48,227,610
160237006 History/symptoms (navigational concept) 10,146,392
309157004 Normal laboratory finding (navigational concept) 581,209
267368005 Endocrine, nutritional, metabolic and immunity disorders 160,475
243800003 Test categorized by action status (navigational concept) 108,176
250541005 Biochemical finding (navigational concept) 100,632
It is unclear how these are used in clinical records although from the above list it appears they may be used as document headers . An inquiry to the UK resulted in an interesting observation that some of these highly used concepts are primarily found in only one of two major primary care systems, and some that were not used much a decade ago are beginning to increase in usage. It was proposed to SNOMED that aside from the highly used concepts above, the remainder of the navigational concepts could be inactivated without much impact on users. However, we would need to consider carefully before inactivating the above concepts without suitable replacements due to their high, albeit incorrect, usage.
Question: Should these be replaced with Record artifact concepts or something else?
Discussion:
The NL and AU have not approved the use of navigational concepts. IMO does not recommend use of these. The more general question is whether to inactivate navigational concepts as a whole. The consensus was that that these should be inactivated. Because there are concepts of high use in the UK, they will be contacted and informed of the impending inactivation. Potential replacement concepts for the high use concepts include:
394617004 Result (navigational concept) → 423100009 |Results section (record artifact)|
160237006 History/symptoms (navigational concept) → 371529009 |History and physical report (record artifact)|
309157004 Normal laboratory finding (navigational concept) → None (laboratory is a vague concept)
267368005 Endocrine, nutritional, metabolic and immunity disorders → None (arbitrary grouping)
243800003 Test categorized by action status (navigational concept) → None (meaning unclear)
250541005 Biochemical finding (navigational concept) → None (context dependent)
Update
Message sent to the UKTC, no response as of yet. Briefing note will be written once input from the UK is received.
Section of Chief Terminologist report to Content Committee June, 2010
Questions have been raised regarding editorial policy for Navigational Concepts. There are two main
questions:
1) What are the criteria for making a concept navigational?
2) Should navigational concepts be used for recording clinical data?
Navigational concept
These concept codes are to be used only as nodes in a Navigation Subset. They are not suitable for
data recording or aggregation.
The subclasses of Navigational concept have the following characteristics:
• They have no IS A subtypes.
• They have no IS A supertypes other than Navigational concept.
• They may be associated with other concept codes by the use of Navigation Links.
JTC Note: From the current SNOMED Editorial Guide: "...Navigational concepts were created to group other concepts without explicit regard for defining attributes (since there were none). Their purpose was to provide top level groupers for subsets and reference sets used in implementations. Because the Reference Set mechanism is now available, there is no longer a need for navigational concepts in the International Release; however, they can be added at the national or lower level."
The Content Managers Advisory Group comments indicate that these terms are not or rarely used (probably erroneously) aside from the few concepts in the UK listed above.
Discussion:
Many of these concepts provide some use, but because they cannot be defined they should not be within the SNOMED taxonomy. For replacement values for high usage, we will determine whether a replacement is needed. Consensus that these concepts be inactivated and a briefing note created for the CoP.
Review of Glossary definition for "Sufficiently defined concept". See sufficiently defined concept
Additional information on Necessary and sufficient conditions: D.2 Necessary and Sufficient - Examples
Can a concept be sufficiently defined if part of the meaning of the FSN is captured only in the wording of a stated intermediate primitive parent, not in defining attribute-value relationships? For example: Joint laxity (finding) is primitive since it has no defining relationship(s) that capture the "laxity" aspect of the FSN meaning - but can its subtypes (e.g. Elbow joint laxity (finding), Hand joint laxity (finding) etc.) be considered to have a sufficient definition based on the stated parent Joint laxity + their finding site relationship specifying which joint is involved? Currently they are all primitive, but some subtypes of Laxity of ligament are defined on the basis of their intermediate primitive parent and their finding site.
Clear, explicit editorial guidance is needed on this question. The statement here "A concept is sufficiently defined if its defining characteristics are adequate to define it relative to its immediate supertypes" is somewhat ambiguous, since it's not clear whether "defining characteristics" here refers to defining attribute-value relationships specifically or to the logical definition as a whole.
- the phrase "relative to its immediate supertypes" would seem to argue against making a concept defined based in part on information in the FSN of an intermediate primitive parent (since a parent concept, as an immediate supertype itself, obviously cannot contribute to define its own subtype relative to itself. However, that implication may be an artifact of imprecise wording rather than representing actual editorial policy.
If information represented in the FSN of a stated intermediate primitive parent can be considered to fill a gap in meaning left by the defining attribute relationships, I think that policy should be clearly stated (and ideally illustrated with an example) either here or under Intermediate Primitive Concept Modeling. (Whichever section the guidance is placed in, it might also be helpful to add a "See ____" link to that guidance in the other section as a kind of cross-indexing).
- The SNOMED Glossary states: ""A sufficiently defined concept has at least one sufficient definition that distinguishes it from any concepts or expressions that are neither equivalent to, nor subtypes of, the defined concept". Is "definition status" of a concept part of the definition of a concept? Currently it acts in that way. This occurs when two or more concepts have the same defining relationships, but only one is marked as sufficient defined. Those that are not marked as sufficiently defined classify as subtypes.
- In some cases the SNOMED concept model is inadequate to "fully" define the meaning of an FSN, yet can provide a sufficient definition to make it unique within the terminology. In these cases the primitive subtypes with the same relationship have the necessary relationships, but not sufficient definitions.
- The Glossary also states "Prior to July 2018, SNOMED CT could only support one sufficient definition for each concept could not represent the 8801005 | Secondary diabetes mellitus (disorder)| example above. A further limitation, that also prevented formal representation of that example was the stated relationship file was only able to represent necessary conditions.".
- Proposed clarification: "Prior to July 2018, SNOMED CT could only support one sufficient definition for each concept, and the stated relationships comprising that definition could represent only necessary conditions. A concept such as 8801005 | Secondary diabetes mellitus (disorder)| , which can be caused either by a substance or by another disorder, could not be sufficiently defined within these constraints, since neither | Causative agent| | Substance| nor| Due to| = 64572001 | Disease| is necessarily true. Assigning the concept two sufficient definitions can, however, allow the full meaning of 8801005 | Secondary diabetes mellitus (disorder)| to be formally represented. (See sufficient definition)."
- Lastly, there is a statement: "Following these changes a concept will only be marked as sufficiently defined if it is sufficiently defined by relationships. However, the OWL axioms may provide a sufficient definition that cannot be fully represented as relationships."
- This has come about with the ability to model concepts with multiple sufficient axioms using GCIs. Proposed clarification: "Following these changes a concept will only be given a definition status of Defined if it is sufficiently defined by the stated relationships in a single axiom. However, multiple OWL axioms may provide a sufficient definition representing different sufficient but not necessary relationships. These concepts will retain the default status Primitive but function as sufficiently defined concepts that will subsume subtypes."
Discussion:
Concepts with identical definitions aside from the Definition status may be classified as supertype/subtypes, due to the limitations of the concept model to allow for more robust definitions. This is being left with the EAG for additional comments to be reviewed at the April meeting. There is a question about whether the browser can be modified to show an icon that can identify a concept as having GCIs. A question will be forwarded to the tech team.
- Jim Case to send a note to the MAG inquiring about the value of a new definition status that identifies a concept with GCIs
10 | AOB | EAG | ||
11 | Next meeting | EAG | Next meeting April 4. SNOMED business meeting | |