Pre-filling mandatory structured documentation in practices (DMP, ePA)

German practices must produce structured documentation that is largely a re-keying of what already sits in the chart: electronic DMP documentation per enrolled patient and, since 1 October 2025, uploads to the "ePA für alle". AI can read the chart, propose the DMP fields, flag what is due, choose the right documents for the ePA and respect patient objections. It cannot, however, run the upload itself: documentation, signature and transmission happen inside the certified PVS and the telematics infrastructure (TI). This is therefore partly feasible today: pre-filling works, but it only pays off where the PVS vendor opens an interface or ships the feature itself.

Problem & value

• Today: for every DMP patient the practice documents indication-specific data sets (initial and follow-up documentation) in the PVS, fixes implausible records returned by the data centre, and watches deadlines per quarter. For the ePA, staff must pick the right documents, check for objections and restrictions, and upload them from the PVS. Many fields are copied from findings that are already in the chart.
• AI value: proposes field values with a pointer to the source entry, lists patients whose documentation is due, catches missing mandatory fields before the plausibility check, and pre-selects ePA documents that meet the obligation. The shadow-gap analysis behind this entry estimates roughly 6 h (DMP) and 4 h (ePA) per practice per period; this is an estimate from a catalogue analysis, not a measured value.
• What is mandatory (verified, Nov 2026): the practice must upload, unless the patient objects, findings reports from its own measures, its own imaging data, lab reports and eArztbriefe from the current treatment. DMP data are, according to KBV, added only on patient request, not as a mandatory item; the medication plan and drug-safety data are being added gradually [1]. The BÄK lists the planned digital medication process (dgMP) for pilot in Q3 2026 and production in Q1 2027 [2].
• Law in motion: the Bundestag passed a law on 6 Nov 2025 (Gesetz zur Befugniserweiterung und Entbürokratisierung in der Pflege) that lets physicians skip uploading for significant therapeutic reasons, significant third-party rights or indications of child endangerment (under 15), with reasons recorded in the chart; The Bundesrat concluded on 19 Dec 2025 and entry into force was 1 Jan 2026 according to Barmer (single secondary source). The under-15 limit comes from the draft bill; KBV describes the rule more broadly in places. Check the statute text before building rules on it [3].
• Evidence: no robust published study on LLM pre-filling of DMP forms or ePA selection was found. Savings in this file are a plausible range, not a measured result; measure them in your own pilot.

Variants

• DMP documentation pre-fill (main case): initial and follow-up documentation per indication (e.g. diabetes, COPD, asthma, CHD, heart failure), including due-date monitoring per quarter.
• ePA upload assistant: selection and checking of documents against the filling obligation, objection and restriction; relevance hint (no suspected or provisional diagnoses, no personal working notes, per KBV guidance [1]).
• Patient-facing explanation: draft plain-language text for what has been uploaded and what the patient may restrict. Patient-side explainers for reports are in PERS-014.
• Specialist and MVZ variants: same logic with other data sets; MVZ and larger practices benefit most from recall lists.
• Private use: not applicable; this is a professional, regulated documentation duty.

How it works

1. trigger (patient visit closed / quarter recall / new document in PVS)
2. read chart (structured PVS fields + free-text notes + lab and findings PDFs)
3. map to target schema (DMP data set of the indication | ePA document types)
4. propose values with source pointer (LLM extraction, only from existing chart entries)
5. rule checks (KBV plausibility rules, mandatory fields, objection/restriction flags, relevance rules)
6. physician or trained staff review (confirm / correct, nothing is sent unreviewed)
7. PVS-certified step: sign, send DMP data set to data centre | upload to ePA via TI
8. log (what was proposed, what was changed, what was sent)

• Key AI parts: a small or general LLM extracts values from free text into the fixed schema; deterministic rules, not the model, decide plausibility, objection handling and what may be uploaded. Where the PVS already holds a value as a structured field, copy it; do not regenerate it.
• Human-in-the-loop: the physician is responsible for the content of a DMP documentation and for what goes into the ePA. The last step (signature, send, upload) stays in the certified PVS.
• Why not UI automation: computer-use agents (AGENT-003) can click through a PVS but are fragile there and sit on top of the TI; a PVS-integrated assistant is the sound design.

Data preparation

Which data: structured PVS data (diagnoses with ICD-10 coding, lab values, medication, enrolment status), free-text notes, scanned findings, the current DMP data set definitions and KBV plausibility rules per indication, and the practice's objection and restriction records.

Where it lives: the PVS (e.g. CGM, medatixx, Doctolib, tomedo, T2med), scanner folders, lab and findings PDFs, and the data-centre feedback mails for rejected DMP records.

Typical gaps: information only in free text, lab values stored as PDF instead of structured, inconsistent coding, enrolment data not up to date, DMP documentation done retroactively at quarter end, no record of who may see what in the ePA.

Preparation steps: 1. Inventory which DMP indications the practice runs and which fields are most often corrected after plausibility checks. 2. Build a test set of 50-100 past documentations with the final, accepted values (PREP-018). 3. Check with the PVS vendor which interfaces exist (BDT/GDT, FHIR, vendor API) and whether an AI module is on the roadmap (PREP-005). 4. Clean up diagnosis coding and structured lab values where cheap (PREP-020). 5. Write down the objection and restriction rules the practice applies to the ePA.

Rough share of effort: about 30 percent of the project; the larger part is the integration into the PVS, not the AI model. See GUIDE-003.

Implementation paths

Which path for whom

• SMB (Arztpraxis, MVZ) - Path A: a practice cannot build a TI-certified integration; the only realistic route is the AI module of the PVS vendor or a vendor that is a certified partner.
• Developer - Path C: PVS-vendor and tool builders can prototype extraction and rule checks on open-weight models with synthetic or de-identified data before they integrate.

Path A - Buy (recommended for practices)

• PVS-native: large PVS vendors (CGM, medatixx, Doctolib's PVS, tomedo, T2med and others) are adding AI assistants, mostly for consultation notes and letters. Doctolib presented its practice software with a telephone and a consultation assistant in November 2025 [4]. I found no verified vendor product that specifically pre-fills DMP data sets or ePA upload sets; ask each vendor and treat any such claim as unverified until demonstrated.
• Adjacent tools: ambient scribes and letter tools (HLTH-003, HLTH-011) already write the chart that feeds DMP fields.
• Choose A when: your PVS vendor offers it or has a documented interface; otherwise wait or use the adjacent tools.
• GP associations call for market-open PVS interfaces for AI tools [5]; this is the bottleneck.

Path B - Build on cloud APIs

• Only sensible for a PVS vendor or integrator with a DPA and EU processing: an EU-region LLM endpoint extracts proposals; the PVS keeps the rules and the send step. A single practice should not build this.
• Needs a DPIA, processor agreement, secrecy duties (§203 StGB) and no training on inputs.

Path C - Self-host (open source)

• Open-weight LLMs (e.g. Qwen, Llama, Gemma, Mistral families) served with vLLM or Ollama on HW2; schema-constrained JSON output; Docling or PaddleOCR for scanned findings; rule engine in plain code.
• Keeps health data in the practice or the vendor's data centre; the effort lies in the PVS integration.

Path D - Custom training

Not needed at first. Fine-tuning pays off only for a vendor with thousands of accepted DMP documentations per indication; reviewer corrections are the natural training data, and consent or de-identification is required.

State of the art (2026)

• Extracting values from German clinical free text into a fixed schema works well with current LLMs when the schema is simple. Ambiguity, negation, dates and old versus current values remain error sources.
• Public evidence specific to DMP or ePA pre-filling is thin; I could not find a peer-reviewed evaluation. Treat vendor time claims (such as Doctolib's "about an hour a day" for its AI functions in general) as marketing until measured [4].
• The ePA is still being built out: current uploads are PDF/A files, and structured data (medication plan, drug-safety data) are added gradually [1][2]. Structured medical information objects (MIOs) and the dgMP will change what pre-filling means from 2027.
• Limits: the certified send step cannot be automated by third parties without the vendor; the legal duties are still being adjusted [3].

Shared resources & combinations

Which use cases to combine for the most effect at once: this one is small alone, but it hits the same chart as the practice's other documentation. - Strongest combination (one data pipe, several wins): HLTH-003 (ambient scribe) writes the chart; HLTH-038 turns that chart into DMP fields and ePA sets; HLTH-011 turns it into letters. All three share the same speech and LLM stack and the same PVS interface, so the integration work is paid once. - Chart access layer: HLTH-018 (chart summarisation and search) and HLTH-028 (terminology mapping and FHIR) provide the structured read path that this use case needs. - Front desk: CONV-002 (phone agent) and HLTH-030 (patient messages) reduce the interrupts that cause late documentation. - Billing: HLTH-005 (coding and billing) uses the same diagnosis coding. - Document intake: DOC-008 sorts incoming findings, which are then candidates for the ePA set. - Patient side: PERS-014 explains uploaded reports to the patient. - Not a good fit: AGENT-003 as the send mechanism (fragile, see above). - Shared hardware: one HW2 server can serve the extraction needs of several of these in a vendor or MVZ setting.

Effort, cost & KPIs

• Path A: weeks if the PVS vendor offers it (licence per practice or per user); otherwise not available.
• Path B/C (vendor or integrator): 6-12 months including PVS certification, DPIA and clinical validation; high integration effort, hence failure_risk high.
• KPIs: minutes per DMP documentation, share of DMP records returned by the data centre, overdue documentations at quarter end, share of fields accepted unchanged, ePA documents uploaded per eligible case, wrongly uploaded documents (target zero).

People & change

Involve early: the practice owner (decision), the medical practice assistants (MFA/VERAH) who do most DMP and ePA work, the PVS vendor and IT service provider, the DPO, and the secrecy duty officer in larger setups.

Works council: no for typical single practices (no works council); in MVZs or hospital outpatient clinics with a council it depends, because a log of who confirms what is suited to monitor staff under §87(1) no. 6 BetrVG (GUIDE-004).

Data protection: health data under Art. 9 GDPR; DPIA, processor agreement and a clear rule that the vendor does not use data for training. Document the review process in the practice's quality management.

AI literacy: Art. 4 AI Act applies; train staff on typical misreads, on outdated values and on not over-trusting a pre-filled field.

Communication and pilot: start with one indication (e.g. type 2 diabetes) and one or two staff members; run parallel to the manual process for a quarter; the physician stays responsible.

Risks, regulation & compliance

• EU AI Act: depends. A tool that only copies and proposes documentation fields is administrative and usually not high-risk; if it proposes diagnoses or therapy decisions it can be a medical device (MDR Rule 11) and then high-risk under Art. 6(1) and Annex I. Check the vendor's intended purpose [6].
• Law and TI: §347 SGB V (filling obligation of the ePA), §137f SGB V / DMP-Anforderungen-Richtlinie (G-BA; these also govern enrolment and data-processing consent; §295a SGB V instead concerns billing of selective contracts and is not the DMP consent rule) and the DMP contracts of the KV regions define what must be documented; DMP data sets and plausibility rules are set by KBV and change with the quarter [1]. Sanctions for missing TI components exist and have been suspended and extended repeatedly; check the current status with your KV [2].
• Medical secrecy and GDPR: §203 StGB, Art. 9 GDPR, patient objection and restriction rights; stigmatising data (e.g. mental health, STI) need patient information before upload [2].
• Risks and mitigations: wrong value pre-filled (source pointer plus mandatory confirmation), upload of data against a patient's objection (rule check before the send step, not model judgement), automation bias (show a diff against the chart, sample audits), vendor lock-in (high: the PVS owns the integration).

Getting started

1. Ask your PVS vendor in writing what AI or pre-fill functions for DMP and ePA exist or are planned, and what interface third parties may use.
2. Measure the baseline: minutes per DMP documentation, share of returned records, ePA handling time.
3. Use an adjacent tool (scribe, letter tool) first to improve the chart quality that DMP fields are taken from.
4. Pilot one indication with a retrospective test: compare proposals to final accepted values.
5. Re-check the legal status (ePA filling obligation, dgMP timeline) before each rollout step.

Sources

1. KBV PraxisNachrichten, "Welche Dokumente stellen Praxen in die ePA ein?" (2025) - https://www.kbv.de/praxis/tools-und-services/praxisnachrichten/2025/07-31/neue-serie-alles-nur-eine-frage-welche-dokumente-stellen-praxen-in-die-epa-ein
2. Bundesärztekammer, Elektronische Patientenakte (ePA) - https://www.bundesaerztekammer.de/aerzte/digitalisierung-in-der-gesundheitsversorgung/elektronische-patientenakte-epa/
3. KBV PraxisNachrichten, "Praxen sollen mehr Freiraum beim Einstellen von Dokumenten in die ePA erhalten" (Sept 2025; Bundestag passage reported by KBV on 6 Nov 2025, praxisnachrichten/2025/11-06) - https://www.kbv.de/praxis/tools-und-services/praxisnachrichten/2025/09-11/praxen-sollen-mehr-freiraum-beim-einstellen-von-dokumenten-in-die-epa-erhalten-kbv-begrue%C3%9Ft-geplante-gesetzliche-regelung
4. heise online, "Doctolib launches practice software with AI support" (4 Nov 2025) - https://www.heise.de/en/news/Doctolib-launches-practice-software-with-AI-support-11039664.html
5. Deutsches Ärzteblatt, Hausärzteverband position paper on AI in GP practices (July 2024) - https://www.aerzteblatt.de/themen/hausarzt/hausaerzte-versprechen-sich-entlastung-durch-kuenstliche-intelligenz-903c844a-830d-4a27-9b7f-3fa59c6c7d74
6. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj