May 27, 2005
May 27, 2005 Teleconference
Time: 11:00 to 12:00 AM Eastern Time Convert
Phone #: (877)407-0183
- 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
Summary of caBIG - VCDE - "Flavors of Null" telecon.
May 27, 2005
Mike Keller, Brian Davis, Harold Solbrig, David Aronow, Kim Klingler,
Jim Kadin (scribe)
- In light of David's comments from months ago and the CDC's CDE
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.
- 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.
- Different MV and MVR make sense in different contexts.
(non-exhaustive - illustrative ) Examples:
- Patient Interview Context
- not sought
- sought but unknown (patient didn't know?)
- Coding data from literature context
Translating data from one resource to another
not resolved (couldn't translate)
Data "extracted from procedures"
deleted for confidentiality
- We discussed several use cases and realized there are fuzzy cases
the same term might be considered a permissible value (quasi MV) for a
field in one instance and a MVR in another.
Clinical test result
Not specified (permissible value in the case where a data source
does not include such an indicator)
- 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
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.
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.
|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|