Keep three layers separate
- App draft: possible insured-user journeys for invoice, status, history, consent and sharing.
- DiPag draft: Fachdienst contracts and FHIR profiles, not an app UI standard.
- HCSA: synthetic, local interactive concept without a production DiPag or TI connection.
Modules, FHIR and data ownership
- G-App combines its base profile with profiles for selected application modules. DiPag FdV and manufacturer duties are separate; the push module is optional.
- The G-App PTV names ZETA 2.0.1_CC and Krypt 2.49.1. The inspected mobile-context draft ZETA 2.0.0_CC explains related architecture but does not verify the exact 2.0.1_CC reference. General ZETA 1.3.2 is a separate baseline.
- DiPag user areas explicitly include permanent deletion of an invoice process, the enriched PDF, invoice PDF, EPC/GiroCode and clipboard actions for recipient, IBAN and payment reference.
- DiPag IG 1.0.8 separates RE-PS submission through $invoice-submit from frontend reimbursement submission in the MVP. DocumentReference/$retrieve uses a document token, not DocumentReference.id. RE-PS/insurer systems must not infer personal markers or states from invoice metadata.
- ePA FdV 2.8.0 defines a separate record-access contract with VAU channel, userSession and HealthRecordContext. The generic demo.document ZETA walkthrough is distinct.
Versioned primary sources
What this page explicitly does not claim: The HCSA demonstration is not app conformance or an operational DiPag service. Drafts may change before formal release.