STU Ballot - Phenotype/Condition Module (January 2025)

[JamedFV]

Purpose of the STU Ballot

This issue is for the Phenotype/Condition Module STU Ballot. The goal of this ballot is to determine whether this module is ready for trial use across platforms' implementation. Feedback gathered during the trial period will inform further refinements.

• Link to Module: https://nih-ncpi.github.io/ncpi-fhir-ig-2/module_phenotype_condition.html

Voting Instructions

• Each platform is allowed one vote (submitted by the assigned POC) that will inform the outcome of the ballot.
  • Once the POC has submitted their vote, please checkoff your platform in the checklist provided below.
  • Other votes are permitted, but will not be considered in the pass/fail determination of the ballot.
• Please follow the format and instructions provided under the "Voting Template" to record your vote.
• Vote Types:
  • Approve (Optional Comments)
  • Disapprove (with Comments)

Voting Template

Copy and paste the following template into a comment to case your vote:
''
Platform Name: [Your platform name here]
Vote: [Approve (Comment Optional) | Disapprove (with Comments)]
Comments:
[Your comments here. If voting "Disapprove (with Comments)," include specific concerns or suggestions.]
''

Platforms Voting Checklist

Please check off your platform once you have submitted your vote in the comments.

• AnVIL
• Kids First DRC
• ImmPort
• Bio Data Catalyst (BDC)
• Cancer Research Data Commons (CRDC)
• dbGaP

Voting Period

• The voting period if open from January 28, 2025 to February 11, 2025.

[RobertJCarroll]

Platform Name: AnVIL
Vote: Disapprove
Comments:
I think we have 2 major needs to address before this is ready and one consideration for the future.

1. We need to set the right scope + naming for the "NCPI Condition". Perhaps something like "Health Status Assertion".
2. We need to add in a profile for "generic measurements". It will add needed clarity of implementation for users and help clarify the scope.
   Re the future consideration:
3. We should consider a Condition profile that is an "NCPI Condition Summary" that shows how users could implement Condition resources for the IG. I put this as a future consideration as we need to figure out the "convention" side of things, eg, "what do we expect servers to support", as this could have "duplicate" information from the "Assertion" profiles.

[bwalsh]

As a researcher interested in a Phenotype(Condition), in order to evaluate if a server has data I can use, it would be most effective if the server maintained a single resource that down stream resources are chained to.

For example:

• Given interest in Breast Cancer I should be able to quickly query Phenotype(Condition) to determine best match.
• Having a match on Condition, I should have predictable paths to reach Patient, etc.
  • Perhaps Phenotype(Condition)->Health Status Assertion(Diagnosis)->Patient->Specimen

To me at least, the "stock" FHIR definition of Condition includes a link to subject and qualifiers, so the goal of having a single resource per studied condition is elusive.

[elthomson]

Platform Name: ImmPort
Vote: Disapprove
Comments:
ImmPort’s existing representation of Condition is at the study level and would not directly apply to all subjects in a study. In order for Condition to be represented for all Participants the ImmPort team would use the arm/cohort annotation to which the participant is assigned as the Condition. Arm/Cohort annotations are free text, not standardized. Details about the condition will require extraction of data from the participant assessment data - this data is uploaded as non-standardized, free text and would require a significant level of effort.

Proof of concept: If determined to be an essential data element to move forward, the ImmPort team could limit the mapping effort to focus solely on the URECA study only and model in R5.
ImmPort question: What would be the preferred approach for addressing combined conditions / confounding health factors an individual participant may have?