Date

25 October 2016

Location

Wellington, New Zealand

Attendees and Observers

See agenda page

1 Call to Order

Jim Case (JCA) welcomed the group.

2 Conflicts of interest

None declared.

3 Approval of 20160822

and 20160928 minutes

Approved without comment.

4 Disjunctive components

Review of the previous discussion and identification of remaining issues.  LOINC parts that contain the “+” sign have been identified as meaning “either or both”, which is not supported by the current DL constructs in SNOMED CT.  How to model observables that use these types of component values needs resolution.  Initial proposal based on discussions from the Observables Project recommended that these observable concepts be modeled as primitives and that the component relationship be left out of the model.

Discussion: GRE suggested that the issue is whether these terms are clinically useful if fully defined.  With GCIs you can fully define some of these disjunctive concepts, but many of the concepts at issue are more like “apples and/or oranges”, which makes them less clinically useful.  Full disjunction is not a likely solution to the issue currently.  GRE mentioned that at the modeling group the main issue to be addressed is GCIs.  The issue is that a conjunctively defined concept is defined by its parents, while a disjunctively defined concept is defined by its children.  Thus you will have “monocytes” as a child of “Monocytes and/or macrophages”, which is an intermediate primitive concept, which has little clinical value.  Do we want a lot of these in SNOMED CT?  It is unclear whether there is value to trying to address these so they can be fully defined.

DKA identified that these concepts are LOINC parts needed to fully define the LOINC expressions, but GRE stated again that these might do more harm than good.  An alternative is to create them in an extension and classify them separately from the core using a full DL representation in OWL.  GRE mentioned that there are differences in importing extensions in OWL vs. RF2.  The challenge was identified and alternatives initially discussed, but the resolution can be postponed until a later date.

A summary by JCA stated that the discussion implies that technical changes to the core must be supported before we can begin adding these components to the core.  In the short term, there is a need to implement the observables model in the core.  So most of these issues must be handled outside the core.  What are the short term conclusions and what are the longer term solutions?

GRE – In the short term, extensions can address this as needed.

JCA – What about the core?  FAS said that the terms with “&” in them represented panels and were out of scope for the core, but those with the “+” sign are in scope and part of the agreement is that IHTSDO would find a way to represent these in the core. There are considerable impacts around adding these to the core and their influence on inferences.  Since we haven’t yet figured a way to handle these externally, should we revise our approach to adding these to the core.  FAS stated that at this time just adding the affected concepts as primitive would meet the immediate needs.  However, about 100 of these have already been added to the core.  What do we do with these?  JCA – question as to whether the ones that have already been added are valid as they are in the substance hierarchy as a combined substance, which these are clearly not.  We should consider that these were invalid to begin with and should be retired.

MCO – asked about the existing ratio concepts (e.g. BUN/Creatinine)?  DKA these would be represented as distinct attributes in the observables model.  However there is no tested solution that fits the core right now to handle these concepts.  Also, the management of the number of GCIs would be problematic.

JCA proposed that the disjunctive concepts that have been added to the substance hierarchy be inactivated. – agreed to by EAG members.

JCA proposed that any observables that might have used these concepts be modeled without the component hierarchy as be added as primitive concepts to the core – agreed to by EAG members.

JCA proposed that we refer the remaining issues to the modeling advisory group as it is not a content issue, but a modeling issue.  – agreed to by EAG members.

TMO asked whether this would be implemented for the 20170301 release? JCA indicated that this is dependent on available resources, but that it needed to be done at the soonest possible time.  In the meantime the editorial staff would be advised not to use the existing terms.

BGO asked how this would affect the combination drug products that are targets for allergies?  Most are modeled incorrectly as having both parents.  KCA stated that the difference here is whether the ALL restriction is being used.  If the SOME restriction is used then it is logically correct.  BGO stated that for allergies, the implication is one or the other, not either or. So the question is the modeling of the allergies, not the substances.  GRE says the solution again is GCIs.  BGO should we just remove the causative agent or leave them with both incorrect parents?  There are not many of these.  JCA recommended the same process be used here, i.e. make them primitive and remove the causative agent relationship.

FAS asked about a prior decision that was made regarding microbiology reporting in which we came to a different conclusion.  JCA recommended that this be tabled for a later discussion

5 Drug concept model meeting summary and discussion – TMO

TMO summarized the organizational issues that were addressed at the drug model meeting on the prior Sunday.

Final deliverables:

-        Concept classes with populated example

-        Terming and modeling guidelines

-        Clear position with respect to external standards (e.g. IDMP)

Major decisions about the model from the meeting

-        Will not support universal (ALL) restriction

-        Will not support nesting

-        Will support numeric values, but not as concrete domain

Testing for support of numeric values will initially focus on creation of combined value/unit constructs supplied by RxNorm and AMT.

Information about the project combined into one confluence site:

https://confluence.ihtsdotools.org/display/IAP/Drug+Model+Directory

KCA expressed his support for the outcome of these initial discussions and support for this from the VA.

JCA stressed that the boundary of what would be supported by the International release would be drug products (single or multiple) at the level of strength, using one of the options currently under test for representation of strength (one concept or two).

Discussion of issues:

What is a product?  The definition of product in SNOMED CT now was presented.  KCA mentioned that the current definition uses language that is specific to the UK.  This was verified by the AU members of the group as well.  KCA stated the underlying definition is acceptable except for the use of virtual products.  Would like to see it revised to something similar to the Australian definition. 

•  Action: Get a copy of the current Australian and US definitions for drug product and revise the current SNOMED CT definition to reflect a more specific definition that does not include virtual products and Product categories.  Add to a discussion page on the EAG site (JCA).  Goal is to come up with a more terse definition.

Question: Is the prescribing use case out of scope for the drug content in the International release?

The current definition does include this.  However, the goal of the common drug model is to provide support for the use cases including prescribing, but the content at the International level may not be sufficient and must be augmented by jurisdictional extensions to meet their specific use cases.

Question: Is there a need for new semantic tags to represent abstract, generic and trade products?

It was previously agreed that trade products are out of scope so not needed for that.  Additional discussion lead to a discussion that new semantic tags are not immediately needed, but may become more important as the generic model is implemented by NRCs.

Prior policy decisions from the Drug Model Group were presented

•  Action: Briefing paper for addressing the current ambiguous FSNs will be sent to the MF for discussion at the December meeting. (JCA)

GRE mentioned that it is important to recognize that combined products are not the same as products with multiple ingredients.

6 Extension of range of CAUSATIVE AGENT to include Product

Currently, there are many duplicate substances created to support modeling due to restriction on the range of CAUSATIVE AGENT.

Discussion: GRE the issue is what is the result on inferences.  Use of a product is OK, but things must be aligned so that you are still transitive to the substance in the product.  We may need to do some additional work to define the property correctly so that these inferences are maintained.

GRE (cont) said he thought it would require a property change and he recommended getting in touch with the modeling team about that.

JCA: the major use cases are pretty apparent, but in many instances something in the product would cause the adverse reaction.

GRE: almost every adverse reaction is from a product. Supporting this is something we have to do to extend the range.

Confusion about adverse reaction; guidance not clear about which to use, product or substance, for causative agent.

JCA: Can we remove duplication of substance and/or product from the hierarchy so remove the ambiguity? Not sure if it's possible - haven't done the testing yet.

JCA: sounds like this is a good idea, modeling considerations need to be taken under advisement, and need to define fairly strict editorial guidance on when to use product and when to use substance.

GRE: would be nice to have concrete examples so can send them for consultation. JCA:  i think we have a number of use cases available to send to the Modeling AG. Also need to look at cross over between product and substance in terms of matching concepts and see if feasible to eliminate one or the other of those.

7 Assessment instrument responses

JCA: come up with policy on assessment tool responses to the international edition. JCA used the introductory material on the agenda, including proposed general guidance.

(1) Only assessment instruments that are in the public domain should have their response values added.

KCA: i think domain is not a sufficiently defined term, some license agreements would not be compatible, maybe just say an appropriate license that allows it to be distributed with snomed.  Interpretation of any specific license goes to MB, and the MB can decide if it wants legal advice. "Unrestricted use" probably not the right term. Maybe assessment instruments that have license agreements compatible with the SNOMED distribution agreement. 1:11. Maybe say any being considered should be forwarded to MB, so that sets up a process and frees us from the judgment.

Observer notes that there are scoring systems, like Beck Depression.

JCA: if a specific response in an instrument, in proprietary instruments there is specific wording only tied to that instrument, those are the ones we're not considering here. not impossible to get permission to use, we've done it before, but harder to do now. We are getting requests tied to specific instruments, and don't want to add and not know that they are proprietary, so want a policy statement about what we can and can't add to IR.

PAM: better to have a process rather than a set of words. KCA and JCA agree that  a process is easier than a definition.

GRE: have to be clear that only can be used in certain contexts, authority dependent, we never resolved how to do that. JCA: we do have a tracker on authority-dependent.

Break

•  Action: JCA said he would work with the Management Team to develop some sort of general contribution agreement so can develop relationships with those vendors and others that have IP controlled instruments. The team could just begin using those instruments without IP controls. Determination of whether they are IP controlled will probably be more difficult than developing the agreement.

(2) Response values must adhere to current FSN naming guidelines. Verbatim responses from the assessment will be added as Preferred Terms (PTs).

GRE: long time ago, many problems came from checklists because those forms usually have a context, but the answer has to be a stand-alone, external to the origin/context. Make sure the context is in the FSN.  

JCA: the purpose is to make sure the specific context of use is included. There are two approaches to that. One is the naming of the FSN, the other is positioning within the hierarchy. (1:19)

(3) Assessment responses will be added under an assessment specific "grouper" term to facilitate navigation

JCA:  would provide the context to that specific instrument.

(4) IP-restricted assessment values may only be added upon permission of the publisher. It is the responsibility of the requester to secure that permission.

JCA: an external requestor for something in SNOMED does not require us to go out and seek an agreement with an external partner.

PAM: any process put in place has to be mindful of the requestor doing the footwork.

JCA: yes, that will be in the editorial guidance. We will do the initial investigation, and if it requires permission, we will send it to the requestor to do the work.

Any other comments? if not I'll work on the editorial guidelines.

PAM: would that include those already signed by IHTSDO?

JCA: excellent idea b/c i don't think we know the background of those.

8 ECE Update

1:23

BGO gave a presentation. First topic was about surgical complications and sequelae (during, before, after operative procedures). In London, he said, he was advised to run it by the Anesthesia SIG. He did that, and the SIG members said preoperative complication includes before, during and after surgery. They made it clear perioperative, interperative and post-operative not necessarily due to the surgery, they just imply a temporal relationship, so, he said, he extended the model. 

JCA: given current definition of complication, how would perioperative complication be presented, because complication is a consequence, so how could the consequence precede the event?

BGO: perioperative complication is different from complication. It just implies a temporal sequence, happening before, during or after surgery. That's different from complication, where you're implying causality. "Complication: an untoward consequence of a disease, injury, procedure or device that is coincident with or follows the inciting condition." "Sequela: a complication that begins after the inciting condition often following a variable latent period."

BGO: When saying complication of, you’re really saying causality. Currently only post-operative complications can be fully defined. Interoperative compliations in SCT remain primitive.

Issue 1: Procedure is not within the allowable range for the due to role and thus complications of procedures are inconsistently defined using a variety of methods even when causality is explicitly called out in the FSN with "due to."

Issue 2: Sequelae of disorders (disorder) are modeled only with the "after" role and not with the "due to" role, thus capturing only the temporal and not causal relationship between the primary insult and its eventual undesired outcome. Complications and sequelae are not related by a parent-child relationship.

Issue 3: postoperative complication (Disorder) and perioperative hemorrhage and hematoma (Disorder) are both descendants of 88797001 complication of surgical procedure (disorder) incorrectly implying that they are due to the surgical procedure rather than just temporally related to it.

Recommendations

• Extend the range of the due to role to include procedure for 116224001 complication of procedure (disorder) and its descendants
• Make 3629977000 sequela (Disorder) a subtype of 116223007 Complication (disorder)
• Define complications using due to role at sequlae using both due and after roles
• Add new attributes in order to define preoperative, intraoperative and perioperative complications

1:31:43

Proposed solution: revised associated with role hierarchy:

JCA: we could now test models in a confined environment without breaking anything, so it could be tested out, if proposals approved by the AG.

BGO: the idea would be to create a new role called "encompassing" or something similar. 1:36:30 Encompassing would subsume before and a newly created During_and/or_after. Used to model perioperative complications, a complication encompassing surgical procedures.

BGO spoke about the Clavien-Dindo classification of surgical complications which defines three types of negative outcome: Complication, Failure to cure, and Sequela (so they differentiate complication from sequela). BGO said his concern with that was if a surgical sequela is not a kind of surgical complication, does it mean that sequelae in general (e.g. sequela of diseases) are not kinds of complications? He noted that it may be a mute point because SNOMED did not represent surgical sequelae.1:40:10

BGO demonstrated his model.

Question: Instead of showing attribute "encompasses" why not just "temporarily associated with" since encompasses means contains. BGO replied that he was open to other options. JCA: sounds like "associates with" but that has difficulties, but "temporarily associated with" would not have those difficulties. GRE: don't really like "encompassing" but can understand how he came to it. GRE gave the example of a surgical scar being a sequela not a complication.

Jim Campbell: Oxford English dictionary does not include procedure as a prequel to a sequelae, only disease, injury or trauma.  BGO said he had numerous definitions and many of them did include it.

JCA: to summarize the decisions you want: 1:49:54

1. agreement that extending the range of the "due to" to include procedures would enable the modeling of all of these complications of surgery. Rest of AG agree with that, given that Bruce would produce the editorial guidance (which is already 90 percent of the way done)?
2. discuss the new attribute of "encompassing" (BGO: or temporally associated with), "temporarily associated with" is clearer, still needs and FSN, but my friendly amendment is that. 
   1. Discussion of temporally unbound/bound, JCA: could restrict it editorially by only applying it in perioperative procedures, shouldn't be used in any other circumstances.
   2. JCA: so are we okay with the naming, given the editorial guidance discussed? BGO agrees. 1:54:25
3. request to define new attributes, during_and/or_after, before and during to promote before and during from unapproved attribute list to approved attribute list. 
4. (see slide on the right)

GRE: I'm not saying we're rejecting, but need further consultation and a way to say it's not always true. Feeling we will be changing something that has potential for improvement, leaving us with something else that has potential for improvement. Sequela may not be a complication, so we cannot model it that way. Issue with current model is non-reproducability. We might have the same problem with this model. 

JCA: so without a decision on making sequela a subtype, how would that impact the other decisions? 2:00

KCA: I'm worried that a lot of this is value-judgment, making it difficult to reproduce. When is an outcome a complication following a procedure, and what is considered a complication might change over time, for example a typical outcome may become so rare that it becomes considered a complication.

BGO: To answer JCA's question, I think if modeling sequelae with the due to attribute it's going to be subsumed by complication. JCA: so it's a logically defined relationship, so possible to model without always having the sequela be a complication. BGO: yes, if you think it's a complication you would use due_to. JCA: that goes back to KCA's point about value judgment, should we say that if your value judgment is different from SNOMED's then you can't make that judgment? This model would improve the consistency of the current hierarchy and resolve a number of the very fuzzy areas that we've got.

JCA: So at this point you get 3 out of 4.

Decision: the AG agreed on 3 out of 4 of BGO's recommendations:

• Extend the range of the due to role to include procedure for 116224001 Complication of procedure (disorder) and its descendants
• Define complications using due to role and sequelae using both due and after roles
• Add new attributes in order to define preoperative, intraoperative and perioperative complications

The recommendation to make 362977000 Sequela (disorder) a subtype of 116223007 Complication (disorder) was not approved at that time because it would require further study.

2:04:43

9 Genomics

JCA: we began to discuss in last conference call and have gotten as far as we can, we do not have even a high-level approach to dealing with genomics in SNOMED at this point. Purpose is try to develop the key issues that need to be addressed, identify priorities, standards of external standards, degree of granularity we need to represent it in the International Release. In IHTSDO we have some consultant terminologist projects looking at genetic disease, familial disease... all together now, including a large number of rare diseases, many of which are genetic, to support those have had to add some phenotypes, need to add more phenotypes of genomics. Many of these have clinical manifestations and don't have way to represent them now, and sources of the genetic mutations, genes and how to represent them in the model. 

KCA: I think we should add concepts for C, T, A and G.

JCA: then you've ignored RNA.

KCA: you can add a U.

Scott Campbell: Jim Campbell and I have been dealing with malignant conditions, a semantic illness though there can be a germ-line. Jim has been the progenitor of the work done in Nebraska in clinical bite-sizes and create an elegant pathway to flow into the ontologies and Refsets required for the level of granularity.

Jim: Keith's level of granularity is too fine, where this is appearing increasingly is observational data, so we've been workign wth the observables group, using as scope is the CAP cancer checksheet b/c validated cliical utiltiy. Intro of genes and increas in proteins is where content really needed as reference material, but we don't want to recraete seicentif databases that are producing the rsults of the genertic reserarch, proposing SCT collaborate, harmonize ontlgoic elements from protein community and gene community and clasify with SCT Their definitions of genes and protens, once can get the clinically relevant genes and proteins, then the model for esoteric falls into place, can then define clinical findings. that's teh idreicatino we'e found o be most productive.

GRE: i would approach differently from process but i don't disagree with jim, when we have requests for extending the coverage for new or incomplete domains, not about add this data/concepts, requestor requesting a solution rather than the requirements. So need to define the scope, then the competency questions, what are the kind of questions/queries or use cases that we need to deal with. We need a process for new content areas or new improvements of content areas. Difficult to say how much you have met the needs unless have acceptance criteria. Clearer request, process, what areas are these trying to do?

Jim Campbell: GRE is right, we started with a set of issues that our researchers wanted, which was big data purposes. Those questions drove the model. 

Scott Campbell: who are the users from the EHR perspective? What was the assessment of the tissue of the tumor? Were there biomarkers studies performed on the tissue or patient, and can they be represented in such a way as they can be presented in the EHR in clinically actionable components? Need to determine retrospectively in clinical bites that a study has been performed so that we don't repeat the test. We asked researchers for the queries that they needed to perform. Looked at those questions/requirements. 2:19

GRE: that's the right direction. 

Scott Campbell: we can't represent all the 5 letters that Keith mentioned in every sequence, that's far beyond the scope. It is not in the model, it points to a folder that has it, it would overburden the terminology to put it in SNOMED.

KCA: at the VA, genomics is a hot buzz word, SNOMED is doing better than, for example, ICD10 in, for example, breast cancer. Ability to identify outcome based on ICD code or SNOMED code, ICD10 tells you right left, where diagnosed, but won't use BRCA2 positive or status of some of the genetic markers that are predictive of outcome. I think we may need to think about how we can line up A, C, T, G, U and even the different proteins. For now the most important thing is whenever we find that there is a test for anything that is clinically significant with regards to genomics, then we need to make sure that that is representable in the terminology. The test and the diagnostic information that can be represented. It doesn't mean that it is due to that genomic condition, means risk is higher and treatment will be different. SNOMED has done many of the right things and ICD doesn't have the same abilities to represent. 

Eric: I think one high value use case for where to start is pharmacogenomics. Area where SNOMED representing certain concepts could improve care options. To do it, need to represent patient's genotype. Specification of 2 alleles, over time each genotype may be associated with more and more information about reactions with drugs, and each allele needs representation, and each is a polymorphism, so useful to link to the polymorphism mapping perhaps to DVSNIP.

Jim Campbell: I wouldn't disagree with that. This grew out of a consultant terminologist project that started with a SIRS request, then I collated all I could related to genomics. 

JCA: the elephant in the room is we're talking about observables in the laboratory space, because of our current agreement with LOINC there are some challenges in adding some new lab observables to the International Release, so how reconcile wish to represent more on genetic disorders to IR without the laboratory part? We cannot solve it in this group. Phenotypes and risk factors we can handle, it's the supporting clinical evidence that is the most difficult to do. If we were to say that that is a current blocker and we have to put something aside until can deal with that, can we go higher up in the hierarchy to see what we can represent?

GRE: if there is international support, some countries having a need for content, then you can't prohibit them to have that content. SCA: need two requests from 2 members. GRE: right so if go to MF, can't avoid evolution of SNOMED.

Scott Campbell: our process has been when we come up with a new observable, particularly for genomics, our thinking is that we have to put it in a SNOMED-centric environment, but it's sent to LOINC for development of a concept. 

JCA: the issues that we, if that is the level of detail to which we want to focus, then the problems now are not technical, if other areas not involving observables we can certainly carry on with that area, not useful to keep talking about what we can't do.

PAM: everyone wants the ability to provide the info with the EHR that allows us to treat our patients, and if we have to spend all of our time dancing around an agreement that's not fit for purpose... If we all agree on that we should change the agreement sooner rather than later.

JCA: so i will try to gather advice from the advisors on how they would like me to proceed in this area.

KCA: my advice is there are areas where this needs to propagate in SNOMED that are independent of the LOINC agreement, making the rep of being positive for a particular agreement is represented independently of the test that confirmed that, that's productive independent of this other encumbrance. 

BGO: shouldn't we speak to Regenstrief about this? JCA: we have an editorial policy group that is within the agreement, that would be appropriate for them to discuss based on what folks feel are the considerable amount of evidence that include content now excluded. Fact that we need to rep observations about genetic mutations, is not asking for a test, it's a definitional aspect rather than a technical aspect. Is that what you mean, Keith?

KCA: yes. wiggle room with how to define the boundary, if a patient has a condition independent of how know that, it should be in SNOMED. If LOINC wants to represent how it was discovered, that's fine, but useful to have a split so not being hamstrung all the time.

Jim Campbell: that level of granularity in what we're doing would not be acceptable to our research compatriots. they want the refined data coming out of the genetics lab. They want to be able to mine data from the EHR in retrospective research.

Scott Campbell: it's the what of the what that's important. LOINC tells us the what but not the what about that what. CAP has representation here so recommend you talk to them b/c they made a policy statement about that to the Office of the National coordinator in the last week.

•  JCA: so i will action to brig this discussion to the EPG and begin a discussion with the folks overseeing the agreement to see what additional things need to be done.