March 31, 2005
Jump to navigation Jump to search
March 31, 2005 Teleconference
- Jim Kadin Jackson Labs
- David Aronow Ardais Corporation
- Harold Solbrig Mayo Clinic
- Brenda Muskie
- Rebecca Crowley, MD UPMC
- Brian Davis Booze Allen Hamilton
- Kim Klingler
- Harold briefly described the HL7 flavors of null and how they were organized.
- A question was raised about the difference between optional fields that were omitted and fields that were present but null.
- David observed that the HL7 flavors of null and their definitions had a very "H&P" (patient centric) focus. The task of information abstraction has a very different focus and requirements. Examples:
- Not sought - didn't bother to look for it
- Not reported - looked for it but it couldn't be found
- Reported and Done - ????
- Not identified - not seen
- Jim described that the mouse sequence had a number of embedded flavors of null, for example:
- not applicable
- not specified
- The question was raised whether Null flavors could be generalized. David suggested that the EVS was the place to record and resolve these various issues. He also suggested that flavors of null might be tightly coupled with the more general problem of negation. David suggested "robustly stocking EVS with terms that cover the different flavors of null".
- Rebecca mentioned that the notion of negation in text may apply here as well.
- There was a discussion about the scope of the group and whether it should include recommendations about how null flavors would fit into the caDSR and related tooling. Brian recommended that the group's solution should be abstract and that the actual solution should be left to the toolmakers.
- There was a short discussion about the fact that "NULL" had a very specific meaning to database people and that the name of the group may be confusing. The majority of the group decided to stick with the existing name.
- Issues were raised about where the notion of "nullability" fit into data element definitions:
- Should "nullability" be something that is added to data elements when necessary -or-
- Should "nullability" be the default setting of all data elements unless otherwise specified
- Rebecca stressed that this is a significant decision because the default case will determine the behavior of the majority of the data elements
- David mentioned that both data sources and data acquisition modules will exist on the grid and the "nullability" characteristics may be different between these
- There was a short discussion about data collection modules and the need to have dropdown lists that allow the selection of the reason(s?) that a data element is omitted.
- Harold mentioned that "nullability", like cardinality may be an attribute of the association of a data element within a "record" or "composite element" and that we wanted to avoid the mistake made by LDAP and the OWL communities when they made cardinality an attribute of the element itself. The outcome of doing this it that it frequently becomes necessary to define two identical data elements that differ soley by their cardinality - (e.g. an optionalBirthDate and requiredBirthDate)
|Post the flavors of null on the mailer||Harold Solbrig||4/1||Complete - posted on this WIKI|
|Find out how HL7 deals with present but null||Harold Solbrig||4/4|
|Post a reference to the types of negation found in text||Rebecca Crowley||4/4|
Next Meeting: First week of April. Date and time TBD