MDR-rada üksikarendajatele. Reegli 11 lugemine ilma vastavusosakonnata.

Kui üksikarendaja loeb esimest korda ELi meditsiiniseadmete määrust, hakkab teatud laadi hirm sisse imbuma. Dokument on üle viiesaja lehekülje. See räägib teavitatud asutustest, vastavushindamise menetlustest, tehnilisest dokumentatsioonist, turule järgsest järelevalvest, valvsusest, EUDAMEDist, ohutuse ja kliinilise toimivuse kokkuvõttest, perioodilistest ohutuse uuendamise raportitest. Juba sõnavara ise viitab tööstusele, mis on kättesaadav vaid ettevõtetele, kel on pühendatud regulatiivse asjaajamise osakonnad.

See mulje on osaliselt õige ja osaliselt vale. Jah, MDR on raske. Jah, täielik vastavushindamine kõrgema riskiga seadmetele on tõsiselt kallis ja aeglane. Aga määrus mahutab ka väiksema, madalama riskiga tarkvara viisil, mis on hoolikale üksikarendajale teostatav, eeldusel et seda hoolikalt loetakse ja vastu seistakse kahele vastandlikule kiusatusele: teesklemisele, et regulatsioon ei kehti, või teesklemisele, et seda ei suuda kuidagi täita.

Küsimus, mis tuleb esimesena

Kõige enne on küsimus, kas tarkvara, mida ehitad, üldse kvalifitseerub meditsiiniseadmeks. MDR artikkel 2 lõige 1 määratleb meditsiiniseadme kavandatud otstarbe järgi. Kui tootja kavandab seda haiguse diagnoosimiseks, ennetamiseks, jälgimiseks, ennustamiseks, prognoosimiseks, raviks või leevendamiseks, on tegu meditsiiniseadmega. Kui see on mõeldud lihtsalt üldiseks elustiili, vormi või heaolu jaoks, ei ole.

Sellele küsimusele ei vastata muuseas. „Kavandatud otstarve” on see, mida arendaja toote kohta väidab: kasutaja poole pööratud kirjelduses, turunduses, rakenduste poe kirjes, ekraanikuvadel. Heaolu jälgija saab meditsiiniseadmeks hetkel, kui tema tootja väidab, et see aitab seisundit hallata. Piiri tõmbab keel sama palju kui funktsioon.

Üksikarendajale on kõige ausam esimene samm visandada kavandatud otstarbe lause enne koodi kirjutamist ja käsitleda seda piirangudokumendina. See ütleb sulle, kas asud MDR ulatuse sees või sellest väljas.

Mida reegel 11 tegelikult ütleb

Kui tarkvara kvalifitseerub meditsiiniseadmeks, määravad VIII lisa klassifitseerimise reeglid selle klassi. Reegel 11 on see, mis kehtib enamiku tarkvarapõhiste meditsiiniseadmete kohta. Lihtsustatult: tarkvara, mis on mõeldud andma teavet diagnostilisteks või ravialasteks otsusteks, on vähemalt IIa klass. Tarkvara füsioloogiliste protsesside jälgimiseks võib olla IIa või IIb sõltuvalt sellest, milliseid parameetreid jälgitakse. Tarkvara üldiseks otsust mittetoetavaks dokumenteerimiseks võib olla I klass.

Praktiline tagajärg on, et vahe I ja IIa klassi vahel on vahe enesedeklaratsiooni ja teavitatud asutuse vahel. I klassi seadmed saab turule tuua tootja enda vastavusdeklaratsiooni, siseriiklikus ametis registreerimise ja vajaliku tehnilise dokumentatsiooniga, ilma teavitatud asutust kaasamata. IIa klass ja kõrgem nõuab teavitatud asutuse kaasamist, mis lisab olulist kulu ja aega.

Üksikarendajatele on realistlik rada seetõttu kujundada rakendus nii, et see asub klassifitseerimise hierarhias nii madalal, kui ausalt selle otstarbega ühildub. Asi ei ole reegli ärakasutamises. Asi on selles, et oled iseendaga ja järelevalvajaga selge, mida tarkvara teeb, ja valid ulatuse sellele vastavalt.

I klass ja enesedeklaratsioon on vahe kuue kuu ja kolme aasta vahel. Vali ulatus teadlikult.

Kus klassipiir tegelikult jookseb

Reegli 11 abstraktne lugemine läheb konkreetseks niipea, kui paned päris tarkvara funktsioonid kaalule. Lühike rida näiteid, nagu need praktikas tavaliselt jaotuvad:

Rakendus, mis võtab patsiendi valuhinnangud, kuvab need nimekirjas ja laseb raviarstil eksportida PDFi, on I klass. See kogub ja dokumenteerib; ei paku ühtegi otsust.

Sama rakendus häirelävega (näiteks: valuhinnang üle 7 käivitab vihje helistada vihjeliinile) liigub IIa klassi piiri lähedale. Otsustav küsimus on, kas rakendus pakub nüüd teavet, mida kasutatakse ravialase otsuse tegemiseks. Kui vihje lihtsalt kordab tavalist suunist, mis patsiendil juba käes on, sobib endiselt I klass. Kui vihje pakub doosi muutmist või soovitab konkreetset tegevust, on tõenäolisem IIa.

Ravimi meeldetuletuse rakendus on tavaliselt I klass, sest see on puhas korralduslik abi ilma ravialase soovituseta. Rakendus, mis arvutab ravimi annuseid (näiteks insuliini süsivesikutest ja vere glükoosist), on IIa või kõrgem, sest arvutuse tulemus kannab otseselt ravialast otsust.

Kroonilise seisundi patsiendi sümptomite päevik, mis salvestab andmed kohapeal ja laseb kasutajal soovi korral need eksportida, on I klass. Sama päevik funktsiooniga, mis ennustab trendiandmetest järgmise süvenemise riskiprofiili, on IIa.

Mõte pole IIa rakendust hoolikate sõnastusega I klassiks rääkida. Kavandatud otstarve ja tegelik funktsionaalsus peavad kokku langema. Mõte on funktsionaalsust teadlikult valida. Rakendus, mis algab puhta dokumenteerimistööriistana ja jätab otsustamise toetuse arstidele, on regulatiivselt palju paremini hallatav kui rakendus, mis kannab otsuse ise, ja paljudes kliinilistes kontekstides on see ka ausam valik.

Tehniline toimik: vähem salapärane, kui kõlab

MDR II lisa loetleb, mida tehniline dokumentatsioon peab sisaldama. Loend on pikk, kuid sisu on äratuntav igaühele, kes on tarkvaraprojekti läbimõeldult teinud: seadme kirjeldus, kavandatud otstarbe avaldus, kohaldatud asjakohaste standardite loend, projekteerimise ja tootmise teave, riskianalüüs, kontrolli ja valideerimise tõendid ning märgistus ja kasutusjuhend.

Väikese arendaja jaoks saab seda koguda järk-järgult, kui toode küpseb. Riskianalüüs ISO 14971 järgi on selgroog: see loetleb ohud, mida seade võib sisse tuua, hindab tõenäosust ja raskust ning dokumenteerib leevendused. Kasutuskogemuse projekteerimine IEC 62366 järgi dokumenteerib, kuidas inimtegurid arvesse võeti. Tarkvara elutsükli protsessid IEC 62304 järgi raamivad arenduse ise.

Ükski neist standarditest pole välja mõeldud väikeste meeskondade piinamiseks. Need on alusküsimuse kodifitseeringud: kas mõtlesid hoolikalt läbi, mis võib valesti minna, ja kas tegid selle suhtes midagi? Üksikarendaja, kes kirjutab nendele küsimustele ausad vastused, versioonihalduses ja kuupäevastatud, on suurem osa sellest teest käinud. Arhitektuuripoolse vaate kohta vaata Privaatsus arhitektuuris terviserakendustes.

Kvaliteedisüsteemi küsimus

Raskem nõue on kvaliteedijuhtimise süsteem. I klassi seadmete jaoks on dokumenteeritud kvaliteedisüsteem nõutav, kuid seda ei pea ISO 13485 järgi sertifitseerima. IIa klassi ja kõrgema jaoks on tavaliselt oodatud sertifitseerimine teavitatud asutuse poolt.

Üheinimese stuudio jaoks on võimalik ehitada päris aga proportsionaalne kvaliteedisüsteem. Süsteem peab määratlema, kuidas projekteerimise otsuseid üle vaadatakse, kuidas muudatusi juhitakse, kuidas tarnijate kvalifitseerimist hallatakse (isegi kui tarnijad on vaba lähtekoodi teekide haldurid), kuidas turule järgne järelevalve käib ja kuidas arendaja tagab, et toode jätkab toimimist, nagu väidetud. Dokumentatsioon ei pea olema mahukas. See peab olema elatud.

Kasulik harjutus on kirjutada kvaliteedisüsteem lühikeste standardprotseduuride komplektina, igaüks üks-kaks lehekülge, mis vastavad sellele, mida arendaja tegelikult teeb. Kui protseduur ütleb midagi muud kui praktika, on üks neist vale.

Teavitatud asutuse kaasamine, kui vaja

IIa klassi seadmete puhul peab teavitatud asutus vastavushindamise läbi viima. Teavitatud asutused on olnud võimsuse all surve all alates MDR rakendumisest. Mitmes kuus mõõdetavad ooteajad on tavalised. Väikese arendaja jaoks algab kaasamine ammu enne tegelikku auditit: eelmise konsultatsioonid on tavaliselt võimalikud ja oma kulu väärt.

Stuudio töötav eeldus on, et kaasamine peaks algama niipea, kui tehniline toimik on umbes seitsekümmend protsenti valmis. Varem raiskad teavitatud asutuse aega ja iseendi oma. Hiljem riskid ootamatu kitsaskohaga just hetkel, kui tahad käivituda.

Turule järgne reaalsus

Mida üksikarendajad sageli alahindavad, on turule järgsed kohustused. Kui seade on turul, peab tootja käitama turule järgset järelevalvet, esitama perioodilise ohutuse uuendamise raporti (IIa klassi ja kõrgema kohta) ja reageerima intsidentidele valvsuse süsteemi all. Need on jätkuvad kohustused, mitte ühekordsed takistused.

Üheinimese stuudio jaoks on kujundamise piirang, mida see tähendab, see, et toode peab olema lõputult käitatav olemasolevate ressurssidega. Keeruline turule järgne plaan, mille läbiviimiseks on vaja meeskonda, on plaan, mis kukub läbi. Lihtsam plaan, mida tehakse igal kvartalil eksimatult, võidab keerukama oma, mis kaheksateistkümne kuu järel lakkab.

Mis see praktikas välja näeb

Stuudio töötav mudel I klassi või piiripealse IIa tarkvarapõhise meditsiiniseadme jaoks on umbes selline. Defineeri kavandatud otstarve kitsalt ja pane see kirja enne koodi kirjutamist. Ehita rakendus üles ainult kohapealsete andmete ja minimaalse väliste sõltuvuste ümber. Hoia riskifail versioonihalduses esimesest sprintist. Dokumenteeri projekteerimise otsused, kui need sünnivad, mitte tagantjärele. Kirjuta kasutusjuhend ja märgistus liidese kõrval, mitte selle järel. Kaasa väline kliiniline ja regulatiivne ülevaatus seitsmekümne protsendi tähisel. Planeeri turule järgne järelevalve toote osana, mitte lõppu külge kirjutatud paberitööna.

Selleks ei ole vaja vastavusosakonda. Vaja on ausat, mõõdetud tempos versioonihalduses tehtud tööd. See on see, mille moodi tarkvaraarendus niikuinii välja peaks nägema.

Sagedased küsimused

Millal kvalifitseerub rakendus ELi MDR alusel meditsiiniseadmeks?

Rakendus kvalifitseerub meditsiiniseadmeks, kui tootja kavandab seda haiguse diagnoosimiseks, ennetamiseks, jälgimiseks, ennustamiseks, prognoosimiseks, raviks või leevendamiseks (MDR artikkel 2 lõige 1). Kavandatud otstarbe määrab see, mida tootja väidab (rakenduste poe kirjes, turunduses, kirjeldustes), mitte ainult funktsioon.

Mida ütleb MDR reegel 11?

Reegel 11 (MDR VIII lisa) klassifitseerib tarkvarapõhised meditsiiniseadmed. Tarkvara, mis on mõeldud andma teavet diagnostiliste või ravialaste otsuste tegemiseks, on vähemalt IIa klass. Tarkvara füsioloogiliste protsesside jälgimiseks on IIa või IIb sõltuvalt sellest, milliseid parameetreid jälgitakse. Tarkvara üldiseks otsust mittetoetavaks dokumenteerimiseks võib olla I klass.

Mis on praktiline vahe I ja IIa klassi vahel?

I klassi seadmed saab turule tuua tootja enda vastavusdeklaratsiooni ja siseriiklikus ametis registreerimisega, ilma teavitatud asutuseta. IIa klass nõuab vastavushindamist teavitatud asutuse poolt, mis lisab oluliselt aega ja kulu (sageli aastad kuude asemel).

Kas üksikarendaja saab MDR nõuetele vastata?

Jah, hoolika planeerimisega. Vaja on: kitsalt määratletud kavandatud otstarvet enne koodi kirjutamist, II lisa kohast tehnilist dokumentatsiooni (ehitatakse järk-järgult), riskianalüüsi ISO 14971 järgi, kasutuskogemuse projekteerimist IEC 62366 järgi, tarkvara elutsüklit IEC 62304 järgi, dokumenteeritud kvaliteedisüsteemi proportsionaalselt klassiga ja turule järgseks järelevalveks töötavat süsteemi.