It is neither the technology inside an App nor its function, it is just ... Product Design .... COCIR has a majority of European-based companies in its membership.
How does the Evolving Role of Medical Device Software Intersect with the Regulatory Environment ? Koen Cobbart, Georg Heidenreich COCIR Medical Software Chairs
In the old days… • … Software could not directly harm anyone, since either – software controls a device or – generates display for use by medical professionals
• such that there was either – a medical device (MD) or – medical doctor (MD) actively contributing to the hazardous chain of events.
page 2 of total
EU „Standalone“ Software as a Medical Device per MEDDEV-Guidance 2.1/6 of 2012 Criteria
Embedded / Part_of_MD_Software
Software not used for medical purposes.
Software supports medical intended use
Not „medical“
Accessory
Purposes of Art 1.2a
Software with medical intended purpose as of Art Software supports 1.2 without medical device while achieving the medical requiring a medical Just search, device hardware send, store purpose
Software embedded in a medical device
No processing
„Standalone“ Software – As a Medical Device
Qualification Result
EU - Qualification „Medical Device“ page 3 of total
1. Qualification • It is neither the technology inside an App nor its function, it is just the medical claim in product-related documents that qualify some software as a medical device. • Each foreseeable hazard has its root in the manufacturer’s documentation with – Intended use (clinical scenario, target disease, context of use) – Instructions for Use (explanation of essential medical function, specification of data at the interfaces)
page 4 of total
2. Mitigation • Manufacturer can only mitigate risks through text: – Limit the intended use – Clearly specify the intended clinical context and usage scenarios including exceptions and limitations – Clearly specify identifiers (to avoid confusion of documents, people, organizations) and terms ( to avoid confusion of clinical concepts and physical units/measures)
• There is no Package Insert with an App, but: – The user interface, the start screen and the About box may specify Intended Use and Instructions for Use !
page 5 of total
3. Product Design • Splitting the Software into Modules, may allow the manufacturer to put most of the software modules as “non-medical” on the market as they only implement send / store / search functions, • While only few modules implement a medical function, such that only a small part of the software falls under MD regulation. • Furthermore, adding a (medical) user-programming feature on top of a send/store/search software does not make it a medical device, while it allows the medical user to implement medical functionality.
page 6 of total
4. Placing on the Market • “Placebo trials” are not practical for software, but comparison with historical data is ! • It is unclear whether the “app store provider” or the “app developer” has the role of the “Legal Manufacturer”. • In real EU life, there is no police monitoring all apps. • For apps with low download numbers and from a small development team, the likelihood of being “seen” is very low.
page 7 of total
5. Using software in clinical settings • Medical hardware devices are being used close to the patient, such that medical professionals can do plausibility checks on the spot: right patient identity, right diagnosis, plausible symptoms of disease, plausible treatment plan (dosage!), plausible effects of treatment • Software is often used remote to the patient, such that these implicit plausibility checks are now missing ! • Complex user interfaces and personal smartphones distract health professionals from their work ! (says FDA incident database).
page 8 of total
6. Incidents • Investigation reveals that nearly all hazardous-chains-ofevents with software are related to – Complex user instructions – Unclear user interface – User/Integrator not understanding the software’s internal status and mode – Unintended operation or confusion of data elements
• Usability, Interoperability and Security are the real root causes when software plays a role in hazards ! • In tomorrow’s regulation “security, usability,interoperability” will be the new “safety” ! page 9 of total
Risks of Software as a Medical Device
innovation
foreseeable effects misuse
Legal Manufacturer will be responsible for these effects here…not for each indirect effect page 10 of total
Existing Medical Device legislation is not appropriate for SaMD – Current focus is on direct consequences and immediate sideeffects • … which don’t exist for software • Risk assessment (“sequence of events”) not explained properly by existing legal frameworks
– Software outcomes (data) are not considered appropriately • Real-world incidents are indirect consequences of SaMD
– Testing is required but software development technology is optional • Real-world good software uses modern development technology
page 11 of total
Practical Situation “In trying to find fault I think a judge will first try to establish • whether a product had a defect, and if it didn’t, people will look at whether – it was constructed according to state of the art, – whether it contains a clear user-machine interface with adequate safeguards such as warnings and precautions. – And finally, the focus will go whether a user or integrator respected those instructions and safeguards. “ (K. Cobbaert)
page 12 of total
Issues with IoT • “In the internet of things, where an app relies on input from a sensor, • runs on platforms such as smart watches and smart clothing and possibly cloud computing and other IT network elements, • it gets increasingly complicated to establish who is liable for what if all these items are manufactured by different parties.”(K. Cobbaert)
page 13 of total
IMDRF* SaMD Risk Categories * International Medical Device Regulators Forum
• A. Derive risk category from risk when being used as intended – How does the SaMD meet one or more of the medical purposes – What is the context of use of the SaMD » Who it’s for - How they will use it - How can output be used » If applicable: patient condition- target population target disease, disorder, condition or risk factor of interest disease type(s)- limits of SaMD use
• Describe the SaMD’s core functionality, including » specific functionality that is critical to maintain performance & safety, » attributes identified by risk management process undertaken by the manufacturer of SaMD
• B. Derive controls from classification page 14 of total
Practical Non-Medical Software in the EU Technical connectivity is not necessarily a medical claim • Publish consistent marketing material without medical claims
Small companies may likely remain under the radar (make technical claims, what the FDA calls ‘tool type’ indications) • No written medical claim –> not a medical device
Small companies targeting big sales may cooperate with a larger distributor acting as “legal manufacturer”. Being a medical device or not depends on the DOCUMENTs not on the software ! • If you publish medical use for your software then it is a medical device !
- MANTRA LOOK AT THE page 15 of total INTENDED USE
The Future of the Software Package Insert ? CONSIDER THE INTENDED USE
•
•
DESIGN FOR MODULES
•
ALLOW USERPROGRAMMING
•
CONSISTENT DOCUMENTS
Thank you for listening ! page 16 of total
COCIR Key Facts & Figures •
COCIR has a majority of European-based companies in its membership. Two types: – 32 companies: mixture of SMEs, MidCap and Large Companies – 13 National Trade Associations representing approx 7 000 companies and regrouping 90% of market in Europe for our sector
•
Unique situation : – Mixture of healthcare, IT and telecom industries – Medical imaging and health ICTs are among the most innovative and dynamic industry sectors in Europe and globally
• • • •
•
Global annual market: €80 billion Investment annual growth rate: 5% R&D investment: up to 8% of sales volume In 2012 alone, volume of major categories of manufactured imaging products sold in the EU 27 summed up to 860 million number of units, for a value of over €8 billion*. In Europe, around 500 000 workers are employed in the healthcare sector at large. Over 80% of medical companies are SMEs. page 17 of total
(*) source: Eurostat, Statistics on the production of manufactured goods Value ANNUAL 2012 http://epp.eurostat.ec.europa.eu/portal/page/portal/prodcom/data/database
COCIR’s Focus: improve market access • Provide COCIR’s members with competence towards policy makers in Europe and outside • Contribute to sustainability of healthcare systems through integrated care approach • Promote Research and Innovation as a key enabler for economic growth • Drive global regulatory convergence (registered once, accepted everywhere) • Optimise use of International standards • Push for national and regional deployment (eHealth) • Pro-active in Green Technology (Eco-Design)
page 18 of total
COCIR Company Members
page 19 of total
COCIR National Trade Associations Members
page 20 of total
Industry sectors covered by COCIR COCIR is a non-profit trade association, founded in 1959 and having offices in Brussels and China, representing the medical technology industry in Europe COCIR covers 4 key industry sectors: • Medical Imaging • Radiotherapy • Electromedical • Health ICT
Our Industry leads in state-of-art advanced technology and provides integrated solutions covering the complete care cycle page 21 of total
