FHIRUS CoreInteroperability

FHIR Condition Resource Explained (R4): Problem List vs Encounter Diagnosis, Codes and US Core Rules

July 25, 202620 min readUpdated Sep 12, 2026

Written by

Nirmitee.io Engineering

Author

FHIR Condition Resource Explained (R4): Problem List vs Encounter Diagnosis, Codes and US Core Rules

The FHIR Condition resource records a patient's problems, diagnoses and health concerns, and whether each one is current, resolved or wrong. Reading a FHIR Condition correctly comes down to four fields: category (problem list, encounter diagnosis or health concern), clinicalStatus, verificationStatus and code.

This field guide is for engineers building problem-list views, risk adjustment, care-gap logic, clinical decision support or AI chart summaries on top of FHIR data. It covers the R4 (4.0.1) element anatomy, the status invariants as a truth table, the current US Core 9.0.0 profiles, dual SNOMED CT and ICD-10-CM coding, searches you can run with curl, and the places where real EHR data breaks the textbook model.

Key takeaways

category decides meaning. A problem-list-item is managed over time, an encounter-diagnosis belongs to one visit, and US Core adds health-concern. Never mix them in one list without the category.
Both status fields are modifiers. Filter out entered-in-error and refuted before you show or count anything.
Abatement forces a status. Rule con-4 says any abatement[x] value requires clinicalStatus of inactive, remission or resolved.
US Core 9.0.0 has two Condition profiles: Problems and Health Concerns, and Encounter Diagnosis. Both require category, code and patient.
Expect dual coding. SNOMED CT carries clinical meaning, ICD-10-CM carries billing meaning, and many real resources carry only one or only text.
Search patient plus category first. It is the only combination US Core makes a SHALL, so it is the one you can rely on across servers.

What is the FHIR Condition resource?

Condition is the FHIR R4 resource for a clinical condition, problem, diagnosis or other clinical concept that has risen to a level of concern. One resource type covers chronic problems on the problem list, diagnoses coded at a single visit, and concerns raised by patients or care teams. The category element tells you which one you are holding.

Condition is where USCDI's Problems, Encounter Diagnosis and Health Concerns data elements land when an EHR exposes them through US Core. That makes it one of the first resources any EHR integration reads, and one of the easiest to misread.

A few things do not belong in Condition. The R4 specification says screening checklist answers such as "do you have a history of hypertension" should be captured with QuestionnaireResponse or Observation, not as negated Conditions. Lab values and vital signs are Observations (see our FHIR Observation field guide). The role and rank of a diagnosis within a visit, such as admission diagnosis or primary diagnosis, sit on Encounter.diagnosis.role and Encounter.diagnosis.rank, which our FHIR Encounter guide covers.

FHIR Condition anatomy: every element and its cardinality

An R4 Condition has one mandatory element in the base spec, subject (1..1). Everything else is optional, including code. Profiles tighten this: US Core makes category 1..*, code 1..1 and subject 1..1, and marks the status and date elements Must Support.

Element	R4 card.	Type and binding	What to watch for
`identifier`	0..*	Identifier	Use for de-duplication across pulls. Server ids can change after merges.
`clinicalStatus`	0..1	CodeableConcept, required binding, modifier	active, recurrence, relapse, inactive, remission, resolved.
`verificationStatus`	0..1	CodeableConcept, required binding, modifier	unconfirmed, provisional, differential, confirmed, refuted, entered-in-error.
`category`	0..*	CodeableConcept, extensible	problem-list-item or encounter-diagnosis in base; US Core adds health-concern.
`severity`	0..1	CodeableConcept, preferred	Subjective clinician assessment. Rarely populated.
`code`	0..1	CodeableConcept, example binding in base	US Core binds it (extensible) to US Core Condition Codes.
`bodySite`	0..*	CodeableConcept, example	Often already inside a SNOMED CT code, so do not assume it is separate.
`subject`	1..1	Reference(Patient \| Group)	The only mandatory element in base R4.
`encounter`	0..1	Reference(Encounter)	Encounter where the record was created, not every visit it was addressed at.
`onset[x]`	0..1	dateTime, Age, Period, Range, string	Five possible types. Parse all of them or you drop data.
`abatement[x]`	0..1	dateTime, Age, Period, Range, string	Presence constrains clinicalStatus (con-4).
`recordedDate`	0..1	dateTime	When the record was first entered. Not onset.
`recorder`	0..1	Reference(Practitioner \| PractitionerRole \| Patient \| RelatedPerson)	Who typed it. US Core lists it as an additional USCDI requirement.
`asserter`	0..1	Same targets as recorder	Who stands behind it. Can differ from the recorder.
`stage`	0..*	BackboneElement (summary, assessment, type)	con-1: needs summary or assessment.
`evidence`	0..*	BackboneElement (code, detail)	con-2: needs code or detail.
`note`	0..*	Annotation	Free text that often holds the real clinical nuance.

Here is a real Condition captured from the public SMART Health IT R4 sandbox (synthetic Synthea data), trimmed of metadata. Notice what is missing: there is no category at all.

GET https://r4.smarthealthit.org/Condition/522ebfda-5cec-49a3-80e6-c9bc66531ee9

{
  "resourceType": "Condition",
  "id": "522ebfda-5cec-49a3-80e6-c9bc66531ee9",
  "clinicalStatus": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
      "code": "resolved"
    }]
  },
  "verificationStatus": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
      "code": "confirmed"
    }]
  },
  "code": {
    "coding": [{
      "system": "http://snomed.info/sct",
      "code": "72892002",
      "display": "Normal pregnancy"
    }],
    "text": "Normal pregnancy"
  },
  "subject": { "reference": "Patient/60c529cb-591e-47ee-a788-4981a407ccdf" },
  "encounter": { "reference": "Encounter/cca5c6a8-cc15-48fc-8b42-51d9bf7c7574" },
  "onsetDateTime": "2014-08-27T16:43:46+00:00",
  "abatementDateTime": "2015-03-11T16:43:46+00:00",
  "recordedDate": "2014-08-27T16:43:46+00:00"
}

When we counted on 12 September 2026, that server held 4,794 Conditions, 45 matched category=encounter-diagnosis and none matched category=problem-list-item. A client that filters on category alone would show an empty problem list for almost every patient. Base R4 allows this; US Core does not.

clinicalStatus vs verificationStatus: how the status rules work

clinicalStatus says whether the condition is happening now: active, recurrence, relapse, inactive, remission or resolved. verificationStatus says how sure the record is: unconfirmed, provisional, differential, confirmed, refuted or entered-in-error. Both are modifier elements, so ignoring either one can turn a wrong record into a displayed fact.

Both code systems are hierarchical. In condition-clinical, recurrence and relapse sit under active, and remission and resolved sit under inactive. In condition-ver-status, provisional and differential sit under unconfirmed. Your filters need to respect that, because a patient whose cancer has relapsed has an active problem even though the code is not active.

The R4 spec links the two fields and abatement with three invariants. These are quoted from the Condition constraints table:

con-3 (guideline): Condition.clinicalStatus SHALL be present if verificationStatus
  is not entered-in-error and category is problem-list-item
  clinicalStatus.exists() or verificationStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-ver-status'
  and code = 'entered-in-error').exists() or category.select($this='problem-list-item').empty()

con-4 (rule): If condition is abated, then clinicalStatus must be either inactive, resolved, or remission
  abatement.empty() or clinicalStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-clinical'
  and (code='resolved' or code='remission' or code='inactive')).exists()

con-5 (rule): Condition.clinicalStatus SHALL NOT be present if verification Status is entered-in-error
  verificationStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-ver-status'
  and code='entered-in-error').empty() or clinicalStatus.empty()

con-3 is only a best-practice guideline. The spec explains that point-in-time encounter diagnoses might not need a clinicalStatus, while problem-list items managed over time should have one. con-4 and con-5 are hard rules that a validator reports as errors.

This truth table applies those three expressions to the combinations we see most often in production feeds.

verificationStatus	clinicalStatus	abatement[x]	category	Result
confirmed	active	absent	problem-list-item	Valid
confirmed	resolved	present	problem-list-item	Valid
confirmed	active	present	any	Invalid, breaks con-4
confirmed	absent	present	encounter-diagnosis	Invalid, breaks con-4 (abatement needs a status even for visit diagnoses)
confirmed	absent	absent	problem-list-item	Valid, but misses guideline con-3
provisional	absent	absent	encounter-diagnosis	Valid, con-3 does not apply
entered-in-error	absent	any	any	Valid
entered-in-error	inactive	any	any	Invalid, breaks con-5

For display, a practical "current problems" filter is: category is problem-list-item or health-concern, clinicalStatus is active, recurrence or relapse, and verificationStatus is not refuted or entered-in-error. Treat a missing clinicalStatus as unknown, not as active. For deeper validation strategy, see why FHIR data passes parsing but fails clinically.

Problem list vs encounter diagnosis vs health concern

A problem list item is an ongoing issue a clinician manages across visits. An encounter diagnosis is what was assessed or billed at one visit. A health concern is a worry raised by the patient, a caregiver or the care team, including social risks. All three are Condition resources; only category separates them.

US Core 5.0.0 split the old single profile in two, and the split holds in the current US Core 9.0.0. The US Core Condition Problems and Health Concerns Profile requires a category of problem-list-item or health-concern, and must-supports clinical status, verification status, onset, abatement, recorded date and the assertedDate extension (date of diagnosis). The US Core Condition Encounter Diagnosis Profile fixes the category to encounter-diagnosis and must-supports encounter and recordedDate. For how these versions line up with USCDI, see our USCDI vs US Core version mapping.

The codes also come from different code systems. problem-list-item and encounter-diagnosis use http://terminology.hl7.org/CodeSystem/condition-category. health-concern uses the US Core code system http://hl7.org/fhir/us/core/CodeSystem/condition-category. A token search that includes the wrong system returns nothing.

Question	Problem list item	Encounter diagnosis	Health concern
Category code	problem-list-item	encounter-diagnosis	health-concern (US Core code system)
Who usually records it	Clinician, reconciled over time	Clinician at a visit	Patient, caregiver or care team
Lifespan	Until resolved or inactivated	Tied to one encounter	Until addressed or no longer a concern
clinicalStatus	Should be present (con-3, US Core SHOULD)	Often absent or always active	Should be tracked
Typical use	Chronic care, CDS, care gaps, AI summaries	Claims context, visit summaries, risk adjustment review	Care plans, SDOH programs, patient goals
US Core 9.0.0 profile	Problems and Health Concerns	Encounter Diagnosis	Problems and Health Concerns

EHRs expose more than these three buckets. Epic's open.epic interface catalog lists separate R4 Condition APIs for Problems, Encounter Diagnosis, Health Concerns, Medical History, Reason for Visit, Care Plan Problem, Dental Finding, Infection and Genomics, plus Outside Record variants. Each Epic API returns its own category: Problems always uses problem-list-item, Encounter Diagnosis uses encounter-diagnosis for admission, visit and discharge diagnoses, Health Concerns uses health-concern and also returns the patient's health status, and Medical History uses medical-history, with refuted marking pertinent negatives. Oracle Health documents problem-list-item, encounter-diagnosis, health-concern and sdoh as the categories its Millennium R4 Condition search supports. Plan for categories you did not expect.

Reconciling problem lists across several EHRs? We build and run these integrations for product teams. Talk to our team and we will map which Condition categories, statuses and code systems each of your target EHRs actually returns.

How to code a Condition: SNOMED CT, ICD-10-CM or both

US Core binds Condition.code to the US Core Condition Codes value set with extensible strength. It includes SNOMED CT clinical findings, context-dependent categories and events, all of ICD-10-CM, and ICD-9-CM for historical data only. US Core says codes SHOULD come from SNOMED CT and ICD-10-CM unless you are exchanging legacy or text-only data.

The value set definition includes SNOMED CT concepts that are a 404684003 (Clinical finding), 243796009 (Context-dependent categories) or 272379006 (Events), plus 160245001 (No current problems or disability). The profiles add that only non-header ICD-10-CM codes SHOULD be used, so a category header like E11 is the wrong choice when E11.9 exists. USCDI names the same two vocabularies for the Problems data element.

The cleanest records carry both codings in one CodeableConcept, plus the text the clinician saw. This example was captured from the public HAPI FHIR R4 server; we trimmed metadata and replaced the patient reference.

{
  "resourceType": "Condition",
  "id": "alex-diabetes",
  "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"
    }]
  },
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/condition-category",
      "code": "problem-list-item"
    }]
  }],
  "code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "44054006",
        "display": "Type 2 diabetes mellitus"
      },
      {
        "system": "http://hl7.org/fhir/sid/icd-10-cm",
        "code": "E11.9",
        "display": "Type 2 diabetes mellitus without complications"
      }
    ],
    "text": "Type 2 diabetes"
  },
  "subject": { "reference": "Patient/example" },
  "onsetDateTime": "2020-06-15",
  "recordedDate": "2020-06-15"
}

Four coding problems show up in almost every multi-source feed:

Text-only conditions. Extensible binding lets a server send only code.text when no code fits. On the same HAPI server we found encounter diagnoses such as "Right wrist sprain" with no coding at all. Keep them, show them, and exclude them from logic that needs a code.
System URI drift. Some feeds use http://hl7.org/fhir/sid/icd-10 (WHO ICD-10) where they mean ICD-10-CM. Normalize known variants, but log them, because the two code sets are not identical.
Dotted vs undotted codes. The same public server returns E11.9 in one resource and undotted forms like R5083 in another. Normalize before matching against value sets.
Mapping is not one-to-one. A SNOMED CT concept does not always map to one specific billable ICD-10-CM code without more context, and an ICD-10-CM code can bundle several clinical ideas. Prefer the coding the source system sent over a code you derived.

Oracle Health adds a write-side detail: its Condition create documentation says code.coding can hold multiple codings, but only one with userSelected=true and one with userSelected=false are written to Millennium. For terminology servers and crosswalk infrastructure, see our guide to SNOMED, LOINC and RxNorm mapping in production.

Onset, abatement and recorded date: which date means what

onset[x] is when the condition started, abatement[x] is when it resolved or went into remission, recordedDate is when the record was first entered, and US Core's assertedDate extension is the date of diagnosis. They answer different questions, and in historical problem lists they can be years apart.

US Core explains that the assertedDate extension represents the date of diagnosis, onsetDateTime the date symptoms began, abatementDateTime the date of resolution or remission, and recordedDate the date the record was created. It also warns that users do not always capture all four, so servers will not always have them to share. USCDI names Date of Diagnosis, Date of Onset and Date of Resolution as separate data elements.

Patterns to handle in code:

Imprecise onset. onsetString ("childhood"), onsetAge and onsetRange are all legal. Keep the original; derive a sortable date only when you can.
Partial dates. dateTime allows 2020 or 2020-06. Do not pad them to January 1 and compute exact durations.
Missing onset. If you fall back to recordedDate for a timeline, label it "recorded", never "onset".
Abatement as a flag. An abatementString sent only to mark resolution still triggers con-4.

How do you search for Conditions?

US Core makes two Condition searches mandatory for servers: by patient, and by patient plus category. Searches on clinical-status, category plus encounter, code, onset-date, asserted-date, recorded-date, abatement-date and _lastUpdated are SHOULD, so confirm them in each server's CapabilityStatement before you depend on them.

# Problem list items for a patient (US Core SHALL)
curl -s -H "Accept: application/fhir+json" \
  "https://r4.smarthealthit.org/Condition?patient=60c529cb-591e-47ee-a788-4981a407ccdf&category=problem-list-item"

# Current problems only: list every active-family code explicitly
curl -s -G -H "Accept: application/fhir+json" "https://hapi.fhir.org/baseR4/Condition" \
  --data-urlencode "patient=example" \
  --data-urlencode "category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item" \
  --data-urlencode "clinical-status=active,recurrence,relapse"

# Diagnoses coded at one visit
curl -s -H "Accept: application/fhir+json" \
  "https://r4.smarthealthit.org/Condition?patient=60c529cb-591e-47ee-a788-4981a407ccdf&category=encounter-diagnosis&encounter=cca5c6a8-cc15-48fc-8b42-51d9bf7c7574"

# Does the patient have type 2 diabetes coded in SNOMED CT?
curl -s -H "Accept: application/fhir+json" \
  "https://hapi.fhir.org/baseR4/Condition?patient=example&code=http://snomed.info/sct|44054006"

# Conditions with onset on or after 2018
curl -s -H "Accept: application/fhir+json" \
  "https://r4.smarthealthit.org/Condition?patient=60c529cb-591e-47ee-a788-4981a407ccdf&onset-date=ge2018-01-01"

# Incremental sync: what changed since the last pull
curl -s -H "Accept: application/fhir+json" \
  "https://hapi.fhir.org/baseR4/Condition?patient=example&_lastUpdated=ge2026-09-01"

Three details matter. First, list the child status codes explicitly, because most servers do not expand the clinical status hierarchy for you; US Core's own example query lists several codes in one comma-separated parameter. Second, a code search is exact, so a SNOMED CT search will not find a record coded only in ICD-10-CM. Third, vendor support varies: Oracle Health's Condition search documentation lists patient, subject, _id, category, clinical-status, encounter, _lastUpdated and _revinclude=Provenance:target, and does not list code or onset-date, so filter those client-side there. On Epic, patient or subject is required for the Problems, Health Concerns and Medical History searches, and Encounter Diagnosis also accepts encounter alone. Leave the patient out and Epic returns error 4111, "Required search parameter missing from request", which its error reference illustrates with Condition?category=diagnosis. Epic applies code, onset-date and recorded-date as post-filters after the native search, and on the Problems API clinical-status=inactive returns deleted problem list entries. More query pitfalls are in 10 FHIR search patterns developers get wrong.

Can you write to the problem list through FHIR?

Sometimes. US Core lists "record or update a patient's problems" as a usage scenario, but write access is a per-vendor and per-customer decision. Epic lists a Condition.Create (Problems) R4 API. Oracle Health documents Condition create for problem-list items and encounter diagnoses with specific rules. Where no FHIR write exists, HL7 v2 problem and diagnosis messages are the fallback.

Oracle Health's documented create rules are a good picture of what EHRs enforce in practice:

Only problem-list-item or encounter-diagnosis, and only a single category per resource.
clinicalStatus must always be provided, and only active is supported for encounter diagnoses.
verificationStatus of entered-in-error or refuted is not supported on create.
encounter is required for encounter diagnoses, and abatementDateTime is not supported for them.

Epic's Condition.Create (Problems) specification does not write straight to the chart. New problems go to a holding tank, Epic runs duplicate checks, and a clinician reviews and reconciles each one; until then the Condition comes back only when you search by its _id. The request needs subject, a code with a display or text (ICD-10 and SNOMED CT are supported and preferred; other code systems need site mappings) and an onset date. clinicalStatus accepts only active or resolved, and must be resolved when the abatement date is in the past. verificationStatus accepts only provisional, and a note is limited to 450 characters. In Epic's catalog, Problems is the only standard R4 Condition create; Encounter Diagnosis create is listed only as a CDS Hooks API. On any EHR, an outside write lands in a chart clinicians own, so most sites expect clinician review. Our piece on the FHIR write problem for AI agents covers that governance question.

When FHIR write is not available, HL7 v2 still does this job in many hospitals. The patient problem message PPR^PC1, PC2 and PC3 (problem add, update and delete) carries problems in the PRB segment. Visit diagnoses travel in the DG1 segment, which appears in ADT messages such as ADT^A01. An interface engine such as Mirth Connect can turn your FHIR Condition into the right v2 message, with the mapping pitfalls covered in our HL7v2 to FHIR migration guide.

How EHRs differ when they return Conditions

Certified EHRs return US Core Conditions, but the same clinical fact looks different by vendor and by site. The differences cluster in five places: categories, status usage, dates, code systems and search support.

Area	What varies	Defensive pattern
Categories	Epic exposes separate APIs per category, including Medical History and Reason for Visit. Oracle Health search adds sdoh.	Query each category you need and store the category with every record.
Status vocabulary	Some systems use resolved where others use inactive. Epic's Problems API returns resolved for resolved problems and inactive for deleted ones. Oracle Health documents active, inactive and resolved, and only confirmed for verification.	Collapse to active-family vs inactive-family for logic; keep the original code for display.
Dates	Onset missing on historical problems; recordedDate reflects migration or entry date.	Never infer onset from recordedDate without labeling it.
Codes	SNOMED CT only, ICD-10-CM only, both, local codes or text only.	Match on any coding, normalize system URIs, keep text as a fallback.
Search	code and onset-date are SHOULD in US Core and are not documented everywhere.	Read the CapabilityStatement and fall back to patient plus category with client filtering.

The pattern behind all of this is described in why FHIR compliant does not mean interoperable, and the US Core baseline itself is covered in our US Core implementation guide.

Using Condition data for risk adjustment, quality, CDS and AI

Condition feeds four kinds of product: HCC risk adjustment, quality measures and care gaps, clinical decision support, and LLM chart summaries. Each one fails differently on bad Condition data, so each needs its own filter on category, status and coding before the data reaches the model or the rule.

HCC risk adjustment. CMS describes its Medicare Advantage risk adjustment models as built on groupings of diagnosis codes called Hierarchical Condition Categories, and publishes ICD-10 to HCC mappings each model year. That makes the ICD-10-CM coding the one that matters. An active problem-list item with no recent encounter diagnosis is a prompt for a clinician to review and document, never a code to submit on its own.
Quality measures and care gaps. Measure logic usually asks whether a diagnosis was present in a period. Use onset, abatement and status together, and decide explicitly whether unconfirmed and text-only conditions count.
Clinical decision support. A CDS service that fires on "patient has heart failure" must exclude refuted and entered-in-error records and should prefer the problem list over one-off visit diagnoses. See CDS Hooks in production for prefetch design.
LLM chart summaries. Models happily state resolved problems as current. Pass status, category and dates as structured fields, drop entered-in-error records before retrieval, and cite Condition ids so a clinician can check each claim. Our FHIR-native RAG pipeline post shows how to chunk this data.

Where teams get stuck with FHIR Condition

Most Condition bugs are not parsing bugs. The JSON is valid and the app still shows the wrong problem list. These are the failure modes we see most, and what they cost.

Building against a sandbox with no categories. The data model assumes one shape, then a real site sends several category APIs. Reworking storage after launch costs far more than storing category from day one.
Treating clinicalStatus as a boolean. Code checks for active, misses recurrence and relapse, or treats a missing status as active. Clinicians stop trusting the list, and that trust is slow to win back.
Ignoring verificationStatus. Refuted and entered-in-error diagnoses leak into risk scores, alerts and AI summaries. This is a patient safety and compliance issue, not a cosmetic one.
Deduplicating on code alone. The same diabetes appears as a problem, as several encounter diagnoses and as a medical history entry. Merging them loses the visit context; not merging them inflates counts.
Assuming search parity. A code or onset-date query that works on one server returns an error or is ignored on another. Teams discover this in user acceptance testing with the second customer, not in development.
Writing without a reconciliation plan. A create call succeeds, then the site's clinicians reject unreviewed problems entering the chart. The integration stalls in governance rather than engineering.

FHIR Condition implementation checklist

Target the US Core 9.0.0 Condition profiles your customers' certified EHRs support, and record which US Core version each site runs.
Store category, clinicalStatus, verificationStatus, every code.coding, code.text and all four dates for each record.
Validate con-4 and con-5 on ingest and quarantine failures instead of silently fixing them.
Filter entered-in-error and refuted records out of every clinical view, score and prompt.
Implement status filters with the hierarchy: active includes recurrence and relapse, inactive includes remission and resolved.
Normalize code system URIs and ICD-10-CM dot formats before value set matching, and log what you normalized.
Read each server's CapabilityStatement, and fall back to patient plus category search with client-side filtering.
Use _lastUpdated for incremental sync, since US Core says it SHOULD reflect status changes and new problems.
Label derived dates in the UI and never present recordedDate as onset.
Confirm write rules per vendor and per site, and design a clinician review step before any problem reaches the chart.

Condition data looks simple until it drives a risk score, an alert or a summary a clinician acts on. Our healthcare interoperability solutions team builds the FHIR and HL7 connection layer across Epic, Oracle Health, athenahealth, eClinicalWorks and NextGen, and our healthcare AI solutions team builds the risk, CDS and summarization features on top of it. Talk to our team to scope what your target EHRs expose for Conditions before you commit a data model.

Ready to scale?

Talk to our healthcare engineering team about building, integrating, and shipping faster.

Book a Call Contact Us

Frequently Asked Questions

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

clinicalStatus says whether the condition is happening now: active, recurrence, relapse, inactive, remission or resolved. verificationStatus says how certain the record is: unconfirmed, provisional, differential, confirmed, refuted or entered-in-error. Both are modifier elements. R4 rule con-5 forbids a clinicalStatus when verificationStatus is entered-in-error, and con-4 requires an inactive, remission or resolved status whenever abatement is present.

What is the difference between a problem list item and an encounter diagnosis in FHIR?

Both are Condition resources. A problem-list-item is an ongoing issue a clinician manages across visits and should carry a clinicalStatus. An encounter-diagnosis is assessed at one visit and should reference that Encounter. US Core 9.0.0 uses separate profiles for them: the US Core Condition Problems and Health Concerns Profile and the US Core Condition Encounter Diagnosis Profile.

Does US Core require SNOMED CT or ICD-10-CM codes for Condition?

US Core binds Condition.code to the US Core Condition Codes value set with extensible strength. It includes SNOMED CT clinical findings, all ICD-10-CM codes and ICD-9-CM for historical data. Codes SHOULD come from SNOMED CT and ICD-10-CM unless the data is legacy or text-only, and only non-header ICD-10-CM codes SHOULD be used. Many EHRs send both codings together.

How do I get only active problems from a FHIR server?

Search Condition with patient, category=problem-list-item and clinical-status=active,recurrence,relapse, because most servers do not expand the status hierarchy for you. Then filter out refuted and entered-in-error verification statuses on the client. If the server does not support clinical-status, fall back to patient plus category, which US Core requires every server to support.

What is a health concern in US Core?

A health concern is a health-related issue or worry raised by a patient, caregiver or care team member, such as a social risk or a worry about cancer risk. US Core represents it as a Condition with category health-concern from the US Core condition-category code system, profiled by the US Core Condition Problems and Health Concerns Profile.

Can a FHIR Condition have an abatement date and still be active?

No. R4 invariant con-4 states that if a condition is abated, clinicalStatus must be inactive, resolved or remission. A resource with abatementDateTime and a clinicalStatus of active, or with abatement and no clinicalStatus at all, fails validation. A recurring condition should be recorded with a recurrence status and no abatement, or as a new Condition.

Can I add a problem to an EHR problem list with FHIR?

Sometimes. Epic's Condition.Create (Problems) R4 API files new problems to a holding tank that a clinician reconciles into the chart, and accepts only active or resolved clinical status with a provisional verification status. Oracle Health documents Condition create for problem-list items and encounter diagnoses with rules such as a required clinicalStatus. Write access is enabled per customer. Where FHIR write is unavailable, HL7 v2 PPR problem messages are the usual alternative.