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 ad 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 concept be modeled as primitives and leave the component relationship 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 defined some of these disjunctive concepts, but many of the concept 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 they need.
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 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 many instances something in the product that would cause the adverse react.
GRE: almost every adverse reaction is from a product. Supporting this is something we have to do to extend the range;
Confusion about whether 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 or not haven't done the testing yet;
JCA:sounds like this is a good idea, modeling considerations need to be taken under advisement, and to define fairly strict ed 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 they can decide if want 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 ocnsidered should be forwarded to MB, so sets up a process and frees us fro the judment.
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 ot that instrument, those are the ones we're not considering herel not impossbke to get permission to use, we've done it beefre, but harder to do nowl KCA: get loang that doesn't up is o position on a oicensel JCA: no, we are getting requests tied to specific instruments, dont want to add and not know it, so want a poicy statement about what we can and can't add to IR
Paul: better to have a process rather than a set of wordsl kca and jca agree that a process is easeir than a definitionl
GRE: have to be colear that onoy can be used in certain contexts, authority depenent, we never resolved how to do thatl JCA: we do have a tracker on authority-dependent
break
Action: JCA said he would work with the MT to develop some sort of general contribution agreement so can delveop reoatoionshpi s with those vendors and others that have IP controlled instrumentsl. The team could just begin using those instruments without IP controls. Determination of whether they are IP controlled will probably more difficult than developing the agreementl
(2) Response values must adhere to current FSN naming guidelines. Verbatim respinoses from the assessment will be added as Preferred Terms (PTs).
GRE: long time ago, many problems come from checklists or whatever b.c those forms usually have a context so the principal is that the answer has to be a stand-alone, don't consider the origin/context. make sure the context is i the fsn.
JCA: the purpse 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 respoinses will be added under an assessment specific "grouper" term to facilitate navigation
JCA: would provide the context to that specific instrumentl.
(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 partnerl
PAM: any process put in place has to be mindful of the requestor doing the footwork.
JCA: yes, that will be in the editorial guide, we will do the initial investigation and if requires persmission , 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 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 i was advised to run it by the anesthesia sig. I did that, and they said preoperative complication includes before during and after surgery. They made it clear perioperative, inter0perative post-operative not necessarily due to the surgery, just implies a temporal relationsihp, so i extended the model.
JCA: given current def of complication, how would peri-operative complication be prersentied b/c complication is a consequence, so how could the consequence precede the event?
BGO: perioperative complication is different from complication 0 it just implies a temporal sequence, happing 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 compliationsin SCT remain primitivel
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 said 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
- 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)?
- 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.
- 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.
- JCA: so are we okay with the naming, given the editorial guidance discussed? BGO agrees. 1:54:25
- 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.
- (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 decendants
- 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
