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.
medicaldeviceslegal 
Hi Erik
This comment is maybe more valid for an earlier article on this forum.
The questions that will rise after the publication of the new EU-guideline (MEDDEV) will be numerous. There are some wordings in the draft guideline that could have been better, especially among the examples.
I just want to mention some traps to avoid for manufacturers and regulators:
– to make qualification decisions merely based on the name of the software system.
o Qualification shall be based on how the manufacturer has defined the intended use, whether or not the software has a medical purpose according to the definition of a medical device in the medical device directives.
– to divide the system into too small modules.
o Don’t divide the system into ”screws and nuts”. A screw or a nut seldom has a medical purpose. Neither does a single memory module or a single data transmitter. The devices we are interested in are most often composed by several software functions that each of them might not be ”medical” but that combines into a system with a medical purpose.
– To define the system only in technical terms
o A system that collects information from “A”, transmit the information to “B”, calculates (something) and then display the result in combination with other information on device “C”. That is not a medical purpose. The intended use has to describe the benefit for the patient relating to the prerequisites in the definition of a medical device, such as support for diagnosis, treatment or alleviation for handicap.
The example Electronic Patient Record systems is interesting. They are not defined by name since the might have a range of different functions/modules in combination. Most modern EPR’s have functionalities with a clear medical purpose, e.g. a medication module.
To divide an EPR in it’s different modules for different qualification, as MD or not, is not always appropriate. The combined system has a medical purpose that might be another than each module. Further the relation between the modules may be such that they are not independent. So EPR’s are definitively not excluded by the qualification criteria in the draft guidelines.
It is a foreseen problem that the draft guideline might give that impression.
Please note that whilst we are willing to give any help and advice we can, any views given by us on the interpretation of the Medical Device Regulations represent our best judgement at the time, based on the information available. Such views are not meant to be a definitive statement of law, which may only be given by the Courts.
Best Regards
Mats Ohlson
The Medical Products Agency, MPA, Sweden