A recurrent problem in representing health data is how to distinguish between clinical findings and disorders. SNOMED CT, for instance, included a “disorder” sub-axis of the “finding” axis, expecting that disorder would turn out to be a specialization of finding. However, while several heuristics can be used to make this distinction, they differ. No principle sufficiently clear to support repeatable classification has been identified, nor, many believe, is it possible to do so.

SNOMED has solved the problem by no longer trying to make the distinction. The “disorder” tags remain in the terminology, but they have no effect or standing in the concept model. In HL7 V3, problem observations are observations: our difficulty remains evident in the decision about whether to use the more specific “problem” term, but the information resides in the same model elements, so the data can be consistently located. Concern acts are explicitly modeled to contain problems, so they are also clear and unambiguous, though their expressiveness has not been widely used.

In FHIR, the problem has arisen in disagreements about whether to represent findings as Observations or Conditions. A simple example:

A patient presents with a cough. This encounter results in three kinds of information.

1. First, the objective fact that the patient coughs.
2. Second, an inferred physiological state that causes the cough – this could be an identified etiology such as asthma, an allergy, or a virus, or it could be the unspecified state of having a “cough.”
3. And third, the procedural inference that this documented cough is of concern, and should be treated.

In FHIR, the name of the Condition resource seems to align it quite well with #2, and this was the original intent: R1 & 2 direct us to “Use to record detailed information about conditions, problems or diagnoses recognized by a clinician.”

However, in STU3, the meaning of the Condition resource changed (largely because of this problem). The definition used the same nouns but added “that has risen to a level of concern,” and it broadened the examples to include things that are not diseases but are of concern, such as unemployment, or having had a coronary bypass graft operation. Also, language was added to make it clear that symptoms of concerns were not to be recorded in Condition.

The FHIR solution to the problem of distinguishing findings and disorders is to not try to make the distinction. The mis-named “Condition” resource is actually for concerns. It continues to confuse because

• its name suggests that it is another way to represent a finding, and
• it is the model representation for properties that belong to the underlying condition.

Here are four general solutions to the problem of distinguishing findings from conditions in FHIR.

1. Since they are not distinguishable, merge Observation and Condition into a single resource.
   • This was argued for four years ago. The primary contrary argument seemed to be that a great deal of effort had already been expended on the current design. We assume that, since more effort has been expended in the interim, the “sunk cost” argument makes this option not feasible.
   • In addition, changes to the definition of Condition make the resources conceptually distinct.
2. Find a heuristic and continue to try to make a distinction.
   • The Logica design proposes to use Observation for evaluations of qualities and Condition for findings about “the patient.”
   • This heuristic, like others, addresses but does not solve the original problem.
   • The design contravenes explicit guidance in the current specification.
   • The design requires the addition of presence/absence modifier extensions on the Condition resource. Modifier extensions are used sparingly because they may be dangerous.
3. Create a new Concern resource so that we can represent all three kinds of fact.
   • The design does not solve the original problem.

None of those options seem to work. Fortunately, existing FHIR design supports all known use cases. The fact that the problem keeps coming up has more to do with clarity than with design.

1. Clarify current documentation to ensure that the distinction between finding and concern is clear.
   • The name of the Condition resource should be Concern.
     1. “Problem” is another option, as it may have wider currency in use. However, it is a bit of a misnomer for things like Pregnancy. And it to some may imply “item on problem list” to the exclusion of other concerns, e.g., encounter diagnoses.
   • The fact that many Condition properties are specific to the underlying condition should be addressed explicitly. E.g., “onsetDate” should be either renamed or explained to be “onset of the condition (as distinct from this expression of Concern about the condition).”
   • clinicalStatus must be either split or acknowledged to be pre-coordinated Concern and Condition status. Values must be reviewed.
   • Explanations of the Symptom cases need to clarify that while it is appropriate to create a Condition resource for a durable and mysterious symptom of concern, that decision is orthogonal to the decision about whether to record the fact of the symptom, which, if appropriate, should be an Observation.
   • Better support is required for the relationships between Problems and Observations. “Evidence” is one kind of relationship; others might include composition, characterization, comorbidity, sequence, etc.
   • For the case of pertinent negatives, specify a preferred Observation pattern to forestall Condition-based solutions.
     1. E.g., provide a “presence” Observation profile with model bindings to the SNOMED situation model, where Observation.code = associatedFinding & Observation.value = findingContext. This pattern would need to explicitly prohibit using Observation.value for general qualification – i.e., post-coordination of findings.
   • Note that this means that FHIR has a way to represent the Observation of the cough and the Concern about the [asthma | allergy | viral infection | cough], but no way to represent the underlying condition independent of concern. Since effort is consumed documenting conditions only when there is some reason for concern, this does not seem to be a problem.