Sundhedsapps Fra Design til Klassificering Faisal Kamal Cand. Scient. i Lægemiddelvidenskab Regulatory Affairs Specialist, Bech-Bruun
Agenda Introduktion Retlig baggrund for CE-mærkning Hvad betyder design for risiko-klasse? Mini WORKSHOP Overvejelser i forbindelse med designproces Spørgsmål
Introduktion Regulatory Affairs Specialist hos Bech-Bruun Cand. Scient. i lægemiddelvidenskab, Københavns Universitet, Sundhedsvidenskabeligt fakultet (tidligere FARMA) Arbejdet selvstændigt med digital medie-produktion igennem flere år og har erfaring med både produktion af digitale medier samt rådgivning om brugen af digitale medier Primært serviceret kunder, der beskæftiger sig med medicinsk udstyr, jura og livstils/luksusprodukter Faisal Kamal fka@bechbruun.com Har rådgivet små og mellemstore virksomheder ved flere lejligheder bl.a. ved iværksættermessen i Forum igennem denne periode
Introduktion Har gennemgået mere end 700 mobilapplikationer til kronisk syge og næranalyseret 280 af disse. Fandt 112 mobilapplikationer, der kunne karakteriseres som medicinsk udstyr, men som manglede den nødvendige CE-mærkning Var for nylig med til at starte debatten vedrørende sundhedsapps og patientsikkerhed på TV2 NEWS
Specialetitel: An exploratory study on mobile applications for disease management: Overview of available applications, regulatory demands & key stakeholder viewpoints Forfattere: Faisal Kamal og Neda Javed Sted: Introduktion Københavns Universitet, Det Sundhedsvidenskabelige Fakultet, Institut for Social Farmaci Vejleder: Sofia Sporrung Kälvemark Beskrivelse: Metode inspiration: Gennemgang af sundhedsapps Gennemgang af Apple s app store ved søgning på kronisk sygdomsrelaterede termer igennem itunes Gennemgang af retlige dokumenter og vejledninger Analyse af nationale lovgivningstekster samt vejlednings tekster fra EU og FDA (USA) Interviews Kvalitative interviews af repræsentanter fra interessentgrupper indenfor sundhedsområdet Content analysis Content analysis Qualitative descriptive analysis Omfang: 5 søgetermer brugt, (cancer, heart disease, diabetes, asthma, depression, migraine) 720 apps gennemgået 280 apps vurderet for retlig status Resultat: 112 apps identificeret som muligt medicinsk udstyr med manglende CE-mærke. Bekendtgørelse om medicinsk udstyr Bekendtgørelse om markedsføring af medicinsk udstyr Lov om markedsføring af sundhedsydelser Lov om behandling af personoplysninger MEDDEV 2.1/6 Mobile Medical Applications Guidance for Industry and Food and Drug Administration Staff (2013) Skabelse og gennemtestning af ny-udviklet metode til kvalificering/klassificering af sundhedsapps Interview subjekt repræsenterede: Medico-industrien Lægemiddelindustrien Læger Patientforeninger Læger bruger apps i deres behandling af patienter. Lægemiddelindustrien udvikler apps til deres produkter. Patientforeninger laver apps som hjælpere til patienter. Medico-industrien har fokus på reglerne for apps. Alle interessenter var positive overfor idéen med at give apps på recept eller give mulighed for at læger kan anbefale apps.
Retlig baggrund for CE-mærkning
7 Retlig baggrund - definition BEK nr. 1263 af 15/12/2008 - Bekendtgørelse om medicinsk udstyr 1, stk. 2 I denne bekendtgørelse defineres medicinsk udstyr som: Ethvert instrument, apparat, udstyr, software, materiale eller anden genstand anvendt alene eller i kombination, herunder software, som af fabrikanten er beregnet til specifik anvendelse til diagnostiske eller terapeutiske formål, og som hører med til korrekt brug heraf, og som af fabrikanten er beregnet til anvendelse på mennesker med henblik på: a) Diagnosticering, forebyggelse, overvågning, behandling eller lindring af sygdomme, b) diagnosticering, overvågning, behandling, lindring af eller kompensation for skader eller handicap, c) undersøgelse, udskiftning eller ændring af anatomien eller en fysiologisk proces, eller d) svangerskabsforebyggelse, og hvis forventede hovedvirkning i eller på det menneskelige legeme ikke fremkaldes ad farmakologisk, immunologisk eller metabolisk vej, men hvis virkning kan understøttes ad denne vej.
8 Retlig baggrund MEDDEV 2.1/6 - Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices Med hensyn til kvalifikation som medicinsk udstyr: if the software does not perform an action on data, or performs an action limited to storage, archival, communication, simple search or lossless compression (i.e. using a compression procedure that allows the exact reconstruction of the original data) it is not a medical device Altering the representation of data for embellishment purposes does not make the software a medical device. In other cases, including where the software alters the representation of data for a medical purpose, it could be a medical device Simple search does not include software which provides interpretative search results, e.g. to identify medical findings in health records or on medical images if the software is an accessory to a medical device, it is not a medical device, but it falls under Directive 93/42/EEC Software made available to the user over the internet (directly or via download) or via in vitro diagnostic commercial services, which is qualified as a medical device, is subject to the medical devices directives
9 Retlig baggrund MEDDEV 2.1/6 - Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices Med hensyn til applikationer, der fungerer som moduler: Computer programmes used in healthcare mostly have applications which consist of both medical device and non-medical device modules. The modules which are subject to the medical device Directives [ ] must comply with the requirements of the medical device Directives and must carry the CE marking It is the obligation of the manufacturer to identify the boundaries and the interfaces of the different modules If the modules which are subject to the medical device Directives are intended for use in combination with other modules of the whole software structure, other devices or equipment, the whole combination, including the connection system, must be safe and must not impair the specified performances of the modules which are subject to the medical device Directives
10 Retlig baggrund Følgende spørgsmål kan opstilles: 1. Hvad er mobilapplikationens tilsigtede anvendelse? Er den tilsigtede anvendelse med applikationen at diagnosticere, forebygge, behandle, overvåge eller lindre en sygdom? 2. Hvordan virker mobilapplikationen? Behandler applikationen data på en måde, der adskiller sig fra lagring, arkivering, kommunikation, simpel søgning eller databevarende kompression? 3. Er det hensigten, at applikationen eventuelt skal fungere sammen med andet medicinsk udstyr? Kan applikationen bruges til at drive eller påvirke brugen af andet udstyr? 4. Er det hensigten, at applikationen skal bruges i kombination med andet software eller indgå i et system som et modul? Er det eksempelvis hensigten, at mobilapplikationen kan bruges med en elektronisk patientjournal?
11 Retlig baggrund Kravene for CE-mærkning er beskrevet i bilagene til bekendtgørelsen og er forbundet med risikoprofilen på applikationen. Sammenhængen mellem risikoprofil og krav til sundhedsapp Klasse I Bilag VII (undtagen app s der indeholder en målefunktion (IIa)) Klasse IIa Bilag VII kombineret med: Bilag IV eller Bilag V eller Bilag VI eller Bilag II (minus punkt 4) Klasse IIb Bilag III kombineret med: Bilag IV eller Bilag V eller Bilag VI eller Bilag II (minus punkt 4) Klasse III Bilag III kombineret med: Bilag IV eller Bilag V eller Bilag II
12 Retlig baggrund MEDDEV 2.1/6 - Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices Med hensyn til klassifikation af medicinsk udstyr:...stand alone software that meets the definition of a medical device shall be considered as an active medical device. This means that rules 9, 10, 11 and 12 of Annex IX to Directive 93/42/EEC may apply Clause 2.3 of the implementing rules in Annex IX states that software which drives a medical device or influences the use of a device, falls automatically into the same class, as the device it drives
13 Retlig baggrund - Klassifikationsregler BEK nr. 1263 af 15/12/2008 - Bekendtgørelse om medicinsk udstyr, bilag IX Med hensyn til klassifikation: Regel 9: Alt terapeutisk aktivt udstyr, der er beregnet til at tilføre eller udveksle energi, henhører under klasse IIa, medmindre dets karakteristika er af en sådan art, at det kan tilføre eller udveksle energi til eller fra det menneskelige legeme på en potentielt farlig måde i betragtning af den pågældende energis art, tæthed og anvendelsessted, idet det i så fald henhører under klasse IIb. Alt aktivt udstyr, der er beregnet til at styre eller overvåge ydeevnen af terapeutisk aktivt udstyr i klasse IIb, eller som er beregnet til direkte at påvirke dette udstyrs ydeevne, henhører under klasse IIb. Regel 10: Aktivt udstyr, der er beregnet til diagnosticering, henhører under klasse IIa [ ] hvis det er beregnet til at muliggøre en direkte diagnosticering eller overvågning af vitale fysiologiske processer, medmindre det er specielt beregnet til at overvåge vitale fysiologiske parametre, hvor variationer for visse af parametrenes vedkommende, navnlig variationer i hjertefunktionen, vejrtrækningen eller centralnervesystemets aktivitet, kan udgøre en umiddelbar fare for patienten, idet det i så fald henhører under klasse IIb.
14 Retlig baggrund - Klassifikationsregler BEK nr. 1263 af 15/12/2008 - Bekendtgørelse om medicinsk udstyr, bilag IX Med hensyn til klassifikation: Regel 11: Alt aktivt udstyr, der er beregnet til at indgive i legemet og/eller fjerne fra legemet lægemidler, legemsvæsker eller andre stoffer, henhører under klasse IIa, medmindre dette foregår på en måde, der er potentielt farlig i betragtning af arten af de anvendte stoffer, den berørte del af legemet eller anvendelsesmåden, idet det i så fald henhører under klasse IIb. Regel 12: Alt andet aktivt udstyr henhører under klasse I
Dokumentationskrav til CE-mærkning
Hvad betyder design for risikoklasse? Mini-WORKSHOP
Hvad betyder design for risikoklasse? Teoretisk eksempel 1: To app-udviklere ønsker at udvikle en app, der skal hjælpe unge med svær overvægt. App-udviklerne tager deres idé med til en forening for svært overvægtige unge, og foreningen synes, at det er en god ídé og vil gerne hjælpe. App-udviklerne samler en gruppe af foreningens medlemmer til at hjælpe dem, og allerede efter første møde er der konsensus i gruppen om, at det ville være rart at kunne se, om man er ved at overspise! App-udviklerne går i gang med at undersøge, hvilke features, der kunne være interessante at have med i en prototype-app, og de gennemgår løbende alle prototype-udgaver med gruppen med henblik på iterativt at forbedre app en. (sprints) En idé opstår om at visualisere brugerens kalorieindtag med en rød, gul og grøn farve, så brugeren kan se, om han/hun holder sig indenfor rammerne af en kostplan. Gruppen er ganske tilfredse med resultatet, og udviklerne lægger app en op på app store under kategorien medicinsk og skriver bl.a.: Denne app kan bruges til at behandle svær overvægt og udviklet i samarbejde med forening.
Hvad betyder design for risikoklasse? Teoretisk eksempel 1: Design: App en ender med at fungere således: Brugeren indtaster sin alder, vægt, højde og køn samt hvad brugerens aktivitetsniveau er, og hvor meget man ønsker at tabe sig om ugen. Brugeren indtaster herefter kaloriemængden for hvert måltid, inden man skal spise. Hvis et måltid kan være årsag til, at man ikke taber sig, lyser app en rødt! Hvis et måltid er for kalorieholdigt og indtaget tidligt på dagen, men ikke nødvendigvis fører til overvægt, lyses der gult! Hvis et måltid kan bidrage til at man taber sig, lyses der grønt! Er dette medicinsk udstyr? Hvis ja, hvilken risikoklasse?
19 Retlig baggrund - opsummering Følgende spørgsmål kan opstilles: 1. Hvad er mobilapplikationens tilsigtede anvendelse? Er den tilsigtede anvendelse med applikationen at diagnosticere, forebygge, behandle, overvåge eller lindre en sygdom? 2. Hvordan virker mobilapplikationen? Behandler applikationen data på en måde, der adskiller sig fra lagring, arkivering, kommunikation, simpel søgning eller databevarende kompression? 3. Er det hensigten, at applikationen eventuelt skal fungere sammen med andet medicinsk udstyr? Kan applikationen bruges til at drive eller påvirke brugen af andet udstyr? 4. Er det hensigten, at applikationen skal bruges i kombination med andet software eller indgå i et system som et modul? Er det eksempelvis hensigten, at mobilapplikationen kan bruges med en elektronisk patientjournal?
20 Retlig baggrund - definitioner MEDDEV 2.1/6 - Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices Med hensyn til kvalifikation som medicinsk udstyr: if the software does not perform an action on data, or performs an action limited to storage, archival, communication, simple search or lossless compression (i.e. using a compression procedure that allows the exact reconstruction of the original data) it is not a medical device Altering the representation of data for embellishment purposes does not make the software a medical device. In other cases, including where the software alters the representation of data for a medical purpose, it could be a medical device Simple search does not include software which provides interpretative search results, e.g. to identify medical findings in health records or on medical images if the software is an accessory to a medical device, it is not a medical device, but it falls under Directive 93/42/EEC Software made available to the user over the internet (directly or via download) or via in vitro diagnostic commercial services, which is qualified as a medical device, is subject to the medical devices directives
Hvad betyder app-design for risikoklasse? Teoretisk eksempel 2: En større virksomhed, der udvikler solcreme, beslutter sig for at bruge et lille eksternt app-udviklingshus til at udvikle en app, der skal fungere som en hjælp til deres kunder, for at servicere deres kunder på nye måder og for at lære deres kunder bedre at kende. App-udviklingshuset samler en gruppe bestående af brugere af solcremen og kører en lignende proces igennem, som i eksempel 1, med iterativ app-udvikling. Flere personer i gruppen er bekymrede for modermærker og ønsker at kunne holde øje med deres modermærker for at forhindre udvikling af hudkræft, hvilket det viser sig, at der er stor interesse for. En idé opstår om at kunne måle, om ens modermærker vokser i størrelse og advare, hvis der er forandringer, som en del af de funktioner app en kan have. En app-prototype bliver udviklet. Budgettet er overskredet, men de unge app-udviklere mener at have udviklet en app som er mere avanceret og derfor retfærdiggør prisen. App en ligger indenfor design-skemaet for virksomhedens produkter og ser grafisk flot ud. App-udviklerne beskriver app en som bl.a. værende i stand til at diagnosticere, om man har hudkræft.
Hvad betyder app-design for risikoklasse? Teoretisk eksempel 2: Design: App en ender med at fungere således: Brugeren logger ind med e-mail og password, som gemmes automatisk, og indsætter data om køn. App en indeholder en sektion med gode råd til, når solen skinner, eksempelvis hvor meget vand man bør drikke etc. App en indeholder også en Mole-Examiner, der fungerer ved, at brugeren tager et billede af sit modermærke i løbet af sommeren, og hvis der er forandringer, kan app en opdage dette og advare brugeren om risikoen for at udvikle hudkræft, baseret på en analyse af modermærket. Er dette medicinsk udstyr? Hvis ja, hvilken risikoklasse?
23 Retlig baggrund - opsummering Følgende spørgsmål kan opstilles: 1. Hvad er mobilapplikationens tilsigtede anvendelse? Er den tilsigtede anvendelse med applikationen at diagnosticere, forebygge, behandle, overvåge eller lindre en sygdom? 2. Hvordan virker mobilapplikationen? Behandler applikationen data på en måde, der adskiller sig fra lagring, arkivering, kommunikation, simpel søgning eller databevarende kompression? 3. Er det hensigten, at applikationen eventuelt skal fungere sammen med andet medicinsk udstyr? Kan applikationen bruges til at drive eller påvirke brugen af andet udstyr? 4. Er det hensigten, at applikationen skal bruges i kombination med andet software eller indgå i et system som et modul? Er det eksempelvis hensigten, at mobilapplikationen kan bruges med en elektronisk patientjournal?
24 Retlig baggrund - definitioner MEDDEV 2.1/6 - Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices Med hensyn til kvalifikation som medicinsk udstyr: if the software does not perform an action on data, or performs an action limited to storage, archival, communication, simple search or lossless compression (i.e. using a compression procedure that allows the exact reconstruction of the original data) it is not a medical device Altering the representation of data for embellishment purposes does not make the software a medical device. In other cases, including where the software alters the representation of data for a medical purpose, it could be a medical device Simple search does not include software which provides interpretative search results, e.g. to identify medical findings in health records or on medical images if the software is an accessory to a medical device, it is not a medical device, but it falls under Directive 93/42/EEC Software made available to the user over the internet (directly or via download) or via in vitro diagnostic commercial services, which is qualified as a medical device, is subject to the medical devices directives
Overvejelser i forbindelse med designproces
Overvejelser i forbindelse med designproces Apps kan bruges med et helbreds/sundheds fokus på adskillige måder: Eksempler kunne være: Sundhedskampagne > Awareness Markedsføring af et produkt > Engagement Behandling af sygdom > Effektivitet (Adherence/Compliance) Etc. Bruger-centrisk design
Overvejelser i forbindelse med designproces Hvilke problemer kan der være med typiske bruger-centriske udviklingsprocesser? En designbeslutning kan afgøre, om produktet er medicinsk udstyr eller ej, og om produktet har en høj risikoprofil eller en lav. Iterative designprocesser kan være svære at verificere undervejs, hvis der i gruppen ikke er en regulatory sagkyndig med særlig viden om sundhedsapps. En virksomhed kan ende med at bruge mange ressourcer/tid (eller ikke turde tage del i væsentlig ny innovation!) grundet usikkerhed om retlige forhold på området.
Design for UX eller for sikkerhed er det enten/eller?
Overvejelser i forbindelse med designproces Overvejelser: Det bør allerede inden projektstart overvejes om app en skal være medicinsk udstyr, og hvad der i givet fald vil kræves af virksomheden. Procesejeren bør overveje at benytte decision tree type instrumenter til at hjælpe udviklingsteamet med at holde fokus på de retlige rammer ved hver designbeslutning eller hver iteration (sprint). Den projektansvarlige bør overveje at have løbende kontakt til regulatory eksperter med særlig fokus på apps fra projektstart.
Spørgsmål?