Why Condition Status Matters

Imagine a clinician opening a transferred chart and seeing two diagnoses: breast cancer and lung cancer. The codes may be accurate, but the codes alone do not show whether one cancer is newly diagnosed, the other is in remission, or either is still being treated. A diagnosis names a condition. Condition Status explains what that condition means now.

That distinction is clinically important well beyond oncology. A urinary tract infection from last year should not carry the same weight as a current infection. A chronic condition that is active and stable is not the same as a condition that has resolved. When status does not travel with the diagnosis, the receiving clinician, care coordinator, researcher, or software application has to reconstruct the meaning from dates, encounter notes, treatment history, and patient recollection.

USCDI v7, released on July 23, 2026, adds Condition Status to the Problems data class. ONC also identifies Condition Status as one of the v7 elements already supported through HL7 FHIR US Core. [1] That is an important foundation, but it does not mean the field is complete or consistently understood in real-world exchange.

The Interoperability Problem Has Three Layers

It is tempting to treat Condition Status as a yes-or-no question: either a system has the field or it does not. Production data suggests a more useful framework. A status field becomes clinically interoperable only when three separate conditions are met.

The distinction matters because a high fill rate in digital data can coexist with major gaps in document-based exchange, and a populated field can still be unusable when every source expresses status differently. Availability is not completeness, and completeness is not normalization.

What Predoc Sees in Our Curated Data

Predoc reviewed condition-level data across two source pathways covering millions of medical records: digitally sourced clinical data and clinical data extracted, normalized, and curated from PDF documents. Fill rate is measured at the condition-entry level as the share of individual condition entries for which a source status value is present. The two cohorts are measured separately. [8]

The 94% digital fill rate is encouraging. It indicates that most born-digital condition records already carry some status information and that structured exchange is feasible without inventing an entirely new clinical workflow. It is also more precise than saying the field is present in every patient or every record: 6% of digitally sourced condition entries still lack a status value.

The PDF result tells a different story. Condition status is present in only 47.6% of condition entries curated from PDFs, which means it is absent in 52.4%. For organizations that still receive scanned charts, generated PDFs, faxed records, or other document-based handoffs, a condition arrives without a status signal just over half the time. The diagnosis may be visible, but its current clinical meaning is not.

The challenge does not end when a value is present. Source systems and documents use a mixture of standardized codes, local labels, and clinician-authored phrases. Expected values such as active, inactive, resolved, remission, or recurrence may appear alongside phrases such as stable, under treatment, history of, or handwritten editorial descriptions. Those phrases can be meaningful to a human reader, but they do not all describe the same concept and they do not map cleanly to one normalized list.

In Predoc’s data sample, for instance, a multitude of values to describe conditions status were present. Several, map directly to FHIR condition clinical vocabularies, while others represent non-standard condition status:

Why USCDI v7 Still Matters When FHIR Already Supports the Field

FHIR R4 already represents clinical status in Condition.clinicalStatus. The required condition-clinical value set contains six lifecycle values: active, recurrence, relapse, inactive, remission, and resolved. [2] US Core 6.1.0 marks clinical status as Must Support for the Condition Problems and Health Concerns Profile and says it should be present for problem-list items. [3]

Must Support is often misunderstood. In US Core, it means a system must support the element when the data is present in the sending system; it does not guarantee that every source has populated the field. [3] The difference between technical support and real-world completeness is exactly what the 94% digital and 47.6% PDF fill rates reveal.

USCDI inclusion therefore solves a different problem than the FHIR resource alone. It establishes Condition Status as part of the core exchange expectation, making it easier for receiving systems to request, test, measure, and rely on the element across exchange methods. The 94% digital fill rate is evidence that implementation is practical. It is not evidence that the standard is unnecessary.

USCDI v7 does not, by itself, fill missing values in PDFs or convert free text into a normalized status. Those steps still require source-system configuration, document extraction, terminology mapping, provenance, and quality controls. The standard supplies the shared destination; implementation determines whether the data reaches it faithfully.

What Better Status Data Enables

Problem lists are already difficult to review. A 2025 study of 362,436 patients found that 18% had more than 20 items on the problem list, 23% had at least one duplicate diagnosis, and clinicians rated the mental effort of a comprehensive problem-list review at 8.3 on a 9-point scale. [4] A separate 2025 analysis found that short-term diagnoses remained on problem lists far beyond their expected relevance - a median of 343 days for acute pharyngitis and 443 days for urinary tract infection. [5]

Structured status does not automatically remove duplicates or correct every outdated diagnosis. It does, however, provide a high-value signal for filtering and prioritization. A receiving system can place resolved or inactive conditions in a historical view, surface active conditions for review, and flag entries with missing or unmapped status instead of presenting every diagnosis with equal apparent urgency.

There is also evidence that structure changes clinical performance. In a randomized crossover trial, clinicians using correctly structured problem lists answered the relevant clinical question correctly 56.3% of the time, compared with 33.5% when using non-curated lists, and they reached correct decisions faster. [6] Condition Status is only one component of a well-structured problem list, but it is one of the most direct ways to communicate present clinical relevance.

Where the Difference Becomes Visible

Condition Status becomes most valuable when records leave the organization that created them. Inside one practice, clinicians may know which entries are historical and which are still being managed. In an aggregated longitudinal record, that institutional memory disappears. The same diagnosis may arrive from several EHRs, an HIE, a payer feed, and a stack of PDFs, each with different dates and different language.

Scenario A - Oncology Intake

A patient is referred to an oncology network with a new lung cancer diagnosis and a history of breast cancer treated five years earlier. Her records include structured data from an oncology EHR and hospital, plus PDF documents from a radiation clinic and primary care practice.

Without reliable status, both cancers may appear as undifferentiated diagnoses. The PDF-derived entries may contain no status at all, or may use phrases such as under treatment, stable, or history of cancer. The receiving team has to read notes and treatment timelines to determine whether the prior cancer is active, in remission, or resolved before planning care.

With structured and normalized status, the system can present the new lung cancer as active and the prior breast cancer as remission or inactive, while preserving the original source wording and provenance. The clinician still reviews the record, but no longer begins with two diagnoses that look equally current.

Scenario B - Curated Patient Data

A care coordinator at a virtual GI practice is preparing for a consultation with a patient whose history spans several gastroenterologists, a hospitalization for a flare, and multiple urgent care visits. Crohn disease appears repeatedly across the record, along with episode-level diagnoses from older encounters.

If every entry lacks status or uses inconsistent language, the coordinator must infer which conditions reflect current disease burden and which belong to prior episodes. The work becomes especially difficult when half of the document-derived entries have no status signal and the remaining entries use a mixture of coded and free-text values.

A curated view can separate active chronic disease from resolved episode-related diagnoses, preserve uncertain entries for review, and avoid translating stable into inactive. That is the practical value of normalization: not removing clinical judgment, but directing it to the entries that actually need judgment.

From a Field to Reliable Clinical Data

To make Condition Status useful across care settings, an exchange pipeline should do more than copy a string from one system to another. A reliable implementation should:

- Exchange the structured Condition.clinicalStatus code when a source system already provides it.

- Preserve the original source value, including free text, so the normalized value remains auditable.

- Normalize only when the meaning is clear. Stable should not be forced into inactive, and under treatment should not be treated as a lifecycle status without supporting context.

- Represent missing and unmapped values explicitly. Unknown is not the same as active, inactive, or resolved.

- Carry provenance so users can see which organization, document, or extraction process supplied the value.

These controls are particularly important for AI-assisted chart preparation. An application can safely prioritize active conditions only when it can distinguish a normalized status from a source phrase, identify missingness, and expose uncertainty. Otherwise, automation risks turning a documentation gap into a false clinical conclusion.

Standards Readiness

Condition Status is representable using existing, normative FHIR R4 standards with no new resource types, profiles, or terminology development required. The path from v7 inclusion to consistent implementation is as clear as any element ONC has ever added to USCDI.

Condition Clinical Status (v7)

Represented in FHIR R4 as Condition.clinicalStatus, using the required binding to the http://terminology.hl7.org/CodeSystem/condition-clinical code system. Values: active, recurrence, relapse, inactive, remission, resolved. This binding is normative in FHIR R4. US Core 6.1.0 marks clinicalStatus as must-support in the US Core Condition Problems and Health Concerns Profile.

As Epic noted in their v7 public comment, the current USCDI v7 definition's use of the phrase "presents or manifests" introduces ambiguity about whether status refers to clinical management state or observable symptom presentation.

‍We recommend ONC align the definition explicitly with the FHIR R4 clinical status value set, which is defined as "the clinical status of the condition,"  and provide examples using the FHIR-defined codes (active, inactive, resolved) to ensure consistent implementation across receiving systems.

Implementation Readiness for v7

Condition Status has one of the lowest implementation barriers of any element ONC has added in recent USCDI versions — and our production data confirms it.

For health IT developers: Condition clinical status is already must-support in the US Core Condition profile, meaning all ONC-certified EHRs are already expected to generate it. Our 94% digital data coverage rates confirm certified systems are doing so consistently today. Requiring its exchange under USCDI standardizes at the regulatory layer what US Core has already established at the implementation guide layer — for most developers, this means documentation updates and exchange configuration, not new development cycles.

For clinicians: No clinical data entry or workflow change is required. Condition clinical status is managed through existing status workflows already present in all major EHR systems — marking a problem as resolved, inactive, or in remission — that clinicians already use. USCDI v7 adds zero additional documentation time for providers.

For receiving systems: This field reduces operational burden rather than adding it. Receiving systems that currently must manually triage every imported condition to determine which are currently active gain a structured, machine-readable signal that enables automatic filtering and display — delivering cleaner problem lists to clinicians without requiring chart review at every care transition.

V7 IS READY TO IMPLEMENT — TODAY

Near-universal production capture, correct FHIR value set alignment, system-generated (not clinician-entered), and already must-support in US Core. The USCDI v7 requirement converts what certified EHRs already produce into what receiving systems can finally rely on.

Summary

Condition Status makes a diagnosis usable outside the system that created it. Predoc production data shows that the signal is already common in digital exchange, with a 94% condition-entry fill rate, but materially less complete in PDF-derived data, where the fill rate is 47.6%. Even when a status is present, local and free-text values can prevent consistent interpretation.

USCDI v7 is therefore important not because the field has never existed, but because the ecosystem needs a shared expectation for exchanging it. The next step is to pair that expectation with clear semantics: a normalized lifecycle status, preservation of the original value, explicit missingness, and provenance. That combination can produce cleaner problem lists, more efficient record review, and safer use of condition data in clinical and AI-assisted workflows.

‍

‍

‍

‍

‍

References

[1] Office of the National Coordinator for Health Information Technology. "ONC Standards Bulletin 2026-2: United States Core Data for Interoperability Version 7." July 23, 2026. https://healthit.gov/standards-and-technology/onc-standards-bulletin/onc-standards-bulletin-2026-2/

[2] HL7 International. "FHIR R4 Condition Resource," version 4.0.1. See Condition.clinicalStatus and the required condition-clinical value set. https://hl7.org/fhir/R4/condition.html

[3] HL7 International. "US Core Condition Problems and Health Concerns Profile," US Core Implementation Guide version 6.1.0. https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-condition-problems-health-concerns.html

[4] Simon J, Panzer J, Ekong A, Driscoll P, Sinsky CA, Wright KM. "Problem and Medication List Review: More Than Checking a Box?" Quality Management in Health Care. Published online November 27, 2025. doi:10.1097/QMH.0000000000000530. https://pubmed.ncbi.nlm.nih.gov/41307509/

[5] Simon J, Panzer J, Ekong A, Sinsky CA, Wright KM. "Checking the Box: The Association between Problem List Reviewed and Outdated Diagnoses on the List." Applied Clinical Informatics. 2025;16(5):1779-1786. doi:10.1055/a-2735-0587. https://pubmed.ncbi.nlm.nih.gov/41265889/

[6] Klappe ES, Heijmans J, Groen K, ter Schure J, Cornet R, de Keizer NF. "Correctly structured problem lists lead to better and faster clinical decision-making in electronic health records compared to non-curated problem lists: A single-blinded crossover randomized controlled trial." International Journal of Medical Informatics. 2023;180:105264. doi:10.1016/j.ijmedinf.2023.105264. https://pubmed.ncbi.nlm.nih.gov/37890203/

[7] Office of the National Coordinator for Health Information Technology. "Condition Status" data element page (legacy URL slug: Disease Status), including public comments on Draft USCDI v7. Accessed August 10, 2026. https://isp.healthit.gov/uscdi-data/disease-status

[8] Predoc Data Team. "Condition Status Fill Rate and Source-Value Normalization Analysis." Internal production analysis, 2026. Fill rate is measured at the condition-entry level; digital and PDF-derived cohorts are analyzed separately. Unpublished.

‍

‍