Phenomics Exchange for Research and Diagnostics, published by HL7 International / Clinical Interoperability Council. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/phenomics-exchange-ig/ and changes regularly. See the Directory of published versions

Modeling phenotypic data

Modeling Decisions

“All models are wrong, but some are useful”.

The GA4GH Phenopacket and this IG intend to support deep phenotyping. The phenopacket organizes information relevant to deep phenotyping and computational analysis for research or for computational differential diagnosis approaches. Here, we discuss the motivations for the decisions we made for this IG.

PhenotypicFeature: Observation or Condition?

In FHIR, an Observation represents a neasurement or simple assertion made about a patient, including vital signs, laboratory Data, imaging results, clinical Findings, device measurements (e.g., EKG), results of clinical assessment tools such as the APGAR or a Glasgow Coma scores, and related entities.

In contrast, a Condition represents a clinical condition, problem, diagnosis, or other event, situation, issue, or clinical concept that has risen to a level of concern. The FHIR documentation notes

This resource is not typically used to record information about subjective and objective information that might lead to the recording of a Condition resource. Such signs and symptoms are typically captured using the Observation resource; although in some cases a persistent symptom, e.g. fever, headache may be captured as a condition before a definitive diagnosis can be discerned by a clinician. By contrast, headache may be captured as an Observation when it contributes to the establishment of a meningitis Condition.

Deep phenotyping can be defined as the precise and comprehensive analysis of phenotypic abnormalities in which the individual components of the phenotype are observed and described, generally in such a way as to be computationally accessible. This process involves the synthesis of a list of of phenotypic abnormalities that characterize a patient in order to support differential diagnostics by literature search or computational analysis to search for candidate diseases with comparable phenotypic profiles. For instance, the Human Phenotype Ontology provides a comprehensive logical standard to describe and computationally analyze phenotypic abnormalities found in human disease. The HPO project has computational models of over 8000 rare genetic diseases and numerous algorithms have been developed that compare the phenotypic profile of a patient (i.e., a list of HPO terms) with these models using specificity weighted, fuzzy matching.

The intended use of PhenotypicFeature’s is thus to contribute to the establishment of Conditions (diagnoses that require clinical attention). Therefore, we model the PhenotypicFeature as an Observation. We note that there can be overlap with Condition. For instance, the Mendelian disease Bardet-Biedl syndrome is often characterized by diabetes mellitus. Clearly, this should be recorded as a Condition in the medical record of the patient. However, in the context of the Phenopacket, it would be regarded as a feature (observation) that supports the diagnosis of the underlying condition (Bardet-Biedl syndrome). Therefore, in this case we would code Diabetes mellitus as an observation, ideally using the corresponding term Diabetes mellitus of the HPO. Of course, this should only be done in the context of the Phenopacket and would be incorrect in other FHIR contexts.