The MDR – where are we now?

fasten-seatbeltsThere seem to be a lot of misunderstandings in the market about the current status of the MDR. Some think it’s finished (it’s not, at least not formally) and there is a lot of insecurity about when it will enter into force.

Currently the MDR and IVDR are in the process of translation. The trilogue produced negotiated texts but these are still not perfect. Upon close reading one discovers typos and numbering issues as a result of the many amendments. When a group of people translates two very complex and partly overlapping texts in 23 languages from a negotiated text that still contains small mistakes and unclarities, there will be questions that arise about the interpretation of the texts. The texts may also require another look at them if that’s unclear. That is currently happening.

Also, the Council and the Parliament will have to give their formal blessing to the texts as follows:

  • Adoption of the Council’s first reading position end 2016
  • EP second-reading vote end 2016 / early 2017

When these approvals have been ensured, the MDR and IVDR official texts will be published in the Official Journal. These texts are final and will enter into force 20 days after publication. That will be the ‘date of entry into force’ in the regulations. And everything will unfold from there.

What were the big surprises coming out of the trilogue?

I have written a lot on this blog about how the MDR will work in general and have posted content that will provide you with a good high and even detail level of how the MDR works and what manufacturers should do to become compliant with it.

Some of the surprises in the MDR are also in the IVDR and I will not discuss them in this post (they were discussed in a previous post about the IVDR). These are:

  • advertising rules
  • competent authorities enlisted in liability cases

What then are the MDR specific items? These are the amended scrutiny procedure, a new classification rule for software and the last minute amendments to the transitional regime.

Scrutiny reloaded

The scrutiny procedure in the MDR has been revamped and is now called ‘mandatory clinical evaluation consultation procedure’. This ’new’ procedure is essentially repackaging of the scrutiny procedure and it now covers implantable class III devices and class IIb active devices intended to administer and/or remove a medicinal product for which no common specifications have been established. Article 44, which used to be the scrutiny procedure, has been rewritten into a sort of safeguard procure that the competent authorities can use if they feel that the CE marked device should not have been on the market as CE marked after all.

The final scope of devices subject to the scrutiny procedure (implantable devices classified as class III, and class IIb active devices intended to administer and/or remove a medicinal product) was also something of a surprise. Earliest versions of the text of the MDR showed a much larger scope of devices subject to scrutiny and the proposed scope diverged immensely between Commission, Parliament and Council. In that light it is actually not so surprising that the end result of the scope was unexpected.

Software classification

If your company sells clinical decision support or monitoring software, brace for impact because a new classification rule especially for that kind of software was inserted during the trilogue so we did not see it coming. Rule 10a reads as follows:

“Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes, is in class IIa, except if such decisions have an impact that may directly or indirectly cause:

– the death or an irreversible deterioration of the state of health, in which case it is in class III;

– a serious deterioration of the state of health or a surgical intervention, in which case it is in class IIb.

Software intended to monitor physiological processes is in class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations is such that it could result in immediate danger to the patient, in which case it is in class IIb.

All other software is in class I. “

Rule 10a consists of three parts that apply to three categories of software:

  1. Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes – will now always be class IIa or higher
  2. Software intended to monitor physiological processes – will be class I, IIa or IIb
  3. All other software – class I

This rule will increase the burden for software and app vendors considerably if their software is currently a class I medical device under rule 12 of Annex IX MDD and has either clinical decision support or monitoring functionality. This is the case for most clinical decision support software, which is now specifically targeted by the first part of rule 10a. This software will be classified in any of  the other available risk classes, which means that clinical decision support software will always be subject to notified body oversight under the MDR. Under the MDR manufacturers and notified bodies classifying such software will need to look at the risks associated with false positives and false negatives that the software can produce. The MDR does not define serious or irreversible deterioration in the state of health, but MEDDEV 2/12 rev. 8 on vigilance does define it. An example of a serious deterioration in the state of health is indirect harm (see paragraphs 5.1.1 and 4.11 of that MEDDEV), which may constitute of misdiagnosis or inappropriate treatment as a result of false positives or false negatives.

The second part of rule 10a is current rule 10 but then applied specifically to software. The reason for this is probably the current unclarity regarding the current rule 10’s application to standalone software.

The third part concerns ‘everything else’, so essentially current rule 12 that most of the standalone software on the market is benefiting from, minus monitoring and clinical decision support software.

I made a nice little flowchart for the application of the rule:


A surprise within the surprise is that this classification clause is not mirrored in the IVDR, because also in the IVD field decision support software (the expert system functionality mentioned in MEDDEV 2.1/6, of which a new version has just been published by the way) becomes more and more important. I would have thought that software for the support of decisions based on interpretation of various IVD results could also have different risk profiles. Software for interpreting genetic test results for life threatening hereditary diseases would have a different risk profile than software for interpreting test results for the presence of pregnancy associated hormones. With the absence of a rule 10a analogue in the IVDR stand alone software will need to be qualified not by its functionality but what test results it tests for.

If you are interested in more detail about this classification rule, check out my article in eHealth Law and Policy in which I describe the rule and its consequences in detail.

Transitional regime

As expected a ‘solution’ was found to address the constraints preventing all medical devices to be transferred into the new system before the end of the transitional period, such as lack of notified body capacity, limited remainder of transitional period after re-notification of notified bodies, etc.

To that end the MDR contains the following transitional regime:

  • There is a three years transitional period running from the date of entry into force to the date of application (article 97 (2));
  • Certificates issued by notified bodies in accordance with Directives 90/385/EEC and 93/42/EEC prior to the entry into force of the Regulation shall remain valid until the end of the period indicated on the certificate, except for certificates issued in accordance with Annex 4 of Directive 90/385/EEC or Annex IV of Directive 93/42/EEC which shall become void at the latest two years after the date of application of the Regulation (article 94 (2)).
  • Certificates issued by notified bodies in accordance with Directives 90/385/EEC and 93/42/EEC after the entry into force of the Regulation shall remain valid until the end of the period indicated on the certificate, which shall not exceed five years from its delivery. They shall however become void at the latest four years after the date of application of the Regulation (article 94 (2) 2nd paragraph).
  • Devices which were lawfully placed on the market pursuant to Directives 90/385/EEC and 93/42/EEC prior to the date referred to in Article 97(2) may continue to be made available on the market or put into service until five years after that date (article 94 (3a)).

Devices that benefit from transitional provisions that allow MDD or AIMDD covered devices on the market after the date of application remain covered by these directives as regards vigilance, registration of manufacturer and authorised representative, Eudamed contents for the devices concerned and clinical investigations with these devices (article 96). Not sure how this works in practice, especially because the MDR is not clear about whether they are covered by the MDR for the other aspects – if that would be the case, the manufacturers of these devices would nonetheless be faced with a lot of new obligations, for example the new PMS obligations. If the MDR does not apply for the other items, then these devices would exist in a relative regulatory empty space, which would be unlikely to be intended. This is one of the big known unknowns under the MDR.

When you lay it out on a timeline I think the options in the transitional regime look a bit like this:

This slideshow requires JavaScript.

In the mean time, there are also other grave concerns

Governance and surveillance

There are serious concerns (by member states themselves no less) about the ability of member states to be able to staff all the functions required under the MDR, like staffing the MDCG, looking in the EUDAMED database, doing things with information from the EUDAMED database, etc. We will need to see how this plays out. Member states have traditionally been reluctant to allocate sufficient resources to medical devices surveillance and policy, so now is the time for them to step up and put their resources where their mouth is.

Notified bodies

The notifications under the MDD will remain in place during the transitional period so notified bodies will still be able to issue certificates under the transitional rules under the MDD and AIMDD, but there is no telling what notified bodies will be notified under the MDR when. More and more are going bankrupt or just ceasing business. An application for notification will remain voluntary and while the assessment of the application is not the member state’s sole prerogative, there is also no deadline for completing the process.

Nobody has any idea how long it will take for notified bodies to be notified under the MDR – I hear estimates ranging from 12 to 18 months. This means that for one third to half of the transitional period no certificates under the MDR will be issued and that the first certificates will be issued towards the end of the transitional period. This means that the capacity of notified bodies for certificates that are planned during the transitional period will be very limited. If your company’s transition strategy revolves around this, make sure that you keep your notified body very very close in your planning and execution of your company’s transition strategy.

Transition plan

Your company should by now be planning for the transition of its products and doing a gap assessment on what is needed to go from the MDD/AIMDD to the MDR. This is not something to be underestimated, because if you do it may cause severe disruptions: certificates expiring with no new certificate on the horizon. New clinical data to be generated that is not there, new procedures to be implemented that no one knows were necessary, devices being classified in higher classes (especially software (rule 10a) and substance based devices (rule 21)).

If you don’t know where to start, start with the BSI white papers on the MDR – I’m mentioning these because I know they are good quality and have contributed to several of them. BSI recently published a white paper on how to do a transition plan, which is a good overview of what is needed. You can also visit the panel I am moderating at the Advamed Conference in Minneapolis tomorrow (2.15 to 3.30 pm), which will concentrate on this.


Missed the session? I’m working on MDR transition plans for several big and small(er) manufacturers and would be happy to help leverage that knowledge for the benefit of your company – just let me know.


Software MEDDEV ‘updated’

EU flagThe Commission issued an updated version of the MEDDEV 2.1/6 regarding standalone software on 15 July. After all the rumors around the difficult discussions surrounding the revision process I was very curious about the changes finally implemented.

Unfortunately these changes turned out to be very limited and in my view do not change the scope of the document or even bring anything new. Essentially what happened is that the Commission added some definitions and slightly amended the flow chart for qualification under the Medical Devices Directive by amending the first decision node of the flow chart.

Definitions and flow chart

The definition of software has been changed to a “set of instructions that processes input data and creates output data“. The new definition of software is used in the new question in decision node 1 in the Medical Devices Directive flow chart (“Is the product a software?”).

The MEDDEV  defines the concepts of input data (“any data provided to software in order to obtain output data after computation of this data“) and output data (“any data produced by a software“) embedded in the new definition of software. The MEDDEV provides for a non-exhaustive list of examples of input data (data given through human interface input devices, documents and data received from / transmitted by devices) and output data (e.g. screen, print or audio data; digital documents). Nothing really surprising.

The MEDDEV now includes the definition of “Software as a Medical Device” (SaMD) from the IMDRF work item on software, but the definition is not operationalized anywhere in the MEDDEV, because the document only refers to the separately defined term “software”. The definition has no apparent function in the MEDDEV other than seemingly paying tribute to the IMDRF work on software.

Mobile apps

The new MEDDEV version contain a new statement to the effect that “The criteria specified in this document apply also to mobile applications.”. Again, not surprising because we knew that already since mobile apps were always software in scope of the MEDDEV. It’s a pity though that the revised MEDDEV does not contain any actual guidance specifically for mobile apps. That means we’re left with the guidance on mobile apps in the Manual on Borderline and Classification, which looks to be further expanded on ad hoc basis as the Manual evolves.


Is this progress? Well, somewhat. However, to me it’s disappointing that the EU does not have more additional guidance to account for after four and a half years of experience with the software MEDDEV. It shows that the expert group working on the MEDDEV had a very difficult job in coming to agreement on what to put into the revised version because there are more than enough questions that could have been addressed. A missed opportunity, given the importance of the subject.

The final text of the IVDR: first impressions

Schermafbeelding 2016-06-30 om 20.13.42The IVDR text that the Council, Commission and Parliament reached agreement on is finally public (since 15 June). I’ve had the time to read it now.

I am not going to draft a long summarizing article that describes the IVDR in detail. For that I refer you to the new BSI white paper on the IVDR  that was just published and that I co-authored with Gert Bos. This white paper provides an overview and to-do list for manufacturers on a chapter by chapter basis, like the one on the MDR published earlier this year (which we will need to update now for the final text of the MDR).

What I will do in this post is describe some last minute surprises that were introduced in the IVDR during the trilogue negotiations compared to the Council general approach. These are the following.

Genetic testing

There were changes to the genetic testing clause, as I had hoped and argued should take place. The Parliament had an ardent wish to regulate informed consent procedures with respect to genetic testing in a lot of detail, which it does not have competence to do under the TFEU, as Julian Hitchcock and I have argued on behalf of companies providing genetic testing services.

The compromise now is that there is an information requirement and access to counseling requirement, except “where a diagnosis of a medical condition and/or a disease which the individual being tested is already known to have is confirmed by a genetic test or in cases where a companion diagnostic is used”.

Scrutiny revamped

The new IVDR mandatory clinical evaluation consultation procedure is a nice bit of repackaging of the scrutiny procedure. It applies to class D IVDs for which no Common Specifications are available and if it is the first certification for that type of device. What used to be the scrutiny procedure has been changed to a sort of emergency backstop that the authorities use to prevent the product from entering the market if they’re not happy with the CE marked end result.

Transitional regime

The transitional regime (2 years grace period of existing IVDD certs and devices which were lawfully placed on the market pursuant to Directive 98/79/EC prior to the date referred to in Article 90(2) may continue to be made available on the market or put into service until three years after that date).

How does it work with the devices that may continue to be made available for three years? Apparently there is no requirement for a valid certificate anymore, otherwise it would fall in the two years bucket. This would mean that there theoretically is no notified body overseeing the device anymore during that period, so no unannounced audits and no surveillance audits. And it is unclear what regime applies to the IVD: the old IVDD or the new IVDR. Very unclear this.

Self-testing devices

There is a sudden down-classification of certain self-testing devices (for the detection of pregnancy, for fertility testing and for determining cholesterol level, and devices for the detection of glucose, erythrocytes, leucocytes and bacteria in urine) from class C to class B. This means that the IVDs concerned will still be subject to notified body oversight, just subject to other conformity assessment procedure.

The principle behind the IVDR and MDR classification logic seems to be that the only way is up, but this is the only example I have come across so far of down-classification.


I don’t understand the absence of a classification rule for software analogous to rule 10a under the MDR (that’s a surprise in the MDR). Especially the clinical decision support functionality that rule 10a MDR up classifies is also an important item in the IVD space, because more and more expert systems become available.

The new classification rule 10a in the MDR will result in all clinical decision support software and monitoring software that is currently mostly in class I to be bumped up to class IIa or higher. This will affect a lot of software devices currently on the market.

All of these devices will need to be certified by notified bodies under the MDR, while notified bodies have almost no experts on software. It’s also strange that clinical decision decision support software has no similar rule under the IVDR.

Claims/advertising regime

There suddenly is a new claims/advertising regime in the new article 5a. This we will now finally have EU harmonized rules for claims and advertising of medical devices:

“Article 5a Claims

In the labelling, instructions for use, making available, putting into service and advertising of devices, it is prohibited to use text, names, trademarks, pictures and figurative or other signs that may mislead the user or the patient with regard to the device’s intended purpose, safety and performance by:

(a) ascribing functions and properties to the product which the product does not have;

(b) creating a false impression regarding treatment or diagnosis, functions or properties which the product does not have;

(c) failing to inform of a likely risk associated with the use of the product in line with its intended purpose;

(d) suggesting uses of the product other than those declared in the intended purpose when the conformity assessment was carried out. “

However, I think the new rules are rather superfluous because they mirror exactly what is already in the Unfair Business to Consumer Unfair Commercial Practices Directive (2005/29/EC) or could be prohibited based on the Misleading and Comparative Advertising Directive (2006/114, its B2B cousin).

Sub c), however, is additional and a tricky one because it makes unimaginative risk management a violation of the law. Essentially you would need to list any likely risk, which reminds me of the patient leaflets for medicinal products that list even the most rare of possible side effects for the product.

Since there is no qualification of how likely the risk has to be in order for it to be listed (something which they actually do consider for medicinal products SPCs side effects listing), any risk with a likelihood of occurring seems to be a candidate for the IFU, but also for inclusion in advertising (it says “and advertising” so I interpret that grammatically as a duty to include all likely risks in advertising) there will be a lot of small print that none will be the wiser for. TV advertisements will need rattle off all the likely risks that viewers will do their best to ignore. More information is not always better protection if you ask me.

Maybe this is a too strict interpretation, but how then how to interpret “likely risk associated with” (not caused by, which is also more narrow)?

CAs enlisted in product liability and other claims

The new article 8 (9) allows member state CAs to request information from manufacturers on behalf of others in product liability and other damage claims:

“If a competent authority considers or has reason to believe that a device has caused damage, it shall, upon request, facilitate the provision, of the information and documentation referred to in the first sub-paragraph to the potentially injured patient or user and, as appropriate, the patient’s or user’s successor in title, the patient’s or user’s health insurance company or other third parties affected by the damage caused to the patient or user, without prejudice to the data protection rules and, unless there is an overriding public interest in disclosure, without prejudice to the protection of intellectual property rights. The competent authority need not comply with this obligation where disclosure of the information referred to in the first sub-paragraph is ordinarily dealt with in the context of legal proceedings.”

This is a matter of concern for industry because of the obvious risks of widely divergent application of this by member states and fishing expeditions by competitors and the wide scope of persons that can request this information. The “other third parties affected by the damage caused to the patient or user” would for example in my view include me as an employer if one of my employees was injured and my employee would be on prolonged sick leave. Mind you, this is not limited to product liability cases only, because in that case the scope would have been limited to ‘defective’ devices. This concerns any kind of damage caused by a device, regardless of whether it’s defective or not.

There are corrections on data protection and protection of intellectual property rights but it really remains to be seen how national competent authorities will implement this since the application is under full discretion of the national authorities.

Person responsible for regulatory compliance

It’s interesting that the person responsible for regulatory compliance can now be split into multiple persons, provided that their areas of responsibility are properly documented.

This documentation will be important to keep a good eye on for manufacturers and will tie into their QMS obligations as well. They will be written up by their notified body if the roles are not properly defined and accurately laid down at any moment in time.

Transparency of clinical data

There are now provisions for sharing raw clinical / performance data on a voluntary basis, where the Parliament was planning to force this off by means of the proposed recital 39a without corresponding provision in the texts of the Regulations that stipulated that the whole set of under clinical data would be non-confidential.

We now instead have an obligation to publish the clinical investigation report and a summary into Eudamed within a year after the trial, which will become public upon CE marking and immediately in case of halt or termination of the study. If the device is not CE marked within a year after entry into Eudamed of the report and summary, then the report and summary become automatically publicly available in Eudamed.

Now what?

Over the summer the text will be looked at by the EU’s lawyer-linguists who will translate the IVDR in each of the official languages of the EU. Since that process may still reveal textual issues in the agreed English language text that will be ironed out, so be prepared for some very minor changes that may happen still. There won’t be surprises though, unless some things were written down in a very ambiguous way.

The text will then be published in the Official Journal of the EU in all official language versions and enter into force shortly after. This will likely happen this autumn.

Stay tuned, also for a next post on surprises in the final MDR text.


Medical devices and the #Brexit

so-long-farewell-and-auf-wiedersehen-goodbyeWow, while I was still working on wrapping my head around the hundreds of pages of final texts of the MDR and IVDR, the Brexit happened.

Speaking of surprises – this was a big one. I do not want to use this blog for political statements, so I won’t bore you with my personal opinion on whether this was a good idea first from the country’s leaders and secondly from the country’s citizens. That’s all moot now anyway, and time will tell. Like always in law and regulation we will work with the tools that the powers that be make available to us.

First, it may not happen at all. The UK is still in discussion with itself about whether this referendum is final. There are already initiatives for another referendum that should produce a more decisive difference between stay and leave votes (it now was 48.1% stay 51.9 % leave).

Secondly, it is not sure yet if the whole UK leaves.The Brexit may not involve the entire UK, as Scotland is already publicly coining the option of not leaving the EU but divest from the UK instead and remain EU member state.

The first questions are starting to arrive in my inbox about what this means for CE marks for medical devices and for the process of the MDR and IVDR as well as medical devices law and policy in the EU in general, so here is my view on that.

CE marks

The situation of a Brexit is unique, so we will need to see what happens as no other member state ever decided to divest from the EU or its predecessors. The provisions in the EU Treaty are not very precise on what exactly happens now and there is no precedent. The procedure is that the UK will now enter into negotiations with the EU about divestiture from the EU and has two years for that process. In that process instruments of the EU internal market (of which medical devices policy is a subject) may be replaced by treaties, much like the mutual recognition agreement that Switzerland has with the EU and that covers, among a lot of other subjects, medical devices. That agreement allows Switzerland to have notified bodies and provides for mutual recognition of the CE mark in Switzerland.

My best guess is that the situation between the EU and UK will come to look very much like that between Switzerland and the EU, because I do not expect the UK to settle for EEA membership (as sort of EU light, which allows for example Norway to have notified bodies and have mutual recognition). EEA membership means automatic implementation of most EU law with none of the influence of a member state in its legislative process. A Swiss type arrangement is a realistic scenario: UK notified body BSI issued a statement along these lines for example. Theoretically the UK could also enter into a customs union with the EU, like Turkey, and that instrument might provide a basis for mutual recognition – but this kind of deal seems reserved for countries that are aspiring EU members.

What the transitional regime would turn out to be is impossible to predict at this stage, but it will probably involve grandfathering, which in turn is influenced by the transitional regime for the MDR and IVDR.

MDR and IVDR impacted?

One of the questions I received was whether the Brexit would impact the MDR and IVDR.

The EU will certainly not suspend the MDR and IVDR project because of the Brexit because the texts were established following the normal legislative procedure. The texts will enter into force in the EU as planned and may also take effect even in the UK, up until the date on when the UK formally disengages from EU law having direct effect in its jurisdiction. They will in any event enter into force in the EU’s 27 member states.

What medical devices law will apply in the UK will depend on where the UK goes. It cannot afford to close itself off of the EU market so it will aim for mutual recognition. The question is when that enters into force, but it will have to be somewhere between now and two years from now.

Now what?

How will this affect you as a company?

Should you ditch your UK notified body now? As quoted above, BSI thinks that it will remain notified – but there are no guarantees. It would be unlikely that the UK would not not retain a notified body, but it was also unlikely that the UK would leave in the first place. It will depend on the deal that the UK negotiates with the EU.

Should you have an authorized representative or manufacturer in the UK? That, too, will depend on the deal that the UK reaches with the EU. Assuming that mutual recognition will be agreed upon, your devices could still benefit from access to the EU market.

If the deal with the EU is bad, some of the historic trade barriers may come back. If it’s good, the UK may become a sort of Switzerland for the purposes of medical device law. That’s basically all I can say at the moment.

Counting down to the final text of MDR and IVDR; more on software

europeIt’s the final countdown! Following the trilogue’s agreement on the MDR and IVDR texts the Commission (DG Growth) confirmed at the eHealth Week in Amsterdam last Friday that (probably late) this Wednesday the agreed text of the MDR (and, I assume, IVDR too) will be made public as the signatures required will finally have been placed that day. Stay tuned to this blog for details!

Entry into force slightly later

It was further confirmed that the formal entry into force will be ‘end of this year / beginning of next year’, which looks to be slightly later than I predicted in my last post with a presentation that contained the likely transitional regime.

Expect some surprises and some IMDRF SAMD influence

The Commission said that a lot had happened during the trilogue, so prepare for some surprises.  Surprises will be present for example in the field of regulation of medical devices software and software as medical device (see below for more detail).


Expect some IMDRF SAMD influence

As it was eHealth Week, the Commission speaker addressed the broader EU regulation picture of software under the MDR and IVDR.

The General Safety and Performance Requirements for software in Annex I to both Regulations have been much debated and might contain more detail (I expect in chapter 14 about software) than we have seen so far. Hopefully there will be more detail on cybersecurity, because the EU is starting to lag behind seriously behind the FDA with its regulatory thinking on this subject for medical devices.

A feature to be expected in the final text was possible deletion of the word “standalone” in relation to software, which would mean that software is qualified and classified regardless of its location. This approach would be a radical departure from the current approach under MEDDEV 2.1/6, since this MEDDEV makes a crucial distinction between software embedded on a device and standalone software in step 2 of the flow chart on page 9 that is the core of the MEDDEV. So that’s a pretty significant change in my opinion.

The Commission mentioned the possibility to create dedicated classification rules for software (making it possible that software falls in class III – currently class IIb is the highest for standalone software) and consideration of the risk categorization principles established in the IMDRF software as medical device (SAMD) work item. Finally, the Commission mentioned the possibility of mandatory clinical investigation for certain types of medical software. That would be the logical consequence of the possibility of software falling in class III, but maybe there is more to this statement – we’ll know on Wednesday.

It was mentioned that we can expect more guidance documents on software under the MDR and IVDR, as a mirror group of EU regulators has been set up to work on transposition of results from the IMDRF SAMD working group to EU medical devices law. This is important, as there are rumors that the Commission was planning to get rid of MEDDEVs altogether under the MDR and IVDR. Apparently the rumors turn out to be wrong.

The Commission further said that we can expect an update of MEDDEV 2.1/6 about software this summer. The update will include an updated section on apps and will incorporate thinking from the IMDRF’s SAMD work item, for example definitions developed in that work item.

Medical devices definition

The Commission raised the – in my view very ill considered – proposal to change the scope of the definition of medical device in order to capture every device with an indirect medical purpose in scope of the MDR and IVDR. The Commission speaker reiterated that both the Council and the Commission were opposed to this amendment because it would lead to the situation that lifestyle and well-being apps would be covered by the MDR and IVDR, which is not the intention of the Commission and the Council. Also this was left implicit, I assume that this means that the Parliament amendment – hopefully – did not make it to the final text. But we won’t be sure until Wednesday.

Now the real work begins

When I asked Mr. Hansson of DG Growth afterwards whether he was taking a long vacation now that the regulations’ texts were done, he said that the real work begins now. His unit will start putting in place the draft delegated and implementing acts necessary to make the MDR and IVDR function (e.g. on Eudamed and UDI) and arrange for the underlying technical infrastructure and that will be a lot of work.

Companies in the medical devices field, as I have been saying for some time, will need to prepare, prepare and prepare.



MDR and IVDR presentation

FullSizeRenderThere was a lot of demand for the presentation referenced in my previous blog about the MDR and IVDR texts having been agreed because a lot of picture quality was lost in the document embedded in the blog. Thanks very much for all the interest and great feedback!

White Papers and presentation

Also the PDF version that I sent to the people that asked for it was not ideal because some of the pictures were compressed to the point that they were difficult to use, so to give you more options I decided to make the uncompressed  presentation document available for download (which was way too big to email to everyone that asked). Feel free to use it – you can download it here (provided that your computer allows downloads from a public Dropbox folder).

I can also recommend looking at the BSI White Papers on the MDR and IVDR and on the MDR specifically (and – disclosure – not only because I was involved in writing them) to get a general picture of things.

Sneak preview: BSI will soon publish another White Paper specifically on the IVDR with better detail on to do items than in my presentation, so watch out for that one.

Remember that everything in the presentation and white papers is still educated guessing and work in progress: the final texts of the regulations are not public yet, but hopefully they will be soon. As soon as I have them without commitment of confidentiality I will post them on this blog and will discuss the final result compared to what we have been guessing would be adopted.

The hateful eight of new EU data protection rules

Also, I have published the first part of an article in two parts in eHealth Law and Policy about the hateful eight referenced in my blog about the new EU General Data Protection Regulation, which you can read in full if you take out a free trial subscription to the journal. The article provides a lot of detail in addition to the blog and embedded presentation. The other part of the article will appear in the next issue (issue 4).


The new General Data Protection Regulation impact on medical devices industry

Erik anonymous

This is not me

The MDR and IVDR are here now, but the General Data Protection Regulation (GDPR) already beat them to the finish line as it was just adopted.

I have written a lot about current and future EU data protection requirements, both on this blog (here, here and here for example) and in other publications. What I have referred to as future EU data protection requirements, the GDPR, is no longer future now that it has finally been adopted and published.

It will apply as of 25 May 2018 so all companies collecting and processing personal data in the EU will have to be compliant by that date. That looks like a lot of time, but don’t forget that a lot needs to happen when you are processing data concerning health (which all medical devices companies will be). And you will have to do it while implementing the MDR, IVDR or both. Better start immediately. By the way, like under the MDR and IVDR everything will become more complex and technical. The fines are astronomical, deliberately to scare companies into compliance (how about 4% of your annual worldwide turnover?).

Why is the GDPR relevant?

Why is the GDPR relevant to medical devices manufacturers? If you are posing yourself that question you have not paid attention to the intense lobby by the healthcare industry with respect to the GDPR. You may also not understand that more and more the customer and patient data that manufacturers process is crucial to their business. Consider this presentation I made to the Personal Connected Health Alliance:

The hateful eight described in this presentation mostly apply to medical devices manufacturers in general:

1.Informed consent criteria

The GDPR increases the risk related to a consent-based business model  considerably by imposing additional and onerous requirements with respect to informed consent. Medical devices manufacturers will need to spend considerably more attention on their consent processes and the way their phrase their privacy policies, because there is a requirement to provide intelligible consent language and to obtain consent by affirmative action. Especially companies that consider their consent processes and policy a formality will likely run into problems under the consent requirements in the GDPR.

Like under the MDR and IVDR there is no grandfathering, so existing consents do not remain valid if they do not meet the new requirements. You will need to do a gap analysis for all consents obtained.

Consent is invalid “in a specific case where there is a clear imbalance between the data subject and the controller”. This will be a tricky one in practice for business models that entail provision of services to the clinical profession and institutions. When a doctor prescribes the use of an app that the hospital uses for monitoring patients at a distance, the patient will mostly not feel in a position to refuse this. Consent would then likely have been obtained in a case of imbalance and be invalid, regardless of the patient ticking all the consent boxes in the app. The imbalance criterion will play an important role in clinical research as well.

Secondary processing (e.g. for the purposes of a registry, or of registry data for other purposes than initially declared) is allowed for scientific purposes without having to go back to the patient for additional consent, provided that the company implements ‘appropriate safeguards’.

2.Data concerning health scope

The definition of health data under the GDPR does not differ materially from the DPD (it’s “personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status”), but its scope is very expansive because of the way the GDPR interprets ‘health status’:

“all data pertaining to the health status of a data subject which reveal information relating to the past, current or future physical or mental health status of the data subject. This includes information about the natural person collected in the course of the registration for, or the provision of, health care services as referred to in Directive 2011/24/EU of the European Parliament and of the Council to that natural person; a number, symbol or particular assigned to a natural person to uniquely identify the natural person for health purposes; information derived from the testing or examination of a body part or bodily substance, including from genetic data and biological samples; and any information on, for example, a disease, disability, disease risk, medical history, clinical treatment or the physiological or biomedical state of the data subject independent of its source, for example from a physician or other health professional, a hospital, a medical device or an in vitro diagnostic test.” (recital 35)

In addition, the GDPR also introduces the concepts of genetic data and biometric data, which may overlap with the concept of personal data concerning health and are largely treated the same as personal data concerning health under the regime for the special categories of personal data. Holding any biological sample is therefore considered processing of personal data.

3.Right to be forgotten (right to erasure)

The right to be the right to be forgotten applies to any processing of health data that is not covered under the concept of scientific research under GDPR, so basically any commercial collection and processing of health data outside clinical research. This is a safe assumption since this exclusion was adopted specifically to address the concern that exercise of the right to erasure could de-power clinical trials. Whether it applies to other research outside clinical research is unclear.

Companies have to implement technically that they can erase any personal data that they process about a person upon request, and also implement this among the companies that process data for them or have received that personal data from them. Withdrawal of consent to processing is sufficient grounds for this. And withdrawal of consent may not be made difficult under the GDPR. 

4.Impact assessment

The GDPR requires that all companies that process personal data concerning health and/or engage in profiling of data subjects conduct a Privacy Impact Assessment (PIA) prior to the processing. A single assessment may address a set of similar processing operations that present similar high risks, which means that a company does not have to perform a new PIA when it extends a service with new functionality, unless that new functionality presents new risks that have not been addressed in the PIA that was performed.

As I have blogged before, having no PIA currently already makes your company unattractive as a target to invest in or acquire, but with the insanely high penalties under the GDPR (max 4% of your company’s last year world wide turnover) processing personal data concerning health without not having conducted a PIA is pretty reckless behavior for a company. In medical devices logic it is tantamount to developing a medical device without doing risk management, usability design and other essential design inputs.

The GDPR provides as minimum requirements for PIA:

(a) a systematic description of the envisaged processing operations and the purposes of the processing. The systematic description is necessary as basis for assessment and help the company determine all the ways in which it collects and processes personal data, and the associated purposes. Describing the purpose of processing accurately and completely is very important, because companies often collect and processes personal data for multiple purposes (e.g. provision of the service to the consumer and use of the personal data collected in provision of the service to monetize that data).

(b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes. This part of the PIA requires for example application of the principles of data minimization and purpose limitation to ensure that not more personal data is processed that is necessary for the declared purpose and that the processing and collection of data happens in a way compatible with the declared purposes.

(c) an assessment of the risks to the rights and freedoms of data subjects. This element forces the company to think about what the processing means for the data subjects and think about whether the way it processes data still allows for exercise of the data subjects’ rights, such as the right of erasure, the right to object to profiling, the right to correction, etc. If the conclusion is for example that the processing is set up in a way that these rights cannot be exercise, the processing cannot be lawful and has to be modified in order to bring it into compliance with the GDPR.

(d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with the GDPR taking into account the rights and legitimate interests of data subjects and other persons concerned. The GDPR is far more prescriptive with regard to security than the DPD and defines a catalogue of security principles and measures. The controller has to document its choices for security and risk management in its PIA.

A good place to start is with the UK ICO’s PIA Code of Practice, which provides for guidance  on conducting a PIA on your company’s processes.

5.Profiling requirements

Profiling is what makes the use of personal data in healthcare relevant, for example to be able to form a picture of how a patient’ health develops over time and to monitor a patient over time. The GDPR defines monitoring as “any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements”, which is precisely what any good medical device service does. As a result, many medical devices manufacturers will need to comply with the profiling requirements. This means:

  • informing the data subject of profiling and its details in advance, more specifically “meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject”;
  • in case of profiling based on data concerning health obtaining explicit informed consent from the data subject for that profiling;
  • when profiling is based on personal data concerning health performing PIA before commencing ; and
  • implementing suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests, at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision.

I expect manufacturers to have a steep learning curve in explaining their profiling to their patients in a meaningful way, performing PIAs and implementing measures to address the risks identified as most companies currently see obtaining meaningful (or even legal) informed consent as an inconvenience.

6.Data portability right of user

This requirement will have a great impact in the medical devices industry but also in eHealth in general (e.g. the electronic health record industry). It means that patients can request the data from their pacemakers or EHR for example and even request that the data is transferred to another provider. While the GDPR does not impose an obligation of controllers to maintain technically compatible systems,

“[t]he data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided”.

Companies have to explicitly inform users about the right of data portability. Where technically feasible, the data subject has the right to have the personal data transmitted directly from one controller to another. When exactly this is technically feasible or not is not addressed in the GDPR, but it is safe to say that the data protection agencies will make a point of portability when looking at whether a company has met its privacy by design obligations. This will likely not be the case where a company deliberately designs personal health data processing devices in a way that the data cannot be exported in a commonly used format.

Especially the right of data portability may necessitate that companies redesign existing systems, since there is no grandfathering under the GDPR. That means that by 25 May 2018 all existing systems must be adapted for data portability. Companies that are currently designing systems may want to do a gap assessment to see if their design complies with data portability requirements.

7.Security requirements

We know risk management and (cyber)security from the medical devices standards and rules. The GDPR will require more or less the same with regard to security. This means privacy by design at work, and achieve the level of the state of art in security, which als needs to be a level appropriate to the risk involved with the data processing.

This means implementing, as appropriate, pseudomisation, encryption, redundancy, regular penetration tests and intrusion detection measures, and implementing a continuous process for evaluating the effectiveness of the measures implemented.

The GDPR will moreover feature a pan-EU breach notification mechanism. Personal data breaches have to be notified to the competent DPA without undue delay, but in any event in less than 72 hours after becoming aware of the breach (unless a delay can be justified), and notify the data subjects concerned if their interests may be affected. A personal data breach is a “breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”.This means that the obligation can be triggered regardless of whether data was stolen or deleted after a security breach. What exactly constitutes a security breach will be further defined in guidelines by the new European Data Protection Board.

8.Export of data to extra-EU jurisdictions

Export of personal data outside the EEA will remain only permissible with adequate level of protection, much like is currently the case and the export requirements will not be materially different.

The question is however if the Privacy Shield for export to the US will ever be accepted and what the member states will do, as they retain the competence to maintain or introduce further conditions, including limitations, with regard to the processing of genetic data, biometric data or data concerning health. This means that e.g. the French healthcare data hosting requirements and similar national measures will continue to exist.

Now what?

In the face of regulatory adversity you make a plan and you follow through, so here is the outline for a plan based on the ABCDE (accept/breathe/consider/decide/engage) model:


  • that a dramatically more onerous regime is upcoming and appoint a Data Protection Officer
  • And you will be implementing this alongside the MDR and/or IVDR so your regulatory department will be stretched to or beyond its limits


Conduct an audit of:

  • data currently held and what you do with that data
  • legal basis for processing data
  • data “exports”
  • data subject access requests


  • Rewrite (or at least revisit) for compliance with additional data protection requirements
    • all consent structures
      • consider the information provided as much as the consent itself
    • all privacy notices and policies
    • all anonymisation and pseudonomisation structures (legal justification and state of art?)
    • legal bases for export of personal data to outside of the EU
    • data processing agreements

Decide how to:

  • Embed “privacy and accountability by design”
  • Design workable structures to give access to patient-level data (or anonymiseearly)
  • Strengthen anonymisationand pseudonymisation tools egISO 27001
  • Legally “export” personal data.

Engage with Competent Authorities, Industry bodies and other third parties to

  • Watch out for specific Member State rules on health data etc, including between Member States
  • Practice procedures for breach
  • Practice data protection Impact Assessments
  • Ask Industry Bodies to update any codes of conduct that were drafted under the old regime of the Data Protection Directive

Some authorities have already provided guidance on what they expect from you, like the UK ICO’s helpful 12 steps plan for implementing the GDPR. Surprise surprise, they also strongly recommend you implement a PIA already now.

Keep Calm – Visit Axon’s seminar on the GDPR

My law firm organises a seminar about the GDPR’s impact in the healthcare industry in Amsterdam on Monday 13 June, which will get you up to speed on the GDPR. One of the guest speakers is the Dutch Data Protection Authority, so you will be able to check assumptions with the competent authority. Please RSVP if you plan to attend – you can bring as many friends and colleagues as you like (just let us know how many).


%d bloggers like this: