Skip to main content
Version: 3.1

Condition

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.

PermissionDescriptionSystem Roles
can_write_encounter_clinical_dataCreate, 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_dataRead 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_dataRead 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_questionnaireSubmit a patient-subject questionnaire (such as symptom or diagnosis), which can record conditionsVolunteer, Staff, Doctor, Nurse, Admin, Facility Admin, Administrator
can_submit_encounter_questionnaireSubmit an encounter-linked questionnaire, which can record conditionsStaff, 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.