Mobile Push Notifications, Responder & Clinical Alerts

Overview#

When a multi-casualty incident is declared or a patient begins to deteriorate, the responders who need to act are rarely sitting in front of a screen. The Mobile Push Notifications service delivers time-critical alerts straight to a responder's phone within seconds of the triggering event, so that paramedics and field crews are reached wherever they are, on whatever device they carry.

The service powers the responder mobile app with a dedicated, typed notification pipeline. It registers each responder's devices, classifies every alert into a clinical category, fans messages out to named individuals or to entire practitioner roles, and respects each person's quiet-hours and per-category preferences while guaranteeing that the most urgent directives break through regardless. Every send is recorded with a transport ticket, reconciled against a delivery receipt, and tracked through to read state, giving operations teams a complete and tenant-isolated audit trail.

For teams building or integrating the responder app, the value is equally direct: register a device token once and gain per-user preference management, role-level fan-out, and full receipt auditing through a single REST or GraphQL interface, with no need to handle platform-specific Apple or Android credentials directly.

Key Features#

• Multi-platform device registration: Each responder can register one or more devices across iOS, Android, Expo, and Web platforms, with a single call that records the platform, the delivery token, an optional Expo token, a friendly device name, and the time the device was last active.

• Ten typed clinical and operational categories: Every alert is classified into a named category covering critical and routine clinical directives, clinical acknowledgement reminders, dispatch assignments, patient deterioration warnings, handover acknowledgements, safeguarding escalations, multi-casualty incident activation, shift reminders, and calibration-due alerts.

• Critical break-through delivery: Quiet-hours windows and per-category mute settings are honoured for routine traffic, while categories marked critical are configured to bypass quiet hours so that life-safety directives always reach the responder.

• Role-level fan-out: A single send can target an individual responder or an entire practitioner-level role, expanding the role to every member's active devices so that an incident commander reaches the whole crew with one action.

• Per-user preference management: Responders control their own quiet-hours start and end times, choose whether critical alerts may break through, and enable or disable each notification category independently.

• Full delivery and read auditing: Every send attempt is persisted with its transport ticket, later reconciled against the provider delivery receipt, and tracked through delivered and read timestamps, giving a complete lifecycle record for each notification.

• Graceful degradation: A transport failure is recorded as a failed send with a captured reason rather than raised as an error, so that a single unreachable device never blocks delivery to the rest of a fan-out.

• Dual REST and GraphQL surfaces: The same capabilities are reachable through a versioned REST interface under /api/v1/push/ and through a typed GraphQL schema, letting app and back-office teams pick whichever fits their stack.

Use Cases#

Pre-hospital and emergency medical services#

• Multi-casualty incident activation: When a major incident is declared, an activation alert fans out instantly to every responder in the relevant roles, breaking through quiet hours so off-shift and resting crews are mobilised without delay.

• Patient deterioration warnings: Monitoring thresholds that flag a deteriorating patient push a warning directly to the assigned crew, shortening the time between a clinical signal and a clinical response.

• Dispatch assignments: As cases are assigned, the responsible responder receives a dispatch alert on their device with the structured payload the app needs to open the case in context.

Clinical governance and safeguarding#

• Critical clinical directives: Time-sensitive clinical instructions are delivered as a critical category that bypasses quiet hours, with acknowledgement reminders following up until the responder confirms receipt.

• Safeguarding escalations: Escalations are routed to the appropriate safeguarding leads by role, ensuring the right people are notified even when individual on-call assignments change.

• Handover acknowledgements: Confirmation that a clinical handover has been accepted is pushed back to the originating responder, closing the loop on continuity of care.

Operations and readiness#

• Shift reminders: Upcoming-shift prompts reach responders ahead of time, honouring each person's quiet-hours and notification preferences.

• Calibration-due alerts: Equipment and device calibration deadlines are surfaced to the responsible role before they lapse, supporting operational readiness.

App development teams#

• Single integration point: Teams building the responder mobile app register a device token once and rely on the service for preference handling, role fan-out, and receipt auditing, without integrating Apple or Android push credentials into the app back end.

Integration#

The service is designed to be plugged into a mobile app and an operations back end with minimal effort:

• REST interface: A versioned set of endpoints under /api/v1/push/ covers device registration and revocation, listing a user's devices, reading and clearing an unread count, listing notifications, marking a notification read, and reading or updating preferences. This is the natural fit for the mobile client and for server-to-server back-office tasks.

• GraphQL interface: A typed schema exposes the same device, notification, preference, and fan-out result types for back-office consoles and reporting tools that prefer to fetch exactly the fields they need in one typed request.

• Authentication: Every call is authenticated as a platform user and authorised against the caller's organisation, so access is consistent across both interfaces.

• Normalised models: Devices, sent notifications, preferences, and fan-out results are represented as stable, normalised models shared across REST and GraphQL, so a consumer learns one shape and reuses it everywhere.

• Managed transport: The service brokers delivery through the Expo Push API, which fans messages out to Apple and Google delivery networks on the app's behalf. Direct Apple and Google delivery are supported as enterprise fallbacks, all behind the same registration and send model, so the customer plugs in once and the platform absorbs the transport differences.

Open Standards#

• Expo Push API: The primary delivery transport. Notifications are submitted as JSON message batches over HTTPS to the Expo push endpoint, which returns per-message tickets and later supplies delivery receipts that the service reconciles against each recorded send.

• Apple Push Notification service (APNs): Supported as a direct delivery path for iOS devices. The service authenticates to APNs using token-based authentication built from a signing key, key identifier, team identifier, and bundle identifier, the standard provider-token model Apple defines for push delivery.

• Firebase Cloud Messaging (FCM): Supported as a direct delivery path for Android devices, used as a transport fallback for deployments that bypass the managed Expo layer.

• Web Push: Registered as a first-class device platform alongside iOS and Android, allowing browser-based responders to receive the same typed alerts as native app users.

• GraphQL (June 2018 specification): The domain publishes its types and operations as a typed GraphQL schema, letting back-office consoles fetch device, notification, and preference data in a single request.

• REST over HTTPS / JSON: The /api/v1/push/ endpoints follow conventional resource-oriented REST semantics with JSON request and response bodies, the lingua franca for mobile and server clients.

• OAuth2 Bearer tokens (RFC 6750) and JSON Web Tokens (RFC 7519): Callers present a bearer access token that the platform validates to identify the user and their organisation before any device or notification operation proceeds.

• JSON Web Signature with ES256 (RFC 7515 / RFC 7518): When delivering directly to Apple, the provider authentication token is an ES256-signed token derived from the configured signing key, the elliptic-curve signature scheme Apple's token-based push authentication requires.

• HTTP/2 (RFC 7540): Direct Apple delivery uses the HTTP/2 multiplexed transport that APNs mandates for its provider connection, enabling efficient concurrent delivery of fan-out batches.

• JSON (RFC 8259): Notification payloads, category preference maps, and message bodies are encoded as JSON throughout, both on the wire and in the structured payload carried to the app.

Security & Compliance#

• Multi-tenant data sovereignty: Every stored record carries an organisation identifier and every query is scoped to it, so devices, notifications, and preferences are strictly isolated between tenants.

• Authenticated and authorised access: All REST and GraphQL operations require an authenticated platform user, and a caller can only act within their own organisation.

• Device revocation: A device token can be revoked at any time so a lost or retired handset stops receiving alerts immediately, with the revocation time retained for audit.

• Complete audit trail: Each send is persisted with its transport ticket, delivery reconciliation, failure reason where applicable, and read state, supporting after-action review and compliance reporting.

• Resilient by design: Delivery failures are recorded rather than thrown, so the audit record stays accurate and one bad device never disrupts an incident-wide alert.

Last Reviewed: 2026-05-26 Last Updated: 2026-05-26