The corpus
Annexbase runs on a requirements corpus, not on hard-coded rules. This page is that corpus: what we read, when we read it, how far each reading can be relied on, and every change we have made since. If you are deciding whether to trust the output, this is the thing to audit.
How we separate the law from our reading
Requirement text is quoted verbatim from the Official Journal. Everything Annexbase adds on top — how a requirement is evidenced, which artefacts satisfy it, which deadline binds — is our reading, and is tagged so you can see where our judgement starts and the law stops.
- Confirmed
- The evidence route follows directly from the text, or from an explicit Commission or D8.2 statement. Safe to build against.
- Provisional
- A reasonable reading, but the detail depends on the Article 36 common specifications, which are due by 26 March 2027 and not yet adopted. Expect this mapping to move.
- Contested
- Competent readers disagree, or the instrument contradicts itself. We state the tension rather than resolve it silently; take advice before relying on either reading.
Sources
- Regulation (EU) 2025/327 (European Health Data Space)OJ L, 2025/327, 5.3.2025 · retrieved 2026-08-26 · primary — verbatim source for all requirement texthttp://data.europa.eu/eli/reg/2025/327/oj
- Xt-EHR D8.2, EHR Conformity Assessment Scheme — Assertion Document and ChecklistsRef. Ares(2026)5060558, 19 May 2026 · retrieved 2026-08-26 · indicative — a Joint Action recommendation feeding comitology, not binding on the Commissionhttps://www.xt-ehr.eu/wp-content/uploads/2026/05/Xt-EHR-D8.2.pdf
- European Commission EHDS FAQ, v1.126 March 2026 · retrieved 2026-08-26 · interpretive — Commission's own reading, not law
What we already know will move
- Art 36 common specifications adopteddue 2027-03-26
Large. Every provisional mapping becomes testable against a normative specification, and conformity with the common specifications carries a presumption of conformity under Art 36(4). Expect the assertion split between automatable and manual to move.
The date is fixed by the Regulation; whether the Commission meets it is not.
- Art 49(4) delegated act on registration datano date
Moderate. Fixes the field list for EU database registration, which today Annexbase can only approximate.
No published timetable.
- Commission uniform template for Annex III technical documentationno date
Moderate. Recital 36 says the Commission should prepare one. Our generator follows Annex III point by point, so adoption is a restructure, not a rewrite.
Recital only — no obligation and no date.
- Art 15 EEHRxF specificationsno date
Large for sections 2.1 and 2.2. Fixes the normative exchange format that the HL7 Europe implementation guides currently stand in for.
Implementing acts foreseen; no published date.
Change history
Separated what the Regulation says from what Annexbase infers. Requirement text is now marked verbatim; every evidence mapping carries a confidence tag and the reasoning behind it, so you can see where our judgement begins.
- added ehds-annex-ii — Provenance block: sources with retrieval dates and verification status, plus a three-point confidence scale (confirmed, provisional, contested).
- added all — textStatus, mappingConfidence and mappingBasis on every requirement. Five mappings are confirmed, eight provisional pending the Art 36 common specifications, one contested.
- flagged AII-1.4 — Marked contested: the Annex II chapeau applies the requirements mutatis mutandis to medical devices, IVDs, AI systems and wellness applications claiming interoperability, while Art 27 cross-references only Section 2 of Annex II. Recital 42 supports the narrow reading. If you ship alongside a medical device, design to the whole Annex until this is settled.
- noted AII-3.2 — Confirmed rather than provisional: the logging format is fixed inside the Annex itself — Art 2(2)(o) defines the European logging software component by reference to the format in Annex II point 3.2 — so this mapping is stable ahead of the common specifications.
Annex II essential requirements extracted verbatim from the Official Journal, with applicability dimensions for the Art 14 priority categories and the functional roles that gate sections 2 and 3.
- added ehds-annex-ii — 14 essential requirements across three sections, each with an assertion type and expected evidence.
The requirements
Section 1 — General requirements (4)
The harmonised software components of EHR systems shall achieve the performance intended by its manufacturer and shall be designed and manufactured in such a way that, during normal conditions of use, they are suitable for their intended purpose and their use does not put at risk patient safety.
Our reading: Performance against intended purpose and patient-safety risk are evidenced by documentation, not by a wire test. D8.2 places assurance that the harmonised components do not impair intended functionality or patient safety among its manually verified checklist items.
Expected evidence: Stated intended purpose · Performance evaluation record (also required by Annex III point 2) · Patient safety risk assessment
The harmonised software components of EHR systems shall be designed and developed in such a way that the EHR system can be supplied and installed, taking into account the instructions and information provided by the manufacturer, without adversely affecting its characteristics and performance during its intended use.
Our reading: Supply-and-install correctness is shown from installation instructions and deployment documentation. D8.2 treats this class as checklist evidence.
Expected evidence: Installation instructions · Deployment/configuration documentation
The EHR system shall be designed and developed in such a way that its interoperability, safety and security features uphold the rights of natural persons, in line with the intended purpose of the EHR system, as set out in Chapter II.
Our reading: The requirement points back to the Chapter II patient rights. Which product features the Commission will expect to see mapped to which right is not yet specified; our mapping is a considered reading, not a settled list.
Expected evidence: Mapping of Chapter II patient rights to product features · Access, rectification, portability, restriction-of-access and opt-out handling
The harmonised software components of EHR systems intended to be operated together with other products, including medical devices, shall be designed and manufactured in such a way that the interoperability and compatibility are reliable and secure, and personal electronic health data can be shared between the device and the EHR system.
Our reading: Reach is genuinely unsettled: the Annex II chapeau applies these requirements mutatis mutandis to medical devices, IVDs, AI systems and wellness applications claiming interoperability, while Art 27 cross-references only Section 2. Recital 42 supports the narrow reading. A cautious manufacturer designs to the whole Annex.
Expected evidence: List of interoperating products · Integration test records
Section 2 — Requirements for interoperability (6)
An EHR system that is designed to store or intermediate personal electronic health data shall provide an interface enabling access to the personal electronic health data processed by it in the European electronic health record exchange format, by means of the European interoperability software component.
Our reading: Export in the EEHRxF is testable against the HL7 Europe implementation guides today, but the normative format is fixed by the Art 15 EEHRxF specifications and the Art 36 common specifications, neither of which is adopted. Passing here is necessary, not yet sufficient.
Expected evidence: Passing DTE content validation for each declared priority category · CapabilityStatement · Live endpoint responding to the declared transactions
An EHR system that is designed to store or intermediate personal electronic health data shall be able to receive personal electronic health data in the European electronic health record exchange format, by means of the European interoperability software component.
Our reading: Same basis as 2.1, in the import direction. The IG set we validate against is our selection of the best current proxy for the eventual specification.
Expected evidence: Successful ingest of conformant instances · Rejection behaviour on non-conformant instances
An EHR system that is designed to provide access to personal electronic health data shall be able to receive personal electronic health data in the European electronic health record exchange format, by means of the European interoperability software component.
Our reading: Access-side conformance will be declared per profile and role under the D8.2 Producer/Consumer/Exchanger model. That model is a recommendation, not yet law.
Expected evidence: Ingest test records for patient-portal and viewer products
An EHR system that includes a functionality for entering structured personal electronic health data shall enable the entry of data with sufficient granularity to enable the provision of the entered personal electronic health data in the European electronic health record exchange format.
Our reading: Structured entry is part machine-checkable (the resulting instance validates) and part documentary (that the entry path exists and is used). The split will firm up with the common specifications.
Expected evidence: Field-level mapping from data capture UI to EEHRxF elements · Round-trip test: enter via UI, export, validate
The harmonised software components of EHR systems shall not include features that prohibit, restrict or place an undue burden on authorised access, personal electronic health data sharing or use of personal electronic health data for permitted purposes.
Our reading: An information-blocking prohibition is evidenced from commercial terms, rate limits and quota configuration — a documentary review. The prohibition itself is unambiguous in the text.
Expected evidence: Commercial terms review: no export fees, throttles, contractual gates · Rate-limit and quota configuration · Attestation of no information-blocking features
The harmonised software components of EHR systems shall not include features that prohibit, restrict or place an undue burden on authorised exporting of personal electronic health data for the reasons of replacing the EHR system by another product.
Our reading: Export-on-switching is evidenced from a documented bulk export path plus contractual terms. Unambiguous in the text; the artefacts are documentary.
Expected evidence: Documented bulk export path · Export completeness and fidelity test · Contractual terms on switching
Section 3 — Requirements for security and logging (4)
An EHR system designed to be used by health professionals shall provide reliable mechanisms for the identification and authentication of health professionals.
Our reading: Identification and authentication mechanisms are testable, but the assurance level the Commission will require is not yet specified.
Expected evidence: Authentication architecture · Token flow test records
The European logging software component of an EHR system designed to enable access by healthcare providers or other individuals shall provide sufficient logging mechanisms that record at least the following information on every access event or group of events: (a) identification of the healthcare provider or other individuals having accessed the personal electronic health data; (b) identification of the specific natural person or persons having accessed the personal electronic health data; (c) the categories of data accessed; (d) the time and date of access; (e) the origin or origins of data.
Our reading: Uniquely among these, the logging format is fixed inside the Annex itself: Art 2(2)(o) defines the logging component by reference to the format in Annex II point 3.2. That makes the mapping stable ahead of the common specifications.
Expected evidence: Sample log records covering all five mandatory fields · Log schema documentation
The harmonised software components of EHR systems shall include tools or mechanisms to review and analyse the log data, or it shall support the connection and use of external software for the same purposes.
Our reading: Review-and-analysis tooling is partly demonstrable and partly documentary; the expected depth is unspecified.
Expected evidence: Log review UI, or documented export/SIEM integration
The harmonised software components of EHR systems that store personal electronic health data shall support different retention periods and access rights that take into account the origins and categories of electronic health data.
Our reading: Point 3.4 implies a per-category, per-origin policy engine for retention periods and access rights. The engineering shape is clear from the text; the acceptance criteria are not.
Expected evidence: Retention policy matrix by data origin and category · Access control matrix
Known limits
- Common specifications under Art 36 are NOT YET ADOPTED. Implementing acts due by 26 Mar 2027. Every mapping below is provisional until they land.
- Article numbering is inconsistent across secondary sources. Verify against consolidated EUR-Lex before customer-facing use.
- Annex II chapeau applies these requirements mutatis mutandis to medical devices, IVDs, AI systems and wellness applications claiming interoperability. Art 27 cross-references only Section 2 — there is genuine textual tension. Cautious manufacturers should design to the whole Annex.