Profile Tissue Affected Status

[torstees]

Requester information

• Name- Eric Torstenson

• Affiliations- VUMC/AnVIL

Request Details

• Purpose- We are currently using Observation for these, but by creating a profile, it can be made much clearer what the observation is and allow us to restrict the codes that can be used to only those that make sense for the stated purpose.

• Who it benefits- Anyone where samples are drawn within a given disease context where the subjects are either Affected or Unaffected by the initial condition.

• Use case- A specimen is taken for the purposes of studying a particular disease and the subject is identified as either a case or a control.

[liberaliscomputing]

Does the affection status at a specimen level deliver a different meaning from that at a condition level?

If not, I wonder if using Observation or creating a new profile off of Observation is necessary to curate the affection status. Condition has an attribute called verificationStatus which seems qualified for recording the affection status. This attribute is defined as:

The verification status to support the clinical status of the condition.

This attribute binds a ValueSet called condition-ver-status with a binding strength required. Since the data type is CodeableConcept with maximum cardinality = 1, we should pick at least one value from this ValueSet. In addition, we cannot specify new or additional codes for these elements. Once that's met, we can include codes from other CodeSystems. For example, when affected,

{
  "resourceType": "Condition",
  "meta": {
    "profile": [
      "http://fhir.kids-first.io/StructureDefinition/Condition"
    ]
  },
  "id": "cd-001",
  "verificationStatus": {
    "coding": [
      # At least one Coding element should be present from the above ValueSet
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
        "code": "confirmed",
        "display": "Confirmed"
      },
      # The rest of the Coding elements can be chosen from other CodeSystems
      {
        "system": "http://snomed.info/sct",
        "code": "103309006",
        "display": "Patient affected "
      }
    ],
    "text": "Affected"
  },
  "subject": {
    "reference": "Patient/pt-001"
  }
}

[RobertJCarroll]

Did you have a proposal for how to handle this, Eric?

[torstees]

This is not the same as patient's status from the condition itself. Instead, it is tied more specifically to the actual specimen. Kristin said this the other day in slack, which clarified things a bit for me: "I think it's more related to the issue that a person may be affected by a disease, but that disease may not manifest in all tissues so it needs to be captured if the sample source tissue is an affected source of tissue."

This is probably not relevant for most datasets, but for our CMG efforts, we will need to differentiate between this status and that of the actual condition under investigation.

We do currently have this implemented, but not profiled, in our fhir ingest library and we are using:

• Subject => Patient
• Specimen => Specimen
• Code => Affected/Unaffected from the hl7 terminology Code System for Observation Interpretation (POS/NEG)

[liberaliscomputing]

@torstees, I see. Then, is this sample-level affection assertion also applied to other studies than oncology studies? If it is about studies in oncology, then it seems to me that this is a matter of whether a tumor or normal (correct me if I am wrong)? If I understand correctly, then we can use Specimen.type.

@RobertJCarroll @kwuichet @allisonheath

[allisonheath]

@liberaliscomputing yes, we have some use cases along these lines where we have tissue from legions or areas that are considered "affected", e.g. bone from areas that aren't growing properly. So I agree with needing the two levels of annotation. I think for the specimen level though, we're likely going to need more than just the Specimen.type field.

In GDC parlance, the type seems to be most aligned with the sample_type: "Text term to describe the source of a biospecimen used for a laboratory test." While what we need for the affected status is more tissue_type: "Text term that represents a description of the kind of tissue collected with respect to disease status or proximity to tumor tissue.".

I will say a lot of people seem to get those fields confused, so not sure if there's better naming or better to align with the terms because they exist?

We probably want a more robust terminology than the handful of verificationStatus that come with condition here as well. Likely NCIt is a good place to start for those.