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

2026-07-06T04:00:05Z

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

← Older revision		Revision as of 09:30, 6 July 2026
Line 79:		Line 79:

	Roles are granted through a user's membership in an organization, facility, or patient, and permissions cascade down the organization tree — so a role held higher up applies to the facilities and reports beneath it.		Roles are granted through a user's membership in an organization, facility, or patient, and permissions cascade down the organization tree — so a role held higher up applies to the facilities and reports beneath it.

			{{Navbox clinical}}

	{{Related}}		{{Related}}
			Wiki: ohcnwiki.tellmey.fyi

Admin: OHC identity seed

2026-07-04T22:43:10Z

OHC identity seed

New page

{{Doc header
|type=concept
|domain=clinical
|title=Diagnostic Report
|order=7
|introduced=3.0
|fhir=Diagnostic Report
|concept=Concepts/Patient
|reference=References/Diagnostic Report
}}

A '''diagnostic report''' is the formal result of a diagnostic test or investigation — the lab panel, imaging study, or pathology workup that answers a clinical question. It closes the loop on an order: each report fulfils a single request and carries the findings, and the clinician's interpretation of them, back into the patient's record.

== What it represents ==

In Care's FHIR-aligned model, a diagnostic report maps to the '''DiagnosticReport''' resource. It captures:

* '''What was investigated''' — the service section it belongs to (for example, laboratory or radiology) and the specific test or panel performed
* '''The findings''' — the individual measured results, which live as observations attached to the report
* '''The interpretation''' — a clinician's conclusion summarising what the results mean, plus any free-text notes
* '''The clinical context''' — the patient, the encounter it was produced under, and the order it answers

A diagnostic report is not the raw measurement itself. The individual values — a glucose level, a haemoglobin count — are '''observations'''; the report is the container that groups them under one investigation, names it, and adds the human interpretation on top. That layering is the point: the observations are facts, and the report is the clinically signed-off reading of those facts taken together.

== Lifecycle ==

A report moves through a sequence of result-readiness states as findings come in and are verified.

<syntaxhighlight lang="text">registered → partial → preliminary → final</syntaxhighlight>
* '''registered''' — the report exists in the system but no results have been attached yet
* '''partial''' — some results are in, but the report is still incomplete
* '''preliminary''' — results are present but not yet verified or signed off
* '''final''' — the report is complete and verified; it is the authoritative answer

Not every report passes through every state — a simple report may go straight from <code>registered</code> to <code>final</code>. The status describes how trustworthy and complete the results are at any moment, which matters when a clinician acts on a preliminary value before final sign-off.

== How it connects ==

A diagnostic report never stands alone — it sits at the centre of an ordering-and-results chain:

* '''Service request''' — every report fulfils exactly one request. The order is placed first; the report is the answer to it, and it cannot exist without the request it resolves.
* '''Observation''' — the individual results that make up the report. One report typically groups many observations.
* '''Specimen''' — for lab work, the sample the investigation was run on is tracked through the request and feeds the report.
* '''Patient and encounter''' — the report is anchored to the patient it concerns and the encounter it was produced under. Both are inherited from the originating order, not chosen on the report.

This is why you create a [[Concepts/Service Request]] before a report can be filed against it, and why deleting the patient, encounter, or originating request also removes the reports tied to them.

== Classification ==

Two coded fields describe what the report is, drawn from standard terminologies so reports stay comparable across facilities:

* '''Category''' — the diagnostic service section the report belongs to, such as laboratory, radiology, or pathology. Required, and it groups reports by the kind of investigation.
* '''Code''' — the specific test or panel performed, named using LOINC. Optional, but it lets a report be identified precisely (a particular metabolic panel rather than just "laboratory").

Because these are coded concepts rather than free text, the same test means the same thing everywhere — which is what makes reports searchable and comparable across a deployment.

== Permissions ==

Access to diagnostic reports is governed by the following permissions.

{| class="wikitable"
|-
! Permission
! Description
! System Roles
|-
| <code>can_write_diagnostic_report</code>
| Create and update a report (including upserting its observations), checked against the originating service request
| Facility Admin, Admin, Doctor, Nurse
|-
| <code>can_read_diagnostic_report</code>
| Retrieve a report, and list reports filtered by their encounter or service request
| Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer
|-
| <code>can_view_clinical_data</code>
| List a patient's reports when no encounter or service request filter is supplied, authorized against the patient
| Facility Admin, Admin, Doctor, Nurse, Staff
|}

Roles are granted through a user's membership in an organization, facility, or patient, and permissions cascade down the organization tree — so a role held higher up applies to the facilities and reports beneath it.

{{Related}}

Concepts/Diagnostic Report - Revision history

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

Admin: OHC identity seed