✨ Profile disease

[liberaliscomputing]

This PR adds:

• a disease StructureDefinition resource;
• an age-at-event SearchParameter resource; and
• a corresponding example resource;

This PR closes #36.

Re @RobertJCarroll @allisonheath

[liberaliscomputing]

Before promoting this to a Ready-for-review PR, we need to discuss whether we need additional CodeSystems and ValueSets for:

• "clinicalStatus"?
• "verificationStatus"?
• "code" (MONDO, NCIt, etc.)?

[RobertJCarroll]

Can we increase the scope of the Status fields without breaking the spec? I didn't think we could as they are required now.

Re code, it could be nice to set a recommendation / example for this. We'll end up with a really big list I expect, though!

[liberaliscomputing]

@RobertJCarroll

Re the Status fields, when an attribute has a bound ValueSet with a binding strength "required", we:

• Should pick at least one code from the bound ValueSet; and
• Could only limit the codes (not adding additionals) when custom-profiling.

So, we should pick at least one codes from the existing ValueSets and then can pick other codes from other CodeSystems (please refer to my comment here: https://github.com/ncpi-fhir/ncpi-model-forge/issues/35).

Re "code", here is an example from PCGC: https://github.com/ncpi-fhir/ncpi-model-forge/blob/profile-disease/site_root/input/resources/examples/Condition-dg-001.json#L55-L69

[RobertJCarroll]

But we can't actually add them, so this is more of a convention / documentation thing as I understand it. I'm not sure I'd try and overload those fields too much- if they aren't suitable for what we need, we should explore other options. I don't see any documentation of the case we are unable to cover in this PR- can you link to it elsewhere? I know we've discussed it, but I don't recall on landing on any "problem case".

[RobertJCarroll]

This was also really interesting to read: https://confluence.hl7.org/display/PC/Representing+Negatives?preview=/65077572/65077576/HL7_XPARADIGM_NEGATION_R1_I2_2019JAN_Edits.docx Makes me wonder a little bit if we shouldn't pursue the positive and negative assessment assertions as observations and optionally include condition resources for positives.

[allisonheath]

Agreed @liberaliscomputing let's leave clinicalStatus andverificationStatus` as-is from FHIR right now.

For the codes, also let's not restrict it for now, but provide some of the recommendations as listed by Phenopackets in the link in the original issue and provide some examples.

@RobertJCarroll that is an interesting approach, could you start a new issue where we could discuss a bit further?

[liberaliscomputing]

@allisonheath, Re "but provide some of the recommendations as listed by Phenopackets in the link in the original issue and provide some examples," I am not sure what it means:

• Our example resource includes codes from MONDO and NCIt (https://github.com/ncpi-fhir/ncpi-model-forge/blob/profile-disease/site_root/input/resources/examples/Condition-dg-001.json#L55-L69), and do you mean that?
• Or we can:
  • create MONDO and NCIt CodeSystems with example codes;
  • create a ValueSet called "disease-codes" including these CodeSystems; and
  • bind this ValueSet to Condition.code with a binding strength "example".

[nicholasvk]

But we can't actually add them, so this is more of a convention / documentation thing as I understand it. I'm not sure I'd try and overload those fields too much- if they aren't suitable for what we need, we should explore other options. I don't see any documentation of the case we are unable to cover in this PR- can you link to it elsewhere? I know we've discussed it, but I don't recall on landing on any "problem case".

Hi Robert, I am not sure I understand what it means that this is convention/documentation only. Our interpretation of the clinicalStatus and verificationStatus fields on condition was that while a value from the existing set is required, additional sets can be added for specificity, and they call out SNOMED as an example in the comments of each field as an option. Our use case for clinicalStatus is capturing more specific status information about the tumor, if its an initial diagnosis, or a progression/recurrence of a tumor. See below for how we thought the required values and SNOMED values might work together within this field. Note: That if we were OK with this approach we would need to align a required field for each of the SNOMED codes since the required code must be added, so for example we probably would want to align "Active" with the Initial tumor.

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

[bwalsh]

+1 LGTM