PhenotypicFeature: Observation vs Condition

[pnrobinson]

PhenotypicFeature seems to be more than FHIR-Observation and less than FHIR-Condition, and in principle it would be possible to model PhenotypeFeature as either one. Do we have thoughts about which is the more appropriate choice?

[jmandel]

https://www.hl7.org/fhir/condition.html#bnr provides a fair amount of context for when to use Observations vs Conditions.

What would be the case for Condition? (In general, Observation is a good fit for phenotypic features and provides a good deal of built-in data model flexibility.)

[mellybelly]

I am in favor of using 'observation' as well. Phenotypic features documented for diagnostic algorithmic purposes and disease characterization are often not things that are clinically managed, such as 'hypertelorism'. The guide suggests: "Use Condition when a symptom requires long term management, tracking, or is used as a proxy for a diagnosis or problem that is not yet determined." I really don't think 'condition' is appropriate.

This is also an example of challenges in using FHIR for things that are not well aligned with the implicit model of a clinical encounter, such as diagnostics, research etc.

[liberaliscomputing]

We (the NCPI FHIR working group) initially used Observation in order for modeling phenotypes, but recently revamped it with Condition (See https://ncpi-fhir.github.io/ncpi-fhir-ig/StructureDefinition-phenotype.html) after having a meeting with HL7. In that meeting, it was clarified that the use of Observation is mainly for point-in-time characteristics of patients while Condition should be considered for longer-term, static phenotypic features. So, we ended up using Condition because our data is about congenital birth defects. With this said, I believe Observation still would be a reasonable option for rendering temporary phenotypes.

[ametke]

I think @liberaliscomputing raises an interesting point but I am still in favour of using Observation. The spec says:

Use the Observation resource when a symptom is resolved without long term management, tracking, or when a symptom contributes to the establishment of a condition.

Use Condition when a symptom requires long term management, tracking, or is used as a proxy for a diagnosis or problem that is not yet determined.

One of the main uses of Phenopackets is sharing phenotypic data with applications that do variant prioritisation, so I think phenotypic features fall under the "or when a symptom contributes to the establishment of a condition" part.

[mellybelly]

I agree @ametke. A phenopacket is meant to represent a 'point in time' characteristic of a patient, though this can be a birth defect. It is not meant to represent a managed condition but of course you can have a phenotypic feature also be managed (a good example is one leg longer than the other).

The main thing is to focus on the collective suite of observations about phenotypic features rather than associating any specific clinical intervention around them. That is a different part of the schema.

I think this is an example of where we may need to define additional characteristics for 'observation' @cgchute

[lmckenzi]

An Observation is a point-in-time statement. Condition, on the other hand, is a long-term statement of patient state and reflects something that can be tracked and may evolve over time. The detection that a patient has a particular variant is definitely an Observation. Observation is also used for point-in-time diagnosis. However, once you get past diagnosis, we generally surface "clinical state of a patient worth monitoring" as Condition. Condition gives us things like severity, stage, etc. that Observation doesn't (and that we wouldn't want to introduce). The primary question you should ask in determining where the content should live is "where do current clinical systems currently store and expose similar types of data?". You'll want to align with that and not introduce inconsistency.

[RobertJCarroll]

From the NCPI FHIR WG side, Lloyd's comments were the catalyst we needed to change our perspective. We were trying to re-invent Condition from Observation to capture information that already had a place in Condition.

Alejandro's comment points to something that may be introducing some tension on the implementation: my understanding is that a Phenopacket is a summary of information, and not intended to be the complete longitudinal record. With that lens of interpretation, if I were building a system to support longitudinal tracking and care, I would record phenotypic features (lower case) as Condition resources. Then when it came time to generate a Phenopacket for sharing/publishing/diagnostics, it may be sensible to use a different mechanism to capture that information in a report- perhaps as a series of Observations asserted by the report-generator based on recorded evidence.

Does that demarcation track with how the Phenopackets team sees a Phenopacket? If so, does it impact direction here?

[pnrobinson]

@lmckenzi @RobertJCarroll @jmandel @liberaliscomputing @mellybelly

Here are some thoughts -- http://phenopackets.org/core-ig/modeling.html

[lmckenzi]

As I understand it, Phenotypic features are the mechanism for gathering "what are the characteristics this patient has that we might want to correlate with the genetic information we know about them?". As such, what matters is not "where would we like this information to exist?", but rather "where is this information likely to exist?". And the short answer there, is "many places". Patient records will include AllergyIntolerance, FamilyMemberHistory, AdverseEvent, Condition, Observation and possibly other resources that contain information that could reflect a long-term physiologic state that is relevant to genetic analysis. What we'll find in Observation are point-in-time assertions. What we'll find in AllergyIntolerance and Condition are assertions that are longer-running and potentially managed/monitored.

In the link provided, diabetes-melitus would most typically be represented as a Condition, not an Observation. (Observations might be A1C levels, or symptoms such as frequent urination, but would rarely be used to capture a diagnosis.)

[pnrobinson]

@lmckenzi -- The intended use case for a Phenopacket would involve pulling information from many places in the EHR, possibly asking a clinical (medical geneticist) to use a tool to record features not included in the EHR (e.g., https://phenotips.com/ -- note this is not an endorsement I am not associated with this company), and to exercise judgement as to whether any given Condition or Observation in the existing record is appropriate for WES/WGS analysis. As such, it should not matter where the information originally "lives", instead the Phenopacket is a snapshot of the current moment intended for differential diagnostics.

[lmckenzi]

If you translate information from the original form, you'll lose data. You certainly don't want to try to recreate the data structures of the non-Observation resources using Observation. So, for instance, if you're starting with a Condition that makes assertions about severity, stage, onset time, etc., it's not appropriate to move the information to Observation and then try to use extensions or components to reconstitute all of those elements. You'd be better handling multiple types of resources. If you want to scan the existing record and just create a simple collection of code + value Observations derived from other data, then Observation could conceivably work. The impression I'd had from past discussions though was that the other data elements were relevant.

[pnrobinson]

@lmckenzi Thanks so much for the feedback! I suspect (as a bioinformatician MD who previously worked in medical genetics) that what our community needs is something that is distinct from what exists in current EHRs (at least, I know of not a single colleague who has used EHR tools for the kind of diagnostics we are thinking about with exome/genome). If you happen to have some time for a chat that would be great -- obviously, we want to get this one just right but there are so many different options.

[lmckenzi]

Schedule this week is relative booked, but we could hopefully find a mutual slot. My email is lmckenzie@gevityinc.com.

[pnrobinson]

We have decided to go with Observation as being closest to the intended semantics (after many discussions).

[lmckenzi]

What is your reason for limiting yourself to a single resource?

[pnrobinson]

Simply put, this is the most appropriate for the intended use case. We have just submitted the manuscript for Phenopackets and hopefully the preprint will be on line soon. This also provides some context https://phenopacket-schema.readthedocs.io/en/latest/phenotype.html