New MEDDEV on authorised representatives: everything you know is wrong

Last week the Commission released a new MEDDEV guidance document on authorised representative as part of the package announced at the beginning of this year and this one is disruptive, especially if you did not see it coming.

Step back: what is an authorised representative and why would you need one? The authorised representative is “any natural or legal person established in the Community who, explicitly designated by the manufacturer, acts and may be addressed by authorities and bodies in the Community instead of the manufacturer with regard to the latter’s obligations under [the Medical Devices Directive]”. You need one if “a manufacturer who places a device on the market under his own name does not have a registered place of business in a Member State”. So an authorised representative can be an internal or external function, depending how your company is organised. Some companies hire a consultant(cy) in the EU to be their authorised representative, others nominate a legal entity in their corporate group that happens to be established in the EU. EU law enables a manufacturer to delegate the performance of certain medical devices requirements to his designated authorized representative. EU law requires an authorised representative so the authorities can address the authorised representative for the purpose of post marketing surveillance with respect to the devices concerned. There is more, but that’s described in a lot of detail in the MEDDEV and it’s not new.

Now, what is new about this new MEDDEV? First, there are the requirements that are expected for authorised representative agreements of which I am very sure that almost no authorised representative agreement in place in the EU meets at this moment. Secondly, there is the ‘supervision’ of these agreements, which is delegated to notified bodies.

As to the first point: the MEDDEV makes it clear that the relationship between the manufacturer and authorised representative is one of delegated powers, which means that the authorised representative is expected to step up and exercise these powers with a certain degree of independence. Below are the items that the member states authorities expect in an authorised representative agreement. This has consequences for agreements currently in place, because from my own experience with authorised rep agreements I know that almost none of the agreements out there complies with the requirements that follow below that I have put in a bit stripped down language for easy reading:

Information

authorised representative is obliged to inform the manufacturer of

  • decisions of a Member State in respect of refusal or restriction of the placing on the market or any making available or putting into service of a device;
  • incidents brought to his knowledge.

manufacturer is obliged to inform the authorised representative of

  • all matters that may be connected to the devices placed on the EU market.

Division of responsibilities

Relation between manufacturer and AR / flow of information

– “The authorised representative should be able to assess whether the manufacturer has the ability to fulfil his regulatory obligations. In order to carry out the assessment the authorised representative should have access to the technical documentation.”

– “The authorised representatives should be in a position to verify that the required information / documentation exists with their manufacturer and that the necessary processes (e.g. for post market surveillance) are established.”

– “The authorised representative must possess appropriate knowledge, expertise and resources to assess and verify the above.”

Competence AR

– “A Member State must be able to assume, when it addresses an authorised representative, that it will receive all the information that it requests.”

Information to be provided to authorities on request

– “A Member State can expect an authorised representative to provide on request the following information:

i) Declaration of conformity,

ii) Copy of the label, packaging and instructions for use (in all languages requested by the countries where the device is marketed),

iii) Notified Body certificates (where relevant),

iv) Post market surveillance process and data, vigilance reports and complaints, processes and data,

v) Technical documentation relevant to market surveillance investigation being undertaken by the Member State,

vi) Relevant clinical data / notification,

vii) Details of any distributors / suppliers putting the CE marked devices on the market,

viii) Incident reports and reports on corrective actions taken.”

Disagreement and non-compliance

– “In the event of a disagreement, where the authorised representative considers that the manufacturer is not complying with the requirements of the Directives, it has a duty to communicate this to the manufacturer. If the disagreement continues, the matter should be submitted to the authorised representative’s Competent Authority for decision. The authorised representative may opt to rescind the contract.”

– “In the event of a clear non-compliance by the manufacturer that could engage the responsibility of the authorised representative and which the manufacturer refuses to correct, the authorised representative has the right to rescind his contract with the manufacturer. The authorised representative has even the obligation to rescind the contract if the non-fulfilment of the manufacturer’s obligations causes him to infringe national law. It should then notify his Competent Authority and the manufacturer’s Notified Body of this.”

This last quote is what member states expect from the parties involved. I really wonder how they see this applied in practice: they want an authorised representative to act contrary to national contract law based on – yes indeed – the non-binding guidance that a MEDDEV is. Apparently they rely on the fact that an authorised representative would be able to defend itself in court by arguing: “I had to break my contract based on an obligation in non-binding EU guidance”. That could lead to the following conversation. “Is there a basis for this obligation in the law? Does the Medical Devices Directive require member states to implement this in their contract law?”, the court would ask. “No, but the Commission says in a MEDDEV that the member states expect it”. “OK, so it’s expected says someone else, even an obligation, and there is no legal basis?”, the court would reply with a question and subsequently order damages and/or specific performance on the part of the authorised representative. Everyone would be the richer for an interesting experience, but you can’t create an enforceable obligation with a MEDDEV as the law now stands.

Would a court act contrary to the principle of Community loyalty enshrined in the EU treaty if it just applied its contract law in this case as described above? I am not so sure as there is no legal basis in the medical devices directives to resolve this conflict. Another question is whether the authorities and notified bodies would help an authorised representative in a scenario like this, e.g. would the authorities intervene in a contractual dispute between a manufacturer and an authorised representative? I think that is very unlikely. So, although this looks nice on paper, it is set up in a way that is asking for trouble from a legal perspective.

Supervision

Another interesting item in the MEDDEV is the supervisory task that is now specifically put on the notified bodies: “The Notified Bodies should verify that a manufacturer who does not have a place of business in the EU, has designated an authorised representative and that the appropriate contract demonstrating delegation of appropriate responsibilities is available.”, says the MEDDEV. Those are a lot of ‘appropriates’ in one sentence. Again, there is a problem that jumps out to me as a lawyer: how will a notified body (who are not lawyers) determine if a contract is ‘appropriate’ and divides responsibilities ‘appropriately’? If the expected criteria above are the criterion, a notified body would need to do legal due diligence on the contract. I have a very well-founded suspicion that notified body auditors are not well equipped at the moment to assess control over subcontractors in subcontractor agreements and do not engage in-house or external lawyers for this, so it is fair to say they are not well equipped to assess the appropriateness of the authorised rep contracts either. This might be a point of improvement for notified bodies – they can also always challenge the manufacturer to explain its contract to the auditor but then the auditor must still be able to understand it.

Conclusion

If you are manufacturer, you should review you authorised representative agreement(s). Otherwise your notified body should challenge you for non-conformity if they find the agreements that are the market standard currently. Authorised representatives should think about how they will exercise the extra responsibility they have now and how to carve out the freedom to do so in their agreements. And notified bodies should think about how they will assess the appropriateness of these agreements. That means lots of homework for everyone. Need help? Let me know.

The new EU MEDDEV on stand-alone software as medical device

Some time ago I already gave you a look under the hood of it and now it is here, the new MEDDEV on stand alone software: an interesting document that provides a lot of much-needed guidance for the developing software industry surrounding medical devices.

Since much of what I wrote about  it (here, here) is still accurate. Some additional points are made in the interview I had with MedTechInsider when the MEDDEV was just out. The interview has a nice overview of what I think will be the future issues with regulated stand alone software.

What I will do is give you a heads-up for a rather comprehensive article that will soon be published on EMDT (and a condensed version will appear in their glossy, European Medical Device Technology) in which I, Bradley Thompson and Jason Brooke compare the resulting EU regulation of clinical decision support systems to the US regulation of clinical decision support systems. Since clinical decision support systems are software, much of what we write in the article will apply to stand alone software in general. It will hopefully help companies to fine-tune their regulatory approach to software regulated as medical device in the two biggest medical technology markets. That’s useful, right?

Decision trees

Some other useful features that you should know about in the new MEDDEV: I like the new document because it contains really convenient decision trees for determining the scope of the medical devices directives with respect to software, and, as you know, a picture says more than a 1000 words, right? Also it contains many examples of regulated software.

First, you apply the tree for the Medical Devices Directive (which I reconstructed slightly, I could not help myself. It’s not identical to the one in the document but the tree runs exactly the same):

 

However, if you have standalone software that is used to analyse data coming for an in vitro diagnostic device, you should subsequently apply the below tree (as the definition of ‘in vitro diagnostic medical device’ contains the nested definition of ‘medical device’), starting at “stand alone software”:

Modules

I was a bit harsh perhaps about the merits of the possibility under the MEDDEV to CE mark software modules with ‘medical’ functionality in a larger suite separately from others in the same suit.  Having mulled it over, I still think it will be complicated to apply in practice. It is up to the manufacturer to define correctly the boundaries of the module(s) and to identify clearly what is regulated and what is not. The MEDDEV does not provide guidance on how to make such a determination but instead refers to the existing rule in Annex I MDD and IVDD for combination devices: “If the device is intended for use in combination with other devices or equipment, the whole combination, including the connection system, must be safe and must not impair the specified performances of the devices. Any restrictions on use must be indicated on the label and/or in the instructions for use.” ( see Annex I, 9.1 MDD and Annex I, B.3.1 IVDD).

I can imagine that it is difficult for manufacturers to identify how the different modules of a larger software system relate to each other and where medical functionality starts or ends. Indeed, the rule in Annex I that the MEDDEV refers to was written for modular physical medical devices rather than software. Furthermore they must ensure that the whole system is safe and does not impair the specified performance of the modules that are subject to the medical device directives if medical functionality modules are combined with non-medical functionality modules. On the other hand, medical device regulations in the European Union are appreciated for their flexibility, allowing manufacturers to present evidence in a way that works for them. Also, if the software is a class I medical device as a lot of this software will be, the manufacturer can decide this all on his own.

Accessories

We will see a lot of challenges with standalone software that functions as a accessory to a medical device. An accessory, as you know, is “an article which whilst not being a device is intended specifically by its manufacturer to be used together with a device to enable it to be used in accordance with the use of the device intended by the manufacturer of the device”.

Accessories of medical devices are regulated as medical devices in their own right. Software that is not itself a medical device nor constitutes an accessory to a device would typically be software for all types of use in a medical setting but not with a regulated intended purpose. An example would be software that is used for reimbursement purposes, staff scheduling, or some other similar purpose. Software that is an accessory will influence a medical device in some way and assists it to achieve its intended purpose but does not itself fall within the scope of the definition of a medical device. An example would be an iPad app that allows a nurse to monitor and control infusion pumps in the ward from the nurse’s station.

The accessory question will become interesting with software of which it may not be completely evident that the manufacturer intended it be used together with medical devices, e.g. very customisable software that is suited for controlling all types of external devices that the manufacturer says in a help forum topic that can be safely used to control infusion pumps at a distance, but they held back on the CE certification because their lawyers are difficult about product liability risks.

PMCF

Better start to think about your post marketing clinical follow-up for software too. If it is a medical device you have to do clinical evaluation and if you’re dealing with a class IIa or higher device, you have to explain to your notified body how you will fulfill your PMCF obligations, for example to fine-tune your algorithms via registry studies and how that relates to your EN62304 obligations for life cycle management of the software.

 

 

 

New EU guidance on Post Market Clinical Follow-Up Studies published and other MEDDEV guidance announced

The EU just released its first MEDDEV of a number that were agreed upon in the recent MDEG meeting. More are expected to trickle onto the Commission’s devices web pages in the coming days/weeks. It is a veritable guidance bonanza that will be discussed on this weblog in the weeks to follow. Some of the documents were truly much anticipated (or much overdue, if you’re more cynically inclined).

Agreed documents are:

  1. Revised guidelines on a Medical Device Vigilance system (MEDDEV 2.12-1 rev.7 ) have been reviewed and updated to include the new Manufacturers  Incident Report Form and the FSCA Form (listed as Annex 3 & 4).
  2. In addition, templates for Manufacturers Trend Reporting and Manufacturers Periodic Summary Reporting (Annex 7 & 8) are being introduced.
  3. Amended guidance on Post Market Clinical Follow-Up (“PMCF”) studies (MEDDEV 2.12-2 rev.2), discussed in more detail below.
  4. A new guideline has been established for Authorized Representatives (MEDDEV 2.5/10)
  5. A new guideline on IVF ART (MEDDEV 2.2/4)
  6. The guidance on Medical Device – Borderline and Classification issues on IVD (MEDDEV 2.14/1 rev.2) has been updated once again and revised to include more detail on some essential qualification criteria and classification issues.
  7. The new guideline on the qualification and classification of stand-alone software used in healthcare (no number assigned yet) within the regulatory framework for medical devices was agreed upon after two years of discussion.

In the following I would like to take a closer look of the first one published on the Commission website, the  guidance on Post Market Clinical Follow-Up (PMCF) studies. It is an update from the 2004 version and provides guidance to manufacturers and Notified Bodies and gives guidance on how to implement section 1.1.c of Annex X of the Medical Device Directive (MDD), which provides that

The clinical evaluation and its documentation must be actively updated with data obtained from the post-market surveillance. Where post-market clinical follow-up as part of the post-market surveillance plan for the device is not deemed necessary, this must be duly justified and documented.

The new MEDDDEV gives pointers as how to do this, see under points 1-7 below.

The new document follows the GHTF guidance, US FDA guidance and adds details on EU legislation. It emphasizes the increased need for PMCF studies to be considered in drafting the risk-based PMS plans in the light of the increased focus on clinical data introduced by 2007/47/EC revision of the MDD and AIMD directives.This increased focus largely boils down to manufacturers having to take post marketing surveillance seriously as a duty to actively collect post marketing information as part of the clinical evaluation cycle implemented in the medical devices directives, as I and my colleague Alex Denoon have argued many times. We cannot emphasize enough the importance of conducting a good legal risk review of the manufacturer’s subcontracting and supply agreements, and perhaps even social media chatter about a manufacturer’s devices. In general it is a good idea for a manufacturer to beef up its clinical post marketing data, if only to be able to substantiate comparative claims in litigation and have a meaningful discussion with healthcare insurance funds. Registry studies however are not addressed in any detail in this document, but may be addressed in subsequent guidance.

The guidance clearly but somewhat superfluously states that ISO 14155:2011 should be basis for clinical studies.

The important part in my view is that it provides details on the evaluation of PMCF by Notified Bodies (“NB”) because that provides the actual homework for the manufacturers as this is what the notified bodies will need to check with respect to PMCF. The NB shall as part of its assessment of a specific medical device (and therefore the manufacturer must itself – prior to that assessment):

  1. verify that the manufacturer has appropriately considered the need for PMCF as part of post market surveillance based on the residual risks including those identified from the results of the clinical evaluation and from the characteristics of the medical device in accordance with section 5 of the guidance;
  2. verify that PMCF is conducted when clinical evaluation was based exclusively on clinical data from equivalent devices for initial conformity in accordance with Annex II.4, Annex II.7, Annex III, Annex V.6 and Annex VI.6 of Directive 93/42/EEC and Annex II.4, Annex II.7, Annex III and Annex V.6 of Directive 90/385/EEC assessment and  that PMCF addresses the residual risks identified for the equivalent devices;
  3. assess the appropriateness of any justification presented by a manufacturer for not conducting a specific PMCF plan as part of post market surveillance and seek appropriate remedy where the justification is not valid;
  4. assess the appropriateness of the proposed PMCF plan in demonstrating the manufacturer’s stated objectives and addressing the residual risks and issues of long term clinical performance and safety identified for the specific device;
  5. verify that data gathered by the manufacturer from PMCF, whether favourable or unfavourable, is being used to actively update the clinical  evaluation (as well as the risk management system);
  6. consider whether, based on the specific device assessment, data obtained from PMCF should be transmitted to the NB between scheduled assessment activities (e.g. surveillance audit, recertification assessment); and
  7. consider an appropriate period for certification of the product in order to set a particular time point at which PMCF data will be assessed by the NB or specific conditions relating to certification for subsequent follow up. (This decision may be based on the residual risks, the characteristics presented in section 5 and the clinical evaluation presented at the time of initial assessment. Conditions the NB may consider could include the need for the manufacturer to submit interim reports between certification reviews, of the clinical data generated from the PMCF and post-market surveillance system).

As you see, this is homework for manufacturers as notified bodies will be expected to phase in compliance with these requirements and challenge manufactures when they have not yet complied by the time the next audit is up.

More general guidance on PMCF and its relation to legislation and interaction and cooperation with registries will be provided in subsequent guidance that will be drafted, according to a press release from BSi, which also mentions that attempts are ongoing to better embed PMCF and PMS planning into the future legislative framework in EU – as I have reported too from the mouth of the responsible persons at the Commission.

CE marking of apps: It Can Be Done and Here Is How

If there is one thing that I have learnt by now working with medical apps and medical device law is that physicians have little idea about rules for apps with medical functionality, companies are in the dark about how to CE mark their apps and EU regulators start to slowly devote some attention to this phenomenon, while the FDA is trying to keep the pace of developments. Regulatory compliance is a starting to take serious proportions in the field of medical apps and when physicians are using them more and more, it is just a matter of time before the scandals start popping up and patients suffer the consequences. Better be compliant from the start, that’s a good business model if you ever want to sell your company for a good price or avoid product liability lawsuits.

For those reasons it is very nice to come across an initiative that shows that It Can Be Done and Here Is How by the UK charity d4. d4 mission is to draw attention to the regulation of health apps and publishes guidance document to help health professionals, organisations, patients and industry.

It Can Be Done

With respect to the It Can Be Done  I would like to draw your attention to a new app, Mersey Burns ( a clinical tool for estimating burn area percentages, prescribing fluids using Parkland, background fluids and recording patients’ details) that was the first app to be officially registered at the UK MHRA as per the local implementation of the Medical Devices Directive. I am celebrating this event because I have no idea if apps have already been registered as class I devices in the Netherlands, for example. I also don’t know which app was the first to ever complete all regulatory requirements for the EU and I know there are some on the market already. However, this is a great example of development and deployment of compliant apps in the scope of the EU medical devices directives, which makes it newsworthy.

Here Is How

Regarding the ‘Here Is How’ d4 published a new guidance document to help draw further attention to the issue of health app regulation and provide practical guidance to both users and manufacturers of apps for the healthcare market. The primary purpose of this guide is to highlight the challenges that surround the provision and use of health apps from a regulatory standpoint, whether as a patient, health care professional, application developer, healthcare organisation, pharmaceutical or medical devices company. That’s right, this document is interesting for all parties concerned with the development, use and implementation of the app.

Although the guidance document has been developed primarily for the UK market, it is a very good guide for other EU member states too, as the system for regulation of medical apps will be similar if not identical because of the harmonization by the EU Medical Devices Directive. I can testify to that as I was involved in some last minute minor edits to the guide.

You can download the guide for free on the website of d4. It’s good reading if you are a hospital starting to work with apps, a developer starting to develop apps or a device manufacturer that wants to develop and deploy your first app. If you can read Dutch, here is a presentation that I did recently together with a French/Dutch company that has an telemedicine product on the Dutch and French markets about how to do compose a technical file and set up a quality system for software as a medical device.

Novelty destroying acts in clinical trials

A recently published decision of the European Patent Office’s (EPO) Board of Appeal about European patents and clinical trials provides for interesting reading and for some important pointers about how to deal with clinical trials for medicinal products but also for medical devices as to not destroy novelty of a patentable invention with invalidity as result.

The clinical trial concerned involved female contraceptive pills. It was established that only the researchers had signed confidentiality agreements, but not the patients enrolled in the trial. As required the patients had been informed of the nature of the medicinal product for the purpose of informed consent but not of the exact pharmaceutical form of the active ingredient in the investigative contraceptives. Finally, not all investigative medicinal products had been returned at the end of the trial.

The Board held, in conformity with its normal strict line of interpretation of the concept of novelty (which is stricter than the US line), that the patent was invalid for lack of novelty as

 is established board of appeal case law that if a single member of the public, who is not under an obligation to maintain secrecy, has the theoretical possibility to access particular information, this information is considered as being available to the public within the meaning of Article 54(2) EPC.

The respondents raised an interesting defense, arguing by reference to novelty cases involving implanted medical devices (T-0152/03 and T-0906/01) that any person involved in a clinical trial is implicitly bound by confidentiality. The Board however held that these cases concerned very different situations: the device trials concerned small groups of patients implanted with prototype investigational medical devices, whereas the drug trial at hand was a large trial in which patients were allowed to take home the medicinal products without confidentiality restrictions. Consequently, they could have shown or handed the medicinal products to anyone. The patients in the device trials referred to on the other hand could not explant their devices to hand them over to other people or have them inspected, so no novelty destroying act took place.

Some critical remarks on the facts: I think that the Board’s reasoning with respect to the implantable devices cases is only as good as the very specific facts of those cases referred to, involving balloon catheters and implantable spinal correction devices. Even if visual inspection may not immediately give away enough to destroy novelty because the device is implanted, I could conceive cases in which it would be possible for a patient with an implanted device to go to a ‘person skilled in the art’ with access to imaging devices or devices that can access the implanted device’s software to learn enough about the device to glean the inventive step claimed in the patent concerned. Also, I expect this argument to become more and more difficult to justify as imaging techniques and other ways to gain external access to the implanted device become more sophisticated.

What other lessons are there here to learn for medical devices manufacturers that provide devices for clinical trails?

  • During trial: if the trail procedure is not limited to an operative procedure to implant an investigational device or to use the investigational device in a procedure, and if the patient is not confined to the research facility for the duration of the trial, there is a risk that there is a novelty destroying act when the patient walks out of the trial facility with the device, whether implanted or not. This typically happens in trials where there is no need to hospitalize the patient for the duration of the trial and the patient visits a hospital a number of times as follow-up after the procedure.
  • Post-trial: be very careful with patients walking away with the devices, whether implanted or not. ISO 14155, the  GCP standard for medical devices clinical trials, imposes a duty on the investigator to provide adequate medical care to the trial subject after participation so the investigator will usually be inclined to allow a happy patient to keep the investigational device. If the device is left to the patient, whether implanted or not, and a patent has not been applied for at that moment, the manufacturer is taking a big risk with respect to novelty of the patent.

Also, remember that the novelty destroying acts cannot only take place with respect to a basic patent for a device that is tested in the trial, but also with respect to any patentable improvements that may be discovered during the trial. As manufacturer you will have spent time negotiating the ownership of possible patents for these with the investigator for the purpose of the clinical trial agreement. But that is only the first step, as these Board of Appeal decisions show. You also have to make sure that you review the IRB, informed consent form and protocol to make sure that these documents do not lead to novelty destroying acts with respect to any improvements. If you are unsure, make sure that the informed consent form includes a confidentiality clause. So, yet another step to include in the SOP for review of clinical investigation agreements.

EU court rules on no-fault liability for medical services with medical devices

The judgment in the Centre hospitalier universitaire de Besançon v Thomas Dutrueux, Caisse primaire d’assurance maladie du Jura case that I wrote about earlier has been handed down by the EU Court on 21 December and as expected, the EU Court followed its Advocate General. For a summary of facts and the judgment, see the EU Court’s press release.

As expected the EU court makes a very clear distinction between the field of no-fault product liability under EU directive 85/374, the product liability directive, and other sources of no-fault and fault-based liability and finds that no-fault liability for medical services involving defective medical devices is not precluded by the EU product liability directive, provided that such liability does not adversely affect the useful effect of the product liability directive. In the words of the EU Court:

it must remain possible for the producer’s liability to be put in issue when the conditions for such liability to exist are fulfilled. The service provider must therefore also be able to use a legal mechanism – such as that of bringing third-party proceedings as provided for by [national] legislation – allowing the producer’s liability to be put in issue.

The EU Court explicitly states that additional recourse for the consumer against the medical treatment provider in the form of no-fault liability for medical services involving a defective medical device is a welcome addition to no-fault product liability as it can contribute to enhancing consumer protection.

From a patient perspective and from a manufacturer’s perspective this development is to be welcomed, as it will prompt medical treatment providers to manage risks with respect to medical devices better. They may become more vigilant in detecting defects in device (whether or not those a manufacturing defects or defects caused by hospital use or adaptation) that otherwise might have been used on patients. Such risk management sometimes leaves a lot to be desired and can be complicated, especially when it involves implementation of software or networked medical devices in the hospital’s infrastructure.

Other solutions than no-fault liability for medical services are also possible: hospitals in the Netherlands have recently signed the Convenant Medische Technologie (Agreement Medical Technology), in which each hospital agrees to implement appropriate life cycle management systems under the direct responsibility of the hospital board. The report “Medische Technologie at Risk?” (“Medical Technology At Risk?”) identifies a number of areas where hospitals and medical devices producers could cooperate to reduce patient risk, e.g. in usability engineering and standardization of connections/interfaces of devices. Such cooperation would clearly fit in better risk management for the benefit of patients, as improvements to usability of devices are both part of the hospitals’ obligations to patients and of manufacturers’ clinical evaluation of their devices.

Developments and outlook re anti-kickback and corruption in the Dutch devices sector

Although no significant things happened in business compliance developments on a EU level for some time since Eucomed asked itself about guidance for sponsorship of conferences, things are very much in flux in the Netherlands. That may not be very exciting for many of our readers because the Netherlands is not such a big market and because they don’t read Dutch anyway, but for those who do and/or have activities in the Netherlands this should be interesting. Don’t forget, what your Dutch colleagues are doing could for example lead to Anti-Bribery Act prosecution in the UK, or get your company stuck with a big fine and a deferred prosecution agreement in the US under the FCPA. Even if your company is not doing anything wrong presently, the issue may pop up if you unsuspectingly acquire a company active in the Dutch medical devices market.

There is a great political push to provide for regulation with respect to business compliance in the medical devices sector, since the broadcast of an investigative reporting programme Reporter earlier this year. The government had already started to commission reports to do a quantitative analysis of possible business compliance issues in the Dutch medical devices industry, but this did not yield any evidence of kickbacks and other influencing of the medical profession by the medical devices industry. The Reporter program did not provide any evidence in that respect either, except suggest that any consultancy contract between a physician and a medical devices manufacturer would corrupt that physician. It also showed that orthopedic surgeons have a staggering lack of knowledge about medical devices legislation, which seems prevalent in the clinical profession. Anyway, the responsible minister felt obliged to do something and decided that she would impose a carbon copy of the CGR code system for medicinal products that works to satisfaction in the Netherlands. The branch associations of the Dutch devices industry were called upon to make this happen before 1 January 2012, or suffer the consequences.

And so they did, despite the fragmentation and number of branch associations active in such a small market (six) with links to different European associations such as Eucomed and COCIR (at least three). It resulted in a self-regulatory code that borrows heavily from the Eucomed code, but does conflict with it at some points. It also envisages setting up a similar dispute resolution system, which is more or less ready in the mean time but has not been made public.

I had the pleasure and honor of presenting the code to the members of FHI Medische Hulpmiddelen, one of the branch associations, on 16 November 2011. You can download my presentation here. As observed, those companies that already implement Eucomed will not find these rules shocking or impossible. What is different is that the code contains some – in my view – completely superfluous rules about advertising that moreover are not consistent with the legal requirements already in place for medical devices advertising in the Netherlands. I won’t go into a lot of detail here on the exact content of all the rules, as this is already in the presentation.

Just remember that on the demand side everybody that has something to do with the purchase decision is included in the concept of HCP, so also staff of the purchasing department or technical staff deciding on specs. On the supply side not only manufacturers are subject to the rules, but all resellers in the entire supply chain of the manufacturer. This is something that will take some time to settle in and may lead to misunderstandings, is my expectation.

What did become clear is that there is a lot of work to do in business compliance on the demand side – at the healthcare professionals. What you may not offer may not be requested, you might say. This is where the government still has some nuts to crack: although the minister has promised the industry that she will make the clinical profession comply with the code as well, these promises come back watered down significantly in a recent written deliberations containing answers to questions in parliament, published on 7 December 2011. The document merely mentions that there is ‘active attention’ for getting the clinical side to accept to be bound by the same rules, without any actually SMART statement how this would be accomplished. Physicians in the Netherlands are of course already bound by their own code.

Even more interesting is the next step: full transparency of relations between industry and healthcare professionals for the medical devices sector. The pharmaceutical sector will start with this in the Netherlands per 1 January 2012 and the medical devices sector is already subject to it in the US under the Sunshine Act. Before long the devices sector will have their own Sunshine Code in the Netherlands too, as some of my more compliant clients already predicted beginning of this year, as the Minister clearly hinted in her letter to Parliament of 24 November 2011. She does not mention any specific date for it, but it is clear that the devices industry is expected to get to work on this. There is of course nothing to stop companies from starting with this already. A client recently informed me they would start since they needed to do it in the US anyway.

So, interesting times ahead for the devices industry in the Netherlands. As I have argued in the past when discussing “business compliance reloaded”: compliance is an opportunity, a tool to out-comply and thus out-compete your competitors.

More on mobile medical apps, and on clinical decision support systems

I have been running around a lot lately doing presentations on conferences about medical devices and software, so I though it would be useful to give you a round-up on that subject.

Medica and FDA guidance on mobile medical apps

To that end, I would like to share with you this presentation of today at the Medica 2011 in Düsseldorf, Europe’s largest medical devices fair. I was invited to speak about the FDA’s draft guidance on mobile medical apps, so I decided to – besides visit clients and my friends of the Continua Health Alliance to catch up – do that and also bridge the gap to the EU from that document. As I and others have argued before, this guidance works very well in the EU too. There are some novelties in this presentation: a summary of the comments to the FDA document and a timeline for the document.

The short version of the summary of the comments made to the FDA about the draft guidance:

  • Intended use approach leads to too broad scope and is not clear enough; FDA should specify positively the intended uses that trigger regulation
    • Define “health and wellness”
    • Impact of consumer use versus professional use in regulation
    • Low risk products should be exempted
  • Normal accessory rule problematic in mobile and electronic health scenarios, because risk profile of these accessories is not necessarily  the same as parent device
  • More guidance is needed for roles and responsibilities of other parties involved in the manufacturing (vendors), network services (ISPs) and distribution (app stores)
  • Provide for modularisation of software and software specific classification rules

 Modularisation

Although the FDA seems to be ahead of the EU in terms of software regulation, there is one area where the EU seems to be ahead of the US is on modularisation of software. This a major concern for the vendors of modular software, because having to also certify non-medical functionality (especially if that is the biggest part of a software package) poses a siginificant regulatory burden. The draft MEDDEV that I have referred to earlier actually contains a model for ‘modularisation’ of software that allows a manufacturer/vendor of a larger software system to slice it up in modules regulated as medical device and others that are not. As the text of the draft MEDDEV currently stands the manufacturer must then make the assessment that

“the whole combination, including the connection system must be safe and must not impair the specified performances of the devices. Any restrictions on use must be indicated on the label or in the instructions for use.”

This, you will of course have guessed correctly, is identical to Annex I point 9.1 of the Medical Devices Directive and 3.1 of the IVD Directive, which the MEDDEV refers to explicitly. Old rules for new solutions, I am curious how this will turn out. I know that at least some of the EU member states have criticised this solution, so it may yet change in the final version, who knows.

 Roles and responsibilities

Since the EU review of medical devices will address post marketing surveillance much more seriously throughout the supply chain, it is my expectation that there will be some attention in the new regulation to the roles and responsibilities of other parties involved in the manufacturing (vendors), network services (ISPs) and distribution (app stores) that the market asks the FDA for.

General health and wellness apps

Although the FDA has now been asked to clarify how it will exercise its enforcement discretion with respect to software for low risk health and wellness intended purpose, the EU does not have that freedom to operate since its medical devices concept is binary and therefore the related enforcement capabilities cannot be exercised on a sliding scale. Of course national authorities may still use other safety related legislation such as the General Product Safety Directive and Unfair Business to Consumers Commercial Practices Directive for policing these apps. For example, that latter statute contains a pretty hard and fast absolute blacklist prohibition rule on “falsely claiming that a product is able to cure illnesses, dysfunction or malformations”. Another nice one for mobile medical apps in general that do not comply with the rules is the blacklisted: “Claiming that a trader (including his commercial practices) or a product has been approved, endorsed or authorised by a public or private body when he/it has not or making such a claim without complying with the terms of the approval, endorsement or authorisation.” That is fully applicable to the sale of medical apps to consumers in the EU.

What is next?

The FDA received a little over 90 submissions on the draft guidelines, some very substantial (100+ pages!), so it will take them some time to ruminate and digest all these comments. As far as I know they are expected to come out with a final guidance document somewhere in the first quarter of 2012. However, if you think that’s it for medical software – think again. The FDA is already planning additional guidance on Clinical Decision Support Systems (CDS) once they have finalized the Mobile Medical Apps guidance. And these may overlap in certain cases of course. So all you manufacturers mobile medical apps and other software with decision support functionality: you are quite there yet for the moment.

Developments in EU product liability for medical devices – or not

Now here is an important case for the medical devices industry. Although product liability litigation has not (yet) evolved into the type of bet the company litigation it can be in the United States and cases about interpretation of the Product Liability Directive have been few, they do shape the scope of no fault liability in the EU of manufacturers of medical devices for their products.

No earlier EU cases about product liability for medical devices

In this present case, C‑495/10 Centre hospitalier universitaire de Besançon versus Thomas Dutrueux,Caisse primaire d’assurance maladie du Jura, the Advocate General has just issued his opinion on 27 October 2011 and as you will have noticed if you clicked on the link to the opinion, it is not (yet) available in English, although it is available in among others German, French, Spanish and Italian. So for those that do not read any of those languages, nor Estonian, Latvian, Greek, Portuguese, Finnish or Swedish either, I will summarise. As a result, this post will be longer than you are used to from me. A good summary is also provided in the English version of the Court’s press release about the AG’s conclusion.

The case  involves a medical device indirectly, which is a novelty in itself as the only really relevant previous product liability directive cases on substantive points of law so far were about medicinal products. This case concerned a patient suffering burns from a malfunctioning electrical matrass used during surgery.

The French hospital was subsequently found liable for this because the French rules that implemented the EU product liability directive have been interpreted as to instate a no-fault liability for hospitals for damages suffered by patients as a result of devices used by the hospital in the course of treatment and care, even if the hospital was not to blame for the malfunction  (see points 7 and 8 of the conclusion).The hospital contested this on appeal, arguing that the ‘closed system’ of no-fault liability for products under the EU product liability excluded this type of liability to be imposed on a medical care service provider. The French appeal court decided to check this with the European Court and asked the European Court the following question:

“Does Directive 85/374 limit the possibility for Member States to define the liability of persons who use defective equipment or products while providing services and, in so doing, cause damage to the recipient of those services?”

If so, the French court wanted to know if the EU product liability directive permits

” the implementation of a liability system based on the special situation of patients in public health establishments, in so far as it recognises, inter alia, that they have the right to obtain from such establishments, even in the absence of fault on the part of those establishments, compensation for injury caused by the failure of products and equipment which they use, without prejudice to the possibility for the establishment to seek indemnity from the producer”

In fact the French court asked the two questions the other way around, but I agree with the AG that this order is more meaningful for answering the questions.

Can EU member states have rules for no-fault liability of service providers that use defective equipment?

As to the first question the AG finds that there would be two theoretical cases in a service provider that uses a defective product in the provision of the service could be liable under the EU product liability directive:

  • the service provider is liable under article 3 (3) of the directive as “each supplier” in case the producer of the product cannot be identified; or
  • service providers are somehow included in the group of potentially liable parties under the product liability directive

The AG finds that article 3 (3) only applies to suppliers forming part of the actual distribution chain of the device, and not to any end users like the service provider using a product that turns out defective (points 28-31). He bases this conclusion on an interpretation by analogy based on another EU directive concerned with product safety and which field of application flanks that of the product liability directive, the General Product Safety Directive. That directive does specify in recital 9 that it

“does not cover services, but in order to secure the attainment of the protection objectives in question, its provisions should also apply to products that are supplied or made available to consumers in the context of service provision for use by them. The safety of the equipment used by service providers themselves to supply a service to consumers does not come within the scope of this Directive since it has to be dealt with in conjunction with the safety of the service provided.”

The same is true under the product liability directive, argues the AG: the use of  products  in the provision of a service must be dealt with in relation to the liability for the service as such, which is outside the scope of the product liability directive.

The AG finds that service providers are not among those persons potentially liable under the product liability directive either, as this group is a closed system according to the case law of the European Court and the Court never expanded the group of liable persons to include service providers, although it had the opportunity to do so in at least one case (points 35-39). Furthermore, the Court has always been explicit in that the product liability directive did not apply outside the scope of what it regulated explicitly and that this did not include liability of service providers for defective products (point 43).

Ergo, no liability for service providers for defective products used in the provision of the service on the basis of the product liability directive says the AG. Mind you, the court’s case law also provides that other forms of liability not related to products and/or having another basis than no-faut liability (e.g. based on negligence) still remain possible.

In case the Court disagrees, the AG submits that the Court should answer the second question.

What about a no-fault liability system based on the special situation of patients in public health establishments?

If service providers are not liable directly, does the product liability directive exclude a system that allows patients hat they have the right to obtain, even in the absence of fault on the part of the service provider, compensation for injury caused by the failure of products and equipment which they use, without prejudice to the possibility for the establishment to seek indemnity from the producer? The answer to this question depends on the legal basis of such a system. Is it the same as the product liability directive, then it is excluded. If not, it is allowed, says the AG (point 51-52).

The AG points out that the referring court is of the opinion that the legal basis of the French rules concerned is not the product as such, but rather the special relationship between the hospital and the patient, resulting in the definition of a group of liable persons other than under the product liability directive, and consequently in a distinct legal basis (point 57).

However, the logical consequence of this is that if  the European Court should disagree with this analysis of the legal base, then it must find that the French rules do have the same legal base, thereby expand no-fault liability for defective products to service providers and are consequently preempted by the product liability directive.

Analysis and context

The AG’s opinion is, in my opinion, neither controversial nor revolutionary and I expect a judgment from the European Court along the same lines. We will be sure about this in a couple of months, when the European Court will hand down its judgment. Statistics do show that the European Court follows its AG in the large majority of cases.

Yet the case is important for the medical devices industry as AG’s opinion, and likely the Court’s judgment, confirms the line of case law with respect to the use of products in the course of the provision of medical services as it was set out in the Veefald vs Århus case from 2001. That case concerned the question if a hospital could be liable for a product manufactured and applied by it in the course of the provision of a medical service (in that case: production of perfusion fluid to be used in a kidney transplant procedure). In that case it was not disputed that the product was defective, but only whether it had been ‘placed on the market’, because it had never left the hospital’s medical sphere. The European Court very clearly separated on the one hand the provision of the medical service as such and on the other hand the placing on the market of the (defective) product, which was subsequently used in the provision of the medical service. Only the latter fact pattern and its consequences (placing on the market of a defective product that subsequently harms an individual) is regulated under the product liability directive. The liability for the provision of the service, and also the question whether the use of a defective product in the provision of medical services is negligent or even subject to no fault liability, falls outside the scope of the product liability directive and is still within the member states’ competence.

As a result, it will depend on the member state concerned what the courses of action of the patient are. The patient can sue the manufacturer of the defective medical device for product liability under the EU product liability directive’s regime, and may sue the hospital on the basis of national law governing the provision of the service, if and to the extent that is possible. Since that latter situation is not harmonised, this leads to the situation that patients in different EU member states will have varying recourse against providers of medical services on varying legal bases. The AG addresses this point explicitly as the Commission had pointed out that the applicability of the contested French no-fault liability for hospitals’ use of defective products was the only recourse for the patient concerned in this case, because since the injury occurred during surgery carried out on 3 October 2000, the injured person’s action against the ‘producer’ of the defective mattress, within the meaning of the directive, would be time-barred (10-year limitation period). I mention this specifically because the European Court mentions is very explicitly in its press release so it must attach importance to this and want to alert external parties to this fact. It may even want to send a signal that harmonisation in this area would be a good idea. Taking into account the EU’s plans to promote cross-border provision of medical care (e.g. through the harmonisation of medical devices reimbursement and the Cross Border Patient Rights Directive), there may be terms to harmonise the liability for the provision of medical services as well, if a functioning internal market for medical services is to be created. Indeed, these were the very considerations that form the cornerstone of the product liability directive (see recital 1 of that directive). The question of course will be if this is politically feasible.

Standalone software regulated as medical device: a look under the hood of the draft MEDDEV

Sometimes you have to go far away to learn a lot about thing close to home and that is what happened to me at the RAPS Regulatory Convergence Conference that I am currently attending in Indianapolis. There was an interesting presentation of Gregory Martin from BSi Healthcare about the developments in EU medical device law with respect to standalone software and I bumped into a bunch of other interesting people that I had chats with, and voila, I was able to reverse-engineer the following about the MEDDEV in the works on EU regulation of standalone medical devices software. More in general the conference has been very interesting and I have learned more than on many conferences I attended in the EU.

In any event I thought it was a good occasion to continue the feuilleton on developments in regulation of software as medical device further to the COCIR workshop I attended recently.

The tree for MDD

I learned that the document will contain two convenient decision trees, one for stand alone software under the Medical Devices Directive (MDD) and the other for stand alone software under the in vitro diagnostics devices directive.

Based on the presentation and the conversations I had I could more or less reverse engineer the decision tree for the MDD, which seems like a refined version of the COCIR version published some time ago and according to my prediction will look more or less like this (abbreviations: SW means software and MD means medical device and MDD means Medical Devices Directive). I knocked it together quickly with NoteTaker HD on my iPad so apologies for the rough graphics. Some clarification:

  • if you answer “no” to question 1, the software does not contain any instructions or subroutines in any programming language and you are probably dealing with an electronic document containing a protocol, for example;
  • if you answer “no” to question 4, you are probably dealing with software for statistic purposes, which – even if used in clincal trails – is not a medical device.
  • if you answer “no” to question 6, you are dealing with software for all types of use in a medical setting but not with a regulated intended purpose, like reimbursement software, staff scheduling etc.
  • if you answered “yes” to question 6, you are probably dealing with software that influences a medical device one way or the other and assists it to achieve its intended purpose while not falling within the scope of the definition of medical device itself, like for example an iPad app that allows a nurse to monitor and control infusion pumps in the ward from the nurses station.

I expect that especially question 6 will be very difficult to work with in practice and will cause a lot of interesting borderline problems.

There should be an IVD decision tree in the document too, but I was unable to get enough information about that to make a reliable recontruction. Maybe at a later stage!

Placing on the market / putting into service

Another interesting observation was that internet software may be covered if the application of it is triggered by the concepts of “placing on the market” and “putting into service”. That does not sound like a surprise, as the FDA draft guidance on mobile medical apps also explicitly proposes to regulate this. the consequence is that it  would bring many websites containing virtual doctors into the scope of the MDD, as I have argued is the case already, without needing to resort to guidance. It will lead to many unhappy doctors needing to CE mark their websites. The concept of “placing on the market” is not suited to deal with this at all if we look at the Commission Interpretative Notice on this Point, as it is written mainly for physical devices, which standalone software might be only if sold on a physical carrier. That is usually not the case with apps, to “putting into service” seems more relevant to delivery of functionality via the web, whether or not is is subsequently run locally or not. Putting into service happens at “the stage at which a device has been made available to the final user as being ready for use on the Community market for the first time for its intended purpose”. So, that happens already when offered in the app store for Apple or Android apps or when otherwise offered for download, and not only when the device actually starts to run. This will have regulatory consequences for intermediaries selling apps.

Modules

Some words on modules. I heard that the guidelines in their current draft (which is still under discussion and there is disagreement on specifically this point) contains a module on modular software that proposes to only regulate those modules of a larger interoperable package of which the intended use falls within the scope of the MDD. However, it is up to the manufacturer to define the boundaries correctly in this respect and to identify clearly what is regulated and what is not. This is of course not very helpful and rather difficult for a manufacturer. What is more however the draft guidance proposes that if modules are intended for use in combination with other modules in a software structure, the whole system architecture, including all connections must be “safe” and must “not impair the specified performance of the regulated modules”. This looks complicated and likely unworkable to me, because it creates an additional evaluation criterion under the MDD that is not required under the statutory instrument itself. Also, the notion of “safe” is something that really clashes with all that is known about risk management and risk/performance evaluation (only the cornerstone of the MDD), because when is a risk sufficiently managed to be “safe”? And how do you prove that in the technical file? This criterion raises more questions than it answers, but then again I understand this is one of the points that is still debated between those involved. My advice: remove this and either certify the system as a whole or justify why a module is stand-alone (yes, stand-alone so not dependent on other software) software and can be certified as device as such. We don’t need guidance to make this already existing possiblity more complicated.

So, food for thought

At least, for me, and I will mull this over and most likely there will be more to say about this, sooner or later.