New members:

Jeremy Rogers - UKTC

Jeff Pierson - IMO

Continuing:

Keith Campbell - US VA

Based on requests from UKTC:

The concepts are 
726018006|Autosomal dominant medullary cystic kidney disease (disorder)|
723373006|Autosomal dominant medullary cystic kidney disease with hyperuricemia (disorder)|
726017001|Autosomal dominant medullary cystic kidney disease without hyperuricemia (disorder)|

The FSN for these concepts align with Orphanet, OMIM and Genetics Home Reference.  The request from the UKTC is 

All terms should ideally be replaced by autosomal dominant tubulointerstitial kidney disease (ADTKD) (see KDIGO report). The above terms are not necessarily the same and don’t really reflect the improved clinical descriptions of the disease based on genetics. ADTKD reflects the inheritance, common phenotype caused by different mutations and can be used for suspected cases. This is well described in the KDIGO report. They also make the point it is a simple term to use and that MCKD is frankly inaccurate!

As above. I would favour not using these terms MCKD 1 and 2 even though they may be commonly used at present. ADTKD-UMOD or ADTKD-MUC1 would be the preferred names. The list of genes is also increasing making a single term more appropriate.

ADTKD would be the parent and the children would be ADTKD associated with UMOD mutations and ADTKD associated with MUC1 mutations.

It is anticipated that this type of request will become more frequent as the move towards genomics continues.

Question: Do we go with the current naming convention to align with Orphanet (our current "Source of truth") or try to keep pace with the evolving nature of content in this area? Do we change the FSN or inactivate and replace?

Discussion: How fast does the source of truth get updated? If rapid, then should we just wait until the source updates its material. If the update cycle is long, then best to update as changes appear.

If the latter, then should we wait until a member identifes the issue?

KCA recommends using the refset mechansim to identify the source of truth so that we can identify when a definition or concept activity changes.

This might be related to a prior discussion on the use of references to definitions. It also relates to the representation of authoritative sources. The list of authoritative sources needs to be available to editors. Modularization of SNOMED may allow for assignment of authoritative sources to each module.

WRT changes in FSN, inactivation for minor changes creates a lot of churn that does not provide a lot of value. We may want to retain the concept if the change to the FSN does not change meaning and is non-substantial.

PAM - Should we be relying on a a single source of truth for specialist areas?

There are clinical areas of rapid evolution and SNOMED needs to be active in that space or it will be fulfilled by other sources. Create clinical reference groups to address each of the areas? Need a strategic approach to the general case of rapidly evolving domains.

GRE - This relates to authority dependent content that we had in the past. Whatever we select should be responsive and have minimum characteristics that meet the changing needs of the terminology, or ability to interact and influence them to meet our needs, should not be any IP restrictions.

We cannot expect our modelers to become "experts" in all areas. Need access to CRGs and become knowledge engineers. providing accurate representation of the content. The old model of domain expert modelers maynot be feasible in the future.

WRT URU - If we have concepts that are not reproducible (i.e. able to be found when needed). then we have not met the URU requirements. Need to meet our users requirements. Any source of truth should be responsive and maintained.

Editorial guidelines need to be updated to reflect the requirements for inactivation and replacement.

Creation of annotation refset? May be limited if restricted to English. Need additional description types for international support of translation.

The clinical reference groups or consensus process needs to replace the current domain expert editor model.

Note: recommendation to not allow ASSOCIATED WITH relationships

 This was initiated from a request for “Reduction of soft tissue for auricular prosthesis”.  There is currently the concept 410771003|   Surgical procedure for clinical finding and/or disorder (procedure), which has 156 direct descendents.  The use of the HAS FOCUS attribute allows for the reason for the procedure to be modeled.  A recent set of diagnostic imaging procedures that included the reason the procedure was being done resulted in an editorial decision to disallow the future addition of precoordinated reasons for procedure.  Recent discussions with editors have questioned whether this is necessary given the spate of requests for this type of concept. 

Concerns from the HoT include:

1) the potential high number of precoordinated terms that would be created if every reason for a procedure were allowed;

2) the reason for a procedure should be captured as a separate clinical finding to document that the “diagnosis” has been established. Precoordinating the reason precludes the need for separately documenting that the condition exists in the patient;

3) some reasons provided for procedures may be so vague as to provide little additional information.  (e.g. Radiography of upper limb for musculoskeletal disorder).

KCA: Opinion is that we should not add the reason for the procedure to the pre-coordinated and leverage the supporting information model to capture the relationships (e.g. CIMI, FHIR). The reasons for procedure may change requiring a lot of maintenance.

GRE: Agrees that combining indication with procedure should be captured elsewhere. Generally you do not add to a procedure things that do not change the way the procedure is performed. E.g. "Skin prep for X"

A potential exception is when the reason changes the nature of the procedure. E.g. reduction of shoulder dislocation (based on the way the reduction is performed).

Should not contaminate the terminology with things that should go into the information model. There has been some overloading of HAS FOCUS and should be reviewed.

BGO: In the KP model, need to have the procedure and the reason for procedure for billing. This is sometimes difficult to capture. But in general, agrees with not pre-coordinating.

PAM: Agrees the the pre-cooridnation should not be allowed, but relying on the information model may not be universally acceptable.

Post-coordination on how to represent these should be provided to users to encourage them to leverage this type of concept.

KCA: Do we have a reproducible meaning for "primary" that does not drift over time?

GRE: We cannot determine that a procedure is primary or not unless we know that a prior procedure has been done in the past. The basis of the knowledge of what is primary or not is dependent on the prior condition of the patient (revision or not). There are a number of multi step procedures, but would each step of these procedure be primary as well?

This similar to "recent" conditions that is a vague notion that is not universally understood. It would be defined in the context of the entire record. There may be some exceptions, but the existing terms can be reviewed for inactivation. Only when a procedure is defined by a revision can this content be allowed.

BGO: Agrees with not creating additional primary procedures. The unspecified procedure should be interpreted as "primary"

PAM: THE UK extension has about 1500 "primary" procedures. The domain where this is needed is plastic surgeons and is needed for quality reporting. Agrees with the prior discussion, but there may be exceptions for specialist surgeons where primary might have a specific meaning.

GRE: You should not have a primary procedure if you do not have a revision. So if a procedure only has one subtype of "primary" then they are semantically equivalent.

PAM: Would like more input from the royal college on why this terminology was recommended.

A question related to the SI position on the classification of "Apps" as devices. ISO has recently developed guidance on this, stating that computer programmes/Apps are for all intents and purposes medical devices if used for medical purposes.

What should be the SI position on this? Modeling impacts?

GRE: We have a de facto position as a software application is already a physical object. This is inherited from GMDN. They consider application as devices, but they may not be physical objects? So while we are by default considering them devices, they are not physical objects. Do we need an alternative representation or is it acceptable as is?

PAM: dependent on how we classify these there are liabilities. Legal issues. Where does the liability lie if someone depending on these applications has a problem.

GRE: No software developer would want his software considered to be a device. Currently we have software linked to devices. We have a "source of truth" from GMDN and they consider software a device. We have inherited this from GMDN and ISO is accepting these as devices.

PAM: Software is not a device in Canada or the UK.

KCA: SI should not take a position on whether it is a device or not, but assure safety of applications that use SNOMED. There is not a universal definition as to whether apps are devices or not.

PAM provided an example of where a software failure caused patient safety issues.

Extended discussion on the evolution of apps as commodities in personal health and the future developments.

Continued to Bratislava

8

A number of requests related to findings related to surgical skin wounds and pressure injury findings reveal an issue with current structure.  Most of the requested terms are Findings related to skin wounds, but currently 262526004 |Wound of skin (disorder)|is a disorder, so cannot be used as a parent for findings related to skin wounds.  There is currently 225552003 |Wound finding (finding)|, but it is not specific to skin.  262526004 |Wound of skin (disorder)|currently has 65 immediate subtypes, many of which could reasonably be viewed as findings (e.g. “Abrasion of X”).  

Need to make a determination of whether observations related to wounds (i.e. color, discharge, odor) should be placed in a subhierarchy different from the "Wound (disorder)" itself.

Continued to Bratislava

Currently we have many concepts in the specimen hierarchy that include “from patient”as well as those that do not include it as an ancestor.  Since the subject of record is the default for specimens, we would like to retire these apparent duplicates, but then we run into the problem of specimens derived from other sources such as donors or normal control patients. 

They cannot be subtypes if the intended meaning is “subject of record”..or can they, since the context is implied?  How do we structure the specimen hierarchy to account for this? 

What are the analytical implications of having different sources for specimens as subtypes of one another?

Continued to Bratislava

The Oxford comma is a comma added after the penultimate term in a list, e.g. For example "Disorder of head, neck, and shoulders". The purpose if its use is to make explicit the fact that the terms are part of a list. The editorial guide is silent about its use, but the example provided does not use the Oxford comma.

There are currently 347 FSNs in SNOMED CT that use the Oxford comma. Most of these are terms obtained from other terminology, such as ICD and nursing. There are 2500 FSNs that contain comma delimited lists, but do not use the Oxford comma.

Should SNOMED CT be consistent in the use of this grammar mark or maintain fidelity to the original source of the terms that do use it?

Continued to Bratislava