Concepts/Condition: Difference between revisions

Content deleted Content added

Inline

Latest revision as of 09:29, 6 July 2026

conceptclinicalFHIR: ConditionCARE 3.0+

A condition is a clinical problem recorded for a patient — a diagnosis, a chronic illness, or a presenting symptom. It is how a patient's diagnoses and problem list are captured, giving every clinician a shared, durable view of what the patient is being treated for.

In the Care product UI, conditions are surfaced as Symptoms.

What it represents

A condition is a standing statement about a patient's health, not a one-time reading. A blood pressure value or a lab result is an observation — true at the moment it was taken. A condition is a claim the care team is making and tracking: "this patient has diabetes," "this patient presented with chest pain." That claim persists across visits until someone changes its status, which is why a condition needs two things an observation does not — a statement of how certain the team is, and a statement of how the condition is progressing.

To keep problems comparable across patients and facilities, the condition itself is recorded as a coded clinical finding (drawn from a SNOMED CT vocabulary) rather than free text. Onset, optional severity, the encounter it was noted in, and a free-text note round out the record.

Classification

The category answers "what kind of problem is this, and where does it live in the record?" Every condition is one of:

Problem-list item — an ongoing problem the care team is tracking for this patient
Encounter diagnosis — a diagnosis made or confirmed during a specific visit
Chronic condition — a long-term condition such as diabetes or hypertension, carried across encounters

Running alongside the category is a separate axis — the verification status — that records certainty. A symptom under investigation might be unconfirmed, provisional, or differential; a settled diagnosis is confirmed; something logged in error is refuted or entered_in_error. Care always requires a verification status, so the record never blurs a working hypothesis with an established fact.

Lifecycle

The clinical status tracks where a condition stands over time. It is distinct from verification — that is about how sure the team is; this is about the condition's actual course:

active → inactive → remission → resolved
   ↑         |
   └─ recurrence / relapse ─┘

active — currently present and being managed
recurrence — returned after a symptom-free period
relapse — returned after being in remission
inactive — no longer active, but not formally resolved
remission — symptoms have abated, but the condition may return
resolved — fully cleared
unknown — current state is not known

This is not a one-way pipeline. A chronic condition can cycle through active, remission, and recurrence many times over a patient's history.

How it connects

A condition never stands alone — it is always anchored to a patient and the visit where it was noted:

Patient — the person the condition describes. Care derives this automatically from the encounter, so the condition is always attached to the right record; clients never set it directly.
Encounter — the visit during which the condition was recorded. Every condition is created in the context of an encounter; chronic conditions can later be re-associated with a new encounter as care continues.

Conditions sit alongside the patient's other clinical records — most closely allergies and intolerances, which capture a different kind of standing risk, and observations, which capture point-in-time measurements and findings.

Permissions

A condition has no permission file of its own — as patient clinical data, it is governed by the patient and encounter clinical-data permissions a user holds in the relevant facility. Creating, updating, and deleting a condition is gated by write access to the encounter's clinical data; reading it requires the patient's clinical-data permission, falling back to the encounter's clinical-data read permission. Chronic conditions are a special case — updating one is gated by the patient's clinical-data permission rather than the encounter's. Conditions can also be captured by submitting a symptom or diagnosis questionnaire.

Permission	Description	System Roles
`can_write_encounter_clinical_data`	Create, update, or delete a condition (the create, update, and destroy paths check write access to the encounter's clinical data; chronic-condition updates are the exception below)	Admin, Doctor, Nurse, Facility Admin
`can_view_clinical_data`	Read a patient's conditions, and update a chronic condition (the read path checks the patient's clinical-data permission; chronic-condition updates check this same permission)	Staff, Doctor, Nurse, Admin, Facility Admin
`can_read_encounter_clinical_data`	Read conditions via an encounter when patient-level clinical access is absent (the read path falls back to this when an `encounter` query param is supplied)	Admin, Doctor, Nurse, Facility Admin
`can_submit_patient_questionnaire`	Submit a patient-subject questionnaire (such as symptom or diagnosis), which can record conditions	Volunteer, Staff, Doctor, Nurse, Admin, Facility Admin, Administrator
`can_submit_encounter_questionnaire`	Submit an encounter-linked questionnaire, which can record conditions	Staff, Doctor, Nurse, Admin, Facility Admin

Roles are granted to users through facility, organization, or patient memberships, and they cascade down the organization tree — a role held high in the hierarchy applies to the facilities and patients beneath it.

Concept: Concepts/Observation
Reference: References/Condition

Wiki: ohcnwiki.tellmey.fyi

@@ Line 88: / Line 88: @@
 Roles are granted to users through facility, organization, or patient memberships, and they cascade down the organization tree — a role held high in the hierarchy applies to the facilities and patients beneath it.
+{{Navbox clinical}}
 {{Related}}
+Wiki: ohcnwiki.tellmey.fyi