What does EU MDR market entry ask of software already shipping in the US?

What does the EU ask for that a US launch never did?

It asks for a file that is complete on one particular day, and the day is the one on which the product goes on the market. Chapter II of Regulation (EU) 2017/745 is headed "Making available on the market and putting into service of devices, obligations of economic operators, reprocessing, CE marking, free movement", and the duties inside it are keyed to that act. Under Article 5(2) a device "shall meet the general safety and performance requirements set out in Annex I which apply to it, taking into account its intended purpose", and Article 5(3) adds that showing you have met them "shall include a clinical evaluation" under Article 61. Both bind the product itself. Neither waits on an internal decision about when a version is ready to go.

Two items in the technical documentation of Annex II behave unlike anything a US programme produces, and they are where a translation plan comes apart.

Annex II Section 4 asks for two lists, and a company arriving from the United States usually brings one. Item (a) wants "the general safety and performance requirements that apply to the device and an explanation as to why others do not apply". The applicable half is familiar. The inapplicable half is an argument somebody writes: for each Annex I requirement you are not answering, a stated reason. Items (b), (c) and (d) then want "the method or methods used to demonstrate conformity with each applicable general safety and performance requirement", "the harmonised standards, CS or other solutions applied", and "the precise identity of the controlled documents offering evidence of conformity", each cross-referenced to where the evidence sits in the full file. Annex II opens by requiring the whole set to be "presented in a clear, organised, readily searchable and unambiguous manner", which is a property of a file built to be read by a stranger.

Annex II Section 6.1(b) is the second item. Nowhere else does the MDR describe what software test evidence has to consist of, and its fourth indent does it in one sentence, asking for three things at once: a description of the software design and development process, "the summary results of all verification, validation and testing performed both in-house and in a simulated or actual user environment prior to final release", and coverage of "all of the different hardware configurations and, where applicable, operating systems identified in the information supplied by the manufacturer". Section 6.1(b) then closes with the sentence that removes the option of silence: "Where no new testing has been undertaken, the documentation shall incorporate a rationale for that decision."

That last clause is where market entry stops being a translation exercise, because the information supplied by the manufacturer for Europe is a new document. Annex I Section 23.4(ab) requires the instructions for use to state the "minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended", repeating as an information obligation what GSPR 17.4 already requires the manufacturer to set out. Write that paragraph and you have defined your own coverage matrix, because Section 6.1(b) keys coverage to what the manufacturer's information claims. Write it after the test campaign has run and the two were never compared.

GSPR 17.3 adds a row nobody puts in the estimate. Software "intended to be used in combination with mobile computing platforms" has to be designed and made "taking into account the specific features of the mobile platform (e.g. size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards level of light or noise)". Those two parentheses amount to a bench of physical handsets and a set of stated ambient conditions, and the Regulation names them itself.

Against all of that, GSPR 17.2 is the whole of the MDR's explicit software process obligation, in one sentence. It names the state of the art and three principles, development life cycle, risk management including information security, and verification and validation, and it specifies no method for any of them. What fills the gap, and why the obvious candidate does not fill it in the way most teams assume, comes further down this page.

Which of the two regulations are you entering under?

That question is settled before class, and it is settled by where your data comes from. Regulation (EU) 2017/745 and Regulation (EU) 2017/746 are both dated 5 April 2017 and were published in the same issue of the Official Journal, OJ L 117 of 5 May 2017. A product answers to one of them and not to both.

MDCG 2019-11 Rev.1 sets a three-step test at its section 3.4. Software providing information according to IVDR Article 2(2) points (a) to (f) should qualify as IVD MDSW. If the information provided is based on data obtained solely from in vitro diagnostic medical devices, the software is an in vitro diagnostic medical device. Where the sources are mixed, step three asks whether the intended purpose is "substantially driven by data sources coming from in vitro diagnostic medical devices"; if it is, the applicable legislation is Regulation (EU) 2017/746, and if the intended purpose is substantially driven by data sources coming from medical devices, it is Regulation (EU) 2017/745. MDCG says of itself that the document did not come from the European Commission, that the views in it bind nobody in law, and that interpretations of Union law with binding force come from one court and not from a guidance group. The reviewer across the table has read it anyway.

The answer costs money, because the residual outcome differs between the two regimes. Under the MDR, the closing sentence of Annex VIII Rule 11 puts software reaching no other limb in class I, and Article 52(7) lets a class I manufacturer issue the EU declaration of conformity after drawing up the technical documentation set out in Annexes II and III. No notified body enters, save for the three exceptions that provision names: sterile presentation, a measuring function, and reusable surgical instruments. The IVDR has no such floor at its own bottom end. Annex VIII Rule 6 reads in full, "Devices not covered by the above-mentioned classification rules are classified as class B", and Article 48 sends a class B device to a notified body under Annex IX Chapters I and III, with the Section 4 technical documentation assessment run on "at least one representative device per category of devices". The same leftover position brings in an assessor under one regulation and leaves you to self-declare under the other.

Which qualification and classification test your product faces on the MDR side is worked in full at is my app a medical device; the diagnostic side, its four classes and its seven rules, is at IVDR software validation. Settle that before anything else on this page is scheduled, because it decides which annex numbers the rest of the work answers to.

What happens if you place the product on the market anyway?

The file starts ageing that day, and three obligations begin consuming evidence that was never in the launch budget.

Article 61(11) requires the clinical evaluation and its documentation to be "updated throughout the life cycle of the device concerned with clinical data obtained from the implementation of the manufacturer's PMCF plan" and the post-market surveillance plan under Article 84, and Article 61(12) puts the clinical evaluation report inside the technical documentation. The document you close in order to launch is one you reopen on a schedule.

Annex XIV Part B defines post-market clinical follow-up as "a continuous process that updates the clinical evaluation" and requires it to be performed "pursuant to a documented method laid down in a PMCF plan". Section 6.2 lists eight items that plan must include at least, ending at (h) with "a detailed and adequately justified time schedule for PMCF activities". Section 6.1(e) names an aim that reads like boilerplate until you have shipped into a market you do not know: "identifying possible systematic misuse or off-label use of the device, with a view to verifying that the intended purpose is correct". A first year in a new country is when that aim earns its place.

Article 83(3) sets out eight things the surveillance data has to be used for, running from the benefit-risk determination through to trend detection under Article 88, and its final sentence decides how much of the work lands on engineering: "The technical documentation shall be updated accordingly."

None of this stays inside the company. The distance between the Section 4 conformity table and the evidence actually standing behind it is the first thing an outside technical reviewer measures, and the file assembled for a European entry is the same file an investor's reviewer opens when a round is live. The gap list you build for a notified body is the list somebody else will build about you, which is the argument for owning it first: what such a reviewer looks at, and in what order, is set out at technical due diligence on a healthtech company.

Which parts of your existing file travel, and which do not?

The quality system travels furthest, and the reason is recent enough that many teams have not repriced it. The compliance date for the US Quality Management System Regulation was 2 February 2026, and from that date 21 CFR Part 820 incorporates ISO 13485:2016 by reference together with Clause 3 of ISO 9000:2015. FDA's own position is that those ISO 13485 requirements are, taken in totality, substantially similar to the Part 820 requirements they replaced. Europe reaches the same standard from the other direction: EN ISO 13485:2016, with its AC:2018 corrigendum and its A11:2021 amendment, stands at entry 10 of the harmonised standards Annex published under Commission Implementing Decision (EU) 2021/1182, in the consolidation dated 7 April 2026. One standard now sits behind the quality system on both sides.

What does not travel is a certificate, because there is none to travel with. FDA neither requires nor issues ISO 13485 certificates of conformance, and such a certificate stands between nobody and an FDA inspection. Article 52 routes class IIa devices and everything above them through Chapters I and III of Annex IX, so the European assessment is somebody else's work, done on somebody else's calendar.

The risk file travels next. Entry 16 of the same Annex is EN ISO 14971:2019 together with its A11:2021 amendment, put there by Commission Implementing Decision (EU) 2022/757, adopted on 11 May 2022 and in force from the day the Official Journal carried it, 17 May 2022. Recital (4) of that Decision records what the A11 amendment is: acting on a standardisation request, CEN and Cenelec revised EN ISO 14971:2019 "in order to take into account the latest technical and scientific progress and to adapt them to the requirements of Regulation (EU) 2017/745". The ISO text your risk file already answers is the same text. The European reference is the EN with its A11 amendment, and that is the reference the Annex II Section 4 table names.

The software life cycle standard is the one that does not travel, and the trap is that it once did. Under the superseded Directive 93/42/EEC it was harmonised: Annex I to Commission Implementing Decision (EU) 2020/437 of 24 March 2020 carries entry No 258, "EN 62304:2006 - Medical device software - Software life-cycle processes (IEC 62304:2006)", followed by EN 62304:2006/AC:2008. Even that reference reached the 2006 base standard and a 2008 European corrigendum, never the 2015 amendment or the Edition 1.1 consolidation your team works to today. Under the MDR there is no entry at all. What Article 8(1) confers, why that changes nothing about the obligations themselves, and which column of the Annex II Section 4 table IEC 62304 belongs in instead, is worked through at EU MDR software requirements.

The last item is the one a US team is most likely to reach for and least likely to hold in European shape. Annex XIV Part A Section 3 sets the equivalence criteria in three limbs, technical, biological and clinical, and the technical limb names your subject matter directly: a device is technically equivalent where it "is of similar design; is used under similar conditions of use; has similar specifications and properties including physicochemical properties such as intensity of energy, tensile strength, viscosity, surface characteristics, wavelength and software algorithms; uses similar deployment methods, where relevant; has similar principles of operation and critical performance requirements". The section then requires the characteristics to be similar "to the extent that there would be no clinically significant difference in the safety and clinical performance of the device" and requires that "Considerations of equivalence shall be based on proper scientific justification". Comparison to another product is available in Europe. It is an argument about your algorithm, and somebody has to write it and defend it.

Four parts of a US medical device file, their reference under the EU MDR, and what still has to be produced for the European market.

What you already hold	Its European reference	What still has to be produced
A quality system built to ISO 13485:2016 under the QMSR since 2 February 2026	Entry 10 of the harmonised list, the EN form of the same standard plus AC:2018 and A11:2021	The assessment itself, where Article 52 sends class IIa and above through Annex IX Chapters I and III
A risk management file built to ISO 14971:2019	Entry 16 of the same list, the EN form plus A11:2021	The link from each hazard into the Annex II Section 4 table, item (d)
Software life cycle records built to IEC 62304 Edition 1.1	None under the MDR. EN 62304:2006 with AC:2008 was listed under Directive 93/42/EEC as entry No 258 of Decision (EU) 2020/437	The evidence itself, recorded under item (c) as an other solution applied
A comparison to a similar product	Annex XIV Part A Section 3, whose technical limb names software algorithms	A written scientific justification that no clinically significant difference in safety and clinical performance follows

Only the quality system and the risk file carry a European reference; the software life cycle records and the equivalence comparison do not. The harmonised standards entries were read in the 7 April 2026 consolidation of Decision (EU) 2021/1182.

What do you do first?

Step 5 is where the work stops moving, and the eighth indent of Annex XIV Part A Section 1(a) is why. That indent asks for "a clinical development plan indicating progression from exploratory investigations ... to confirmatory investigations ... and a PMCF as referred to in Part B of this Annex with an indication of milestones and a description of potential acceptance criteria". A plan with milestones is a plan with dates in it, and those dates are what decide whether the quarter written on the roadmap was ever real. Teams postpone step 5 because it is the step that answers the question the board asked, and the answer is often later than the question expected.

What sets the calendar, and which half of it is not yours?

Two things set the scope, and one of them belongs to you.

The one that belongs to you is the claim. Annex XIV Part A Section 2 requires the clinical evaluation to be "thorough and objective" and adds that "Its depth and extent shall be proportionate and appropriate to the nature, classification, intended purpose and risks of the device in question, as well as to the manufacturer's claims in respect of the device". A narrower claim is a smaller evidence set and a shorter calendar. That is a product and pricing decision before it is a regulatory one, and it belongs to whoever owns the revenue number. It does not belong to the engineer who first raised it.

The one that does not belong to you is the assessor. Article 52 sends class IIa devices through Chapters I and III of Annex IX including the technical documentation assessment of Section 4 "of at least one representative device for each category of devices", class IIb through the same chapters with that assessment "of at least one representative device per generic device group", and class III through Annex IX or the Annex X and Annex XI alternative. Only class I under Article 52(7) escapes it. That slot is procured, it carries a lead time, and a board meeting moving does not shorten it.

The transitional deadlines quoted around this decision were written for a different population of products. Article 120(3a) and 120(3b) of the MDR keep devices on sale that were certified under the old Directives, as far as 31 December 2027 and 31 December 2028, and the five conditions in Article 120(3c) carried application and signature deadlines that fell in 2024. Article 110(3b) of the IVDR does the same job with three dates, staggered by class from 2027 through to 2029, and Article 110(3c) attaches six conditions of its own whose notified body application deadlines ran from May 2025 to May 2027. Every one of those paragraphs presupposes a device already lawfully on the European market under a previous Directive. A first entrant holds no such position, so none of it is available.

Where do EU entry plans go wrong?

• The class is written into the technical documentation with no Annex VIII rule behind it, when Section 1.1(f) of the technical documentation Annex wants both the risk class and the reasoning for the rule that produced it.
• The European instructions for use are drafted last, after the test campaign has run, so the platforms claimed in them and the platforms in the evidence were never held up against each other.
• The Section 4 conformity table lists what applies and leaves the rest blank, where item (a) asks for the explanation as to why the other requirements do not apply.
• Testing that was never undertaken is simply absent from the file, when Section 6.1(b) ends by requiring a written rationale for that decision.
• IEC 62304 is recorded in the file as a harmonised standard on the strength of a Directive-era listing that covered EN 62304:2006 with AC:2008 and ended with the Directive.
• PMCF is left out with no paper behind the omission, where Annex II Section 6.1(d) asks for the plan and the evaluation report or a justification why PMCF is not applicable.
• The plan assumes an IVD product classifies the way an MDR product does, so a residual class B device under IVDR Annex VIII Rule 6 is budgeted as though it were class I with no assessor.
• The launch calendar is built on the Article 120 or Article 110 transitional dates, which extend a certificate the company has never held.

What do we run for a company entering the EU?

We work the evidence side of the file, and we say plainly which side that is. Conformity is declared by the manufacturer and the assessment is performed by a notified body; no testing supplier stands in for either. What we produce is the material both of them read.

The first piece is a coverage comparison. We take the European instructions for use as drafted, list every hardware configuration and operating system it claims, and set that list against what the existing evidence actually exercised. The output is a matrix with every gap marked and priced, which is the question Section 6.1(b) of Annex II puts when it ties the evidence to the platforms your own product information names. Where a gap will stay open, we draft the rationale that same provision requires, so no row is left blank.

The second piece is execution against the claim. We agree the acceptance criteria before a run starts, run the product both in-house and in a user environment that is simulated or real, and hand back records carrying the build identifier and the configuration they came from, so a reviewer repeats a run without asking anybody a question. Beside the results we write the process description, because the indent wants the process and the results together and most files arrive with only one of the two. The execution work is medical device software testing; the protocols, matrices and reports that hold it together are validation documentation.

Entering a new market usually means standing up an environment that does not exist yet, in a country whose rules on where engineers may sit are already part of your customer's procurement questions. Those terms go in writing before the environment exists, and project data stays inside your systems while the work runs. We do not need production PHI to test. Environments run on synthetic and de-identified data. We sign a Business Associate Agreement before any engagement that touches PHI. What a buyer asks before handing over an environment is answered at how we work with protected health information, and two of the questions there carry no published answer yet.