This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Negation Requirements Project Minutes 20 April 2016"
Jump to navigation
Jump to search
Line 106: | Line 106: | ||
## Rob had sent a proposal to use one field, renamed "code," and to define two distinct value sets | ## Rob had sent a proposal to use one field, renamed "code," and to define two distinct value sets | ||
## This proposal might allow the use of an extension field to support a 2-element design. This was met with disquiet. | ## This proposal might allow the use of an extension field to support a 2-element design. This was met with disquiet. | ||
+ | # Action items | ||
+ | ## Jay suggests a "real" flag to ensure requirements are real | ||
+ | ## Vocabulary co-sponsors | ||
+ | ## SD & FHIR were asked a while back. We'll move on to DESD. | ||
+ | ## Wiki: still not done | ||
+ | # Classes | ||
+ | ## 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. | ||
+ | ### Observable absent | ||
+ | ### Condition refuted | ||
+ | ### Procedure not done (Also: need a glossary to clarify that "procedure" means any act that might be recorded or negated) | ||
+ | ### Goal not held | ||
+ | ### Do we need a negated condition? | ||
+ | # Principles | ||
+ | ## New: "Absence of evidence is not evidence of absence." Impact: no requirement to deal with inferred negation; negation cannot be inferred. | ||
+ | ## Others not reviewed during call | ||
+ | ### use real requirements, not inferred cases designed to illustrate potential issues | ||
+ | ### separate requirements & design models | ||
+ | ### avoid double negs | ||
+ | ### avoid excessive abstraction | ||
+ | ### support requirements with minimal transformation | ||
+ | ### 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) | ||
===Meeting Outcomes=== | ===Meeting Outcomes=== |
Revision as of 17:10, 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
- Term Info recap
- Action items
- Classes
- Principles
Minutes
Minutes/Conclusions Reached:
- Term Info
- Rob had sent a proposal to use one field, renamed "code," and to define two distinct value sets
- This proposal might allow the use of an extension field to support a 2-element design. This was met with disquiet.
- Action items
- Jay suggests a "real" flag to ensure requirements are real
- Vocabulary co-sponsors
- SD & FHIR were asked a while back. We'll move on to DESD.
- Wiki: still not done
- Classes
- 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.
- Observable absent
- Condition refuted
- Procedure not done (Also: need a glossary to clarify that "procedure" means any act that might be recorded or negated)
- Goal not held
- Do we need a negated condition?
- 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.
- Principles
- New: "Absence of evidence is not evidence of absence." Impact: no requirement to deal with inferred negation; negation cannot be inferred.
- Others not reviewed during call
- use real requirements, not inferred cases designed to illustrate potential issues
- separate requirements & design models
- avoid double negs
- avoid excessive abstraction
- support requirements with minimal transformation
- 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)
Meeting Outcomes
Actions
|
Next Meeting/Preliminary Agenda Items
|
© 2012 Health Level Seven® International. All rights reserved.