> ## Documentation Index
> Fetch the complete documentation index at: https://docs.connectivehealth.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Condition
> The FHIR Condition resource as produced by Connective Health
[FHIR R4 Condition](https://www.hl7.org/fhir/R4/condition.html) ·
[US Core Condition (Problems and Health Concerns)](https://hl7.org/fhir/us/core/STU9/StructureDefinition-us-core-condition-problems-health-concerns.html) ·
[US Core Condition (Encounter Diagnosis)](https://hl7.org/fhir/us/core/STU9/StructureDefinition-us-core-condition-encounter-diagnosis.html)
`Condition` is used for **two** distinct purposes in the [Patient Everything](/fhir/patient-everything-bundle) and
[Patient Summary](/fhir/patient-summary-bundle) bundles -- the patient's problem list, and the diagnosis attached
to a specific encounter. Each uses a different US Core profile and is documented separately below. It is not
produced for [Bulk Medication History](/fhir/bulk-medication-history-bundle).
# Usage 1: Problem list
Problem list `Condition` resources are top-level entries in the bundle.
## Stable ID
The `id` is derived from the patient, the recorded date, the primary diagnosis code, the rate code, and whether the
problem is active.
The "primary" diagnosis code is chosen by preferring an [ICD-10](http://hl7.org/fhir/sid/icd-10-cm) code where one is
available among the problem's codes, and otherwise falling back to the source's own primary code.
Only the primary code participates in the `id` -- the additional translated codings described below do **not**.
A problem is therefore assigned the same `id` regardless of how many translated codes accompany it, so gaining or
losing a translation never changes a `Condition`'s identity.
## Fields
| Field | Cardinality | Notes |
| ---------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `meta.profile` | 1..1 | Always set to the US Core Condition (Problems and Health Concerns) profile URL. |
| `subject` | 1..1 | Reference to the [Patient](/fhir/resources/patient). |
| `clinicalStatus` | 1..1 | `active` or `inactive` from the [condition-clinical](http://terminology.hl7.org/CodeSystem/condition-clinical) system, based on whether the source problem is active. |
| `category[0]` | 1..1 | Always `problem-list-item` from the [condition-category](http://terminology.hl7.org/CodeSystem/condition-category) system. |
| `category[1]` | 1..1 | The problem's **rate** (for example acute versus chronic), modeled as a second category. Following [community guidance](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.E2.9C.94.20Acute.20versus.20chronic.20problems/near/272966198), acuity is expressed as a category rather than a dedicated field. The entry is always present, but carries no coding when the source has no rate code. |
| `code` | 1..\* | One coding for the source's primary diagnosis code, plus **one coding for every translated code** available for that problem -- so a single problem is typically expressed in ICD-10, SNOMED, and any other systems the source provided. Codes with no value are omitted. |
| `recordedDate` | 0..1 | The date the problem was recorded. |
| `recorder` | 0..1 | Contained [PractitionerRole](/fhir/resources/practitioner-role) for the provider who diagnosed the problem. |
`verificationStatus`, `onset[x]`, `abatement[x]`, and `severity` are not populated for problem list entries.
# Usage 2: Encounter diagnosis
Each [Encounter](/fhir/resources/encounter) carries its diagnosis as a `Condition` **contained** inside the
`Encounter` and referenced from `Encounter.diagnosis.condition`.
## Stable ID
No `id` is assigned. The resource exists only inside its parent `Encounter`, so it is neither addressable on its own
nor deduplicated. Use the parent `Encounter`'s `id` to track it over time.
## Fields
| Field | Cardinality | Notes |
| -------------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `meta.profile` | 1..1 | Always set to the US Core Condition (Encounter Diagnosis) profile URL -- note this differs from the problem list profile above. |
| `subject` | 1..1 | Reference to the [Patient](/fhir/resources/patient). |
| `category` | 1..1 | Always `encounter-diagnosis` from the [condition-category](http://terminology.hl7.org/CodeSystem/condition-category) system. |
| `clinicalStatus` | 1..1 | Currently, Aalways `active`. |
| `verificationStatus` | 1..1 | Always `confirmed` from the [condition-ver-status](http://terminology.hl7.org/CodeSystem/condition-ver-status) system. |
| `code` | 0..\* | The visit's diagnosis. In the **Patient Everything** bundle, one coding is selected per code system -- ICD-10, ICD-9, and SNOMED where available -- plus the source's own primary code, deduplicated so no code system appears twice. In the **Patient Summary** bundle, a single pre-resolved diagnosis coding is published. |
`recordedDate`, `recorder`, `onset[x]`, and `encounter` are not populated on the encounter diagnosis -- the link
to the encounter is expressed by containment and by `Encounter.diagnosis.condition` instead.