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
Line 59: Line 59:
 
|-
 
|-
 
|  || Rob Hausam
 
|  || Rob Hausam
|colspan="2"|
 
|-
 
|  || Rob McClure
 
 
|colspan="2"|  
 
|colspan="2"|  
 
|-
 
|-
Line 68: Line 65:
 
|-
 
|-
 
|  || Juliet Rubini
 
|  || Juliet Rubini
|colspan="2"|
 
|-
 
|  || Ron Van Duyne
 
 
|colspan="2"|  
 
|colspan="2"|  
 
|-
 
|-

Revision as of 16:56, 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. FHIR/allergy topic
  2. Negating conditions
  3. Design considerations
    1. Requirements & constraints
    2. Observable & finding

Minutes

Minutes/Conclusions Reached:

Term Info topic: FHIR allergy patterns:

  1. one field for present substance & absent assertion
  2. present substance & absent substance field
  3. value field + presence field
  4. value field + negation field
  • From a requirements perspective, 1-3 all work; #4 seems to introduce some ambiguity.
  • Lisa asks, is our goal to accurately represent semantics or help us do logical reasoning?
    • A good representation should support reasoning of many forms, including DL
    • 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.
    • FHIR, as a RESTful approach, seems more aligned with a UI/Business object perspective, so approach 1 seems like a likely approach.
    • Even with #1, the computability case we know about (drug/order check) will work without additional computational steps.
      • 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"?
      • A system could check whether a value is a presence value or an absence value, but it doesn't seem necessary.
      • Only positive assertions will have an effect on the check rule, but both positive and negative assertions may appear in a displayed list.
    • 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.
  • We identified some candidate principles
  1. semantic differences may not require different fields, but they do require different value sets.
    1. Using Grouping value sets
    2. Concepts must be different - if one contains "latex" the other should contain "no allergy to latex"
  2. double negation is bad and should be avoided, where possible.
    1. where this is not possible, double (or subsequent) negation affirms negation, and does not transform into affirmation
  3. Boolean "negation indicators" tend to be abstract and ambiguous. Make semantics specific where possible
  4. 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.
  • Do we need to negate conditions?
    • 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?").
    • If there are edge cases, might "clinical impression" support them?

Meeting Outcomes

Actions
  • review examples for completeness, classification for accuracy (all)
  • secure Vocabulary co-sponsorship (Rob H)
  • request involvement from SD & FHIR (Jay)
  • consolidate wiki pages (Jay)
Next Meeting/Preliminary Agenda Items
  • none identified

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