[Core Modules]

Electronic Patient Care Report Clinical Workspace

An ambulance crew attending a suspected stroke does not have time to navigate a seven-tab clinical form while continuing a structured assessment.

Module metadata

An ambulance crew attending a suspected stroke does not have time to navigate a seven-tab clinical form while continuing a structured assessment.

Back to All Modules

Source reference

content/modules/epcr-clinical-workspace.md

Last Updated

Apr 17, 2026

Category

Core Modules

Content checksum

a37cca385f6cb5a2

Tags

modulescompliancegeospatial

Overview#

An ambulance crew attending a suspected stroke does not have time to navigate a seven-tab clinical form while continuing a structured assessment. A clinical audit lead reviewing twenty encounters before the Monday morning review cannot piece together vitals, interventions, and protocol decisions from three separate systems. A member of the public who was treated by a paramedic last week and wants a copy of their record should not have to submit a freedom of information request to get it.

The Electronic Patient Care Report Clinical Workspace gives ambulance services a single field-first application that follows a patient from dispatch through on-scene assessment, clinical decision, conveyance or non-conveyance disposition, hospital handover, and post-incident audit. The same platform gives clinical audit leads a governance view of every encounter, gives patients a secure citizen view of their own ambulance visits with patient-reported outcome surveys, and gives service administrators a place to configure protocol cards, decision rules, forms, roles, and key performance indicators without calling an integrator.

Diagram

flowchart TD
    A[Dispatch / Call Taker] --> B[Encounter Created]
    B --> C[On-Scene Assessment]
    C --> D[Vitals and Interventions]
    D --> E[Clinical Protocol Card]
    E --> F{Disposition}
    F -->|Convey| G[Hospital Handover Record]
    F -->|Treat and Leave| H[Non-Conveyance Record]
    G --> I[Submitted to Audit]
    H --> I
    I --> J[Clinical Audit Review]
    J --> K[Citizen Ambulance Visit Record]
    K --> L[PROMs Share Token]
    L --> M[Patient Outcome Survey]
    I --> N[KPI Dashboard]
    I --> O[Deployment Forecast]

Last Reviewed: 2026-04-17 Last Updated: 2026-04-17

Key Features#

  • Encounter Record: Every dispatched incident creates a structured encounter with call sign, incident number, crew lead, care model (Emergency, Non-Conveyance, Specialist), dispatch timestamp, and masked patient identifier. Encounters progress through ACTIVE, SUBMITTED, AUDITED, and CLOSED states with role-based transition rules.

  • Structured Clinical Form: The encounter detail view presents Overview, Patient, Assessment, Vitals, Interventions, Medications, Clinical Practice Guideline Decisions, and Handover tabs. Each tab is independently saveable and preserves draft state across network interruptions so a crew losing connectivity on a dual carriageway does not lose the work they already recorded.

  • Clinical Practice Guideline Engine: Protocol cards encode each step of a clinical pathway (for example, suspected stroke, chest pain, cardiac arrest) with the assessment items the crew must complete, the interventions the guideline indicates, and the decision points that determine the next step. Decisions are captured on the encounter with the rule identifier that triggered them, producing a complete, reviewable record of why a given course of action was taken.

  • Decision Rule Administration: Administrators configure decision rules against clinical practice guidelines from a dedicated admin page. Each rule names the guideline, the triggering conditions, the recommended action, and the review cadence. Rule changes are versioned so a retrospective audit sees the rule that applied at the time of the encounter, not today's rule.

  • Protocol Card Administration: The same admin surface configures the cards themselves. An operations manager can add a new card for a new care pathway, adjust assessment items, or retire a card without a code release.

  • Form and KPI Configuration: Administrators edit patient assessment forms and key performance indicators through typed configuration pages. A new national reporting field, a new safeguarding prompt, or a new operational KPI is added through the admin page rather than a change request.

  • Role Administration: Role definitions control who can access the active encounter list, who can sign off a submitted record, who can perform clinical audit, and who can configure the system. The role page enforces least-privilege defaults for paramedic, advanced paramedic, clinical lead, audit officer, and service administrator personas.

  • Device Register: Every defibrillator, monitor, tablet, and signature pad used to collect the encounter is tracked in a devices page with serial number, assigned crew, firmware version, last calibration, and current home station. A device flagged as out of calibration blocks encounter submission until a compliant replacement is recorded.

  • Hospital Handover Document: When an encounter reaches the Handover tab, the crew can preview a handover document that summarises the patient identifier, chief complaint, vitals trend, interventions given, drugs administered, guideline decisions, and receiving hospital. The printed view is formatted for physical handover at the ED door where a digital hospital record is not yet available, and the same document is submitted electronically to hospitals that accept structured intake.

  • Clinical Audit Queue: Clinical audit officers work through SUBMITTED encounters in the audit list, opening each case to review clinical decisions, compare them against the CPG, confirm documentation completeness, and either mark the case AUDITED with comments or return it to the crew for correction. Every audit event is recorded with the reviewer, timestamp, and outcome.

  • KPI Dashboard: The KPI page surfaces service-level indicators such as time on scene, response time by acuity, non-conveyance rate, hospital pre-alert compliance, and CPG adherence, calculated from the encounter records rather than manual reporting.

  • Deployment Forecasting: The deployment page predicts incoming call volume, high-acuity call share, and geographic hotspots across 1h, 4h, 12h, and 24h horizons and recommends vehicle redeployment between stations. Recommendations are advisory and are marked against the vehicle status so a crew can decline or accept them with a one-click action.

  • Citizen Ambulance Visit Record: A patient who was treated signs in through the citizen portal and sees every encounter where they were the patient, with date, chief complaint summary, disposition, receiving hospital, and availability of a discharge document. They can download their discharge document and complete their patient-reported outcome survey without contacting the service office.

  • Share-Token PROMs Survey: Each encounter optionally issues a time-limited share token that opens a patient-reported outcome measures survey without requiring the patient to hold a full platform account. The survey template is configurable, question keys are stable for downstream PROMs aggregation, and submissions are scoped to the tenant and the encounter that generated the token.

Use Cases#

  • Ambulance Crew Completing an Encounter: A paramedic crew attends a chest pain call, opens the dispatched encounter on the in-vehicle tablet, works through the Assessment, Vitals, and Interventions tabs while on scene, selects the appropriate chest pain CPG card, records drugs administered from the formulary, conveys the patient, and completes the Handover tab at the hospital. The encounter progresses from ACTIVE to SUBMITTED without paper forms.

  • Non-Conveyance Decision with Safeguarding: A crew attends an elderly faller who does not require hospital transport. They complete the Hear, See, Treat pathway, record the safeguarding assessment, and submit the non-conveyance record with a GP referral. The safeguarding service flags the record for follow-up review.

  • Hospital Pre-Alert for Major Trauma: A crew attending a serious road traffic collision activates the trauma CPG, which triggers a hospital pre-alert to the designated trauma centre containing the patient identifier, chief complaint, vitals, and estimated time of arrival. The receiving hospital sees the pre-alert through their configured channel (FHIR, REST, or SMS fallback) before the ambulance arrives.

  • Clinical Audit Cycle: A clinical audit officer works through the previous week's submitted encounters, compares the recorded CPG decisions against the current guideline version, returns two cases for correction, and marks the rest AUDITED. The audit outcome feeds the service KPI dashboard and individual crew CPD records.

  • Deployment Redistribution at Shift Change: A duty officer opens the deployment page at shift change and reviews the 4-hour forecast. The model predicts elevated demand in the west of the service area. The officer accepts the recommendation to move two vehicles to the western stations and declines a third recommendation because one of the vehicles is committed to a scheduled specialist transfer.

  • Patient Accessing Their Own Record: A citizen who was treated two weeks ago signs in to the citizen portal, reviews the summary of their ambulance visit, downloads their discharge document, and completes the PROMs survey that was sent to them by share token.

  • Research and Analytics Export: A regional service uses the audit queue and KPI records to build a dataset of all suspected stroke encounters in the previous quarter for review by the regional clinical director, including the exact CPG version in force at each encounter.

Integration#

  • Dispatch System: Encounters are created from the dispatch record using the incident number, call sign, and location as the anchor. Updates to the dispatch record (for example, a reassignment) are reflected on the encounter in real time.
  • Hospital Pre-Alert: The TraumaRoutingService and HospitalPreAlertService deliver pre-alerts to the receiving hospital via the FHIR R4 PatientArrivalNotification profile where supported, a configurable REST endpoint where the hospital publishes one, and SMS to the charge nurse as a last-resort fallback.
  • Formulary Service: Medication administration records reference the platform formulary, which is maintained by the clinical lead and versioned so a retrospective audit sees the formulary entry that applied at the encounter time.
  • Immutable Audit Service: Every status change, CPG decision, medication administration, and handover submission is written to the encounter immutable audit trail.
  • Community Paramedic Module: Hear, See, Treat and non-conveyance records feed the community paramedic record for follow-up scheduling and outcome tracking.
  • Coroner Evidence Pack: Encounters involving a death or significant adverse event are assembled into a coroner evidence pack for forwarding to the coroner's office.
  • Deterioration Predictor: Vitals recorded on the encounter are evaluated against a clinical deterioration model, and an alert is raised on the encounter if the trajectory suggests imminent deterioration.

Open Standards#

  • HL7 FHIR R4 (https://www.hl7.org/fhir/R4/): the PatientArrivalNotification and related profiles are used for hospital pre-alerts. The encounter and observation representation in the handover document follows FHIR R4 resource patterns so external systems can consume it without a proprietary mapping layer.
  • SNOMED CT and ICD-10: clinical coding on assessment and disposition uses the tenant's configured terminology, defaulting to SNOMED CT with ICD-10 discharge coding where the service records it.
  • NATO STANAG 4774 / 4778: encounter records containing protected information carry the platform's confidentiality marking and metadata binding, so records crossing into a partner system retain their classification.
  • W3C PROV-DM: every CPG decision, medication administration, and handover event is recorded with the activity, agent, and entity that generated it, producing a provenance chain that survives export.
  • IHE Cross-Enterprise Document Sharing (XDS.b): discharge documents and handover documents can be published to a connected IHE XDS registry where the receiving hospital or regional health record supports it.
  • EHDS (European Health Data Space) conformance: patient-facing access to ambulance records and PROMs survey responses follows the primary-use and secondary-use split defined in the EHDS regulation, managed by the platform's EHDS conformance service.