General Feedback - NCPI Participant observations

[mholck]

What were you reviewing?

NCPI Participant profile

Feedback:

Should there be a recommended valueset for the population values to use and should we allow string which breaks semantic interoperability? The extension dob-method is bound to valueset Enumerations for how DOB was constructed but the expansion shows title-types. Perhaps this is just a placeholder? Rather than birthdate should we consider something like ageAtEnrollment or perhaps that should be on ResearchSubject.

Review Date:

October 11, 2024

[RadixSeven]

This looks like several issues. I'll separate them, rephrase them as I understand them, and put comments under each.

• What should be the value set for Patient.extension:population? string is not usually interoperable.
  • Summary of my comments below: Remove string as an option. Make the cardinality 0..*. Rename the population slice to raceEthnicityOrAncestry.
  • I agree that Patient.extension:population should not have string as an option. All use cases for string that I can think of can be taken care of by CodeableConcept.text
  • This should have a cardinality of 0..* rather than 0..1. You may want more than one descriptor absent from US-Core.
  • We should rename this field. raceEthnicityOrAncestry is possible, but population is the wrong name. (I'll make another issue proposing using camelCase for the extension slice names.)
    • Population can mean case/control, smoking/non-smoking, or many other things.
    • Any CodeableConcept variable could be put under population. Though this has efficiency and elegance implications (below), unclarity over what variables belong there would hinder interoperability.
      • On one hand, I like putting all the CodeableConcept Observation resources for a study into a Participant resource's population field
        • It would make finding patients with particular values easy in the FHIR search syntax
        • It reduces the boilerplate over putting these in Observation.
        • It would make data transfer faster (because of the reduced boilerplate.)
        • It models them as attributes of the participant rather than reified resources with an independent ID - values rather than references.
      • On the other hand
        • It could make Participant resources very large.
        • It is not clear which study-reported participant characteristics to make into "Observation" and which to make into attributes - which would hinder interoperability
  • In an ideal world, the categories under US Core Race and US Core Ethnicity should be subsumed under raceEthnicityOrAncestry. However, the standard extensions will be more interoperable with existing data.
• There is a disagreement between ResearchDateOfBirthMethod and the expansion of the value set.
  • This looks to have been rectified.
• Suggesting that we use ageAtEnrollment rather than Patient.birthDate.
  • The age at which a particular measurement is taken will be more valuable than either. Though specific time periods can be predictive (e.g., childhood exposure to lead before leaded gasoline was banned in one's natal country), age is usually much more predictive.
  • Since Patient.birthDate is optional, it's OK to leave it in.
  • dbGaP never has Patient.birthDate (it is not allowed because it is considered identifying information) and seldom has ageAtEnrollment.