This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Negation Requirements Project Minutes 20 April 2016"

From HL7Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by the same user not shown)
Line 84: Line 84:
 
===Agenda===
 
===Agenda===
 
'''Agenda Topics''' <br/>
 
'''Agenda Topics''' <br/>
−
# FHIR/allergy topic
+
# Term Info recap
−
# Negating conditions
+
# Action items
−
# Design considerations
+
# Classes
−
## Requirements & constraints
+
# Principles
−
## Observable & finding
 
  
 
===Minutes===
 
===Minutes===
Line 104: Line 103:
 
'''Minutes/Conclusions Reached:'''<br/>
 
'''Minutes/Conclusions Reached:'''<br/>
  
−
Term Info topic: FHIR allergy patterns:
+
# Term Info
−
# one field for present substance & absent assertion
+
## Rob had sent a proposal to use one field, renamed "code," and to define two distinct value sets
−
# present substance & absent substance field
+
## This proposal might allow the use of an extension field to support a 2-element design. This was met with disquiet.
−
# value field + presence field
+
# Action items
−
# value field + negation field
+
## Jay suggests a "real" flag to ensure requirements are real
−
 
+
## Vocabulary co-sponsors
−
* From a requirements perspective, 1-3 all work; #4 seems to introduce some ambiguity.
+
## SD & FHIR were asked a while back. We'll move on to DESD.
−
* Lisa asks, is our goal to accurately represent semantics or help us do logical reasoning?
+
## Wiki: still not done
−
** A good representation should support reasoning of many forms, including DL
+
# Classes
−
** But there is a tension between design patterns that are closer to the UI and those closer to some other use. Any form will incur translation cost & risk when used for purposes more distant from its paradigm.
+
## We are trying to identify classes of negations, with the intent that any use case falling in a particular class should be managed in a consistent way.  
−
** FHIR, as a RESTful approach, seems more aligned with a UI/Business object perspective, so approach 1 seems like a likely approach.
+
### Observable absent
−
** Even with #1, the computability case we know about (drug/order check) will work without additional computational steps.
+
### Condition refuted
−
***E.g., the check might say a) "Strawberry": does the ordered product contain strawberry?; b) "no allergy to latex": does the ordered product contain "no allergy to latex"?
+
### Procedure not done
−
*** A system ''could'' check whether a value is a presence value or an absence value, but it doesn't seem necessary.
+
#### (Also: need a glossary to clarify that "procedure" means any act that might be recorded or negated)
−
*** Only positive assertions will have an effect on the check rule, but both positive and negative assertions may appear in a displayed list.
+
### Goal not held
−
** Approach 1 might imply a change to the semantics of the field. It might be advisable to consider a name change, &/or some kind of explicit semantic binding.
+
### Do we need a negated condition?
−
* We identified some candidate principles
+
# Principles
−
# semantic differences may not require different fields, but they do require different value sets.
+
## New: "Absence of evidence is not evidence of absence." Impact: no requirement to deal with inferred negation; negation cannot be inferred.
−
## Using Grouping value sets
+
## Others not reviewed during call
−
## Concepts must be different - if one contains "latex" the other should contain "no allergy to latex"
+
### use real requirements, not inferred cases designed to illustrate potential issues
−
# double negation is bad and should be avoided, where possible.
+
### separate requirements & design models
−
## where this is not possible, double (or subsequent) negation affirms negation, and does not transform into affirmation
+
### avoid double negs
−
# Boolean "negation indicators" tend to be abstract and ambiguous. Make semantics specific where possible
+
### avoid excessive abstraction
−
# Concept should be "encoded." This can be by pre- or post-coordination, and post-coordination can be by expression or model, but we want to avoid text in order to support unambiguous computation.
+
### support requirements with minimal transformation
−
* Do we need to negate conditions?
+
### negation should be handled as consistently as possible without violating semantics of respective cases
−
** Examples found so far are supported by FHIR Condition verification status (e.g., refuted) for rule-outs, or by Observation for "safety check" questions ("any bleeding disorders?").
+
### data should support automated use of semantics to extent possible (viz., code not text)
−
** If there are edge cases, might "clinical impression" support them?
+
# Re TermInfo Allergy question
 +
## Can we determine relative volumes of transactions: capturing/representing in UI vs CDS?
  
 
===Meeting Outcomes===
 
===Meeting Outcomes===
Line 148: Line 148:
  
 
* review examples for completeness, classification for accuracy (all)
 
* review examples for completeness, classification for accuracy (all)
−
* secure Vocabulary co-sponsorship (Rob H)
 
−
* request involvement from SD & FHIR (Jay)
 
 
* consolidate wiki pages (Jay)
 
* consolidate wiki pages (Jay)
  

Latest revision as of 17:20, 20 April 2016


Back to Negation Minutes

Minutes

Meeting Information

HL7 PC-CIMI-POC Meeting Minutes

Location: PC call line

Date: 2016-04-20
Time: 11:00-12:00 ET
Facilitator Jay Lyle Note taker(s) Jay Lyle
Attendee Name Affiliation


Jay Lyle JP Systems
Serafina Versaggi
Lisa Nelson
Rob Hausam
Susan Campbell
Juliet Rubini

Agenda

Agenda Topics

  1. Term Info recap
  2. Action items
  3. Classes
  4. Principles

Minutes

Minutes/Conclusions Reached:

  1. Term Info
    1. Rob had sent a proposal to use one field, renamed "code," and to define two distinct value sets
    2. This proposal might allow the use of an extension field to support a 2-element design. This was met with disquiet.
  2. Action items
    1. Jay suggests a "real" flag to ensure requirements are real
    2. Vocabulary co-sponsors
    3. SD & FHIR were asked a while back. We'll move on to DESD.
    4. Wiki: still not done
  3. Classes
    1. We are trying to identify classes of negations, with the intent that any use case falling in a particular class should be managed in a consistent way.
      1. Observable absent
      2. Condition refuted
      3. Procedure not done
        1. (Also: need a glossary to clarify that "procedure" means any act that might be recorded or negated)
      4. Goal not held
      5. Do we need a negated condition?
  4. Principles
    1. New: "Absence of evidence is not evidence of absence." Impact: no requirement to deal with inferred negation; negation cannot be inferred.
    2. Others not reviewed during call
      1. use real requirements, not inferred cases designed to illustrate potential issues
      2. separate requirements & design models
      3. avoid double negs
      4. avoid excessive abstraction
      5. support requirements with minimal transformation
      6. negation should be handled as consistently as possible without violating semantics of respective cases
      7. data should support automated use of semantics to extent possible (viz., code not text)
  5. Re TermInfo Allergy question
    1. Can we determine relative volumes of transactions: capturing/representing in UI vs CDS?

Meeting Outcomes

Actions
  • review examples for completeness, classification for accuracy (all)
  • consolidate wiki pages (Jay)
Next Meeting/Preliminary Agenda Items
  • none identified

© 2012 Health Level Seven® International. All rights reserved.

Retrieved from "https://wiki.hl7.org/w/index.php?title=Negation_Requirements_Project_Minutes_20_April_2016&oldid=118483"