Negation Requirements Project Minutes 13 April 2016

Back to Negation Minutes

Minutes

Meeting Information

HL7 PC-CIMI-POC Meeting Minutes Location: PC call line		Date: 2016-03-30 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
	Rob McClure
	Susan Campbell
	Juliet Rubini
	Ron Van Duyne

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.