Questions people actually ask

No, and it is not meant to be. It supports existing 911, PSAP, dispatch, EMS, fire-rescue and law-enforcement services, and it never dispatches an emergency on its own. What it adds is the minutes before a crew arrives, the equipment nobody can see from a dispatch desk, and the detail a phone call loses on the way through.

Residents, community responders, professional responders, dispatchers and agencies can all take part, but they do not see the same things. What a person sees follows their role, their verification, their qualifications and the restrictions the community and agencies set — medical detail and certain incident categories are held to authorized responders only.

No. Cardiac arrest is the case the community-response model was proven on, and it is the only one PulsePoint was built for, which is why the two are so often spoken about together. Here the same alert reaches verified responders for other time-critical emergencies as well: opioid overdose, severe bleeding, drowning, heat stroke, diabetic emergencies and hypothermia, along with strokes, choking and anaphylaxis where the value a bystander adds is earlier recognition and a call made sooner. The project's research paper carries the published figures for each of those, and they are set out in the community-response section of this page with the study each one came from. What any individual responder is alerted for still follows their verified training and the community's own rules — and law-enforcement, mental-health and hazardous-material calls are never sent to community responders.

Community administrators and authorized agency leadership. Which capabilities are enabled, who may access them, the requirements a community responder must meet, escalation rules and alerting policy are all configuration decisions — not platform defaults.

It is built to sit alongside them, not to displace them. Integration with existing systems is a configuration project that is worked through with each agency, and the platform continues to work as a standalone support where no integration is in place.

Access is role-based and audited. Sensitive categories — medical information, mental-health crises, restricted law-enforcement incidents — are limited to authorized personnel, records of access exist, and a resident decides what emergency information they keep on file and what they share.

Yes, and that is the point of the modeling layer rather than a side feature. Live National Weather Service products are read as they are issued: the warning's own published boundary, its motion and speed, its timing, its severity and certainty, and the areas and zones it names. Those are what get modeled — the corridor ahead of a storm, what falls inside the polygon, what a surge or a flood stage would reach — and the layer follows the product as it is updated, superseded, canceled or allowed to expire. It is not a forecast of our own: we model what an authority has already published, the authority's product stays official and is shown exactly as it was issued, and anything we build from it is labeled a hypothetical planning exercise.

No. They are planning scenarios built from recorded conditions, and they are labeled as hypothetical planning exercises wherever they are shown. The issuing authority's warning remains the official product and is shown as it was published; what we build from it is planning, never a substitute for it.

No, and it is built that way deliberately. There is no direct coupling to an agency's CAD system: nothing is installed on a dispatch workstation, no call depends on us, and there is no write path into CAD. If the portal is unavailable, your CAD, radios, phones and procedures are exactly as they were and calls arrive the way they always have. Where an agency connects anything at all, it is a read-only information layer the agency controls and can switch off. Nothing we run is a dependency in your chain of response.

Several separate things. Sign-in is authenticated, and the privileged surfaces — dispatch, administration, the database console — are reachable only through their own separately issued credentials, held as hashes rather than passwords that can be read. Two-factor sign-in applies to those surfaces, and where a decision is significant a third factor is required as well: a device check answered on a second screen before the session is trusted. Open privileges expire on a window and have to answer again rather than lasting indefinitely, and every administrative action is written to an audit trail kept separately from the incident record.

Those categories are handled differently from everything else. An active-threat, law-enforcement, mental-health or hazardous-material call is restricted: it is shown only to the accounts authorized to work it, and it is not published, shared or carried on a public page. The public side gets what may be published — a lockdown, shelter-in-place or evacuation notice, directed by the people responsible for it — and nothing about who is involved. Lockdown triggers work in the other direction too: a lost device, a suspected compromise or an administrator's decision can end open privileged sessions on the spot rather than waiting for them to expire, and the console has to prove itself again before it is used.

The phone they already carry. It installs as an app on a phone and runs in a browser on a computer, with no special hardware and no dedicated radio equipment required — which is what makes it usable by a resident, a business and an agency at once.

An organization can register the emergency equipment it already owns so it becomes findable in an emergency, and can talk to us about participating, partnering or evaluating a deployment. Anyone can start the conversation using the contact address on this page.

Only what is needed to do the job: incident records with the notes, media and stages attached to them, the resource records a community maintains, the emergency information a person chooses to enter on their own profile, and the messages and notification records that go with an incident. There is no advertising profile and no third-party tracking on the public pages.

Only the people authorized to work that incident. Access follows role, verification and agency configuration: a resident, a community responder and a dispatcher do not see the same screen. Medical detail, mental-health crises and restricted law-enforcement incidents are held to authorized personnel, and a responder alert carries what the responder needs in order to act and nothing beyond it.

Sensitive fields, including medical information, are encrypted at the field level rather than stored as plain text. Sign-in is authenticated, and the privileged screens — dispatch, administration, the database console — require their own separately issued credentials, held as hashes, with periodic re-validation while a session is open. Two-factor sign-in applies to those surfaces, and where a decision is significant a third factor is required as well, answered by a second device. Lockdown triggers can end an open privileged session immediately if a device is lost or a compromise is suspected. Access rules are applied per record and per role, and administrative actions are written to an audit trail kept separately from the incident record.

No. Your position is used when you share it — to attach a location to a report you are making, to find resources near you, or while a responder is actually responding to a call. Alerting is based on the locations you deliberately subscribe to, not on where you happen to be standing, and a location you set by hand is treated as a location you set.

Yes. An account can be deleted from inside the application, and the published privacy-rights and privacy-policy pages set out what applies to a person. Incident records and audit records belong to the agency's own record-keeping obligations, so retention in those cases follows the agency's policy rather than a platform default — and that is a question worth asking directly, which the contact address on this page answers.