Patient-side explainer for medical reports, lab results & health records (ePA)

Patients receive findings, lab sheets and discharge letters written for clinicians, often days before they can ask anyone. An explainer reads the person's own documents, translates jargon into plain language, shows which values are outside the reference range, builds a timeline across years and turns open points into questions for the doctor. It informs; it does not diagnose or advise treatment. That line is both the product promise and the regulatory boundary (MDR).

Problem & value

• Today: since the German ePA became available to all statutorily insured people (opt-out model, rollout 2025), patients can see documents, but the content stays technical. People search the web, ask general chatbots or wait for the next appointment. Many consumer chatbots already get health questions from users, so the realistic alternative is not "no AI" but unguided AI [1][2].
• AI value: understandable explanations, better-prepared consultations, a longitudinal view that fragmented records (GP, specialist, hospital) rarely give, and translation for patients with a migration background. Practical access is improving: ePA versions 3.x add a medication plan and push notifications [1].
• Evidence status: published benefit figures for consumer explainers are limited and mostly small studies of reading comprehension; no reliable outcome numbers are quoted here.

Variants

• Lab-result explainer: value, unit, reference range, trend; the best-defined sub-case (e.g. the German service Was hab' ich? turns findings into plain language [3]).
• Discharge-letter explainer: diagnoses, procedures, medication changes, follow-up tasks.
• ePA / EHDS record assistant: works over the whole record via the kassen app or a FHIR interface. The European Health Data Space Regulation (EU) 2025/327 gives citizens electronic access to priority data categories and the right to export and share them, applying in stages over the following years [4].
• Chat-with-your-records products: consumer chatbots that connect medical records (e.g. OpenAI's ChatGPT Health, launched Jan 2026 [2]); excluded from the EEA, Switzerland and the UK at launch and, per press reports, still not available there after the wider US rollout in July 2026; check availability.
• Caregiver mode: a relative managing records of a child or parent (needs a valid authorisation).
• Multilingual mode: summary in the patient's own language with a glossary.
• Related, not covered here: institutional extraction (DOC-007), clinician-side report generation (HLTH-011), pre-visit triage (CONV-010), wearable coaching (PERS-002).

How it works

1. intake (photo/PDF/ePA export/FHIR)
2. OCR + layout parsing (tables, units, reference ranges)
3. structuring (LOINC/ICD codes, values to a personal timeline)
4. deterministic checks (value vs. range, trend, red-flag rules)
5. LLM explanation grounded in the document + curated sources (RAG)
6. safety layer (no diagnosis/dosing advice, urgent-symptom escalation, uncertainty wording)
7. output: plain-language summary, timeline, questions for the doctor

• Extraction: a VLM or document parser reads the sheet; numbers and units are then validated against the structured value, never taken from free generation.
• Grounding: explanations cite the passage of the report and a curated source (e.g. patient information from a medical society or health authority), via retrieval.
• Rules before LLM: range comparison and critical-value flags are plain code. The LLM only phrases.
• Human-in-the-loop: the doctor remains the interpreter. The output always ends with "discuss with your doctor", and critical flags tell the user to seek care now instead of explaining at length.

Data preparation

The data are medical findings, discharge letters, lab values, imaging reports and medication plans. For patients they sit in paper folders, PDFs from doctors' portals, e-mail attachments and increasingly the electronic patient record (ePA). For clinics or insurers they sit in hospital information systems, document archives and portals. Typical gaps are scanned letters of poor quality, handwritten notes, inconsistent lab units and reference ranges, duplicated reports and mixed-up patients.

Preparation steps: - Collect documents per person and chronologically; remove other people's data. - OCR scanned reports (PREP-006) and convert formats such as images or faxes (PREP-007); verify OCR on numbers manually because a misread value changes the meaning. - Normalise lab values and units into a table (PREP-011) and keep the reference ranges printed on the report. - For organisations: define who may see what (PREP-023), classify the data as special-category (PREP-024), check the legal basis (PREP-025) and pseudonymise test data (PREP-022). - Build a small evaluation set of reports with physician-approved explanations (PREP-018).

Effort share is low to medium for individuals and clearly higher for organisations, where access rights, FHIR/HIS interfaces and quality review dominate. Plan at least a third of the project for these tasks. See GUIDE-003.

Implementation paths

Which path for whom

• Private: A. Dedicated explainers and insurer apps with a health-data processing agreement are the safest low-effort route for occasional use.
• Developer: B. Multimodal models in EU regions plus OCR give good results quickly; keep records out of logs and training.
• Enterprise: C. Clinics, insurers and health platforms handle special-category data at volume, so self-hosted or sovereign-cloud models behind their own access control avoid third-party exposure and per-seat cost.

Path A — Buy (recommended for individuals)

• Findings/lab explainers: Was hab' ich? (DE, plain-language translation of reports, EU) [3]; kassen apps and ePA front-ends of the statutory insurers (EU); general assistants (ChatGPT, Claude, Gemini) with documents uploaded manually. Check: EU hosting, no training on health data, deletion, MDR status claims.
• Choose A when: occasional use, no wish to build anything. Prefer providers with a health-data DPA over a generic free chatbot.

Path B — Build on cloud APIs

• Multimodal frontier models (Claude, Gemini, GPT, Mistral) in EU regions for explanation; Azure AI Document Intelligence / Mistral OCR for scans; FHIR access through a compliant gateway.
• Orchestration: structured outputs for lab tables, RAG over curated patient-information sources.
• Practical for health-insurer apps, patient portals and start-ups. Requires a DPA, DPIA and a clear intended-purpose statement (see risks).

Path C — Self-host (open source)

• Local, nothing leaves the device: open-weight models (Qwen3, Gemma 3, Llama, Mistral Small; medical tunings such as MedGemma) via Ollama, llama.cpp or vLLM; Docling or PaddleOCR for parsing; a local vector store (Chroma, Qdrant). Combine with PERS-005.
• Hardware: HW1 for a small model on a laptop (adequate for lab values), HW2 for a 24–32B model with better reasoning over long letters. Operations effort is low for one household, higher for a service.

Path D — Custom training

Only for providers: fine-tune on German/EU clinical phrasing, abbreviations and lay-language pairs, with clinician review. Needs licensed, de-identified record pairs; the safety evaluation is the larger cost.

State of the art (2026)

• Frontier and open-weight models handle lab interpretation and plain-language rewriting well on clean text. Providers have launched dedicated health modes with record connection and extra privacy controls [2].
• Limits and failure modes: hallucinated values or ranges (reference ranges differ per lab, age, sex); missed context such as medication or pregnancy; over-reassurance or alarmism; misreading photos and units; sycophancy when users push for a "diagnosis". Cross-checking against the printed range and the structured value is mandatory.
• Medical-specific models and benchmarks (e.g. HealthBench-style evaluations) show progress but do not prove safety for real patients; the ePA itself has no built-in AI explainer at time of review, and critics expect general assistants to move faster than central platforms [1].
• Security of the ePA infrastructure has been criticised (reported circumvention of protections) [1], so exporting records to a third party needs deliberate consent.

Shared resources & combinations

• Same stack (ocr-docparse + vlm + llm-general + rag): DOC-007 (institution-side extraction), PERS-008 (official letters), LANG-010 (simplification).
• Medical knowledge base shared with KNOW-010; terminology mapping and FHIR with HLTH-028.
• Timeline data connects to PERS-002 (wearables) and PERS-005 (private local assistant on a home server).
• Clinician-side counterpart: HLTH-011; pre-visit triage: CONV-010.

Effort, cost & KPIs

• Path A: minutes; free to a modest subscription.
• Path B: 2–4 months for a product with FHIR integration, safety evaluation and DPIA; costs are dominated by compliance and clinical review, not tokens.
• Path C: a weekend for a private setup; 2–3 months for a service.
• KPIs: factual accuracy of values and ranges against ground truth (target near-complete), clinician-rated safety of explanations, comprehension scores, rate of correct escalation of critical values, user-reported readiness for the visit, deletion and consent audit.

People & change

For individuals, the key person is the treating physician: use the explanation to prepare questions, never to replace advice. Relatives who help should have the patient's consent.

For an enterprise rollout (clinic, insurer, health platform) involve management for the purpose and liability decision, the department lead (medical director or service lead) as process owner, IT and IT security for integration and access, the data protection officer and legal/compliance from the start. A DPIA under Art. 35 GDPR is very likely because health data are special categories processed with new technology; conclude an AVV (Art. 28) with every processor. Check whether the tool counts as a medical device before making diagnostic claims.

Works council: depends. If staff use the assistant and the system logs their activity, §87(1) no. 6 BetrVG applies because objective suitability to monitor is enough; inform the council under §90(1) no. 3 when work processes change, and use §80(3) if an expert is needed. Public hospitals involve the Personalrat. See GUIDE-004.

Measures to support AI literacy (Art. 4 AI Act) should cover limits, hallucinated values and escalation to a physician (GUIDE-006). Start with a small pilot group of clinicians, communicate that humans decide and the tool only explains (GUIDE-008), and log corrections for review.

Risks, regulation & compliance

• EU AI Act: depends on purpose. A pure information tool is typically minimal/limited risk (Art. 4 AI literacy, Art. 50 transparency for chatbots). If marketed for diagnosis, monitoring or treatment decisions it becomes medical-device software and, under Annex I with Reg. (EU) 2017/745 (MDR), a high-risk system [5]. Not a prohibited practice, but emotional-state inference and insurer-side scoring from the same data need separate review.
• MDR boundary: state the intended purpose clearly ("explains, does not diagnose"); features that interpret results to suggest conditions or therapy can make the product a medical device (class IIa or higher under MDR Rule 11).
• GDPR: health data are special-category data (Art. 9). Basis is explicit consent; use data minimisation, EU hosting, no use for training or advertising, deletion, DPIA (Art. 35), processor contract. Patient access rights: Art. 15 GDPR and Germany's SGB V rules for ePA.
• EHDS: Reg. (EU) 2025/327 strengthens access, export and sharing rights, and sets interoperability and secondary-use rules phased in over the following years [4]. Wellness apps claiming interoperability may fall under its labelling provisions.
• Other risks: delayed care through false reassurance; anxiety from unexplained findings; leakage of records to US services; family members or insurers pressuring access. Mitigations: red-flag rules, citations, uncertainty wording, local processing, access log review.

Getting started

1. Pick a recent lab report and test two or three tools; check every value and range by hand.
2. Request your ePA export (via the kassen app) and your data under GDPR Art. 15 to see what exists.
3. Prefer Path C (local) for sensitive records; pair with PERS-005.
4. Keep a one-page timeline of key values and medications and bring generated questions to the visit.
5. If building: write the intended-purpose statement first, then run a DPIA and an MDR qualification check.

Sources

1. Pharmazeutische Zeitung — "ePA im Wettlauf gegen die KI" (2026) — https://www.pharmazeutische-zeitung.de/epa-im-wettlauf-gegen-die-ki-166293/seite/2/
2. OpenAI — ChatGPT Health announcement (2026) — https://openai.com/index/introducing-chatgpt-health/
3. Was hab' ich? — plain-language explanations of medical findings — https://washabich.de
4. Regulation (EU) 2025/327, European Health Data Space — https://eur-lex.europa.eu/eli/reg/2025/327/oj
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
7. gematik — Elektronische Patientenakte (ePA) — https://www.gematik.de/anwendungen/epa
8. Google — MedGemma open models — https://developers.google.com/health-ai-developer-foundations/medgemma