Skip to main content
Version: 3.0

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.

registered → partial → preliminary → final
  • 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 registered to final. 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 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.

PermissionDescriptionSystem Roles
can_write_diagnostic_reportCreate and update a report (including upserting its observations), checked against the originating service requestFacility Admin, Admin, Doctor, Nurse
can_read_diagnostic_reportRetrieve a report, and list reports filtered by their encounter or service requestFacility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer
can_view_clinical_dataList a patient's reports when no encounter or service request filter is supplied, authorized against the patientFacility 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.