STU Ballot - Participant Module (November, 2024)

[JamedFV]

Purpose of the STU Ballot

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

• Link to Module: https://nih-ncpi.github.io/ncpi-fhir-ig-2/module_participant.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 Comment)
  • 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 November 26, 2024 to December 10, 2024.

[elthomson]

ImmPort
Approve
Comments: ImmPort is using R5 and that may have an impact in creating / supporting a generic query interface across the different FHIR servers. For instance, there are several property name differences between the R4 and R5 ResearchSubject resource. Some of the difference are listed below:

R4 R5
individual subject (Patient)
assignedArm (string) assignedComparisonGroup (id of a Group)

ImmPort is using the Group resource to link Patients to an ARM/Cohort. Other groups may be using another method to identify groups of Patients.

In ImmPort there is only one Patient resource for each individual however other teams mentioned using multiple Patient resources to represent an individual because a Patient record in one study may have different consent requirements in another study.. ImmPort handles Patients that participate in several studies by creating multiple ResearchSubject records, one for each Study/Patient combination.

Currently ImmPort is not using Tags or Extensions in the Resources as other teams appear to be using. One issue we are facing is how to tie an Observation record to a specific ResearchSubject linked to a specific ResearchStudy. The subject property in Observation does not allow linking to a ResearchSubject resource. Using Tags may be one way to address this issue.

Depending on the final version of the IG. ImmPort may need to update the ETL software used to transform the data from our relational format into FHIR resource format matching the IG.

[bwalsh]

Platform Name: CRDC

Vote: Approve

Comments:

The IG describes the ResearchSubject to Patient relationship:

"ResearchSubject provides the linkage between a Patient and a ResearchStudy.

This is the pattern we are following.

At the same time, the IG describes the Group relationship as:

Some groups, eg, Immport, use a sub-grouping within a study to describe in more detail the relationship of Participant and Study. This could be a new entity, it could be “just” a sub-Study, or it could be an attribute of the Study Participation.

The IG would benefit if we tightened this language and linked it to examples.

[Mborsellino]

Platform Name: BioData Catalyst
Vote: Approve
Comments: N/A

[RobertJCarroll]

Platform Name: AnVIL
Vote: Approve
Comments:
Overall this looks like a reasonable place to pilot implementation. There are a few areas, eg, as discussed in #88 , that could use some testing and review. I'm anticipating that we'll need to do these iterations in the future.

[calkinsh]

Platform Name: Kids First DRC
Vote: Approve
Comments: N/A

[mingward]

Platform Name: dbGaP
Vote: Approve
Comments: We approve this with the understanding that, as a group, we will continue to improve the IG2 module. Normally, the prototypical HL7 STU ballot means only minor changes—such as typos or small suggestions—are expected. However, we believe the current IG requires more revisions, including fixing the definitions of some entities (for example, #68 (comment)) and addressing a set of documentation issues that could lead to misunderstandings of IG2 (listed here: https://github.com/NIH-NCPI/ncpi-fhir-ig-2/issues). We believe that approving now will enable each repository to move forward with testing the Participant module in IG2, which will further improve this specification.