Anatomic Site - CDE (Various)

[GeoffLyle]

caDSR Link: 6161035

Definition: "The text term used to describe the anatomic site of origin, of the patient's malignant disease, as described by the World Health Organization's (WHO) International Classification of Diseases for Oncology (ICD-O)."

Issues:

• Do we allow for multiple values to be selected for this field or do we harmonize to a general term (ex. Brain, NOS) or an unknown/null term (ex. Unknown primary site)?
• How to handle situations where we have more specific data than is in the CDE (ex. Thalamus)?
• Do we select all applicable values for the anatomic site (ex. Frontal lobe, Cerebrum, and Brain, NOS)?
• When we ask other institutions who want to join the federation to harmonize their data in the future, is it going to be clear what they need to do?

[GeoffLyle]

Slack Discussion:

From Geoff Lyle on October 23rd, 2023: Some tumors can be found in multiple locations at presentation. There is an option Unknown primary site (where the primary site can't be determined due to metastasis at presentation). However, many brain tumors can be diffuse or spanning multiple regions of the brain. For example, Treehouse has "brain; right; temporal lobe, frontal lobe" - we could select both Frontal lobe and Temporal lobe or the general Brain, NOS. There is also the option of Overlapping lesion of brain, however, in most cases we do not know whether there are two separate sites or one lesion that spans multiple sites. Finally, there are more specific brain locations in our data that is not captured by the CDE (ex. Thalamus is not an anatomic site). This raises the following issues:

• Do we allow for multiple values to be selected for this field or do we harmonize to a general term (ex. Brain, NOS) or an unknown/null term (ex. Unknown primary site)?

  • I am leaning towards allowing for multiple locations to be selected. I think this is more useful to the end user. However, if there are technical or other logistical reasons for not allowing multiple locations, I could be persuaded otherwise.

• How to handle situations where we have more specific data than is in the CDE (ex. Thalamus)?

  • Similarly to other CDEs, I believe we can use a less precise term as long as it is still accurate. For Thalamus, we could use Brain, NOS or potentially Cerebrum. We will still link back to the unharmonized value where the user can determine if they want to use the more specific information.

• Do we select all applicable values for the anatomic site (ex. Frontal lobe, Cerebrum, and Brain, NOS)?

  • I feel that we should select the most specific region that is still accurate. It would be useful for a tool that groups these anatomic sites into categories (ex. all the brain sites could fall into Brain, NOS) to be developed for the end user, but I do not that think that should fall on the Federation member. There are likely to be some inaccuracies in harmonizing this field, and requiring a member to fill out all possible regions will lead to more inaccuracies.

[GeoffLyle]

Slack Discussion:

From Stephanie Sandor on November 1st, 2023: After a first (quick) pass, St. Jude Cloud also has a slight disjoint in mapping. After speaking with our Scientific Lead, he also agrees that mapping our subtypes to the permissible values for the anatomic site is not really an accurate mapping. We really do not capture "site" for our samples. We might be able to map some, but not all (e.g. bone marrow testing for leukemia ... would we assign this to bone marrow or blood?).
I think discussing this as a broader group is crucial to understanding how we intend to map as a Federation.

[GeoffLyle]

Slack Discussion:

From Clay McLeod on November 2nd, 2023: In short, my thoughts are:

• We allow for multiple values and select every value that applies. This is necessary to select all values that apply, else, individual sites are making decisions about the level of granularity at which to report the information and the value of doing this whole exercise becomes much less clear. If the end user cannot apply programmatic rules to determine some level of harmonization, then I think we have lost a great deal of that value. Note that, in the case of selecting every applicable value, one can perform a set intersection to evaluate what metadata values match up.
• For the less specific term, I agree with your reasoning with the tweak that you should select all applicable values and not just the closest one (not sure if you were implying that or not but wanted to be clear). Our only other avenue is to approach the owner of the CDE, which we should arguably do regardless.
• I guess here I’m seeing we hold opposing opinions. As an aside, for me, NOS is an explicit value of “there are no other permissible values in the CDE that would represent our unharmonized value” and does not represent, say, a root node of all brain tumors. With respect to your point about requiring selection of every applicable value and how that may introduce inconsistencies—it is really a question of which is the lesser of two evils: (a) the opportunity to introduce more inconsistency in the data simply because there are more possible values to map versus (b) how each site or reporter returning a different level of granularity is going to mean much less practical value for the API. I tend to think the latter is the lesser evil, primarily because mistakes are expected and can be corrected (in reference to (a)), but a design where the data is not comparable brings into question the value of doing the exercise at all.
• There is one further point to the above, which is this: when we ask other institutions who want to join the federation to harmonize their data in the future, is it going to be clear what they need to do? They won’t have this group to bounce ideas off of, so the instructions need to be clear. I think that pushing concept of the most appropriate level of granularity is going to cause a lot of confusion and questions, whereas selecting all applicable values is a very easy process to understand (albeit with more opportunities for errors to be introduced)

[GeoffLyle]

Please review the following questions:

• Do we allow for multiple values to be selected for this field or do we harmonize to a general term (ex. Brain, NOS) or an unknown/null term (ex. Unknown primary site)?
• How to handle situations where we have more specific data than is in the CDE (ex. Thalamus)?
• Do we select all applicable values for the anatomic site (ex. Frontal lobe, Cerebrum, and Brain, NOS)?
• When we ask other institutions who want to join the federation to harmonize their data in the future, is it going to be clear what they need to do?

From June 21, 2024 meeting:
Potentially allow for multiple harmonized values, similar to Disease at Diagnosis #38. Up to Federation member how many harmonized values to list. The permissible values are based on ICD-O terms, so we will be unable to add more specific terms to this CDE. For our specific terms should we use the most general term (ex. use 'Brain, NOS' for 'Thalamus')?

[calkinsh]

We would request multiple values, if there are multiple valid CDE terms to pick (vs a broader one). I think it is of more value to provide as much specificity as possible (for example, if a tumor affects multiple brain regions) than the broader, less precise and therefor less informative term.

For cases of more specific data than is in the CDE, we have a lot of these. Since this is not a CDE where we can easily request to add values, we may just have to rely on the presence of the unharmonized value along side the harmonized one. I suppose we could allow more than one ontology like we do for disease, and then add in something like Uberon, but that would be a really significant change and would then shift us away from an established CDE.

Our general practice for selecting values when we've used ICD-O codes in the past would be to select as many codes as possible that are applicable at the lowest level of specificity, but not codes at a higher level than that. So for example if a tumor extended to the Frontal Lobe and Cerebrum, we would select both of those but not Brain, NOS. If a tumor extended to the Frontal Lobe and an area of the brain that did NOT have another valid code, then we would pick Frontal Lobe and Brain NOS, using the Brain NOS code to represent the part of the location that can't be accurately coded (and assuming Brain NOS is the most specific value available for that region). I think the difficulty with "select all applicable" is that its kind of hard to draw a line, like in the example above you could argue it should also include "Head, Face, or Neck NOS", and "Central Nervous System" even though to me those don't seem particularly useful. In general, I would use an NOS code only if we truly are not otherwise specifying the specific region, and I'd default to using only the most specific codes that apply.

[dunnpa]

NCI Semantics team (including caDSR, NCIt, EVS) are moving to adopt uberon as an anatomic site reference source.

[bfurner]

An issue with the "multiple values" approach is that it is not clear if multiple values imply conjunction or disjunction.

For example, we have a value "Bladder/Prostate" that means there is no way at source to distinguish whether the observation applies to bladder or prostrate so the meaning of the string "Bladder/Prostate" is Bladder or Prostate. If multiple values exist, to me, that implies an and operation.

[jpat1546]

CDE Public ID	CDE Long Name	CDE Short Name	Preferred Question Text	Owned By
15066905	Disease Anatomic Site Uberon Identifier	14156277v1.00:11365369v1.00	Anatomic Site Uberon Identifier	Pediatric Cancer
15075913	Disease Anatomic Site Uberon Identifier Name Text	14156277v1.00:15074396v1.00	Anatomic Site	Pediatric Cancer
15066891	Disease Anatomic Site Uberon Name	14156277v1.00:12299652v1.00	Anatomic Site	Pediatric Cancer

We could also consider CDE '12299653' Specimen Original Anatomic Site Uberon Name as a potential option. This CDE aligns with the NCI Semantics team's move towards adopting Uberon as an anatomic site reference source and could potentially address the issues of specificity and multiple value selection raised in the discussion. Will defer to the curation team to confirm this would be a valid option. @dunnpa

[GeoffLyle]

From September 20th Meeting:

Federation members are to review the following CDEs and determine which one would fit their data (and other Federation members') best. Discussion about which CDE we should adopt will take place at the next CCDI Data Harmonization subgroup meeting:

• Disease Anatomic Site Uberon Identifier 15066905
  Definition: "The location in the body where disease is present as captured in the Uberon identifier."
• Disease Anatomic Site Uberon Identifier Name Text 15075913
  Definition: "The location in the body where disease is present as captured in the Uberon identifier and Uberon name."
• Disease Anatomic Site Uberon Name 15066891
  Definition: "The location in the body where disease is present as captured in the Uberon name."

[GeoffLyle]

From October 4, 2024 meeting:

Discussed which Uberon terms the Federation should report to the user. Potentially can support multiple fields, one for Uberon Name, one for Uberon Identifier, and one that concatenates these two values.
Questions for CCDI:

1. Is there are preferred Uberon data field to report to users? If it is both the Identifier and Name is there a preferred way of concatenating these values?
2. Can we have a link to the Uberon terms currently being used by CCDI members (or a link to the Uberon terms to be used by the CCDI Federation)?

[GeoffLyle]

From October 18, 2024 meeting:

Discussed using Uberon terms for reporting sample anatomic site. Federation members all preferred Uberon over ICD-O. Questions still remain over how Federation would implement Uberon terms in the API (which version would be used, how to enforce terminology).

@dunnpa Can you provide details on how the CCDI is using Uberon ontology and how version control is implemented.

[dunnpa]

re: Uberson versioning
Uberon appears to be using a timestamp.

https://www.ebi.ac.uk/ols4/ontologies/uberon
Uber-anatomy ontology
Version 2024-09-03

If the question is how is version control implemented, I think that's a Q for EMBL.

re: How is CCDI planning to use Uberon, that's still in planning and we look forward to Federation insights.
As noted, Uberon has a large number of terms.
One approach would be to maintain a local sub-set of Uberon terms and codes for the relevant sub-set of of Uberon that CCDI sees and use that for validation (~347 site terms currently). If a user provided term does not match the CCDI local copy, an API call to Uberon might be made to see if a match can be found. A manual search of Uberon is another option if the frequency of not finding local copy matches is not high. Updating the local CCDI subset of Uberon would be a curation maintenance task.