Ambiguous Clinical Boundaries - Observation vs Condition

Now we’re at the point where Dr. Alice looks at Bob’s low hemoglobin results and says, “Bob, you have anemia.”

That diagnosis - anemia - gets recorded as a FHIR Condition resource. But here’s where things get interesting (and a bit confusing): the line between what should be an Observation and what should be a Condition isn’t always crystal clear.

What Is a Condition Resource?

The Condition resource represents clinical conditions, problems, diagnoses, or other health-related situations that have risen to a level of concern. Think of it as the “what’s wrong” or “what we’re dealing with” part of healthcare.

Here’s Bob’s anemia diagnosis as a Condition resource:

{
  "resourceType": "Condition",
  "id": "cond-1",
  "clinicalStatus": {
    "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/condition-clinical", "code": "active" } ]
  },
  "verificationStatus": {
    "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status", "code": "confirmed" } ]
  },
  "code": {
    "coding": [ { "system": "http://snomed.info/sct", "code": "271737000", "display": "Anemia" } ],
    "text": "Anemia"
  },
  "subject": { "reference": "Patient/bob-patient" },
  "encounter": { "reference": "Encounter/enc-1" },
  "onsetDateTime": "2025-08-08",
  "evidence": [ { "detail": [ { "reference": "DiagnosticReport/drpt-cbc-1" }, { "reference": "Observation/obs-hb-1" } ] } ]
}

Breaking Down the Condition Resource

Let’s look at what makes this condition tick:

clinicalStatus: Is this condition active, resolved, or in remission? Bob’s anemia is “active” - it’s currently a problem.
verificationStatus: How sure are we about this diagnosis? Bob’s anemia is “confirmed” based on his lab results.
code: What exactly is the condition? Here it’s anemia, coded using SNOMED CT (a medical terminology system).
subject and encounter: Links back to Bob and his visit.
evidence: This is powerful! It points to the diagnostic report and hemoglobin observation that support this diagnosis.

The Confusing Part: Observation vs Condition

Here’s where things get tricky. Let’s say Bob walks in and tells Dr. Alice, “I’ve been having headaches.”

Should that be recorded as:

An Observation (what the patient reported)?
A Condition (a health problem that needs attention)?

The answer is… it depends. And that’s frustrating but also realistic.

What the FHIR Specification Says

The FHIR documentation tries to help us with this boundary issue:

“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.”

But then it immediately adds:

“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.”

So headaches could be either an Observation OR a Condition. Helpful, right? 😅

The Real-World Guidelines

Here’s how to think about it practically:

Use Observation when:

A patient reports a symptom directly
It’s a single occurrence
It contributes to figuring out a bigger diagnosis
It’s resolved without ongoing management

Example: Bob mentions he had a headache yesterday. That’s probably an Observation.

Use Condition when:

It’s a persistent symptom that needs tracking
It requires ongoing management
It’s being used as a working diagnosis
It’s something that will be on the patient’s problem list

Example: Bob has been having daily headaches for three months. That’s probably a Condition.

The Gray Areas Are Real

The FHIR specification acknowledges this confusion exists in medical practice, not just in FHIR:

“The boundary between clinical findings and disorders remain a challenge in medical ontology.”

Even doctors and medical professionals sometimes disagree on what constitutes a symptom versus a condition. FHIR reflects this real-world ambiguity.

What You Might See in the Wild

When you’re working with FHIR data from different healthcare systems, you might see:

Headache as an Observation in one system
Headache as a Condition in another system
Fatigue recorded as both an Observation AND a Condition for the same patient
Family history recorded as a Condition (even though there’s a FamilyMemberHistory resource)

This isn’t necessarily wrong - it depends on the context, the healthcare system’s policies, and which FHIR profile they’re following.

Types of Conditions

The Condition resource is incredibly flexible. It can represent:

Diagnoses

Anemia (like Bob’s)
Diabetes
Hypertension

Problems

Chronic pain
Sleep difficulties
Mobility issues

Health Concerns

Risk of falls
Family history concerns
Social determinants (like lack of transportation)

Life Situations

Pregnancy (not a disease, but affects care)
Post-surgical status (like “amputee”)

When Conditions Connect to Everything Else

Conditions are central to healthcare workflows. Bob’s anemia condition:

Was based on evidence from his DiagnosticReport and Observation
Became the reason for his iron therapy Procedure
Justified his ferrous sulfate MedicationRequest
Will be referenced in his Claim for insurance

This is why the Condition resource has so many connections - it’s often the “why” behind healthcare actions.

The “No Known Problems” Situation

What if Bob has no health problems? FHIR handles this in two ways:

Using a coded condition: Create a Condition with code “No current problems or disability”
Using an empty List: Create a List resource that says “no conditions found”

Both approaches work, though the FHIR community is still discussing which is better.

Don’t Let the Ambiguity Stress You Out

If you’re feeling confused about when to use Observation versus Condition, you’re not alone. Even the FHIR specification admits this is challenging.

Here’s the practical advice:

Follow your organization’s guidelines first
When in doubt, think about ongoing management needs
Remember that different systems might make different choices
Focus on capturing the clinical intent accurately

Key Takeaways

Condition resources represent diagnoses, problems, and health concerns
The boundary between Observation and Condition can be fuzzy
This ambiguity reflects real-world medical practice
Conditions are central to healthcare workflows
Different systems might make different choices, and that’s okay

The beauty of FHIR isn’t that it eliminates all ambiguity - it’s that it provides a flexible framework that can handle the complexity of real healthcare while still enabling data exchange and interoperability.

Want to Learn More?

Check out the official Condition Resource specification for more detailed examples and use cases. The FHIR documentation includes extensive guidance on boundaries and relationships between resources.

Remember: healthcare is complex, and FHIR reflects that complexity while trying to make data exchange possible. Don’t expect perfect clarity - expect practical solutions that work in the real world.