EHDS scope check

Describe what your system does. Annexbase resolves the exact Annex II requirements that apply, your deadline, and the FHIR implementation guides you will be tested against.

Priority data categories (Art 14)
Functional roles (Annex II gating)
9requirements apply
2automatable
1hybrid
6manual evidence
2029-03-26conformity deadline
Save this scope to an account →Free to start. No patient data ever touches Annexbase.

Earliest obligation is driven by: Patient summaries, Electronic prescriptions

Implementation guides in scope: hl7.fhir.eu.eps, hl7.fhir.eu.mpd, hl7.fhir.eu.laboratory

Corpus 0.2.0 · Regulation (EU) 2025/327

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.
AII-1.1 · Annex II 1.1General requirementsmanual

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.

Mapping confirmedwhy this is our reading, not the text

The requirement text above is quoted verbatim from the Official Journal. What Annexbase adds — how you evidence it — is 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.

Evidence: Stated intended purpose · Performance evaluation record (also required by Annex III point 2) · Patient safety risk assessment
Not automatable. Requires a documented risk assessment. Overlaps with ISO 14971 if the vendor already holds it — a strong reuse story for MDR-regulated vendors.
AII-1.2 · Annex II 1.2General requirementsmanual

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.

Mapping confirmedwhy this is our reading, not the text

The requirement text above is quoted verbatim from the Official Journal. What Annexbase adds — how you evidence it — is our reading. Supply-and-install correctness is shown from installation instructions and deployment documentation. D8.2 treats this class as checklist evidence.

Evidence: Installation instructions · Deployment/configuration documentation
AII-1.3 · Annex II 1.3General requirementsmanual

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.

Mapping provisionalwhy this is our reading, not the text

The requirement text above is quoted verbatim from the Official Journal. What Annexbase adds — how you evidence it — is 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.

Evidence: Mapping of Chapter II patient rights to product features · Access, rectification, portability, restriction-of-access and opt-out handling
Chapter II rights: access, rectification, portability, restriction of access, opt-outs. A failure here can constitute a reportable serious incident under Art 2(2)(r)(ii) — 'serious prejudice to a natural person's rights'.
AII-1.4 · Annex II 1.4General requirementsmanual

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.

Reading contestedwhy this is our reading, not the text

The requirement text above is quoted verbatim from the Official Journal. What Annexbase adds — how you evidence it — is 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.

Evidence: List of interoperating products · Integration test records
AII-2.3 · Annex II 2.3Requirements for interoperabilityautomatable

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.

Mapping provisionalwhy this is our reading, not the text

The requirement text above is quoted verbatim from the Official Journal. What Annexbase adds — how you evidence it — is 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.

Evidence: Ingest test records for patient-portal and viewer products
AII-2.5 · Annex II 2.5Requirements for interoperabilitymanual

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.

Mapping confirmedwhy this is our reading, not the text

The requirement text above is quoted verbatim from the Official Journal. What Annexbase adds — how you evidence it — is 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.

Evidence: Commercial terms review: no export fees, throttles, contractual gates · Rate-limit and quota configuration · Attestation of no information-blocking features
ANTI-INFORMATION-BLOCKING. Constrains the vendor's COMMERCIAL MODEL, not just the code. Export fees and degraded-fidelity exports are non-conformant. Expect resistance — this is where vendors discover the regulation costs them revenue.
AII-2.6 · Annex II 2.6Requirements for interoperabilitymanual

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.

Mapping confirmedwhy this is our reading, not the text

The requirement text above is quoted verbatim from the Official Journal. What Annexbase adds — how you evidence it — is our reading. Export-on-switching is evidenced from a documented bulk export path plus contractual terms. Unambiguous in the text; the artefacts are documentary.

Evidence: Documented bulk export path · Export completeness and fidelity test · Contractual terms on switching
ANTI-LOCK-IN. Same commercial-model exposure as 2.5, aimed squarely at switching costs.
AII-3.2 · Annex II 3.2Requirements for security and loggingautomatable

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.

Mapping confirmedwhy this is our reading, not the text

The requirement text above is quoted verbatim from the Official Journal. What Annexbase adds — how you evidence it — is 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.

Evidence: Sample log records covering all five mandatory fields · Log schema documentation
This clause is ALSO the normative definition of the LOG FORMAT — Art 2(2)(o) defines the logging component by reference to 'the format defined in point 3.2 of Annex II'. Five mandatory fields, checkable mechanically. This is the single most automatable requirement in the Annex and the best candidate for the demo.
AII-3.3 · Annex II 3.3Requirements for security and logginghybrid

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.

Mapping provisionalwhy this is our reading, not the text

The requirement text above is quoted verbatim from the Official Journal. What Annexbase adds — how you evidence it — is our reading. Review-and-analysis tooling is partly demonstrable and partly documentary; the expected depth is unspecified.

Evidence: Log review UI, or documented export/SIEM integration