Phenotypic feature review

[ShahimEssaid]

Reviewing our PhenotypicFeature profile and related content. This issue is to track and discuss anything while we review the current modeling of a phenotype. This first post can be considered a wiki post and a summary of the review status.

[ShahimEssaid]

I'm starting some work in the "se-phenotypic-feature-review" branch.

[ShahimEssaid]

A few working notes to use during our next meeting:

Issues to consider addressing related to modeling a phenotype, the PhenotypicFeature profile, and other related artifacts:

• For the profile introduction section:
  • It is written from the GA4GH Phenopacket point of view, and refers to modeling concepts that are unique to it. For example, this phrase used to describe a phenotypic feature that characterizes the subject of the Phenopacket does not make sense in FHIR since, in FHIR, an Observation points to it's subject and there is no equivalent of the idea of a subject of the Phenopacket. This section should be written from the point of view of FHIR and later can be mapped to concepts in Phenopacket in a separate section.
  • It should be focused on the profile only and not assume how it will be used, how other profiles might refer to it, etc. For example, there is no need to refer to the idea of a packet or the Phenopacket profile. The usage of this profile, in this IG, will automatically be detected by the Publisher and this information will be added to the generated pages. Also, there is no need to give the sense that this profile should be used with our other profiles. Users should not assume this, and they should be able to refer to this profile in their own IGs as they see fit.
  • severity component discriminator. Should we use LOINC as well? This? https://loinc.org/LL6109-4
    • So this is not tied to HPO
    • The content of the component can use whatever a project agrees to (HPO vs others).
    • Should this be en entry in the modifiers slice instead of it being its own slice?
    • Do we really want a required binding to HPO? I think we should be more flexible here, and allow folks to extend as they see fit. Explore R5's new binding features.
  • Add Phenopackets mapping information to the profile itself.
  • pattern discriminator type is now deprecated and we should update to value. See: https://hl7.org/fhir/R5/profiling.html#discriminator
  • The slicing we have can be rewritten in a cleaner way. See: https://build.fhir.org/ig/HL7/fhir-shorthand/reference.html#step-3-constrain-the-slice-contents
    • No need to do step 1 over and over, do one contains rule, etc.
  • Should we define a CS/VS for our own component discriminators?
    • This reduces our dependency on external CSs/Vss
  • No need to use the display as part of the discriminator.
  • onset not fully modeled (the coded onset is not available) but there is this extension:
    • https://build.fhir.org/ig/HL7/phenomics-exchange-ig/branches/master/StructureDefinition-CodedOnset.html
    • Its context is Condition
    • Should we model this as a component, or use an extension? I am in favor of using the .component approach for all phenotype modeling but a general extension for various resources might be more flexible especially if we need some complex structure.
    • But, let's stick with the FHIR way and the FHIR model as much as possible until we have a real need/use case.
  • resolution not modeled (same as above)
  • We should probably think about how a phenotype instance can be used for knowledge resources. For example, this disease type can show this phenotype (as opposed to a patient phenotype instance). This is relevant to Evidence in Phenopacket
  • Do we really need to set cardinality 0 for some of the Observation fields? I think it's better to add what we want, document it, and not block other fields. Others, including our IG, can extend this profile and have a very concrete and use-case specific profile to force additional validation beyond our semantics (defining the components, bindings, VSs, etc.)
  • Review the must support decisions. If we use it at all, we should have an explanation in our IG for what that support means on both the client and server side, and the overall use case.
    • Do we need MS at all?

[ShahimEssaid]

From @julsas , and example of an extension for the onset/resolution issue above. See: https://simplifier.net/mii-basismodul-diagnose-2024/mii_pr_diagnose_condition https://simplifier.net/packages/de.basisprofil.r4/1.4.0/files/656774

We can implement something similar, and to be applied to the appropriate contexts even nesting into Period.

[julsas]

pattern discriminator type is now deprecated and we should update to value. See: https://hl7.org/fhir/R5/profiling.html#discriminator

To clarify: I understand this should work in R4 because 'pattern' and 'value' as discriminator types work the same way and hence they deprecated 'pattern' in R5. What 'value' as a discriminator does is, it checks ElementDefinition.pattern[x] and ElementDefinition.fixed[x] and decides whether the profile defines a fixed value or pattern via these elements. So the discriminator type 'pattern' is deprecated but we can still use the concept of patterns in profiling. The default in FSH is pattern, so something like

* component[severity].code.coding = $hpo#HP:0012824

will become

        "patternCoding": {
          "code": "HP:0012824",
          "system": "http://human-phenotype-ontology.org"
        }

The 'exactly' keyword in FSH will switch this to fixedCoding but we shouldn't use this here because it is less flexible.

[julsas]

* component ^slicing.discriminator.type = #pattern
* component ^slicing.discriminator.path = "code.coding"
* component ^slicing.rules = #open

Btw. it is sufficient to declare this once. It does not need to be repeated on every component. And we should change the path to just "code", because atm we don't allow alternative codings.

[ShahimEssaid]

Yes, I read a little more of the FSH docs. Specifically, the assignment rules section: https://build.fhir.org/ig/HL7/fhir-shorthand/reference.html#assignment-rules It helped clarify that the keyword exactly is the one that drives the pattern[x] vs fixed[x]. I did not see a difference in the Sushi output if we use #value vs #pattern but I don't know if that has any implication for the validator when it validates R4.

I'm still interested in learning if the LOINC LLx codes are okay to use or not for the discriminator. From reading the LOINC documentation here it appears that the LLx codes are similar to the regular codes, and maybe we can use them that way.