Profile Disease

[torstees]

Requester information

• Name- Eric Torstenson

• Affiliations- VUMC/AnVIL

Request Details

• Purpose- Condition maps very well to a researcher's Disease, however, our use of verificationStatus isn't exactly the same as the original intent and profiling these would allow us the opportunity to clarify what is to be expected when working Conditions of this sort. We can also restrict the codes to only the relevant codes to avoid misapplication or confusing data sneaking in.

• Who it benefits- Any research project in which there is a need to express Affected/Unaffected status to a disease.

• Use case- A dataset in which there is a traditional status of affected/unaffected can more clearly indicate their cases and controls using this profile.

[allisonheath]

This should likely align with the Phenopackets concept of Disease: https://phenopackets-schema.readthedocs.io/en/latest/disease.html including their recommendations for terminology to utilize.

Do we have some text we can use to describe the verificationStatus?

[liberaliscomputing]

Re verificationStatus, I commented on a wrong issue, but here is my initial thought: https://github.com/ncpi-fhir/ncpi-model-forge/issues/35

[torstees]

@allisonheath Sorry, I forget that not everyone has been a party to our discussions here at vandy.

Our current implementation for CMG fhir plugin uses the following:

• Confirmed => Affected
• Refuted => Unaffected
• Provisional => Possibly Affected

@liberaliscomputing, I couldn't find your comment.

[liberaliscomputing]

@torstees, the first comment on this issue: https://github.com/ncpi-fhir/ncpi-model-forge/issues/35 (my comment was on a Specimen issue, but the argument itself is about Condition.verficationStatus.

[allisonheath]

@torstees ok great, I think that aligns with how we want to use this for KF data as well. And the agreement was for now if something was not reported / unknown / etc., we would just leave it out, correct?

[torstees]

@allisonheath That is my understanding

[nicholasvk]

In addition to verificationStatus, our team is also interested in capturing information about tumor progression/recurrence in the condition resource and clinicalStatus seems like it could be a good fit. Our recommendation is to use the required code set within this field to indicate active/inactive status and add a SNOMED code set to capture additional detailed information.

eigdwh_69.diagnosis	Condition.clinicalStatus	SNOMED CT
Initial CNS Tumor	-	86049000 or 372087000
	active (level 0)	55561003
Progressive	-	255314001
-	remission (level 1)	277022003
-	relapse (level 1)	263855007
-	resolved (level 1)	723506003
Recurrence	recurrence (level 1)	246455001
Secondary Malignancy	-	128462008
-	inactive (level 0)	723506003

Section 3.1 in this document provides a more detailed description of our thoughts on this field. https://docs.google.com/document/d/1I-4OkQaUiFnVQbpXxplmTIVpdnfptSzMqnQvBYvLCC4/edit

[liberaliscomputing]

In line with Nick's comment, our recommendation for verificationStatus is first select from the required codes and then add extra concepts from SNOMED CT (if our enumerations are not coverd by the required ValueSet).