n Tema: Godkendelse af medicinsk udstyr software, der betragtes som medicinsk udstyr, men efterlader stadig god plads til fortolkning og dermed også anledning til forvirring. Enkelte landes myndigheder og andre organisationer har udgivet vejledninger, som uddyber og præciserer fortolkningerne, ligesom der også fra de amerikanske myndigheder - FDA - er udgivet en vejledning »Mobile Medical Apps« (MMA) [2] (www.fda.gov) i forhold til fortolkning på apps. MMA-vejledningen indeholder adskillige eksempler på funktionalitet, som gør en app (og anden software med samme funktionalitet) til medicinsk udstyr. I grænsetilfælde mellem medicinsk udstyr og ikke-medicinsk udstyr ser man bl.a. på, hvordan måledata fra en person/ patient behandles. Hvis softwaren indeholder en af nedenstående funktioner, der behandler måledata eller deraf afledte data, vil det blive klassificeret som medicinsk udstyr. ● Tabsbehæftet komprimering. ● Filtrering. ● Mønstergenkendelse. ● Modellering. ● Interpolering. ● Transformation. ● Klassificering (f.eks. udregning af score for en tumor i henhold til specifikke kriterier). ● Komplekse beregninger. ● Kvantificering. ● Kvalificering (sammenligning af data med referencer). ● Visualisering og fortolkning. Bemærk, at ovenstående er eksempler, og at listen ikke er fuldstændig. Plotning af data over tid i forhold til et sæt af (u)sunde værdier vil altså typisk være en reguleret funktionalitet, ligesom apps beregnet til at udføre beregninger eller fortolke indtastede eller opsamlede måledata medfører, at appen bliver betragtet som medicinsk udstyr. Hvis appen udfører komplekse beregninger, som erstatter en klinikers egne beregninger, og som klinikeren derfor forlader sig på, vil appen også være et medicinsk udstyr. Derimod vil apps som er tiltænkt anvendelse som undervisningsudstyr eller opslagsværk som udgangspunkt ikke være et medicinsk udstyr. nen af, hvad der er medicinsk udstyr. For softwareudviklere forventes det, at der kommer væsentligt større fokus på udviklingsprocesserne til sammenligning med den nuværende lovgivning. Forordningen ventes p.t. at foreligge i endelig udgave i slutningen af 2015, men er tidligere blevet forsinket flere gange. Håndtering af kravene under udvikling af software Agile metodikker har længe været anvendt ved softwareudvikling og for producenter af software generelt, men særligt for app-udviklere, hvor produktet har en forholdsvis kort udviklingstid og kort tid på markedet, er det nødvendigt at være særdeles agile i arbejdet med produktudviklingen, men også i håndtering af kvalitets- og dokumentationsprocesserne for at imødekomme både krav til time-to-market og de regulatoriske krav. En effektiv tilgang kan være at tænke i »Minimal Viable« og lægge energi i optimering af de processer, der virkelig kan flytte noget. I en agil kontekst med mange ændringer er effektiv ændringsstyring en af de vigtigste processer at have på plads. Standarden IEC 62304 [5] (webstore.iec.ch) beskriver software livscyklusprocesser, og er den standard, der bør følges ved udvikling af software, som er til medicinsk udstyr. AAMI TIR45 [6] (marketplace.aami.org) er en vejledning i brug af agile praktikker ved udvikling af software til medicinsk udstyr. Begge disse standarder indeholder god praksis og inspiration til processer. Den væsentligste faktor for at opnå patientsikker software er dog stadig den organisation, som udvikler softwaren, og den indstilling organisationen har til kvalitet. Brian Hedegaard. Klassifikation af software som medicinsk udstyr og konsekvensen Software, som er medicinsk udstyr, følger samme klassifikationsregler som alt andet medicinsk udstyr. I EU inddeles medicinsk udstyr i klasse I (m/s), IIa, IIb og III baseret på den risiko, der er forbundet med brug af udstyret. Software betragtes som aktivt udstyr, og vejledningen MEDDEV 2.4/1 [3] (ec.europa.eu) kan hjælpe med afklaringen af, hvilken klassifikation udstyret får. Klassifikationen, og de deraf følgende procedurer for opfyldelse af overensstemmelse med lovgivningen, er for software ofte vanskelig, og konsekvensen for forretningsmodellen kan være stor, hvorfor det er vigtigt at have en klar definition af appens tiltænkte anvendelse. Kravene til producenter af software som klassificeres som klasse I er lettest at håndtere, mens konsekvensen af en klassificering andet end I straks er mere omfattende, da der jf. NBMED/2.2 [4] (www.team-nb.org) er krav om, at der skal etableres et kvalitetssystem, som omfatter hele produktudviklingen samt omkringliggende kvalitetssikringsprocesser. Referencer [1] http://ec.europa.eu/health/medicaldevices/files/meddev/2_1_6_ol_en.pdf. [2] http://www.fda.gov/downloads/MedicalDevices/./UCM263366.pdf. [3] http://ec.europa.eu/health/medicaldevices/files/meddev/2_4_1_rev_9_classification_en.pdf. [4] http://www.team-nb.org/documents/2010/Recommendation-NBMED-2_2-4_rev5_Software_and_Medical_Devices.pdf. [5] https://webstore.iec.ch/preview/info_ iec62304%7Bed1.0%7Den_d.pdf. [6] https://marketplace.aami.org/eseries/ scriptcontent/docs/Preview%20Files/ TIR45_1208_preview.pdf. Medicoteknik | nr. 3 | Juni 2015 Stramning af kravene på vej Lovgivningen for medicinsk udstyr er under revision, og udkastet til den kommende forordning ligger p.t. i forhandlinger mellem EU-Kommissionen og Europa-Parlamentet i forhold til formuleringer i teksten. I udkastet, som udkom første gang i 2012, var der væsentlige stramninger, som - hvis de kommer med i den endelige tekst - vil udvide definitio- 6
Download PDF fil
Se arkivet med udgivelser af Medicoteknik her
TechMedias mange andre fagblade kan læses her