Seventeen questions, grouped by who can answer them. Most already have a recommendation from us — in those cases we need a yes or a different answer, not a discussion.
The field mapping is complete. All 34 fields across the five blocks — Sendungsebene, Rechnungskopf, Versichertendaten, Kostenträger/Arzt and Positionsdaten — have a confirmed source in Maptara. No new custom fields are required; the data already exists on the patient, the doctor, the prescription document and the invoice lines.
The transport is understood: SFTP to edx.azh.de, directory to_azh/, Begleitdatei plus zipped Datendatei and PDFs, UTF-8, returns via *EPO/*AVO/*NVD/*DIFF files. The XSDs and worked examples have been validated against our data model.
We are not blocked on any of the questions below. They determine scope and correctness, not whether work can begin.
We need the edx.azh.de account created and the SSH key exchange arranged. Test access was offered in the ticket description and again in the note of 4 August 2026, and has not yet been taken up on our side.
Why it matters: azhDirekt has no separate test environment. Without the account we can build and validate the submission locally, but we cannot confirm that azh accepts what we produce until we are pointed at a real endpoint. Every day this waits is a day the first real submission moves later.
Given there is no test environment, how do we validate a first submission without it being treated as a live claim? Options we can think of: a test Kundennummer, a flagged submission, or an agreed window in which NOVENTI checks and discards what we send.
Why it matters: the alternative is that our first ever §302 submission is also our first real one. For a billing interface that is an uncomfortable place to be, for both sides.
Sondererfassung1 = Maptara invoice number confirmThe Datenmapping proposes passing the Maptara invoice number (account.move.name) in Sondererfassung1, and notes that formal confirmation from NOVENTI is still outstanding.
Why it matters: one field, trivial to change now, but it is the identifier we would use to reconcile a rejection back to an invoice. If the field has format constraints — length, permitted characters — we need them before the first submission rather than after.
The Datenmapping lists this as open: which Leistungserbringergruppenschlüssel are valid for each Kostenträger.
Why it matters: LEGS is carried on every position line. We can build and test the mechanism without the list, but real submissions will be rejected if the wrong key is sent.
The specification describes four return file types: *EPO.xml, *AVO.xml, *NVD.xml and *DIFF.xml. We would like to know which of these are always produced for a submission, which are conditional, and what the expected turnaround is.
Why it matters: it determines how often Maptara should check for responses, and how long a submission stays in "submitted" before we treat silence as a problem worth surfacing to a user.
EinlieferungsArt — paper only, or digital documents as well? changes scopeThe interface supports paper submission (value 2) and digital document submission (values 1 and 3). The Datenmapping lists this as undecided.
Why it matters: this is the single largest scope question on the list. Paper-only means we transmit structured data and the prescriptions travel physically. Digital means every submission also carries the scanned prescription and supporting PDFs, which brings in document selection, file size handling and the packaging of those documents into the submission.
The interface permits a maximum of 3 000 Verordnungen per Datendatei. How many invoices do you expect in a typical submission — tens, hundreds, or thousands? And how often would you submit: daily, weekly, monthly?
Why it matters: it tells us whether file splitting is an everyday occurrence that needs to be visible and manageable in the interface, or a safety limit nobody will ever reach.
All open §302 invoices at once, or explicit selection by the user?
Why it matters: it determines whether the user reviews what is about to be sent, or trusts a filter.
The Datenmapping proposes a manual button rather than automatic submission on invoice posting, which we agree with. Where should it live — in the action menu on a filtered invoice list, on the invoice itself, or in a dedicated §302 view?
The Datenmapping states that the VerordnungsId is printed as a Code 39 barcode onto the paper prescription (Muster 16), from Maptara. We need to know whether that printing already happens today and we are adding a barcode to an existing document, or whether the prescription printing itself is new work.
Why it matters: this is the one item in the specification that was not visible in any earlier planning, and the answer changes what it involves considerably.
The ECE test plan includes two processes where the Kostenträger starts the conversation: Direktauftrag (the payer creates a delivery order) and Versorgungsanfrage (the payer asks whether we can supply, and requests a cost estimate). Today Maptara only sends and then polls for an answer.
Why it matters: supporting these means Maptara retrieves work that no user initiated, and we need to know what it becomes when it arrives — an order, a case, or something new. That is a business question rather than a technical one, and we would rather ask it than assume.
The §302 specification (§2.1) places both routes in Release 1. The azh route is fully specified and in progress. The direct route — EDIFACT ESOL/AUF per Technische Anlage 1 versions 21 and 22, certificate-based encryption, DAVASO validation, Dakota transmission, KOTR payer files — is a separate body of work with its own prerequisites, none of which are yet in hand.
The specification itself (§4.2, §6.2) states that existing Odoo modules remain leading for pricing, contracts, supplies and approvals, and that the §302 module works from an immutable snapshot of them. We will implement exactly that: the existing claim, batch and provider models are extended; the workflow, field concepts and state names from the specification are adopted; the generated module serves as reference material.
The direct route cannot be built abstractly. It needs a real Datenannahmestelle, the TA1 test procedure, DAVASO access and payer certificates.
Named twice in the requirements (picking list for paper logistics; accelerated billing) and nowhere in the specification.
Accelerated billing at Pierenkemper, and whether to implement the full §302 parameter set or only the net-price logic. The second decides whether a parameter engine exists at all.
The specification (§22.2) makes "fix order → reserve invoice numbers → post in sequence → transfer to e-billing" the leading process. That is an accounting workflow touching invoice numbering and posting order, not an interface one.
| # | Question | Consequence of no answer |
|---|---|---|
| 1 | SFTP account | We can build and validate locally, but nothing is ever confirmed against azh. Outstanding since 4 August. |
| 6 | EinlieferungsArt — paper or digital | The largest scope variable on the list. We will proceed on paper-only unless told otherwise. |
| 10 | Prescription printing | Determines whether the barcode is a small addition or a new document. Currently unknown to us. |
Where we have made a recommendation above, we will build to it unless told otherwise, and we will keep those choices easy to reverse. Nothing on this list prevents work starting — but questions 1, 6 and 10 will change either the timeline or the scope, so the earlier they are answered the less rework they cause.
Prepared by the Maptara development team. Sources: Maptara_azh_Datenmapping_§302 Schnittstelle neu; Schnittstellenbeschreibung azhDirekt HiMi V2.4; Schnittstellenbeschreibung azhIndex HiMi V1.0; ticket CR #1197 and the ECE test plan under CR #1173.