April 7, 2005

April 7, 2005 Teleconference

Time: 3:30 to 4:30 PM Eastern Time Convert
Phone #: (877)407-0183
PassCode: 743824#

Attendees:

• Jim Kadin Jackson Labs
• David Aronow Ardais Corporation
• Harold Solbrig Mayo Clinic
• Brian Davis Booze Allen Hamilton
• Kim Klingler SAIC

Discussion

Harold discussed an e-mail about the the value of "other" in the Sex&Gender proposal.

The issue of how caBIG intended to deal with multiple representational forms was raised. Would there be a single "preferred" internal form, with mappings defined to and from other external forms? If so, how should the translations be handled between differing levels of granularity and specificity?

David suggested that this problem may be at least partially reconciled if caBIG adopts the "80-20" rule and doesn't try to capture everything at the finest level of granularity. Using the example of the shoe color, if caBIG handled "green shoes" and didn't try to capture nuances such as "pale lime green", "bright green", etc. HRS - hasn't the Sex&Gender recommendation already brought this to the doorstep by proposing to define compositional gender information - "Male as reported by the patient", "Female as determined by Karotype", etc?

Harold suggested that, by representing null information as metadata, we had already brought translational issues to our doorstep, but perhaps they could be restricted to this general area.

Kim indicated that, while she agreed with the proposal, she would need to talk to some internal folks to understand the ramifications regarding the existing implementations.

David reiterated his previous objection to the use of the word "NULL" in that it changed the scope of the group to presence/absence instead of valid values such as "Unremarkable". He proposed that it should be up to the curators of a data element to select which EVS flavors of null could be used in the specific conceptual domain.

Harold asked what should be done about non-enumerated elements, stating that it seemed like many of the nullibity characteristics applied to them as well.

David that he that, while he didn't know the answer, he thought that moving FON out of valid value sets would get us into trouble. Also, it needed to be recognized that many data elements required two value sets, such as an indicator and a text note, or a percent and a numeric count.

---

DA - some of the thoughtful comments in this section are incorrectly attributed to me - are they yours Jim?

There was some discussion about the "proposed" decisions on the web page. David asked for clarification about the phrase "rooted at a single domain" in bullet 3. The intent was that all of the various nuances of null would all be subtypes of this generic "null" domain, which would allow applications to take any code and ask whether it represented a real value or a type of "null".

David asked about the potential open-endedness of any approach that allowed a data element to use any of the children of the "null" domain. He was concerned that, as new flavors were added, the available choices would change in the data element itself.

David also asked about bullet point 4, which asserted that optionality and nullability should be separate from the data element declaration. He indicated that he viewed optional data elements as different things than required elements and wasn't sure that having to define both was such a bad idea.

This led to a discussion involving how optionality was currently defined in caBIG. The group wasn't clear whether optionality was a core part of the caDSR or was asserted by external applications like the form builder. There was some discussion about whether a "well behaved" application could make any assumptions about required data. Jim asserted that one of the points of being able to share data was the ability to document what is and isn't provided. He presented an example of "gene", which, in a microarray report might be optional, as not all probes would be coupled with known genes, but which would be required in other types of transactions.

---

Brian suggested that we need to keep our options open until we review the use cases. He expressed some doubt that the EVS solution was viable.

Action Items:

Task	Assignee	Due	Status
Gather more use cases to determine actual caBIG needs	Group	Next Meeting	Complete
Find out how null is represented now	Kim Klingler	Next Meeting	Complete
Discuss technical issues w/ NCI staff and report back	Kim Klingler	Next Meeting	Complete
Review some of the 1043 data elements with "unknown" as a value	Kim Klingler	Mailer	Complete

---

---

Next Meeting:

Group will attempt to gather at next week's FTF. Followup meeting won't be until week of April 18 at the earliest. Ongoing discussion will occcur over e-mail and this WIKI.

Outstanding action items from earlier meetings :

Task	Assignee	Due	Status
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

---

---