Difference between revisions of "May 27, 2005"
(9 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | == | + | == May 27, 2005 Teleconference == |
− | Time: | + | Time: 11:00 to 12:00 AM Eastern Time [http://www.timeanddate.com/worldclock/fixedtime.html?month=5&day=27&year=2005&hour=11&min=00&sec=0&p1=263 Convert]<br> |
Phone #: (877)407-0183<br> | Phone #: (877)407-0183<br> | ||
− | PassCode: | + | PassCode: 680305# |
=== Attendees: === | === Attendees: === | ||
+ | * [mailto:jak@informatics.jax.org Jim Kadin] Jackson Labs ''(scribe)'' | ||
+ | * [mailto:drdata@ardais.com David Aronow] Ardais Corporation | ||
+ | * [mailto:solbrig@mayo.edu Harold Solbrig] Mayo Clinic | ||
+ | * [mailto:bdavis@3rdmill.com Brian Davis] Booze Allen Hamilton | ||
+ | * [mailto:klinglerk@saic-solutions.com Kim Klingler] SAIC | ||
+ | * [mailto:keller_michael@bah.com Michael Keller] Booze Allen Hamilton | ||
+ | === Minutes: === | ||
+ | Summary of caBIG - VCDE - "Flavors of Null" telecon. | ||
+ | |||
+ | May 27, 2005 | ||
+ | |||
+ | Attendees: | ||
+ | |||
+ | Mike Keller, Brian Davis, Harold Solbrig, David Aronow, Kim Klingler, | ||
+ | |||
+ | Jim Kadin (scribe) | ||
+ | |||
+ | (anybody else?) | ||
+ | |||
+ | Decisions: | ||
+ | |||
+ | 1) In light of David's comments from months ago and the CDC's CDE | ||
+ | document, | ||
+ | |||
+ | we agreed that "missing values" or "missing value reasons" is a better | ||
+ | |||
+ | name for this small working group than "flavors of null". | ||
+ | |||
+ | It is probably more confusing to change the name of our group at this | ||
+ | |||
+ | point, but it did clarify our thinking significantly. | ||
+ | |||
+ | Our task is to come up with an approach for handling "missing | ||
+ | |||
+ | values" (MV) and "missing value reasons" (MVR) in caBIG. | ||
+ | |||
+ | 2) We agreed that what we should focus on is the "currency of data | ||
+ | |||
+ | exchange". That is, we are concerned with how MV and MVR are handled at | ||
+ | |||
+ | the messaging level where data is exchanged between caBIG | ||
+ | resources/tools. | ||
+ | |||
+ | We are not concerned with how null or MV or MVR are handled within | ||
+ | |||
+ | databases and applications. In this sense we view CDEs as defining the | ||
+ | |||
+ | semantics of fields at the messaging level. | ||
+ | |||
+ | 3) Different MV and MVR make sense in different contexts. | ||
+ | |||
+ | (non-exhaustive - illustrative ) Examples: | ||
+ | |||
+ | * Patient Interview Context | ||
+ | ** not sought | ||
+ | ** refused | ||
+ | ** sought but unknown (patient didn't know?) | ||
+ | ** unknown | ||
+ | |||
+ | * Coding data from literature context | ||
+ | |||
+ | not specified | ||
+ | |||
+ | Translating data from one resource to another | ||
+ | |||
+ | not resolved (couldn't translate) | ||
+ | |||
+ | not loaded | ||
+ | |||
+ | Data "extracted from procedures" | ||
+ | |||
+ | not done | ||
+ | |||
+ | not tested | ||
+ | |||
+ | not evaluated | ||
+ | |||
+ | Other/many contexts | ||
+ | |||
+ | deleted for confidentiality | ||
+ | |||
+ | not applicable | ||
+ | |||
+ | 4) We discussed several use cases and realized there are fuzzy cases | ||
+ | where | ||
+ | |||
+ | the same term might be considered a permissible value (quasi MV) for a | ||
+ | |||
+ | field in one instance and a MVR in another. | ||
+ | |||
+ | Examples: | ||
+ | |||
+ | Clinical test result | ||
+ | |||
+ | Normal | ||
+ | |||
+ | Abnormal High | ||
+ | |||
+ | Abnormal Low | ||
+ | |||
+ | Not specified (permissible value in the case where a data source | ||
+ | |||
+ | does not include such an indicator) | ||
+ | |||
+ | 5) Outline of our deliverables to VCDE workspace: | ||
+ | |||
+ | a) define a vocabulary of missing value reasons that CDEs can draw | ||
+ | |||
+ | from. This is likely to be a hierarchy. | ||
+ | |||
+ | b) develop recommendations to CDE developers. They will need to wrestle | ||
+ | |||
+ | with MV vs. MVR. | ||
+ | |||
+ | One possibility: include MV (e.g., unknown, not specified) in the | ||
+ | |||
+ | permissible values | ||
+ | |||
+ | And/Or create a linked CDE for the MVR - with values chosen from the | ||
+ | |||
+ | vocabulary in (a). | ||
+ | |||
+ | It seems probable that we will need some way in the caDSR for | ||
+ | |||
+ | linking a CDE with a CDE for the MVR. | ||
+ | |||
+ | c) develop recommendations for the architecture ws on how MV and MVR for | ||
+ | |||
+ | fields are linked in the messaging layer. | ||
=== Discussion === | === Discussion === | ||
+ | After reviewing the CDC Common Data Elements document, we realized that David Aronow had been right from the beginning and the name "Flavors of Null" was misleading and confusing. The group unanomously adopted a new moniker - "Missing Value Reason". This new named helped to clarify and focus much of the rest of the discussion. | ||
+ | |||
+ | The group found the [http://informatics.mayo.edu/wiki/index.php/Image:CDC_-_Data_Elements.pdf CDC document] quite useful (Thanks again, Kim). There was a question about whether it was still the latest version or not. | ||
+ | |||
+ | The group reviewed David Aronow's [http://informatics.mayo.edu/wiki/index.php/CaBIG_Flavors_of_Null#Examples_and_Use_cases use cases] and the results of the review are carried there. | ||
+ | |||
+ | |||
+ | While an official synopsis is pending, following are the general conclusions: | ||
+ | |||
+ | * The focus of this group is on the semantics and architectural requirements for MVR's. The physical representation of MVR's (e.g. separate fields, different values in the same field, etc.) are outside the scope of this group. | ||
+ | * EVS needs to have a centralized but extensible collection of MVR's | ||
+ | * The specification of a CDE should include the ability to select which MVR's, if any, are applicable. | ||
+ | * A mechanism needs to be developed to link a MVR attribute with the corresponding data element - both in CDE specification time and in the messages themselves. | ||
+ | |||
+ | === Action Items: === | ||
+ | <table border="2"> | ||
+ | <tr> | ||
+ | <th>Task<th>Assignee<th>Due<th>Status | ||
+ | <tr> | ||
+ | <td>Circulate a draft recommendation document</td> | ||
+ | <td>David Aronow</td> | ||
+ | <td>Next Meeting</td> | ||
+ | <td><b></b></td> | ||
+ | <tr> | ||
+ | <tr> | ||
+ | <td>Review, and edit draft document</td> | ||
+ | <td>Group | ||
+ | <td>Next Meeting | ||
+ | <td><b></b></td> | ||
+ | <tr> | ||
+ | <tr> | ||
+ | <td>Review the examples of MVR's collected to date and initate a draft proposal to EVS</td> | ||
+ | <td>?</td> | ||
+ | <td>Next Meeting</td> | ||
+ | <td><b></b></td> | ||
+ | <tr> |
Latest revision as of 18:29, 1 June 2005
May 27, 2005 Teleconference
Time: 11:00 to 12:00 AM Eastern Time Convert
Phone #: (877)407-0183
PassCode: 680305#
Attendees:
- Jim Kadin Jackson Labs (scribe)
- David Aronow Ardais Corporation
- Harold Solbrig Mayo Clinic
- Brian Davis Booze Allen Hamilton
- Kim Klingler SAIC
- Michael Keller Booze Allen Hamilton
Minutes:
Summary of caBIG - VCDE - "Flavors of Null" telecon.
May 27, 2005
Attendees:
Mike Keller, Brian Davis, Harold Solbrig, David Aronow, Kim Klingler,
Jim Kadin (scribe)
(anybody else?)
Decisions:
1) In light of David's comments from months ago and the CDC's CDE document,
we agreed that "missing values" or "missing value reasons" is a better
name for this small working group than "flavors of null".
It is probably more confusing to change the name of our group at this
point, but it did clarify our thinking significantly.
Our task is to come up with an approach for handling "missing
values" (MV) and "missing value reasons" (MVR) in caBIG.
2) We agreed that what we should focus on is the "currency of data
exchange". That is, we are concerned with how MV and MVR are handled at
the messaging level where data is exchanged between caBIG resources/tools.
We are not concerned with how null or MV or MVR are handled within
databases and applications. In this sense we view CDEs as defining the
semantics of fields at the messaging level.
3) Different MV and MVR make sense in different contexts.
(non-exhaustive - illustrative ) Examples:
- Patient Interview Context
- not sought
- refused
- sought but unknown (patient didn't know?)
- unknown
- Coding data from literature context
not specified
Translating data from one resource to another
not resolved (couldn't translate)
not loaded
Data "extracted from procedures"
not done
not tested
not evaluated
Other/many contexts
deleted for confidentiality
not applicable
4) We discussed several use cases and realized there are fuzzy cases where
the same term might be considered a permissible value (quasi MV) for a
field in one instance and a MVR in another.
Examples:
Clinical test result
Normal
Abnormal High
Abnormal Low
Not specified (permissible value in the case where a data source
does not include such an indicator)
5) Outline of our deliverables to VCDE workspace:
a) define a vocabulary of missing value reasons that CDEs can draw
from. This is likely to be a hierarchy.
b) develop recommendations to CDE developers. They will need to wrestle
with MV vs. MVR.
One possibility: include MV (e.g., unknown, not specified) in the
permissible values
And/Or create a linked CDE for the MVR - with values chosen from the
vocabulary in (a).
It seems probable that we will need some way in the caDSR for
linking a CDE with a CDE for the MVR.
c) develop recommendations for the architecture ws on how MV and MVR for
fields are linked in the messaging layer.
Discussion
After reviewing the CDC Common Data Elements document, we realized that David Aronow had been right from the beginning and the name "Flavors of Null" was misleading and confusing. The group unanomously adopted a new moniker - "Missing Value Reason". This new named helped to clarify and focus much of the rest of the discussion.
The group found the CDC document quite useful (Thanks again, Kim). There was a question about whether it was still the latest version or not.
The group reviewed David Aronow's use cases and the results of the review are carried there.
While an official synopsis is pending, following are the general conclusions:
- The focus of this group is on the semantics and architectural requirements for MVR's. The physical representation of MVR's (e.g. separate fields, different values in the same field, etc.) are outside the scope of this group.
- EVS needs to have a centralized but extensible collection of MVR's
- The specification of a CDE should include the ability to select which MVR's, if any, are applicable.
- A mechanism needs to be developed to link a MVR attribute with the corresponding data element - both in CDE specification time and in the messages themselves.
Action Items:
Task | Assignee | Due | Status |
---|---|---|---|
Circulate a draft recommendation document | David Aronow | Next Meeting | |
Review, and edit draft document | Group | Next Meeting | |
Review the examples of MVR's collected to date and initate a draft proposal to EVS | ? | Next Meeting | |