
911 Health Data Standardization Initiative (HDSI)
From IoT to ICU — Standardizing Wearable & Device Data for 911
​
NG911 modernizes call routing, multimedia, and precise location, but there is no standard pathway for physiological data from consumer wearables and IoT medical devices. 911‑Intl.net will fill this gap by defining the 911 Health Data Schema (911‑HDS), building a cross‑platform 911 Emergency Data Kit (911‑EDK) SDK, and operating a secure Supplemental Data Gateway that bridges device data to PSAPs and EMS/EHR systems. The result is faster, smarter triage, improved outcomes, and a scalable, standards‑aligned ecosystem that positions 911 as the safety layer of the IoT era.
​
Problem & Opportunity
-
Problem: PSAPs receive location and narrative, not physiology. Out‑of‑hospital cardiac arrest, respiratory distress, overdose, trauma, and elder falls are common scenarios where pre‑arrival vitals would change dispatch and treatment.
-
Opportunity: Hundreds of millions of wearables already capture high‑value signals (HR, HRV, SpO₂, respiratory rate, temperature, motion). A universal schema, SDK, and 911‑aware consent flow can turn these into actionable pre‑arrival intelligence.
​
Goals
-
Define a portable, privacy‑preserving 911‑HDS that maps to NG911 and HL7 FHIR.
-
Deliver a vendor‑friendly 911‑EDK SDK for mobile, firmware, and cloud.
-
Stand up a Supplemental Data Gateway (SDG) that integrates with ESInets and PSAP CAD/EMS systems.
-
Launch a 911‑Certified Device program to accelerate industry adoption.
-
Lead standards and policy updates so “Send Health to 911” becomes a universal capability.
​
Use Cases (Minimum Viable Scope)
-
OHCA/Cardiac: Wearable detects bradycardia/asystole‑like patterns; PSAP sees trend + advisory; EMS gets pre‑arrival report.
-
Respiratory: Low SpOâ‚‚ trend + low RR; PSAP prioritizes ALS dispatch; dispatcher script adapts.
-
Falls/Elder Care: High‑confidence fall + abnormal HR; automatic call with location and vitals snapshot.
-
Heat Illness: Elevated skin temp + HR pattern + location context; pre‑arrival cooling guidance.
-
Behavioral/Overdose: Abnormal RR/SpOâ‚‚ pattern with consented context flags for naloxone readiness.
​
Architecture Overview
Device/Treatment Edge → Phone App or Device Cloud → 911‑EDK (consent, packaging, security) → 911 Supplemental Data Gateway (SDG) → ESInet / Additional Data Repository (ADR) → PSAP CAD / 911 Triage Console → EMS ePCR/EHR via FHIR Bridge.
​
Resiliency features: Store‑and‑forward buffering, cellular/SOS fallback with short URLs to encrypted payload, offline consent tokens, and audit trails.
​
Data Model: Core Entities (Conceptual)
-
Subject: Pseudonymous ID, age band, sex (optional), consent token (FHIR Patient minimal).
-
Device: Manufacturer, model, firmware, sensors, QA/accuracy class, unique device ID (FHIR Device; IEEE 11073).
-
Measurement: Type (HR, HRV, SpOâ‚‚, RR, temp), value, unit, confidence, sampling rate, signal quality (FHIR Observation).
-
Episode: Start/stop time, triggers (fall, button press), anomaly flags (FHIR Encounter emergency).
-
Location: Latitude, longitude, z‑axis, uncertainty, method (PIDF‑LO / NENA GIS).
-
Consent: Scope, duration, revocation handle, provenance (FHIR Consent).
-
Alert: Event type (bradycardia, hypoxemia, fall), severity, ruleset version (FHIR DetectedIssue/Flag).
-
Context: Posture, activity class, ambient conditions (FHIR Observation derived).
Data Dictionary (Selected Fields)
-
Identity & Provenance
-
Subject ID: Pseudonymous stable ID (required).
-
Device ID: Unique identifier (required).
-
Vendor Signature: Device‑signed payload attestation (required).
-
Firmware Version: QA/recall traceability (required).
-
-
Time & Location
-
Timestamp: ISO‑8601 UTC (required).
-
Lat/Lon/Z: Required for Lat/Lon; Z if available.
-
Accuracy: Horizontal/vertical uncertainty.
-
Method: GPS, Wi‑Fi RTT, carrier, BLE.
-
-
Vitals & Quality
-
HR, HRV, SpOâ‚‚, RR, skin temp (optional).
-
Signal quality scores (required).
-
Trend window metrics.
-
-
Consent & Policy
-
Scope: Who can access (required).
-
Duration: Expiry (required).
-
Revocation: Token/URL (required).
-
Purpose: Emergency/medical (required).
-
Standards Mapping
-
Subject: FHIR Patient minimal → Call‑ID/Incident binding.
-
Device: FHIR Device → certification registry.
-
Measurement: FHIR Observation → ADR payload reference.
-
Episode: FHIR Encounter (emergency) → incident context.
-
Location: FHIR Location/Geo → PIDF‑LO.
-
Consent: FHIR Consent → policy binding.
-
Alert: FHIR DetectedIssue/Flag → CAD enrichment.
SDK Proposal: 911 Emergency Data Kit (911‑EDK)
-
Surfaces:
-
Mobile SDK (iOS/Android).
-
Firmware library (embedded C/C++).
-
Cloud connector (server‑side adapter).
-
-
Core Capabilities:
-
Consent UI & tokens.
-
Schema validation & normalization.
-
Signal quality heuristics.
-
Secure transport & replay protection.
-
Store‑and‑forward with backoff.
-
PSAP acknowledgment/status callbacks.
-
-
Developer Experience:
-
Reference implementations.
-
Test vectors & conformance suite.
-
Sandbox with synthetic incidents.
-
“911‑Certified Device” checklist.
-
Supplemental Data Gateway (SDG)
-
Role: Policy‑enforced broker between vendors and PSAPs.
-
Functions:
-
Token exchange & consent verification.
-
Vendor authentication & key management.
-
GIS‑based routing to PSAP.
-
Persistence in ADR with expiry/audit logging.
-
FHIR Bridge to EMS ePCR/EHR.
-
-
Resilience & Security:
-
End‑to‑end encryption.
-
Active‑active regional deployment.
-
Data minimization & automatic purging.
-
Policy, Standards, and Lobbying Plan
-
Targets:
-
NENA: i3 Architecture WG, Data Structures WG.
-
IETF: ECRIT/PIDF‑LO extensions.
-
HL7 FHIR Foundation: Emergency profiles.
-
FCC: NG911 rulemaking for telemetry.
-
DHS/CISA: Critical public safety modernization.
-
3GPP/ETSI/ITU: Global telecom interoperability.
-
IEEE 11073: Device semantics harmonization.
-
-
Deliverables:
-
911‑HDS v0.1 Informational spec.
-
NENA Technical Reference draft.
-
IETF Internet‑Draft for telemetry.
-
HL7 Implementation Guide.
-
-
Advocacy Narrative:
-
Public benefit framing.
-
Vendor incentives.
-
PSAP ops improvements.
-
Compliance & Liability
-
Privacy: Consent‑first, purpose‑limited, short retention.
-
Security: Device attestation, HSM keys, TLS, signing, replay detection.
-
Quality: Accuracy classes, per‑sensor confidence.
-
Audit: Immutable logs, incident‑bound lineage.
-
Legal: HIPAA alignment, BAAs, Good Samaritan considerations.
PSAP Operator Experience (911 Triage Console)
-
Incident timeline with vitals trend.
-
Confidence badges & signal quality indicators.
-
One‑tap CAD attach & auto‑populate EMS form.
-
Adaptive dispatcher scripts.
Pilot Program Plan (12 Months)
-
Phase 1 (0–3 months): Spec v0.1; SDK alpha; SDG MVP; ethics/legal review.
-
Phase 2 (4–8 months): Two PSAP pilots; one OEM; simulated drills; KPI tracking.
-
Phase 3 (9–12 months): Expand to 3–5 PSAPs; add second OEM; NENA/IETF submissions.
-
Key KPIs:
-
Time‑to‑dispatch delta.
-
ALS vs. BLS accuracy.
-
OHCA ROSC and shock timing improvements.
-
False alert rates.
-
Delivery success and latency.
-
Business Model & Impact
-
Revenue: Certification fees, SDK support, SDG access tiers, SaaS to PSAPs, integration services.
-
Costs: Standards, infrastructure, certification lab, pilot support.
-
Philanthropic Zones: Job creation in under‑resourced regions; workforce development.
-
Ecosystem Value: Reduces fragmentation, accelerates adoption, positions 911‑Intl.net as standards convener.
Roadmap (18–24 Months)
-
v0.1 spec + SDK alpha + SDG MVP → pilots.
-
v0.9 pre‑standard + certification beta → NENA/IETF/HL7 submissions.
-
v1.0 standard + multi‑OEM rollout.
-
Add cuffless BP, CGM, fall risk scores, broader device classes.
-
Internationalization with ETSI/3GPP/ITU.
Appendices
-
Measurement Semantics & Units: HR bpm; HRV ms; SpOâ‚‚ %; RR breaths/min; skin temp °C; confidence 0–1.
-
Data Quality Heuristics: Motion artefact handling; skin tone bias mitigation; multi‑sensor fusion.
-
Interop Profiles: FHIR Bundles; ADR references; incident binding.
-
Governance: Advisory board, transparency reports, conformance tests.
Tier 1: Immediate (High Impact + High Feasibility)
-
OEM Adoption Incentives (AR)
-
Offer “911-Certified Device” co-branding and regulatory lobbying support.
-
Provide SDK integration stipends or cost-share pilot programs to overcome inertia.
-
-
Timestamp Harmonization (WM)
-
Implement a synchronization protocol across wearables, vehicles, and IoT devices.
-
Ensures incident timelines are coherent for PSAPs.
-
-
Advocacy Narrative Refresh (VLI)
-
Emphasize patient survival and response time in messaging.
-
Position “Every Second Counts: Wearables Save Lives with 911” as the public-facing slogan.
-
Tier 2: Near-Term (High Impact + Medium Feasibility)
-
PSAP Dashboard Visualization (SVI)
-
Prototype multi-sensor UI with layered vitals and GIS overlays.
-
Ergonomic design is critical for dispatcher workload reduction.
-
-
Cross-Device Expansion (LT)
-
Add vehicle telematics, smart speakers, and home IoT (fall detectors, thermostats).
-
Broaden beyond wearables into an IoT emergency ecosystem.
-
-
Predictive Triage Models (PR)
-
Use aggregated data to detect clusters (opioid overdoses, heatwave distress).
-
Enable proactive deployment before calls spike.
-
Tier 3: Strategic (High Impact + Longer Horizon)
-
Emergency Interoperability Layer (AT)
-
Evolve “911-Certified Device” into a universal Emergency IoT Interop Layer.
-
Broader adoption across health, fire, and disaster devices.
-
-
Future-Proof Schema Extensions (FI)
-
Build flexible fields for cuffless BP, noninvasive glucose, brain activity, and novel sensors.
-
Avoid obsolescence as consumer medtech advances.
-
Tier 4: Continuous (Ongoing Intelligence)
-
Standards Leverage (CI)
-
Use HL7 FHIR and IEEE 11073 mappings to accelerate adoption and credibility.
-
-
Process Self-Audit (META)
-
Track SDK adoption, PSAP readiness, and lobbying traction.
-
Adjust tactics based on data rather than assumptions.
-
​
-