Difference between revisions of "May 27, 2005"

From HL7Wiki
Jump to navigation Jump to search
Line 27: Line 27:
 
Decisions:
 
Decisions:
  
1) In light of David's comments from months ago and the CDC's CDE
+
# In light of David's comments from months ago and the CDC's CDE
 
document,
 
document,
  
Line 42: Line 42:
 
values" (MV) and "missing value reasons" (MVR) in caBIG.
 
values" (MV) and "missing value reasons" (MVR) in caBIG.
  
2) We agreed that what we should focus on is the "currency of data
+
# 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
 
exchange". That is, we are concerned with how MV and MVR are handled at
Line 55: Line 55:
 
semantics of fields at the messaging level.
 
semantics of fields at the messaging level.
  
3) Different MV and MVR make sense in different contexts.
+
# Different MV and MVR make sense in different contexts.
  
 
(non-exhaustive - illustrative ) Examples:
 
(non-exhaustive - illustrative ) Examples:
Line 89: Line 89:
 
not applicable
 
not applicable
  
4) We discussed several use cases and realized there are fuzzy cases
+
# We discussed several use cases and realized there are fuzzy cases
 
where
 
where
  
Line 110: Line 110:
 
does not include such an indicator)
 
does not include such an indicator)
  
5) Outline of our deliverables to VCDE workspace:
+
# Outline of our deliverables to VCDE workspace:
  
 
a) define a vocabulary of missing value reasons that CDEs can draw
 
a) define a vocabulary of missing value reasons that CDEs can draw

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:

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.

  1. 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.

  1. 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

  1. 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)

  1. 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:

TaskAssigneeDueStatus
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