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 proposal is a suggestion someone has put forward; a plan is part of an agreed plan of care; a directive is a standing instruction; an order 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 — laboratory, imaging, counselling, surgical_procedure, or education. Priority sets how soon — routine, urgent, asap, or stat. 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.
draft → active → on_hold → completed
↘ ended / revoked / entered_in_error
- 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.
| Permission | Description | System Roles |
|---|---|---|
can_write_service_request | Create, update, complete, cancel, and apply an activity definition to service requests within a facility | Facility Admin, Admin, Doctor, Nurse |
can_read_service_request | List and view service requests within a facility | Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer, Pharmacist |
can_write_specimen | 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.
Related
- Reference: Service Request (technical)
- Concept: Encounter — the context every request is raised in
- Concept: Activity Definition — the template a request can be built from
- Concept: Specimen — collected to fulfil a request
- Concept: Diagnostic Report — the result produced for a request
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.