HL7 FHIR Condition Resource: clinicalStatus, verificationStatus, US Core Profiles & SNOMED/ICD-10 Coding

The FHIR Condition resource is the canonical clinical data structure in HL7 Fast Healthcare Interoperability Resources (FHIR) used to record detailed information about a clinical condition, problem, diagnosis, or health concern that has risen to a level of clinical significance. Within electronic health record (EHR) repositories and clinical research data warehouses, Condition separates longitudinal problem-list tracking from point-in-time encounter diagnoses while supporting multi-terminology coding across SNOMED CT and ICD-10-CM.

How Does the FHIR Condition Resource Represent Diagnoses and Problem Lists?

In HL7 FHIR R4 (https://hl7.org/fhir/R4/condition.html), the Condition resource models ongoing or historical clinical assertions rather than transient diagnostic measurements (which belong in Observation) or allergic sensitivities (which belong in AllergyIntolerance). How a given Condition instance behaves in a clinical chart or research cohort query is governed primarily by its category element.

Beginning with the HL7 FHIR US Core Implementation Guide v5.0.0 and continuing through v6.1.0 and v7.0.0 (https://hl7.org/fhir/us/core/), ONC/ASTP USCDI requirements split the base resource into two distinct profiles based on workflow context:

• US Core Condition Problems and Health Concerns Profile: Captures longitudinal conditions managed over time on a patient’s active or historical problem list (category code problem-list-item), clinician- or patient-identified health concerns (health-concern), and Social Determinants of Health assessments (sdoh).
• US Core Condition Encounter Diagnosis Profile: Captures point-in-time diagnoses established or addressed during a specific clinical visit or hospital stay (category code encounter-diagnosis), linked directly to a FHIR Encounter resource via Condition.encounter.

Core Element	Cardinality (FHIR R4)	Data Type	Clinical and Research Function
clinicalStatus	0..1	CodeableConcept	Tracks the biological or physiological course of the condition (e.g., active, remission, resolved).
verificationStatus	0..1	CodeableConcept	Tracks diagnostic certainty (e.g., provisional, differential, confirmed, refuted).
category	0..*	CodeableConcept	Distinguishes problem-list-item, encounter-diagnosis, and health-concern records.
severity	0..1	CodeableConcept	Grades clinical intensity using SNOMED CT qualifiers (mild 255604002, moderate 6736007, severe 24484000).
code	0..1 (1..1 in US Core)	CodeableConcept	Identifies the specific disease, disorder, or finding using SNOMED CT, ICD-10-CM, or ICD-11 codes.
subject	1..1	Reference(Patient|Group)	Links the condition to the patient record.
onset[x] / abatement[x]	0..1 / 0..1	dateTime | Age | Period | Range | string	Defines when the condition began and when it entered remission or resolved.

What Is the Difference Between clinicalStatus and verificationStatus in FHIR Condition?

A frequent source of error in clinical data extraction and observational research cohort building is conflating clinicalStatus with verificationStatus. The two fields represent orthogonal dimensions of a medical assertion and are both marked as Is-Modifier elements in the FHIR R4 specification because either element can invert the meaning of the record.

• clinicalStatus (http://terminology.hl7.org/CodeSystem/condition-clinical): Describes whether the pathophysiological state is currently affecting the patient. Permitted codes in the required binding are active, recurrence, relapse, inactive, remission, and resolved.
• verificationStatus (http://terminology.hl7.org/CodeSystem/condition-ver-status): Describes the epistemic certainty of the clinician’s assessment. Permitted codes in the required binding are unconfirmed, provisional, differential, confirmed, refuted, and entered-in-error.

To prevent contradictory states, the FHIR R4 specification enforces two formal invariants on every Condition resource:

1. Invariant con-3 / us-core-1: clinicalStatus SHALL be present if verificationStatus is not entered-in-error or refuted (for problem-list items).
2. Invariant con-4: If a condition is marked with an abatement[x] date or age, its clinicalStatus MUST be inactive, remission, or resolved.

In longitudinal phenotyping, a computable phenotype query that filters only by Condition.code without checking verificationStatus != 'refuted' and verificationStatus != 'differential' will erroneously include ruled-out diagnoses in the study cohort.

How Are ICD-10 and SNOMED CT Codes Bound in US Core Condition?

Because clinical documentation and medical billing rely on different classification ontologies (see SNOMED vs ICD-10), Condition.code uses a CodeableConcept data type capable of carrying an array of coding objects simultaneously.

Under the US Core Condition profiles, Condition.code is bound with an extensible binding to the US Core Condition Code value set:

• SNOMED CT (http://snomed.info/sct): Serves as the primary clinical terminology for problem list entries and clinical findings (specifically hierarchies under Clinical Finding 404684003, Situation with Explicit Context 243796009, and Event 272379006).
• ICD-10-CM (http://hl7.org/fhir/sid/icd-10-cm): Permitted as an additional coding element—and routinely populated as the primary or dual code in encounter-diagnosis resources—to support revenue cycle claims, risk adjustment, and epidemiological reporting.

{
  "resourceType": "Condition",
  "id": "condition-t2dm-example",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-problems-health-concerns"
    ]
  },
  "clinicalStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
        "code": "active",
        "display": "Active"
      }
    ]
  },
  "verificationStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
        "code": "confirmed",
        "display": "Confirmed"
      }
    ]
  },
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/condition-category",
          "code": "problem-list-item",
          "display": "Problem List Item"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "44054006",
        "display": "Diabetes mellitus type 2 (disorder)"
      },
      {
        "system": "http://hl7.org/fhir/sid/icd-10-cm",
        "code": "E11.9",
        "display": "Type 2 diabetes mellitus without complications"
      }
    ],
    "text": "Type 2 Diabetes Mellitus"
  },
  "subject": {
    "reference": "Patient/patient-101"
  },
  "onsetDateTime": "2021-04-12",
  "recordedDate": "2021-04-15T10:30:00Z"
}

RESTful Search Parameters and CDISC SDTM Mapping

Under US Core Server CapabilityStatements, every certified FHIR R4 API must support specific RESTful query combinations for retrieving patient conditions:

• Mandatory Search by Patient: GET [base]/Condition?patient=[id] returns all conditions for the target patient across both problem lists and encounter diagnoses.
• Search by Patient and Category: GET [base]/Condition?patient=[id]&category=problem-list-item isolates active and historical problem-list entries from visit-level billing diagnoses.
• Search by Patient and Clinical Status: GET [base]/Condition?patient=[id]&clinical-status=active,relapse,recurrence retrieves only currently active conditions.

In EHR-to-EDC clinical trial pipelines that transform FHIR data into CDISC SDTM submission datasets, Condition resources with onsetDateTime prior to informed consent map to the Medical History (MH) domain, whereas newly emerging conditions or worsening baseline conditions during the trial map to the Adverse Events (AE) and Clinical Events (CE) domains.

Frequently Asked Questions

How does the FHIR Condition resource represent diagnoses and problem lists?

The FHIR Condition resource differentiates longitudinal problem lists from visit-specific diagnoses through its category element and corresponding US Core profiles. Problem list entries use the problem-list-item code under the US Core Condition Problems and Health Concerns Profile, while visit diagnoses use encounter-diagnosis and link to a specific visit via Condition.encounter.

What is the difference between clinicalStatus and verificationStatus in FHIR Condition?

The clinicalStatus element indicates whether the condition is physiologically active, in remission, or resolved in the patient, whereas verificationStatus indicates the clinician’s diagnostic confidence—such as whether the diagnosis is provisional, part of a differential, confirmed, or refuted.

How are ICD-10 and SNOMED CT codes bound in US Core Condition?

US Core binds Condition.code extensibly to value sets that prioritize SNOMED CT (http://snomed.info/sct) for clinical semantics while allowing ICD-10-CM (http://hl7.org/fhir/sid/icd-10-cm) to be transmitted as an additional coding translation within the same CodeableConcept array.