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

2026-07-06T04:00:13Z

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

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

	This concept aligns with the FHIR '''ServiceRequest''' resource. Care implements a minimal, opinionated subset and uses snake_case values for status, intent, and priority rather than FHIR's hyphenated codes.		This concept aligns with the FHIR '''ServiceRequest''' resource. Care implements a minimal, opinionated subset and uses snake_case values for status, intent, and priority rather than FHIR's hyphenated codes.

			{{Navbox clinical}}

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

Admin: OHC identity seed

2026-07-04T22:43:17Z

OHC identity seed

New page

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

A '''service request''' is an order to do something for a patient — run a lab test, take an X-ray, book a counselling session, perform a procedure. It turns a clinician's "please do this" into a tracked item that another team can pick up and that later results can attach to.

== What it represents ==

In Care's FHIR-aligned model, a service request maps to the '''ServiceRequest''' resource. It captures:

* '''What is being asked for''' — a coded service or procedure, an optional body site, and a free-text title
* '''Why and how''' — the category of work, the priority, and any notes or patient instructions
* '''Where it sits in care''' — the patient and encounter it was raised in, the facility, and optionally the service, locations, or clinician fulfilling it
* '''Its standing''' — an intent (firm order or mere proposal?) and a lifecycle status everyone can see

The key thing to hold onto: a service request is the ''order'', not the ''result''. The specimen that gets collected, the diagnostic report that comes back, the observations that get recorded — those are separate records that each point back to the originating request. One request can spawn several of them.

== Intent — how binding is it? ==

Every request carries an '''intent''' that says how committed the order is, so the same record can represent anything from a tentative idea to a confirmed instruction: a <code>proposal</code> is a suggestion someone has put forward; a <code>plan</code> is part of an agreed plan of care; a <code>directive</code> is a standing instruction; an <code>order</code> is a firm request to actually carry the work out. Intent answers "is this real yet?" — distinct from status, which answers "where has it got to?"

== Category and priority ==

Two coded fields route and rank the work. '''Category''' decides which team picks it up — <code>laboratory</code>, <code>imaging</code>, <code>counselling</code>, <code>surgical_procedure</code>, or <code>education</code>. '''Priority''' sets how soon — <code>routine</code>, <code>urgent</code>, <code>asap</code>, or <code>stat</code>. Together they let a busy department triage a queue of requests without reading every one in full.

== Lifecycle ==

A request always sits in exactly one status — there is deliberately no "unknown". The active states are on the left; the four on the right are terminal.

<syntaxhighlight lang="text">draft → active → on_hold → completed
↘ ended / revoked / entered_in_error</syntaxhighlight>
* '''draft''' — being written, not yet actionable
* '''active''' — live and ready to be worked on
* '''on_hold''' — paused for now, expected to resume
* '''completed''' — the work has been fulfilled
* '''ended''' — stopped before completion, with no intent to resume
* '''revoked''' — cancelled or withdrawn
* '''entered_in_error''' — created by mistake; kept for audit, treated as void

== How it connects ==

A service request is the hub that ties an order to the rest of the record:

* It is always raised inside an '''encounter''', and the patient is inherited from that encounter — you never set the patient directly.
* It can be created from an '''activity definition''', a reusable template that supplies the category and the catalogue of valid service codes.
* Once work begins, a '''specimen''' may be collected against it, and a '''diagnostic report''' and its '''observations''' are produced for it — all linking back to this request.
* It can name the '''healthcare service''' that fulfils it and the '''locations''' within the facility where it applies, plus the '''requester''' who placed it.

== Permissions ==

Access to service requests is governed by these facility-scoped permissions.

{| class="wikitable"
|-
! Permission
! Description
! System Roles
|-
| <code>can_write_service_request</code>
| Create, update, complete, cancel, and apply an activity definition to service requests within a facility
| Facility Admin, Admin, Doctor, Nurse
|-
| <code>can_read_service_request</code>
| List and view service requests within a facility
| Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer, Pharmacist
|-
| <code>can_write_specimen</code>
| Create a specimen against a service request
| Facility Admin, Admin, Doctor, Nurse
|}

Roles are granted through a user's facility, organization, or patient memberships, and permissions cascade down the organization tree — a role given high in the tree applies to the facilities beneath it.

== FHIR reference ==

This concept aligns with the FHIR '''ServiceRequest''' resource. Care implements a minimal, opinionated subset and uses snake_case values for status, intent, and priority rather than FHIR's hyphenated codes.

{{Related}}

Concepts/Service Request - Revision history

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

Admin: OHC identity seed