Overview#
A Community First Responder (CFR) is often the first clinically useful person at a medical emergency in a village, housing estate, or sparsely crewed rural sector. They are volunteers or affiliated responders who are not the full-time ambulance crew, yet control still needs to know who is genuinely available within reach of the call, and the responder needs a phone experience that tells the truth about whether they will be paged.
Community First Responder Paging gives that honesty on both sides. On the Argus responder mobile app, a CFR checks in with a live location refresh so they appear in the nearby pool control can page. Check-in is only shown after the server confirms it. Presence goes stale after a short freshness window if the phone stops refreshing, and the UI says so in plain language rather than leaving someone believing they are still pageable. Check-out is one tap, and a failed check-out keeps warning that they may still be paged until the server confirms they are clear. Pages arrive on a dedicated alert path so a volunteer is not dropped into a full dispatcher console they were never trained to use.
For ambulance trusts, community response schemes, and multi-agency PSAP programmes evaluating field volunteering alongside professional crews, this module is the operational bridge between "we have volunteers on paper" and "control can page people who are actually available right now".
Last Reviewed: 2026-09-15 Last Updated: 2026-09-15
Key Features#
-
Server-confirmed availability: The mobile screen never paints "checked in" from local optimism. Availability becomes checked in only after the PSAP check-in endpoint confirms the post. A failed check-in renders as checked out with an error, so a volunteer does not believe control can see them when the network rejected the update.
-
Periodic presence refresh: While checked in and the app is foregrounded, the client re-posts on a short interval so the registry keeps a fresh location. Control nearby queries stop returning a responder once presence is older than the freshness window (fifteen minutes after the last confirmed post), which matches how real volunteer schemes think about "still available" versus "phone in a pocket somewhere".
-
Staleness that speaks plainly: When the last confirmed check-in is older than the freshness window, the UI labels the state as checked in with stale presence and tells the responder that control is no longer paging them until they update. That wording is deliberate: volunteer programmes lose trust when apps imply readiness the backend has already dropped.
-
Honest check-out: Check-out is a single action confirmed from the server response. If check-out fails, the screen keeps saying the responder may still be paged, rather than silently flipping to checked out on the device alone.
-
Foreground-honest refresh loop: Refresh runs while the app is active. Background timer freezes on mobile OS platforms are acknowledged in product copy: closing the app means pageability ends about fifteen minutes after the last successful post, which is the behaviour control already enforces.
-
Dedicated paging surface: Pages reach CFRs through the CFR alert experience rather than a dispatcher-grade console. Accept and decline stay in the volunteer workflow. Declined or missed pages remain visible in incident history where policy allows, so scheme managers can review response patterns without inventing a second system of record.
-
Role-gated entry: Only roles authorised for CFR flows see availability and paging destinations. Route access follows the same navigation catalogue and auth grants used elsewhere on responder mobile, so a role change on the server updates who can present as a CFR.
-
Localised field copy: Availability and paging strings ship with locale parity for the supported mobile languages, so schemes that operate in more than one language do not strand volunteers on English-only status text during an emergency.
Use Cases#
-
Rural and village schemes: A volunteer marks available after dinner. When a nearby medical call needs early attendance, control's nearby pool includes them, they receive a page, and they can accept from the phone before the nearest double-crewed ambulance arrives.
-
Shift and lifestyle edges: At the end of a duty window the responder checks out. If they forget and simply close the app, presence ages out of the nearby pool automatically so overnight pages do not hit a phone that is no longer on service.
-
Trust and governance review: Scheme leads can see that availability was server-confirmed and that stale presence was excluded from paging, which matters when auditors ask whether the organisation paged people it still believed were available.
-
Multilingual community programmes: Schemes spanning language communities present status, warnings, and page copy in the responder's chosen locale without maintaining a parallel bespoke app.
-
Mixed professional and volunteer response: Full-time crews keep their operational consoles. CFRs keep a narrow availability and paging path that fits volunteer training and device norms, while still feeding the same incident picture.
Integration#
Community First Responder Paging sits on the PSAP CFR check-in API in argus_middleware (/api/v1/psap/cfr/checkin for check-in, location refresh, and check-out) and the nearby selection path control uses when building a page list. Identity comes from the session token server-side. Responder mobile hosts CfrAvailabilityScreen, the availability store with the refresh loop, and the CFR alert screen for inbound pages. auth_service supplies the role grants that decide who may enter those routes. Notification delivery uses the platform notification path already shared with other field alerts.
Customers typically wire this alongside existing PSAP incident creation and ambulance dispatch. The module does not replace CAD. It adds a trustworthy volunteer availability layer that dispatch and supervision can consume when local early attendance is part of the response plan.
Open Standards#
- HL7 FHIR (Encounter / Practitioner context): When a CFR attendance feeds clinical handover, encounter and practitioner references can align with FHIR identifiers used in Argus clinical and ePCR modules.
- ETSI emergency communications practices: Paging and availability semantics stay compatible with public-safety alerting expectations used across Argus PSAP modules.
- OAuth 2.0 / OpenID Connect: Session-bound identity for check-in and page receipt follows the same platform auth model as other responder surfaces.
- WCAG 2.2: Availability controls and page response actions expose accessible names and states suitable for field use under assistive technologies.
- ISO 8601: Presence timestamps and freshness calculations use unambiguous time representations shared with the wider incident audit trail.