Software as medical device – regulatory requirements, product liability
I attended an interesting seminar today about software as medical device organised by NEN, the Dutch standardisation institute. Speakers at the seminar highlighted the different views on this subject from the perspective of the Dutch competent authority, manufacturers of medical devices, hospitals and the legal/regulatory perspective. My presentation on legal and regulatory issues (in Dutch) is a condensed version of three other earlier presentations of mine in English that deal with the same subjects, which can be accessed here (medical devices regulatory & software), here (control over subcontractors) and here (software and product liability). It is also based on an earlier article I wrote with a colleague.
My take-home of the seminar is that manufacturers are struggling with the situation of insufficient standards for software as medical device and with the borderline between software as medical device and software functioning in a medical setting (e.g. electronic patient files). With respect to the borderline it was argued from the side of the manufacturers that it would be more productive to develop validation and quality criteria for all software functioning in a medical setting rather than to have to determine on a case by case basis whether a particular program constitutes a medical device or not. Some illustrative examples of this borderline (as well as other valuable guidance) are given in an excellent document drafted by the Swedish Läkemedelsverket, the Swedish competent authority. As far as I am aware, this document is now being used as basis for the MEDDEV on software that is currently in advanced stages of development. I have seen a recent version of that draft MEDDEV and it is remarkably similar to the Läkemedelsverket document.
By the way, borderlines between medical devices and medicinal products are also a very interesting subject (for me at least) and I will be speaking among other things about that subject on the DIA Euromeeting in Geneva on 28-30 March 2011. I will also co-chair a half-day seminar about medical device law for pharma industry people at that meeting.
Hospitals, on their part, have problems with implementation and maintenance of software because of the constant influx of new software that needs access to and/or runs on hospital IT infrastructure and individual medical devices. They are faced with issues resulting from software being implemented in a wider setting, being customised locally, interfaces being developed that create new dependencies and the decision whether or not to have the manufacturer maintain the software (and if not, whether to conduct maintenance according to manufacturer specs or not).
The competent authority outlined its enforcement policy for the next year, which will also focus on software as medical device. It warned the audience that it was aware of severe underreporting of incidents and that it could identify at least some of the manufacturers that are underreporting, by reference to the reports of their competitors. This year’s policy focuses on classification (especially classification in a too low risk class) as well as missing CE marking, both highly relevant for software as medical device.
I discussed legal aspects, including some regulatory problems, how to control your subcontractors for software as medical devices manufacturer and how to deal with product liability issues. As said above, all these issues were condensed from two earlier presentations (this one and this one). My argument is that manufacturers have a lot to gain from improving their contracting strategies with third-party developers, which I find presently underdeveloped and insufficient to meet their obligations under the EU medical devices rules. In general manufacturers often forget that they are responsible for conformity of the device with the medical devices rules, and not their suppliers. Manufacturers can do a much better job than I normally see at encapsulating their software suppliers in their quality systems. And notified bodies might do a better job in checking that this actually happens.