Voice-based nursing & long-term care documentation (Pflegedokumentation)

Nurses and care workers in nursing homes and outpatient care spend a large part of each shift typing documentation, often after the round and often in a language that is not their first. Speech recognition combined with an LLM lets them speak a few sentences at the bedside; the system extracts the structured facts, maps them to the care record and drafts the handover. The care professional reviews and confirms; the benefit is time back for residents and more complete records.

Problem & value

• Today: documentation is entered on a terminal or tablet, or written on paper and transcribed later. Late entries lose detail, entry quality varies, and handovers are assembled by hand. Care staff are scarce and many are non-native German speakers, so typing free text in German is a real barrier.
• AI value: speaking is faster than typing at the point of care, entries are made while the observation is fresh, the AI maps free speech to the structured fields the software and the quality system expect, and handover reports are generated from the day's entries.
• Evidence (vendor-reported, treat with care): voize reports a US$50M Series A (led by Balderton Capital, announced Nov 2025) and use in about 1,100 care facilities in Germany and Austria (as of Nov 2025), with integrations into care software such as Vivendi PD and Medifox DAN [1][2]. Time-saving figures differ by vendor and study; measure your own baseline rather than relying on marketing numbers.
• Regulatory context: in Germany the simplified documentation approach (SIS, Strukturmodell) was introduced to cut bureaucracy: documentation focuses on the individual risk assessment, deviations from the routine and care plan changes rather than every routine action [3].

Variants

• Inpatient long-term care (stationäre Langzeitpflege): dictation into the resident record, Barthel/Braden and fall/pain/wound assessments, handover per shift. Early adopters include large church-affiliated providers (the catalogue's research cites Evangelische Heimstiftung and BruderhausDiakonie; verify current status with the vendor).
• Outpatient care (ambulante Pflege): dictation after each visit, offline-capable because of poor mobile coverage, linked to tour planning and billing evidence.
• Hospital nursing and rehabilitation: nursing notes in the hospital information system; overlaps with HLTH-003 and HLTH-011 but with short commands instead of a doctor-patient dialogue.
• Private use: family care diaries: simple voice-to-note apps suffice.

How it works

1. smartphone app (push-to-talk, on-device VAD, offline buffer)
2. ASR (care vocabulary, dialect / accent robust, multilingual)
3. resident identification (selected in app or by name / room; never guessed silently)
4. LLM / classifier extraction into care schema (vitals, pain, wound, fall, intake, mood, measure done)
5. rule checks (value ranges, unit plausibility, contradictions with care plan)
6. score suggestions (Barthel, Braden, pain scales) from structured facts
7. review screen: nurse confirms / corrects, audio source linked
8. write-back via interface (HL7 FHIR / vendor API) + audit log
9. handover draft per shift from confirmed entries

• ASR is tuned for German care terms (drug names, wound vocabulary, abbreviations); a custom vocabulary matters more than raw model size. Offline operation requires an on-device or edge model or a store-and-forward queue.
• Structuring is a schema-constrained extraction: the LLM may only fill known fields and must leave fields empty if the speaker did not say them. Values like blood pressure are validated by rules.
• Human-in-the-loop: every entry is confirmed by the care professional, who remains legally responsible for the record. Score suggestions (Barthel, Braden) are proposals, not assessments; the assessing nurse decides.

Data preparation

Little classic training data is needed; the effort lies in the context the system must know. Resident master data, care plans, SIS fields and measure catalogues live in the care software (Vivendi, Medifox Dan, CGM); medication lists often in a separate pharmacy system; handover notes partly on paper or in free-text fields.

Typical gaps: inconsistent measure catalogues, outdated care plans, abbreviations and dialect terms that ASR misrecognises, missing audio from noisy wards, and unclear access rights per ward.

Preparation steps: 1. Clean the care-plan and measure catalogues in the care software and agree on one set of terms. 2. Build a facility glossary of abbreviations, drug names and local expressions (PREP-015) and use it as ASR vocabulary. 3. Collect 50-100 real (consented, pseudonymised) sample dictations with the correct target entries as a test set (PREP-018, PREP-022). 4. Verify the interface and role-based access per resident group, and define which data may leave the building (PREP-024).

Tools: the care software's own export or API, Whisper for transcription tests, a spreadsheet for the test set. Expect roughly 15-25 percent of the total effort in data preparation; the larger share goes into training, change management and integration. See also GUIDE-003 and PREP-025 for the legal-basis check.

Implementation paths

Which path for whom

• smb: A - mature EU-hosted products such as voize exist with interfaces to the common care systems, and care documentation is a standard process.
• enterprise: C - large providers have high volumes and very sensitive resident data, so a self-hosted Whisper-class ASR plus a small LLM can pay off, ideally on a shared internal platform.
• developer: C - open ASR and small LLMs on HW2 allow building and testing a care-specific pipeline without sending health data to third parties.

Path A — Buy (recommended)

• voize (DE/EU, Berlin): voice-to-structured-documentation app with interfaces to Vivendi, Medifox DAN and other care systems [1][2].
• Care-software vendors' own voice modules: Medifox Dan, CGM, Connext Vivendi and similar vendors add or partner for speech input; check the current roadmap of the system you already run.
• Choose A when: you already run a mainstream care system with a supported interface and want results within weeks. Check EU hosting, data processing agreement, offline mode, audit trail.

Path B — Build on cloud APIs

• ASR: EU-region speech services (Azure Speech in EU regions, Google Cloud Speech, AWS Transcribe in Frankfurt) or EU providers such as Mistral (Voxtral) and Speechmatics (UK); test on real accented care speech.
• Structuring LLM: frontier or EU models (Mistral, Claude or GPT/Gemini via EU endpoints) with JSON-schema outputs.
• Integration: most care software has no open API; expect partner programmes, FHIR where available (ISiK profiles in hospitals), or RPA as a last resort.
• Choose B when: you are a software vendor or large provider with developers and a special workflow, not a single home.

Path C — Self-host (open source)

• ASR: OpenAI Whisper large-v3 / turbo variants (faster-whisper, whisper.cpp), NVIDIA Canary/Parakeet, fine-tuned German models; whisper.cpp or sherpa-onnx run on the phone for offline use.
• LLM: Mistral Small, Qwen3 or Llama-class models of 8-30B via vLLM or Ollama for extraction.
• Hardware: HW2 handles the ASR and a mid-size extraction model for a mid-size provider; edge devices (HW1) suffice for on-device ASR only.
• Effort: meaningful MLOps and evaluation work; the interface to the care system is usually the hard part.

Path D — Custom training

Fine-tuning ASR on in-house, consented recordings of accented and dialect care speech and care vocabulary reduces word error rate where generic models fail. Needs transcribed audio, staff consent and a works council agreement.

State of the art (2026)

• Modern ASR (Whisper-class, Voxtral, Canary) handles standard German well; dialects, noise from care environments, overlapping speakers and non-native accents remain the main error sources.
• LLM structuring from short utterances is reliable for common fields; weak spots are resident mix-ups, unit and number errors, negations ("no pain"), medication names and invented details.
• Limits: no autonomous assessment; the system should never create clinical content that the speaker did not state. Quality checks need a regular sample review against audio.

Shared resources & combinations

• Same stack (asr + llm-general + guardrails): SPEECH-005 professional dictation, HLTH-003 ambient documentation, HLTH-030 message triage; one ASR server can serve all.
• Downstream: HLTH-011 discharge and transfer letters from the care record, HLTH-018 chart summarisation, HLTH-015 fall detection events feeding into the fall protocol.

Effort, cost & KPIs

• Path A: weeks, per-user or per-facility subscription; effort mainly onboarding, interface set-up and staff training.
• Path B: 3-6 months for a product with care-system integration.
• Path C: 4-9 months incl. evaluation; GPU server plus ops.
• KPIs: documentation minutes per shift, share of entries made at the point of care, completeness of mandatory fields, ASR word error rate on own audio, correction rate on review, handover duration, staff satisfaction, MDK/Medicinal Service audit findings.

People & change

Involve management and the nursing director (department-lead) first for scope and budget; bring IT, the data protection officer and the works council in before the pilot starts, not after. The DPO is needed for resident health data (special category, Art. 9 GDPR): a DPIA (Art. 35) is likely, plus a processing agreement (Art. 28) with every vendor (GUIDE-005).

Works council: yes in practice. Voice notes, timestamps and per-person usage logs make the system objectively suited to monitor behaviour or performance, so §87(1) no. 6 BetrVG applies (BAG: suitability suffices); §90(1) no. 3 requires early information about AI-planned work processes, and §80(3) allows an expert. In church-run or public facilities the staff council or MAV rules apply. Conclude a works agreement that excludes performance evaluation of individuals (GUIDE-004).

AI literacy: support staff's competence with short hands-on sessions (Art. 4 AI Act) covering what the system can misunderstand and how to correct entries (GUIDE-006). Start with one volunteer ward and champions per shift, and address concerns openly: fear of surveillance, of extra work through corrections, and of speaking German with an accent. Every entry stays a draft until the nurse confirms it; the person remains responsible for the record (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: typically minimal or limited risk for documentation support (AI literacy duty, Art. 4). If the software makes diagnostic or prognostic claims (e.g. automatic pressure-ulcer risk scores or deterioration alerts) it may qualify as a medical device under MDR and thus be high-risk under Art. 6 / Annex I: check the intended purpose stated by the vendor. Emotion recognition of employees in the workplace is prohibited (Art. 5(1)(f)): do not analyse staff voices for stress or mood [4].
• GDPR: health data of residents (Art. 9) and voice data of staff; processing agreement, DPIA likely required, EU hosting, deletion of audio after confirmation, no use of resident data for vendor model training without a legal basis. Church providers apply KDG/DSG-EKD in place of GDPR [5].
• Sector rules: SGB XI documentation duties and quality audits, SIS/Strukturmodell, professional duty of confidentiality (§203 StGB) for third-party service providers, works council co-determination (§87 BetrVG) for performance-related monitoring.
• Risks and mitigations: wrong resident (confirm the name on screen), hallucinated values (rules and mandatory review), automation bias (sampling audits), audio in public areas (headset, discretion).

Getting started

1. Measure the baseline: documentation minutes per shift, backlog, handover duration in two pilot wards.
2. Check which care software you run and whether the vendor offers a voice partner or interface.
3. Run a 4-8 week pilot with 10-20 staff including non-native speakers; record error types.
4. Agree DPIA, works council agreement and rules on audio storage before go-live.
5. Review a weekly sample of entries against the audio and tune the vocabulary and rules.

Sources

1. Startbase — voize secures US$50M Series A — https://www.startbase.de/news/voize-sichert-50-mio-us-dollar-series-a/
2. Deutsche Startups — voize interview (Nov 2025) — https://www.deutsche-startups.de/2025/11/25/unser-erfolg-ist-nicht-lange-unbemerkt-geblieben/
3. Ein-STEP — Entbürokratisierung der Pflegedokumentation (SIS) — https://www.ein-step.de/
4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
6. whisper.cpp — https://github.com/ggml-org/whisper.cpp
7. faster-whisper — https://github.com/SYSTRAN/faster-whisper
8. Health Capital Berlin-Brandenburg — Berlin's voize raises $50M for nursing AI (18 Nov 2025) — https://www.healthcapital.de/news/artikel/berlins-voize-raises-50m-for-nursing-ai