Offline voice dictation and structured reporting for emergency response teams in the field.
In the back of a moving ambulance, with one hand on a patient and three minutes until the trauma bay, a paramedic still has to remember every drug, every vital, every minute that just passed — and write it down later. Often much later. Sometimes not at all.
vera exists because the people we ask to do the hardest work also get the worst tools for recording it. Clipboards on a thigh strap. EHR tablets that want a WiFi network the patient compartment doesn't have. State-mandated forms that take fifteen minutes to fill out when the patient was on scene for nine.
The premise is simple: a responder should be able to say what's happening as it happens — and end the call with the report already most of the way written.
vera is Latin for true. A vera report is a record of what actually happened, in the responder's own words, captured on the device they already had in their pocket.
It's also a person's name. We chose a calm one on purpose. The tools first responders carry should feel like a steady colleague, not another piece of equipment.
To put a private, offline, field-grade reporting tool in the hands of every emergency responder — and to make the resulting records compatible with the standards (NEMSIS, NFIRS, NIMS / ICS, HL7 FHIR) the rest of the healthcare and public-safety system already speaks.
- The responder is the user. Not the agency, not the audit committee. If a feature gets in the way of the next call, it goes.
- Privacy is not a feature. Audio and transcripts never leave the device unless the responder chooses. There is no analytics endpoint to disable, because there is no analytics endpoint.
- Offline is the default. Network outages, dead zones and airplane mode are operating conditions, not edge cases.
- Truth over polish. Capture what was said and observed. Make it easy to correct, easy to sign off, hard to silently rewrite.
- Owned by the people who use it. Records are stored in open, standards-aligned formats (JSON, NEMSIS XML, FHIR). No proprietary container. No migration tax if an agency moves on.
- Standards-aligned. Interoperability is the responder's side of the deal, not the vendor's. Reports plug into the systems that already exist.
The screenshot above is the current report runner on an Android tablet: an EMS Patient Care Report being filled field by field, on the Vitals step. The responder dictated "blood pressure 158 over 96, heart rate 112, sat 94, pain 7 out of 10" and vera parsed it into a structured vitals set — the voice bar echoes what it heard and what it did. The progress bar shows all required fields are done; "Review & handover" generates the MIST and SBAR views. (Updated when the app changes substantially — the rolling set lives in docs/screenshots/.)
Status: Phases 1–3 complete — dictation core, offline PWA, and structured voice-guided EMS Patient Care Reports with MIST/SBAR handover views. See
ProjectPlan.mdfor the full roadmap.
- Works without network. Designed for environments with no reception: tunnels, basements, remote terrain, airplane-mode discipline.
- Privacy by default. Audio and transcripts never leave the device. Everything is stored locally in IndexedDB; optional encryption at rest.
- Built for the field. High-contrast UI, large touch targets, glove-friendly, screen-wake-locked, visible recording state at all times.
- Structured output. Free-form dictation is parsed into schema-driven fields ready for handover or export.
- Streaming on-device speech-to-text (Moonshine Tiny via ONNX Runtime Web)
- Voice Activity Detection (Silero VAD) to gate inference and save battery
- Report templates aligned with US standards — NEMSIS (EMS), NFIRS (fire), NIMS / ICS (incident command), CDC field-triage and START / JumpSTART — with field-by-field voice navigation ("next", "previous"). See
ReportingModel.md. - Free-form parsing (e.g. "blood pressure 120 over 80" →
bp_systolic=120,bp_diastolic=80) - Standard handover views: MIST / ATMIST, SBAR, optional 9-line MEDEVAC
- Domain vocabulary correction (phonetic + edit-distance) for medical and operational terms
- Per-field audio retained alongside text for later verification
- Installable as a PWA (Android / Chrome), works fully offline after first load
- Export to NEMSIS XML, HL7 FHIR R4 bundle, PDF, JSON, plain text, or encrypted ZIP; share via Web Share API or Bluetooth
| Layer | Choice |
|---|---|
| Build | Vite |
| UI | Svelte + Tailwind CSS |
| ASR | Moonshine Tiny (ONNX) via @huggingface/transformers |
| Audio | Web Audio API + AudioWorklet (16 kHz mono PCM) |
| VAD | @ricky0123/vad-web (Silero, WASM) |
| Inference | Web Worker, ONNX Runtime Web (WASM, optional WebGPU) |
| Offline | vite-plugin-pwa (Workbox) |
| Storage | IndexedDB via idb |
| Export | pdf-lib |
- Modern Chromium-based browser (Chrome / Edge ≥ recent stable) on desktop or Android, or Safari ≥ 17 on iOS for the secondary path
- A microphone with permission granted to the site / installed PWA
- ~150 MB free storage for model weights and cached app shell on first run
- Recommended: device with WebGPU support for lower latency (auto-falls back to WASM)
vera is built as a PWA so the same codebase reaches every device — but the platforms have very different capabilities, and the project plan is shaped around them. Long-term goal: run well on any Linux, Android, or iOS device. iOS is treated as a secondary tier today because of platform-level PWA restrictions described below.
| Device | OS / Browser | Role | Notes |
|---|---|---|---|
| Lenovo Tab P12 | Android 13+, Chrome | Field tablet | Large 12.7" screen, MediaTek Dimensity 7050, 8 GB RAM. Generally has WebGPU available; benchmark before relying on it. The reference device for Phase 1 latency targets. |
| Lenovo ThinkPad X12 | Linux (Wayland/X11), Chromium or Firefox | Command-post / write-up | Originally a Windows 2-in-1, re-flashed to Linux for long-term sustainability. Strong x86 hardware → fastest inference target, used for benchmarking and report review. |
| Device | OS / Browser | Notes |
|---|---|---|
| Android phones (varying hardware) | Android 10+, Chrome | Wide spread of SoCs and RAM; WebGPU and even AudioWorklet performance vary. WASM fallback and a smaller model path are required. |
| iPhones (various models) | iOS 17+, Safari | PWA support on iOS is the main constraint — see iOS specifics below. Targeted from iPhone 12 / A14 upward for realistic on-device inference. |
- All mainline Linux distributions on x86-64 and ARM64 with Chromium or Firefox
- Any modern Android device (phone, tablet, foldable) on Chrome / Edge / Samsung Internet
- Any modern iOS / iPadOS device on Safari, within the limits Apple permits
- Performance tier varies by ~5×. ThinkPad X12 (x86 + WebGPU) → Tab P12 (Android + WebGPU) → mid-range Android (WASM SIMD) → iPhone (WASM SIMD, no WebGPU on older iOS). The plan budgets latency and model size per tier and falls back gracefully.
- Two model variants will ship. Moonshine Tiny for capable devices; a smaller / quantised model (or Whisper-tiny INT8) for low-end phones. Selected automatically at first run.
- iOS specifics. Safari PWAs cannot prompt for install (user must use Add to Home Screen), are subject to ~50 MB storage eviction pressure, and have historically restricted background audio. Wake Lock works since 16.4; WebGPU since iOS 26. The plan accommodates these and gates iOS-specific features.
- Microphone & permissions. Android Chrome and Linux Chromium grant persistent mic permission to installed PWAs; iOS Safari re-prompts more aggressively. UX needs to handle re-prompt without losing in-progress reports.
- Hardware diversity on Android phones means runtime detection (RAM, cores, WebGPU adapter info) decides the model variant — there's no single "Android" target.
A full per-platform breakdown — exact API support, fallback strategy, and phase impact — lives in ProjectPlan.md.
# clone
git clone https://github.com/horkah/vera.git
cd vera
# install
npm install
# dev server (LAN-accessible, with COOP/COEP headers for WebGPU)
npm run dev
# production build
npm run build
# serve the production build (recommended for tablet smoke-testing)
npm run previewBoth dev and preview bind to all interfaces, so a tablet on the same LAN can reach the host machine. getUserMedia requires a secure context — use http://localhost on the host, or expose the LAN endpoint over HTTPS (for example via a reverse proxy or a tunnel) for the tablet.
On first launch vera fetches the ASR model from Hugging Face (~tens of MB, one-time) and the service worker precaches the app shell. After that the app runs fully offline — see the Offline readiness panel in the UI for cache status.
- Build and serve:
npm run previewon the development machine. - On the tablet, open the LAN URL in Chrome (HTTPS strongly recommended).
- Tap the microphone, grant permission, speak. The first segment will be slow (model downloading); subsequent segments should hit the <500 ms latency budget.
- Use the Install prompt to add to the home screen.
- Toggle airplane mode and re-launch to verify offline behaviour.
Latency, RTF and lifetime stats are persisted in IndexedDB; they survive reloads and are visible in the Latency panel.
Android (Tab P12, phones) — Chrome
- Open the deployed site in Chrome while online.
- Accept the Install app prompt (or use ⋮ → Install app).
- Launch from the home screen — runs standalone and offline.
- Test airplane mode before relying on it in the field.
Linux (ThinkPad X12 and others) — Chromium / Chrome
- Open the site in Chromium.
- Use the ⊕ icon in the address bar or ⋮ → Install.
- Launches as a standalone desktop window.
iOS (iPhone / iPad) — Safari 17+
- Open the site in Safari (not in another browser — on iOS they all wrap WebKit but only Safari installs PWAs).
- Tap Share → Add to Home Screen.
- Launch from the home screen. Grant microphone permission on first dictation; expect occasional re-prompts.
- Verify offline behaviour and that audio recording survives screen-lock for your iOS version before relying on it.
vera/
├── README.md ← this file — user-facing overview
├── ProjectPlan.md ← development plan, architecture, roadmap, target platforms
├── ReportingModel.md ← data & reporting model (NEMSIS / NFIRS / ICS / FHIR)
└── … ← source to follow
- For the architecture diagram, phase-by-phase roadmap, exit criteria, target-platform details and open technical decisions, see
ProjectPlan.md. - For the report schemas, handover formats (MIST, SBAR, …), triage tags, ICS forms and export targets (NEMSIS XML, FHIR), see
ReportingModel.md. Becomes load-bearing from Phase 3 onward.
- English only at the moment (Moonshine Tiny is English-only). German or other languages would require a fallback model such as Whisper-tiny / base.
- Domain vocabulary must be curated per deployment — out-of-the-box ASR will mis-hear medications, codes and place names until the dictionary is populated.
- iOS is secondary, not primary. Safari PWAs can run vera, but install UX, background audio, storage quota, and haptics are weaker than on Android / Linux. Plan around it; don't rely on it for life-safety reporting until Phase 5 hardening is complete.
- Low-end Android phones may need the smaller model variant and may not hit the <500 ms latency target — they are explicitly a secondary tier.
To be decided. Until a license is added, all rights are reserved by the project owners.