This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "April 7, 2005"

From HL7Wiki
Jump to navigation Jump to search
Line 24: Line 24:
 
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.
 
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 propopse
+
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.
 +
----
 +
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. 
 +
 
 +
=== Action Items: ===
 +
<table border="2">
 +
<tr>
 +
<th>Task<th>Assignee<th>Due<th>Status
 +
<tr>
 +
<td>Gather more use cases to determine actual caBIG needs</td>
 +
<td>Group</td>
 +
<td>Next Meeting</td>
 +
<td></td>
 +
<tr>
 +
<td>Find out how null is represented now
 +
<td>Kim Klingler
 +
<td>Next Meeting
 +
<tr>
 +
<td>Discuss technical issues w/ NCI staff and report
 +
<td>Kim Klingler
 +
<td>Next Meeting
 +
</tr>
 +
</table>
 +
----
 +
----
 +
=== Outstanding action items from earlier meetings : ===
 +
<table border="2">
 +
<tr>
 +
<th>Task<th>Assignee<th>Due<th>Status
 +
<td>Find out how HL7 deals with present but null
 +
<td>Harold Solbrig
 +
<td>4/4
 +
<tr>
 +
<td>Post a reference to the types of negation found in text
 +
<td>Rebecca Crowley
 +
<td>4/4
 +
</tr>
 +
</table>
 +
----
 +
----

Revision as of 21:10, 7 April 2005

April 7, 2005 Teleconference

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

Attendees:

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.

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.

Action Items:

TaskAssigneeDueStatus
Gather more use cases to determine actual caBIG needs Group Next Meeting
Find out how null is represented now Kim Klingler Next Meeting
Discuss technical issues w/ NCI staff and report Kim Klingler Next Meeting

Outstanding action items from earlier meetings :

TaskAssigneeDueStatus 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
Retrieved from "https://wiki.hl7.org/w/index.php?title=April_7,_2005&oldid=297"