Admin: Automated edit (via update-page on MediaWiki MCP Server)

2026-07-06T03:59:44Z

Automated edit (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:29, 6 July 2026
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.		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}}		{{Related}}
			Wiki: ohcnwiki.tellmey.fyi

Admin: OHC identity seed

2026-07-04T22:43:07Z

OHC identity seed

New page

{{Doc header
|type=concept
|domain=clinical
|title=Condition
|order=3
|introduced=3.0
|fhir=Condition
|concept=Concepts/Observation
|reference=References/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 [[Concepts/Observation|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 <code>unconfirmed</code>, <code>provisional</code>, or <code>differential</code>; a settled diagnosis is <code>confirmed</code>; something logged in error is <code>refuted</code> or <code>entered_in_error</code>. 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:

<syntaxhighlight lang="text">active → inactive → remission → resolved
↑ |
└─ recurrence / relapse ─┘</syntaxhighlight>
* '''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 [[Concepts/Allergy & Intolerance|allergies and intolerances]], which capture a different kind of standing risk, and [[Concepts/Observation|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.

{| class="wikitable"
|-
! Permission
! Description
! System Roles
|-
| <code>can_write_encounter_clinical_data</code>
| 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
|-
| <code>can_view_clinical_data</code>
| 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
|-
| <code>can_read_encounter_clinical_data</code>
| Read conditions via an encounter when patient-level clinical access is absent (the read path falls back to this when an <code>encounter</code> query param is supplied)
| Admin, Doctor, Nurse, Facility Admin
|-
| <code>can_submit_patient_questionnaire</code>
| Submit a patient-subject questionnaire (such as symptom or diagnosis), which can record conditions
| Volunteer, Staff, Doctor, Nurse, Admin, Facility Admin, Administrator
|-
| <code>can_submit_encounter_questionnaire</code>
| 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.

{{Related}}

Concepts/Condition - Revision history

Admin: Automated edit (via update-page on MediaWiki MCP Server)

Admin: OHC identity seed