EHDS Conformity Assessment
EHDS conformity assessment is a self-declaration route, not an MDR-style notified body pathway. The deliverable set an EU EHR, medical device or wellness vendor has to produce is fixed: technical documentation, an EU declaration of conformity and an information sheet. The EUR 20 million fine ceiling sits in the secondary-use chapter rather than the conformity chapter, and Article 26(2) defers the real Chapter III deadline to 2031 for SaaS and in-house EHR systems.
34 min read
38 views
Key takeaways: EHDS conformity assessment 6
Why the route is self-declared with no notified body, the Article 26(2) deferral that moves the real Chapter III deadline to 2031 for SaaS and in-house systems, the fixed artefact set and where the EUR 20 million ceiling actually sits.
- Self-declaration route, no notified body Recital 36 names it a mandatory conformity self-assessment scheme and Annex IV puts it under the manufacturer's sole responsibility. The only independent-body test, Article 37(4), is a documentation-failure remedy and not a conformity gate.
- An interoperability claim, not the product, pulls you in Whether EHDS bites at all turns on intended user and purpose, and for medical devices, in vitro diagnostic devices, high-risk AI systems and wellness applications it turns on whether the manufacturer claims interoperability. Our reading of how the definitions interact: the claim, not the product's nature, triggers Articles 27, 47 and 48.
- The Article 26(2) carve-out defers Chapter III to 2031 EHR systems built and used inside a health institution, and any EHR system offered as a service, are deemed put into service, and the fourth paragraph of Article 105 defers the whole of Chapter III for them to 26 March 2031 rather than the staged 2027 to 2029 sequence.
- The deliverable set is fixed and self-authored Article 37 with Annex III technical documentation, an Annex IV declaration of conformity, an Article 38 information sheet and CE marking under Article 41, plus the two mutually independent harmonised software components required by Article 25(1) and Annex II.
- The regulation names no interoperability standard Article 15 defers the European electronic health record exchange format's technical specifications to an implementing act due by 26 March 2027, and HL7, FHIR, IHE and openEHR appear nowhere in the text.
- There is no post-market surveillance system The standing obligations are Article 30(2) continuous compliance tied to the technical documentation, a three-day serious incident clock under Article 44(7) and Article 45 handling where the real sanction is market removal. The Article 64(5) EUR 20 million ceiling sits in the secondary-use chapter and does not attach to EHR conformity.
EHDS conformity assessment is a self-declaration route. Search the full text of Regulation (EU) 2025/327 for "notified body" or "conformity assessment body" and both return zero occurrences. There is no third party sitting between your build and the market, the way there is under the Medical Device Regulation. This page pins down three things: the exact artefact set a manufacturer must produce, the Article 26(2) deferral that pushes the real Chapter III deadline to 2031 for SaaS and in-house EHR systems, and where the EUR 20 million fine ceiling actually sits, in a different chapter than the one that governs EHR conformity. What follows is that deliverable set, for an EHR system or medical device, in vitro diagnostic device, high-risk AI system or wellness application claiming interoperability with one.
The self-assessment scheme in short
Recital 36 names the route itself, "a mandatory conformity self-assessment scheme for EHR systems processing one or more priority categories of electronic health data should be established to overcome market fragmentation while ensuring a proportionate approach". Annex IV requires the declaration itself to state that it is "issued under the sole responsibility of the manufacturer", and CE marking runs through the general product safety framework rather than a device-specific one. The one genuine third party mechanism, an independent body test under Article 37(4), is an enforcement remedy for a manufacturer who fails to produce documentation on request, not a conformity route. The deliverable set is concrete: technical documentation under Article 37 and Annex III, an EU declaration of conformity under Annex IV, an Article 38 information sheet, and two harmonised software components under Annex II. Chapter III is deferred to 26 March 2031 in full for in-house health institution builds and SaaS EHR systems.
Does any of this apply to your product?
Four categories decide what a given product owes EHDS.
An EHR system, defined in Article 2(2)(k), is software, or hardware plus software, that allows personal electronic health data in the priority categories to be stored, intermediated, exported, imported, converted, edited or viewed, intended by the manufacturer for use by healthcare providers providing patient care or by patients accessing their own data. That definition carries the full Chapter III regime: placing on the market or putting into service under Article 26(1), manufacturer duties under Article 30, technical documentation under Article 37, the declaration of conformity under Article 39 and CE marking under Article 41.
General purpose software used in a healthcare setting is different. Article 25(2) excludes it from Chapter III entirely, so a generic database engine does not become an EHR system merely because a hospital runs it.
A medical device, an in vitro diagnostic device under Regulation (EU) 2017/745 or Regulation (EU) 2017/746, or a high-risk AI system under Article 6 of Regulation (EU) 2024/1689 outside MDR and IVDR, is governed by its own regulation first. EHDS reaches it only through Article 27, only on a manufacturer's interoperability claim, and owes only proof of compliance with the Annex II Section 2 essential requirements and the Article 36 common specifications, none of the duties an EHR system owes. Market surveillance stays with MDR, IVDR or the AI Act, and registration under Article 49(3) is a double entry.
A wellness application, defined in Article 2(2)(ab), is software, or hardware plus software, intended by the manufacturer for use by a natural person to process electronic health data for a purpose other than providing healthcare. EHDS reaches it the same way, on an interoperability claim only. Article 47 then requires a manufacturer-issued label stating the data categories for which Annex II compliance is confirmed, the common specifications used and the label's validity period, capped at three years. Article 48 requires informing users of the interoperability and forbids automatic data sharing without the person's consent and a per-category choice.
What actually triggers an EHDS obligation
The rule that ties these together, our reading rather than a procedure the regulation itself states: intended user and purpose decide the base category, and a voluntary interoperability claim decides whether a device, AI system or wellness application is pulled into EHDS obligations at all. The claim, not the product's nature, triggers Articles 27, 47 and 48. Annex II's essential requirements apply mutatis mutandis to any of them once that claim is made, and Article 28 forbids the documentation from ascribing functions the system does not have, failing to disclose interoperability or security limitations, or suggesting uses outside the intended purpose.
Which deadline applies to you
The regulation carries a citation line in EUR-Lex's own metadata reading "OJ L, 2025/327, 5.3.2025, ELI: http://data.europa.eu/eli/reg/2025/327/oj", recording publication in the Official Journal on 5 March 2025. Article 105's first paragraph sets entry into force at the twentieth day following that publication date, without stating a calendar date itself. Counting twenty days from 5 March 2025 gives 25 March 2025 as the entry into force date, a derived figure absent from the regulation's own printed text. This distinction matters: entry into force is 25 March 2025, derived from the 5 March 2025 Official Journal publication date plus the twentieth day, a figure Article 105 itself never states, while the 26 March dates that appear throughout this regulation are application dates, not the entry into force date.
Application dates differ from entry into force and are stated directly in the text. Article 105's second paragraph is unambiguous: "This Regulation shall apply from 26 March 2027". The third paragraph immediately carves several articles out of that general date, and the EHR system core obligations are among them: "Articles 3 to 15, Article 23(2) to (6), Articles 25, 26, 27, 47, 48 and 49 shall apply as follows". Articles 25, 26 and 27, the harmonised components obligation, the placing-on-market obligation and the medical device and AI Act overlap routes, are staged separately from the general 2027 date rather than starting on it.
Chapter III is deferred to 2031 for SaaS and in-house systems
Article 105's fourth paragraph carries the single highest-value date in this whole timeline for a specific slice of the audience, stated in a single sentence sitting between two much longer paragraphs: "Chapter III shall apply to EHR systems put into service in the Union referred to in Article 26(2) from 26 March 2031". Article 26(2) defines that category precisely: "EHR systems that are manufactured and used within health institutions established in the Union, as well as EHR systems offered as a service as defined in Article 1(1), point (b), of Directive (EU) 2015/1535 of the European Parliament and of the Council to a natural or legal person established in the Union, shall be considered as having been put into service". Put simply, an in-house EHR system built and run by a health institution itself, and any EHR system offered as a service, get the whole of Chapter III, technical documentation, the declaration, CE marking, the harmonised components, deferred to 26 March 2031, well past the staged 2027 to 2029 sequence that applies to a shrink-wrapped commercial product. If a vendor ships EHR software as SaaS, or a health institution builds its own system in house, that vendor's or institution's real deadline is 2031, not 2027.
Two legal bases land on the same 2031 date
The carved-out articles apply from "26 March 2029 to priority categories of personal electronic health data referred to in Article 14(1), points (a), (b) and (c), and to EHR systems intended by the manufacturer to process such categories of data", patient summaries, electronic prescriptions and electronic dispensations. A second stage applies from "26 March 2031 to priority categories of personal electronic health data referred to in Article 14(1), points (d), (e) and (f), and to EHR systems intended by the manufacturer to process such categories of data", which are imaging studies and related reports, laboratory and other diagnostic results, and discharge reports. That is the whole of the primary-use 2031 milestone.
A separate, secondary-use 2031 milestone exists alongside this one, and the two rest on different legal bases. Article 105's fifth paragraph governs Chapter IV, secondary use, and states: "Chapter IV shall apply from 26 March 2029. However, Article 55(6), Article 70, Article 73(5), Article 75(1) and (12), Article 77(4) and Article 78(6) shall apply from 26 March 2027; Article 51(1), points (b), (f), (g), (m) and (p), shall apply from 26 March 2031; and Article 75(5) shall apply from 26 March 2035". Article 51(1)(f) covers "human genetic, epigenomic and genomic data", and Article 51(1)(m) covers "data from clinical trials, clinical studies, clinical investigations and performance studies subject to Regulation (EU) No 536/2014, Regulation (EU) 2024/1938 of the European Parliament and of the Council, Regulation (EU) 2017/745 and Regulation (EU) 2017/746". Genetic data and clinical trial data reach 2031 through this secondary-use paragraph, not through the primary-use Article 14 categories. Both halves land on the same calendar date and neither is wrong, but they are two different legal bases and should not be written as one milestone. None of the dates covered above, or anywhere else in the regulation, falls in 2026: the string 2026 occurs zero times in the regulation's own text. The regulation also uses no certification vocabulary for this route at all, using self-assessment, EU declaration of conformity and CE marking instead.
One codebase shipped two ways
Putting into service is defined, in Article 2(2)(l), as the first use, for its intended purpose, in the Union of an EHR system covered by the regulation. Placing on the market is not defined by this regulation. Article 2(2)(d) imports it, with making available on the market and the market surveillance vocabulary, from Regulation (EU) 2019/1020. Regulation (EC) No 765/2008 contributes only the CE marking principles, via Article 2(2)(p) and Article 41(3).
Article 26(2) then deems two things put into service: EHR systems manufactured and used within health institutions established in the Union, and EHR systems offered as a service to a person established in the Union.
Take the ordinary case of a vendor shipping one codebase two ways, as a licensed product a customer installs and as a hosted service. The licensed form is placed on the market. The hosted form is deemed put into service under Article 26(2).
Article 105 attaches different dates to those two routes. The third paragraph stages the placed-on-market form at 26 March 2029 or 26 March 2031, depending on the priority data categories the system processes. The fourth paragraph defers Chapter III for the Article 26(2) route to 26 March 2031 regardless of category. Article 26(1) gates both routes identically on Chapter III compliance, with no variant carve-out. Annex III item 1(e) requires the technical documentation to describe all forms in which the system is placed on the market or put into service, so both forms sit inside one documentation package rather than two.
A full-text search of the operative text of Article 105 and Chapter III finds nothing that resolves a product falling under two application dates at once: there is no whichever-is-earlier rule, no most-stringent-applies rule and no dual-form provision.
Our reading, and this is our reading, not the regulation's own statement: because both forms sit in a single Annex III documentation package and a single EU declaration of conformity covers the harmonised software components, the earlier date effectively governs the documentation work. The regulation does not say this, and a vendor relying on the later date for the hosted form should take advice before doing so.
Self-declaration, not an MDR-style pathway
No external body is named anywhere in this chain, though an engineer coming from medical device work will instinctively look for one: a notified body, a CE certificate, an identification number attached to it. Article 39(5) puts the weight on the manufacturer directly instead: "By drawing up the EU declaration of conformity, the manufacturer shall assume responsibility for the compliance of the harmonised software components of the EHR system with the requirements laid down in this Regulation when it is placed on the market or put into service". Article 39(1) is equally direct about who does the demonstrating: the EU declaration of conformity "shall state that the manufacturer of an EHR system has demonstrated that the essential requirements laid down in Annex II have been fulfilled".
CE marking follows the same logic here as everywhere else in the regulation. Article 41(3) states that "The CE marking of conformity shall be subject to the general principles set out in Article 30 of Regulation (EC) No 765/2008", the accreditation and market surveillance framework that underpins general product safety CE marking across the EU, rather than the device-specific route in Regulation (EU) 2017/745. No identification number gets affixed alongside the mark either, per Article 41(1): "The CE marking of conformity shall be affixed visibly, legibly and indelibly to the accompanying documents of the EHR system and, where applicable, to the packaging of the EHR system". Article 42(1) closes the door on national conformity assessment layering on top: "Member States may adopt national requirements for EHR systems and provisions on their conformity assessment in relation to aspects other than the harmonised software components of EHR systems", so the harmonised components themselves stay closed to national addition.
Recital 36 also states plainly that "Manufacturers should use those digital testing environments to test their products before placing them on the market while continuing to bear full responsibility for the compliance of their products", which is why this self-declaration structure is built into the regulation by design. Responsibility does not transfer to the testing environment any more than it transfers to a notified body, because there is no notified body to transfer it to.
The one genuine third party route: a documentation-failure remedy
There is exactly one place in the regulation where an independent body touches an EHR system, and it is worth stating precisely so nobody mistakes it for the conformity route itself. Article 37(4) says that where a manufacturer fails to supply requested technical documentation, "the market surveillance authority may require it to have a test performed by an independent body at its own expense within a specified period in order to verify the conformity with the essential requirements laid down in Annex II and the common specifications referred to in Article 36". That is triggered by a documentation failure a market surveillance authority has already found, it costs the manufacturer money, and it happens after the fact. Most products never trigger it at all.
The two harmonised software components
Article 25(1) sets the frame for the whole of Chapter III: "EHR systems shall include a European interoperability software component for EHR systems and a European logging software component for EHR systems (the 'harmonised software components of EHR systems'), in accordance with the provisions laid down in this Chapter". Article 2(2) defines each one and, in both definitions, requires the other to stay architecturally separate. The interoperability component is "a software component of the EHR system which provides and receives personal electronic health data under a priority category for primary use established under this Regulation in the European electronic health record exchange format provided for in this Regulation and which is independent of the European logging software component for EHR systems". The logging component is "a software component of the EHR system which provides logging information related to access by health professionals or other individuals to priority categories of personal electronic health data established under this Regulation, in the format defined in point 3.2. of Annex II thereto, and which is independent of the European interoperability software component for EHR systems". Article 30(1), point (b) turns that independence into a manufacturer obligation directly, requiring the manufacturer to "ensure that the harmonised software components of their EHR systems are not adversely affected by other software components of the same EHR system". Nothing about that is optional: the isolation is a legal requirement, not a best-practice suggestion.
The logging component's semantics are precise about what it captures. Annex II point 3.2 requires it to "provide sufficient logging mechanisms that record at least the following information on every access event or group of events", and the five mandated fields are: "identification of the healthcare provider or other individuals having accessed the personal electronic health data", "identification of the specific natural person or persons having accessed the personal electronic health data", "the categories of data accessed", "the time and date of access" and "the origin or origins of data". In plain terms, who accessed which record, when and from where, on every access event or event group.
Logs are not write-only
Annex II point 3.3 adds a second deliverable: "The harmonised software components of an EHR system 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". Producing the log records satisfies half the requirement. A review and analysis capability, built in or connectable, is a separate line item.
The anti-lock-in requirement
Annex II point 2.6 is a specific, engineering-relevant clause: "The harmonised software components of an EHR system 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". Data export cannot be made deliberately harder for the specific purpose of discouraging a customer from switching vendors. This binds the export path itself, beyond just the sales contract around it.
What the interoperability component has to speak
Article 15 requires the Commission to lay down, by implementing act and by 26 March 2027, the technical specifications setting out the European electronic health record exchange format. The format has to be commonly used, machine-readable, capable of transmitting data between different software applications, devices and healthcare providers, and able to support both structured and unstructured health data. It must cover harmonised datasets defining structures for clinical content, the coding systems and values used in those datasets, and technical interoperability specifications for exchange, including content representation, standards and profiles. Article 15(2) provides for regular updates as coding systems and nomenclatures are revised, Article 15(3) allows the format to extend to further data categories, and Article 15(4) requires Member States to ensure priority categories are issued in the format, with a receiving provider able to accept and read it. Article 36 requires the common specifications to take account of state-of-the-art health informatics standards and this exchange format.
The finding that matters for build planning: the regulation names no standard. HL7, FHIR, IHE, openEHR, SNOMED, LOINC and DICOM each occur zero times in its text. The binding technical content arrives in an implementing act that is not yet in force, so no team can build to a named profile from the regulation alone. Readers who need the HL7 and FHIR vocabulary the regulation itself does not use can find it in our EHR integration guide.
The deliverable set
Everything above is the framing. What an engineering team actually has to produce before an EHR system reaches the market is a fixed set of artefacts, and Article 45 treats a gap in any one of them as non-compliance on the same footing as a product defect: "the technical documentation is not available, not complete or not in accordance with Article 37" sits alongside the product itself not meeting the essential requirements as a listed finding of non-compliance. A working product with an incomplete documentation package is a non-compliant product.
The technical documentation package
Article 37(1) sets the baseline obligation: "Manufacturers shall draw up technical documentation before the EHR system is placed on the market or put into service, and shall keep that documentation up to date". The minimum contents are fixed too, with a link to the testing work: Article 37(2) provides that documentation "shall contain, as a minimum, the elements set out in Annex III and a reference to the results obtained from a European digital testing environment referred to in Article 40". Article 37(3) adds a translation obligation: on a reasoned request from a Member State's market surveillance authority, the manufacturer must supply the relevant parts translated into that Member State's language. And Article 37(4) sets a hard clock: on request, the manufacturer must produce the documentation or a translation of it "within 30 days of the date of the request, unless a shorter deadline is justified because of a serious and immediate risk".
Annex III sets the actual contents, introduced as a floor: "The technical documentation referred to in Article 37 shall contain at least the following information, as applicable to the harmonised software components of an EHR system in the relevant EHR system". Point 1 opens with "A detailed description of the EHR system including", then runs ten sub-items:
- Intended purpose plus the date and version of the EHR system.
- The categories of personal electronic health data the system was designed to process, the field that ties a given product to whichever staged application date applies to it.
- How the system interacts, or can be used to interact, with hardware or software outside itself.
- Versions of relevant software or firmware and any version update requirements.
- A description of every form in which the system is placed on the market or put into service.
- A description of the hardware the system is intended to run on.
- A description of the system architecture, and here Annex III is explicit about the artefact: "a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing, including, where appropriate, labelled pictorial representations (e.g. diagrams and drawings), clearly indicating key parts or software components and including sufficient explanation to understand the drawings and diagrams". Labelled architecture diagrams are a named, mandatory item under Annex III.
- Technical specifications, including a detailed description of data structures, storage and input and output of data.
- A lifecycle change log: "a description of any change made to the system throughout its lifecycle". This is the item that pairs with Article 30(2) below, which forces every design change back into this same documentation.
- Instructions for use and, where applicable, installation instructions.
Four further points close Annex III. Point 2 asks for a description of the system in place to evaluate performance, where applicable. References to any common specification used under Article 36 in relation to which conformity is declared are required by point 3. Point 4 is the testing evidence, and the language is stronger than a bare pass or fail: "The results and critical analyses of all verifications and validation tests undertaken to demonstrate conformity of the EHR system with the requirements laid down in Chapter III, in particular the applicable essential requirements". A raw test log without analysis does not satisfy this on its own. Points 5 and 6 are simply a copy of the Article 38 information sheet and a copy of the EU declaration of conformity, folded into the same package.
Annex III mapped to the evidence that satisfies it
The table below is our proposed structure for satisfying Annex III with concrete engineering evidence. It is not a form the regulation itself prescribes.
| Annex III requirement | What satisfies it | Where it comes from |
|---|---|---|
| 1(a) and 1(b), a detailed description of the system and its intended purpose | A written system description plus an intended-purpose statement naming the categories of data and the intended user | Product requirements and design documentation |
| 1(c), how the system interacts or can be used to interact with hardware or software outside itself | An interface inventory listing every external system, API and integration point | Architecture and integration documentation, API specifications |
| 1(d), versions of relevant software or firmware and any version update requirement | A signed release manifest listing component versions and stating any mandatory update cadence | Release tooling and version control tags |
| 1(e), a description of all forms in which the system is placed on the market or put into service | A distribution matrix listing every packaged form the product ships as, such as a licensed install, a hosted service and an OEM bundle. This is the row a dual-shipping vendor cannot leave vague; see the dual shipping section below | Release and distribution tooling, product packaging records |
| 1(f), a description of the hardware the system is intended to run on | A supported-hardware specification listing minimum and recommended host configurations | Infrastructure and deployment documentation |
| 1(g), a description of the system architecture, with labelled pictorial representations such as diagrams and drawings | An exported architecture diagram with labelled components, sufficient on its own to be understood without the surrounding text | Design documentation and the architecture repository |
| 1(h), technical specifications, including a detailed description of data structures, storage and input and output of data | A technical specification document covering features, dimensions and performance attributes, plus a detailed description of data structures, storage and input and output of data | Product specification documentation and data architecture records |
| 1(i), a description of any change made to the system throughout its lifecycle | A lifecycle changelog tying each change back to the affected documentation | Engineering changelog and design documentation |
| 1(j), instructions for use and, where applicable, installation instructions | User-facing instructions for use and, where applicable, installation instructions | Product documentation and installation guides |
| 2, a description of the system in place to evaluate EHR system performance, where applicable | A description of the performance evaluation methodology or system used, where applicable | QA and performance monitoring documentation |
| 3, references to any common specification used under Article 36 in relation to which conformity is declared | A reference list naming each Article 36 common specification the declaration relies on | Compliance documentation and the declaration of conformity |
| 4, the results and critical analyses of all verification and validation tests, plus the Article 40 digital testing environment result | A test report that includes analysis rather than a raw log, plus the recorded result from the digital testing environment | QA reporting, CI output and the digital testing environment record |
| 5, a copy of the Article 38 information sheet | The information sheet itself, exported as a document | Product documentation or the EU registration database export |
| 6, a copy of the EU declaration of conformity | The EU declaration of conformity itself, included as a copy | The declaration of conformity document |
The EU declaration of conformity
Article 39(3) points the declaration's contents at Annex IV, and Annex IV requires "all of the following information", eight items, a stricter word than the "at least" used for the technical documentation. In order, the declaration must state: the name of the system, its version and any additional unambiguous identifying reference; the manufacturer's name and address; the sole-responsibility statement quoted above; a statement of conformity with Chapter III "complemented by the result from the testing environment mentioned in Article 40", meaning the same testing result has to appear here and in the technical documentation, not just one place; references to any harmonised standards used; references to any common specifications used; and the place and date of issue. That last item matters because it makes self-assessment a named, accountable act rather than an anonymous checkbox: "Place and date of issue of the declaration, signature plus name and function of the person who signed and, if applicable, an indication of the person on whose behalf it was signed". A named human being, with a stated job title, signs this document. Annex IV point 8 leaves room for additional information where applicable.
Article 39(4) adds a retention rule where the declaration is issued digitally: it "shall be made accessible online for the expected lifetime of the EHR system and, in any event, for at least 10 years from the placing on the market or the putting into service of the EHR system". Article 39(2) also handles the case where an EHR system is covered by another EU legal act that requires its own declaration of conformity: rather than two documents, "a single EU declaration of conformity shall be drawn up in respect of all Union legal acts applicable to the EHR system". That merges the paperwork, it does not merge the underlying assessment work behind it. Article 39(6) promises a Commission-published standard template for the declaration, in a digital format and in all official Union languages. The regulation leaves the template itself to future Commission action rather than specifying its contents directly.
The Article 38 information sheet
An EHR system must be accompanied by an information sheet, with Article 38(1) setting the audience and the standard: it must contain "concise, complete, correct and clear information that is relevant, accessible and comprehensible to professional users", professional users specifically, not patients. Article 38(2) specifies five fields: the manufacturer's identity and contact details; the system's name, version and release date; its intended purpose; the categories of electronic health data it was designed to process, a field textually distinct from the similar Annex III item because this one drops the word "personal"; and, most engineering-legible of the five, "the standards, formats and specifications supported by the EHR system and versions of those standards, formats and specifications", a versioned interoperability declaration attached to the product itself. Article 38(3) offers an alternative to shipping a physical or digital document: a manufacturer may instead enter the same information into the EU database for registration of EHR systems and wellness applications under Article 49.
Testing: the digital testing environment
Article 40(1) puts the Commission in charge of building the testing infrastructure: "The Commission shall develop a European digital testing environment for the assessment of harmonised software components of EHR systems. The Commission shall make the software supporting the European digital testing environment available as open-source". Article 40(2) adds a second, parallel tier: Member States themselves "shall operate digital testing environments for the assessment of harmonised software components of EHR systems", each complying with the same common specifications and each reported to the Commission.
Article 40(3) is the mechanism that sits exactly where a notified body assessment would sit under the Medical Device Regulation, except run by the manufacturer itself: "Before placing EHR systems on the market, manufacturers shall use the digital testing environments referred to in paragraphs 1 and 2 of this Article for the assessment of harmonised software components of EHR systems. The results of that assessment shall be included in the technical documentation referred to in Article 37. The elements in relation to which the results of the assessment are positive shall be presumed to be in conformity with this Regulation". A positive result here carries a legal presumption of conformity, because the manufacturer both runs the test and records the result. No external body signs off on it.
What does not exist yet
Several pieces referenced above are deferred to implementing acts that the regulation itself does not specify. Article 40(4) leaves the actual technical content of the digital testing environment open: "The Commission shall, by means of implementing acts, lay down the common specifications for the European digital testing environment". The real identification and authentication mechanism is deferred the same way, under Article 16(2): "The Commission shall, by means of implementing acts, determine the requirements for the interoperable, cross-border identification and authentication mechanism for natural persons and health professionals, in accordance with Regulation (EU) No 910/2014". Article 36(1) lists identification management common specifications as one of the subjects still to be covered by future common specifications. And Article 39(6) promises the Commission's uniform declaration template. The regulation defers these implementing acts and the template to future Commission action and does not itself specify their content.
The identification and authentication gap
This gap is sharpest for identification and authentication. Annex II point 3.1 is the entire essential requirement on the subject, one sentence: "An EHR system designed to be used by health professionals shall provide reliable mechanisms for the identification and authentication of health professionals". No standard, no assurance level and no protocol is named. The concrete bar that does exist, an eIDAS reference, sits in Article 12 and binds Member States, not manufacturers, for health professional access services specifically: those services "shall be accessible only to health professionals who are in possession of electronic identification means which are recognised pursuant to Article 6 of Regulation (EU) No 910/2014 or other electronic identification means compliant with common specifications referred to in Article 36 of this Regulation". Until the Article 16(2) and Article 36(1) common specifications materialise, a manufacturer's actual identification and authentication obligation is that one-sentence requirement of reliable mechanisms, nothing more specific.
The standing obligations, not post-market surveillance
A search of the regulation's full text for "post-market" or "postmarket" returns zero occurrences. There is no post-market surveillance plan, no periodic safety update report and no post-market clinical follow-up requirement of the kind that exists under the Medical Device Regulation. What exists instead is a set of standing obligations spread across Article 30, and Article 30(2) is the sentence that carries the most weight for engineering teams: "Manufacturers of EHR systems shall ensure that procedures are in place to ensure that the design, development and deployment of the harmonised software components of an EHR system continue to comply with the essential requirements laid down in Annex II and the common specifications referred to in Article 36. Changes in EHR system design or characteristics with regard to the harmonised software components of an EHR system shall be adequately taken into account and reflected in the technical documentation". Design, development and deployment are named together, the phrase is "continue to comply", and every design change has to feed back into the same technical documentation package. The obligation runs continuously alongside the codebase, rather than closing at a one-time release gate.
Article 30(1) lists fifteen specific manufacturer duties, and several of them are concrete engineering or support process commitments rather than paperwork. Where the manufacturer has reason to believe a system is no longer in conformity, it must "take without undue delay any necessary corrective action" and notify national authorities of the non-conformity together with the corrective action taken, including the remediation timetable. The trigger for that duty is subjective and low, "consider or have reason to believe", and the notification has to carry an actual timetable, an engineering commitment rather than a legal formality. The manufacturer must also "establish channels of complaint and keep distributors informed thereof" and "keep a register of complaints and a register of non-conforming EHR systems", two separate registers. Contact details, including a single point of contact, must sit inside the product itself in a language users and market surveillance authorities can understand, an in-product UI requirement rather than only a paperwork one. And where the system carries any mandatory preventive maintenance, its frequency has to be disclosed to distributors and, where applicable, users.
Article 30(3) sets the retention window for both the technical documentation and the declaration of conformity: ten years after the system covered by the declaration was placed on the market. The same paragraph carries a disclosure duty: "Manufacturers of EHR systems shall make available the source code or the programming logic included in the technical documentation, upon a reasoned request, to the relevant authorities, if that source code or programming logic is necessary in order for those authorities to be able to check compliance with the essential requirements laid down in Annex II". The disclosure obligation stays conditional, tied to whatever source code the technical documentation already includes. It is no blanket source code escrow requirement on its own.
The three-day incident clock
The regulation's closest thing to a vigilance obligation, Article 44(7), runs on a three-day clock. Manufacturers must report any serious incident to the relevant market surveillance authorities, and Article 44(7) second subparagraph fixes the deadline: reporting must happen "immediately after the manufacturer has established a causal link between the EHR system and the serious incident or the reasonable likelihood of such a link and, in any event, not later than three days after the manufacturer becomes aware of the serious incident involving the EHR system". Three days, running from awareness, not from confirmed causation. The same paragraph notes this reporting sits alongside Directive (EU) 2022/2555, NIS2, incident notification rather than replacing it, so the two clocks stack for a vendor already covered by NIS2.
Article 2(2) defines "serious incident" broadly enough to include near misses: a malfunction or deterioration that "directly or indirectly leads, might have led or might lead to" the death of or serious harm to a natural person, serious prejudice to a natural person's rights, or serious disruption of critical health sector infrastructure. "Might have led or might lead" means a near miss counts on its own terms.
The real sanction is market removal
Article 45 is titled "Handling of non-compliance" and it is the enforcement route that actually reaches a vendor. Where a market surveillance authority finds non-compliance, whether the system itself fails Annex II, the technical documentation is incomplete, the declaration of conformity was not drawn up correctly, the CE marking was affixed wrongly or not affixed, or registration under Article 49 is missing, it requires corrective action by a specific deadline. Where that correction does not happen, Article 45(2) states the consequence plainly: "the market surveillance authorities shall take all appropriate provisional measures to prohibit or restrict the EHR system from being made available on the market of their Member States, or to recall or withdraw the EHR system from that market". For a vendor, the real commercial consequence of failed conformity is losing market access, not a fine of any particular size.
Where the EUR 20 million ceiling actually sits
Separately, the EUR 20 million or 4 percent of worldwide turnover fine ceiling sits inside Chapter IV, Secondary Use, not the conformity assessment chapter, and it does not attach to conformity failure. It comes from Article 64(5), which sets fines for "infringements shall be subject to administrative fines of a maximum of EUR 20 000 000 or, in the case of an undertaking, of a maximum of 4 % of its total worldwide annual turnover in the preceding financial year, whichever is higher". That tier attaches to a listed set of infringements, among them a health data user processing data obtained under a data permit for one of the uses Article 54 prohibits. Article 64(4) sets a separate, lower tier in the same chapter, EUR 10 000 000 or 2 percent of worldwide turnover, for infringements of the health data holder or health data user duties set out in Article 60 and Article 61(1), (5) and (6). Neither tier reaches an EHR system failing conformity. A vendor placing a non-conforming EHR system on the market is instead handled under Article 45, whose real consequence is market removal, and Article 99 leaves the actual figure to national law: "Member States shall lay down the rules on penalties applicable to infringements of this Regulation, in particular for infringements which are not subject to administrative fines pursuant to Articles 63 and 64, and shall take all measures necessary to ensure that they are implemented. The penalties provided for shall be effective, proportionate and dissuasive", a sentence that names no figure at all.
What to do next, by vendor archetype
The dates and duties above split cleanly along one line: which of these five archetypes describes your product. Placing a system on the market, having a system deemed put into service, and merely claiming interoperability with somebody else's harmonised software components are three different relationships to the regulation, and each carries its own date and its own duty list.
If you place an EHR system on the market or put one into service
- A commercial vendor licensing an EHR system that customers install is placing it on the market. Chapter III applies in full, staged at 26 March 2029 or 26 March 2031 by priority data category. Full obligations follow: Article 30 duties, Article 37 and Annex III documentation, the Annex IV declaration, the Article 38 sheet and Article 41 CE marking.
- A vendor offering the same EHR system as a hosted service sits under a different provision. Article 26(2) deems that put into service rather than placed on the market, so the fourth paragraph of Article 105 defers all of Chapter III to 26 March 2031. The obligations match the first archetype's, only the date differs.
- A health institution building and using its own EHR system in house follows the same Article 26(2) route to the same 2031 date. An in-house team carries manufacturer obligations too, a point that is easy to overlook when nothing is being sold to anyone.
If you only claim interoperability
- A medical device, in vitro diagnostic device or high-risk AI system maker claiming interoperability with the harmonised software components enters through a narrower door. Article 27 is the only route in, and it owes proof of compliance with the Annex II Section 2 essential requirements and the Article 36 common specifications, not the full EHR regime above. Market surveillance stays with the MDR, IVDR or AI Act authority, and Article 49(3) requires registration in both databases. No interoperability claim means EHDS never reaches the product.
- A wellness application claiming interoperability answers to Article 47 and Article 48 instead. Article 47 requires a manufacturer-issued label naming the confirmed data categories, the common specifications used and a validity period capped at three years. Article 48 requires informing users of the interoperability and forbids automatic data sharing without consent and a per-category choice.
Work that applies either way
One block of work applies no matter which archetype fits:
- Assemble the Annex III package now, using the mapping table earlier on this page as the working structure.
- Run the two harmonised software components through a digital testing environment under Article 40(3) and keep the result, because it has to appear in both the technical documentation and the declaration of conformity.
- Build the Article 30(1) complaint register, the non-conforming-system register and a corrective-action path behind both of them.
- Wire an incident route that can meet the three-day Article 44(7) clock, counted from the moment of awareness rather than from confirmed cause.
- Keep the two harmonised software components architecturally independent from the start, per Article 30(1) point (b), because retrofitting isolation afterward is far harder than designing it in.
- Track the Article 15 implementing act, due by 26 March 2027, since the exchange format's binding technical content arrives there and nowhere else.
This sequencing is our recommendation, not a schedule the regulation itself sets. The regulation fixes dates and obligations here, but it prescribes no order of work.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 8
No matches
Try a different keyword, change the topic or clear filters
-
No. The strings notified body and conformity assessment body occur zero times in Regulation (EU) 2025/327. Recital 36 names the route a mandatory conformity self-assessment scheme.
Article 39(5) puts compliance responsibility on the manufacturer. Annex IV requires the declaration to be issued under the manufacturer's sole responsibility. The one independent-body mechanism, Article 37(4), is a remedy a market surveillance authority may impose at the manufacturer's expense when documentation is not produced, not a conformity route.
-
Putting into service IS defined, Article 2(2)(l): first use for its intended purpose in the Union. Placing on the market is NOT defined by this regulation; Article 2(2)(d) imports it from Regulation (EU) 2019/1020.
Article 26(2) deems in-house health institution systems and EHR systems offered as a service to have been put into service. It matters because the fourth paragraph of Article 105 attaches a different date to that route.
-
Article 2(2)(ab) defines a wellness application as software intended for a natural person, processing electronic health data for purposes other than the provision of healthcare. EHDS reaches it only if the manufacturer claims interoperability with the harmonised software components.
Then Article 47 requires a manufacturer-issued label naming the data categories for which Annex II compliance is confirmed, a reference to the common specifications and a validity period capped at three years, and Article 48 requires informing users and forbids automatic sharing without consent and a per-category choice.
-
Article 27 binds MDR and IVDR manufacturers, and high-risk AI providers outside those regulations, only when they claim interoperability with the harmonised software components. What is owed is proof of compliance with the Annex II Section 2 essential requirements and the Article 36 common specifications.
It does not import Article 30 manufacturer duties, Article 37 technical documentation, Article 39 declaration or Article 41 CE marking. Market surveillance stays with the MDR, IVDR or AI Act authority, and Article 49(3) requires registration in both databases.
-
No. The regulation names no standard at all: HL7, FHIR, IHE, openEHR, SNOMED, LOINC and DICOM each occur zero times in its text. Article 15 requires the Commission to set the technical specifications for the European electronic health record exchange format by implementing act by 26 March 2027, covering harmonised datasets, coding systems and interoperability specifications including profiles.
Until that act is in force no team can build to a named profile from the regulation alone.
-
Both. The licensed on-premises form is placed on the market and is staged by the third paragraph of Article 105 at 26 March 2029 or 26 March 2031 by data category.
The hosted form is deemed put into service under Article 26(2), and the fourth paragraph of Article 105 defers Chapter III for it to 26 March 2031. Nothing in the regulation resolves a product sitting under two dates at once. Our reading, not the regulation's, is that the earlier date governs the documentation package, because Annex III item 1(e) requires all forms to be described in one package.
-
No. That ceiling is Article 64(5), and Article 64 sits inside Chapter IV, secondary use. It is imposed by health data access bodies on health data users and health data holders, for infringements such as processing permitted data for uses Article 54 prohibits.
Article 64(4) sets a lower tier, EUR 10 000 000 or 2 percent, for Article 60 and Article 61 duties. A vendor shipping a non-conforming EHR system is handled under Article 45, where the consequence is market removal, with national penalties under Article 99 that name no figure.
-
No. The string 2026 occurs zero times in the regulation's text. The dates that exist are 26 March 2027 for general application, 26 March 2029 and 26 March 2031 staged by priority data category under the third paragraph of Article 105, and 26 March 2031 for the Article 26(2) put-into-service route.
The regulation also uses no certification vocabulary for this route: it uses self-assessment, EU declaration of conformity and CE marking.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
