For Comment: Deeper dive into how NCPI Condition links to NCPI Participant

[mingward]

Link to Profile

https://nih-ncpi.github.io/ncpi-fhir-ig-2/StructureDefinition-ncpi-condition.html

Feedback Submission

Will FHIR allow linking NCPI Condition to NCPI Participant from subject?
We ask because of the following:
NCPI Condition.subject is supposed to link to NCPI Participant.
NCPI Condition is derived from Observation.
NCPI Participant is derived from base (not Patient).
Observation.subject has a limited set of resources it can link to ( see: https://www.hl7.org/fhir/observation.html ) and base class is not one of them. Will FHIR allow linking NCPI Condition to NCPI Participant from subject?

Is this feedback implementation-blocking?

Yes, this issue will block implementation.

[RadixSeven]

I propose deriving NCPI Participant from the Patient resource. There are several overlapping fields

• participantId -> id
• externalId -> identifier
• dateOfBirth -> birthDate

Narrowing the semantics of these fields by changing the text description and then adding other fields as extensions seems more compatible with other FHIR implementations than having a resource that is just one big extension.

[RadixSeven]

Using Patient would also remove the need for Person as a separate resource. Person has two attributes: the participant and an identifier. We could just use "identifier" with an appropriate code. The participant identifier comes from the containing object. This would better match the overview diagram, which shows Participant being composed of multiple Person resources. The identifier entries that substitute for Person could be distinguished from those used for externalId by having a different type field.

[RadixSeven]

Since I wrote the above, the definitions have changed. Participant is now based on Patient. And there have been other significant changes (e.g., using the US Core profiles for race, ethnicity, and birth sex).

At first glance, birth sex should be modified slightly - we frequently do not know birth sex directly. Instead, we have things like an asserted sex or a chromosomal sex. In 99% of cases these will be the same, but we should be precise on this issue.

[RadixSeven]

Since the change to use Patient as a base this issue no longer is a problem. However, there are other problems about which I should create issues.

• The US Core links go to an old version of the standard; they link to STU3.1.1, and the current version is STU5.0.1. The 5.0.1 version adds crucial values for Birth Sex (OTH and ASKU)
• Birth sex is a poor choice.
  • Birth sex is different than chromosomal sex. We almost certainly do not have birth sex (most studies do not collect birth certificates).
  • dbGaP has a lot of chromosomal sex and a lot of "sex recorded by the study."
  • I recommend switching to sex parameter for clinical use, though that is not a perfect fit because what we want is "sex parameter for research use." However, "sex used to interpret this study" is pretty close to what we want.
  • We could consider a custom "simplified sex" field with the semantics "whatever the curators thought would be most convenient for users" and include the full details in appropriate Observation resources. This would lose precision but be much more convenient for 99% of users.
• US Core Ethnicity has a required binding and does not have values that match the GRAF-pop ancestry values computed by dbGaP. At a minimum, we should mention in the IG how we map →ethnicity. For example, we could document that POP 3: "East Asian" will be represented as 2034-7 "Chinese" (this may not be a good choice; I'm not recommending it, just using it as an example).
• The population member needs better documentation. From the example, I can see this element is intended to be some kind of ancestry string, but I have no idea how to fill it out or how to search it.