Negation Requirements Project Minutes 13 April 2016
Jump to navigation Jump to search
Back to Negation Minutes
|HL7 PC-CIMI-POC Meeting Minutes
Location: PC call line
Time: 11:00-12:00 ET
|Facilitator||Jay Lyle||Note taker(s)||Jay Lyle|
|Jay Lyle||JP Systems|
|Ron Van Duyne|
- FHIR/allergy topic
- Negating conditions
- Design considerations
- Requirements & constraints
- Observable & finding
Term Info topic: FHIR allergy patterns:
- one field for present substance & absent assertion
- present substance & absent substance field
- value field + presence field
- 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
- semantic differences may not require different fields, but they do require different value sets.
- Using Grouping value sets
- Concepts must be different - if one contains "latex" the other should contain "no allergy to latex"
- double negation is bad and should be avoided, where possible.
- where this is not possible, double (or subsequent) negation affirms negation, and does not transform into affirmation
- Boolean "negation indicators" tend to be abstract and ambiguous. Make semantics specific where possible
- 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?
|Next Meeting/Preliminary Agenda Items|
© 2012 Health Level Seven® International. All rights reserved.