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 128: Line 128:
 
### negation should be handled as consistently as possible without violating semantics of respective cases
 
### negation should be handled as consistently as possible without violating semantics of respective cases
 
### data should support automated use of semantics to extent possible (viz., code not text)
 
### data should support automated use of semantics to extent possible (viz., code not text)
 +
# Re TermInfo Allergy question
 +
## Can we determine relative volumes of transactions: capturing/representing in UI vs CDS?
  
 
===Meeting Outcomes===
 
===Meeting Outcomes===

Revision as of 17:16, 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 (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)
  • 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.