Lääkintälaiteohjelmiston markkinoille saattaminen MDR:n alaisuudessa – osa 2

Tämän 7-osaisen blogisarjan tarkoituksena on täsmentää ja sukeltaa syvemmälle uuden asetuksen tuomiin vaatimukseen lääkintälaiteohjelmistokehittäjien näkövinkkelistä. Samalla pureskellaan Euroopan komission julkaisemaa lisäohjeistusta lääkintälaiteohjelmistojen valmistajille: “Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR”.

Blogisarjan toisessa osassa keskitytään osaamiseen ja sen arvointiin, resursointeihin sekä osaamisen hankintaan. “Artikkelin alkulämmittelynä on Elias Haapakorvan 19.12.2019 julkaistu blogikirjoitus, jota on syvennelty lopussa ohjelmistokehityksen tuomiin lisämausteisiin.”

Osa 2: Varmistu riittävästä osaamisesta ja resursseista

Lääkinnällisen laitteen kehittäminen vaatii rutkasti erityisosaamista, ei pelkästään tuotteen tekniseen kehitykseen, vaan myös regulaatioihin ja kaupallistamiseen liittyen. Erityisesti riittävän kattavan regulaatio-osaamisen puuttuminen on usein pullonkaulana uuden tuotteen kehittämisessä. Tavallisen tuotekehitys- ja kaupallistamisosaamisen lisäksi yrityksellä tulisikin olla jo alusta saakka käytettävissään osaamista mm. laadunhallintaan, käytettävyyteen, kliiniseen arviointiin, riskienhallintaan ja regulaatioprosesseihin sekä lääkintälaiteohjelmiston kyseessä ollessa ohjelmiston elinkaarihallintaan liittyen.

Tekemällä asiat alusta saakka oikein, nopeutat merkittävästi tuotteen markkinoille saattamista ja siten pienennät koko kehitystyön hintalappua. Erityisesti aloittelevat yritykset joutuvat kuitenkin usein operoimaan niukkojen pääomien paineessa, joten priorisointi on ymmärrettävää ja välttämätöntäkin. Täten, jo kehityksen alkuvaiheessa olisi hyvä tehdä vähintäänkin alustava riskienarviointi, gap-analyysi vaatimuksiin nähden sekä selkeät askelmerkit jatkokehitykselle, vaikka itse dokumentaation tuottaminen jäisikin myöhempään vaiheeseen. Näistä saat jo hyvän kuvan siitä vaatimuskentästä, joka tuotettasi koskee, ja näin toimien voidaan välttää ainakin osa mahdollisista karikoista.

Etenkin lääkintälaiteohjelmistomaailmassa pätee vanha sanonta: Mitä ei ole dokumentoitu, sitä ei ole tehty. Monelle lääkintälaitealan yritykselle tämä on tullut tuskallisen tutuksi, kun jälkijättöisesti on yritetty kasata lääkintälaiteohjelmiston elinkaarihallintastandardin mukaista dokumentaatiota tuotteen ollessa teknisesti valmis ja tuotteen puutteellisen dokumentaation ollessa markkinoillepääsyn esteenä.

MDR:n Artikla 10 (Valmistajien yleiset velvoitteet) on hyvä benchmark sille, minkälaista osaamista yrityksellä tulisi olla käytössään. Käytännössä nämä Artiklassa 10 kuvatut velvoitteet ovat myös keskeisiä laadunhallintajärjestelmän prosesseja, sisältäen mm.

1. Suunnittelu ja valmistus asetuksen vaatimusten mukaisesti
2. Riskienhallinta
3. Kliininen arviointi
4. Teknisten asiakirjojen laatiminen ja ylläpito
5. Laadunhallintajärjestelmän perustaminen ja ylläpito
6. Markkinoille saattamisen jälkeinen valvonta
7. Korjaavat ja ehkäisevät toimenpiteet, vaaratilanneilmoitukset

Tämän osaamisen voi hankkia myös ostopalveluina, mutta riittävä regulatorinen osaaminen tulisi aina olla myös yrityksellä itsellään, vieläpä mielellään niin, että tämä henkilö on osa yrityksen johtoryhmää.

Mikäli yrityksellä ei vielä ole laadunhallintajärjestelmää, sen laatiminen kannattaa aloittaa mahdollisimman alkuvaiheessa, sillä kuten yllä todettua, se ohjaa myös tuotteen suunnittelua ja tuotekehitystä (Design and Development -prosessia) ja helpottaa merkittävästi koko regulaatiokokonaisuuden hahmottamista. Ja toki kannattaa muistaa, että laadunhallintajärjestelmä ei ole pelkkä pakko, vaan kokonaisuus, joka kattaa kaikki yrityksen keskeiset prosessit ja on siten erinomainen johtamisen työkalu.

Ja nyt sinne syvään päätyyn!

Keskeisimmät lääkinnällisen ohjelmiston kehitystä ohjaavat standardit ovat laadunhallintajärjestelmästandardi EN ISO 13485:2016, riskinhallintastandardi EN ISO 14971:2019 sekä ohjelmiston elinkaarenhallintastandardi IEC 62304:2006.

Ohjelmiston elinkaarenhallinnassa osaamista tarvitaan erityisesti tuotekehitysprojektin hallintatyökalujen valintaan, jotka mahdollistavat jäljitettävyyden. Pakollinen vaatimusten jäljitettävyys tarkoittaa sitä, että tunnistetut tuotevaatimukset, riskit sekä niiden hallintakeinot, jotka muotoutuvat mahdollisiksi uusiksi vaatimuksiksi, linkittyvät keskenään. Tuotekehitysympäristö ei siis pelkästään ole koodinhallintaa, vaan siihen tulee ulottuvuuksia myös vaatimusten-, testauksen sekä riskienhallinnasta. Lääkinnällisten ohjelmistojen kehittämiseen kohdennettu tuotekehitysympäristö tuo siis merkittävää kilpailuetua, kun järjestelmä itsessään helpottaa ja mahdollistaa regulaatiovaatimusten täyttymisen.

Regulaatio-osaaminen tuo kilpailuvaltteja myös kehitysnopeuteen järkevöittämällä ohjelmistoarkkitehtuurin suunnittelua ja toteutusta. Ohjelmistojen elinkaarenhallintastandardissa erityisesti ohjelmistojen turvallisuusluokitukseen kannattaa siis kiinnittää huomiota. Suomeksi, ohjelmistoarkkitehtuurin eri osien turvallisuusluokitus kannattaa tunnistaa jo suunnittelun alkuvaiheessa – tämä mahdollistaa ohjelmiston eri osien sekä komponenttien vaatimusten ja niiden täyttämiseksi suunniteltuja ratkaisuja lajittelun eri luokkiin, mikä taas mahdollistaa ohjelmiston osien eriyttämisen. Eriyttämällä ohjelmiston osia voi kehitystyötä vauhdittaa merkittävästi. Tämä sen vuoksi, että korkeimpaan turvallisuusluokkaan (luokka C) asetettujen komponenttien tulee täyttää 100% elinkaarenhallintastandardin vaatimuksista kun taas alimman turvallisuusluokan (luokka A) tulee täyttää vain n. 40% standardin vaatimuksista. Toki tässä on hyvä muistaa, että eritettyjen ohjelmisto-osien tulee myös pysyä erillään ja kehittäjän varmistua siitä, ettei eri osat edes tahattomasti pääse vaikuttamaan toistensa toimintaan.

Kehittämisen pyörteissä on myös hyvä muistaa, ettei lääkinnällisten ohjelmiston elämä lopu julkaisuun, siihen kuuluisaan final releaseen ja markkinoille saattamiseen. Regulaatiot vaativat, että myös ohjelmiston ylläpito ja päivitykset on mietitty etukäteen. Ja taas päästään kilpailuvalttiin – suunnittelemalla kehittämisen vaiheet, eritoten versiohallinnan, voi ohjelmistokehittäjä väistää monta ongelmaa markkinoille saattamisen jälkeen. Tässä kyse on siis muutoksista, ja regulaatiokielessä tuttavammin niistä ”merkittävistä muutoksista”. Suunnittelemalla ja määrittelemällä versiostrategian eli eri versioihin vaikuttavien muutosten laajuuden ja muut kriteerit, voi ylläpitoa toteuttaa ketterämmin. Merkittävät muutokset kun nähdään lääkinnällisissä ohjelmistoissa aina käytännössä uutena tuoteversiona – koko tekninen tiedosto ja muut dokumentaatiot tulee siis päivittää kokonaisuudessaan.

Nälkä kasvaa syödessä! Mutta jottei blogi räjähtäisi ihan käsiin, lopetellaan tässä vaiheessa. Mikäli sinulla heräsi kysyttää ohjelmistojen tuotekehityksen hallintatyökaluista tai muista kehittämiseen liittyvistä nikseistä ole rohkeasti yhteydessä minuun – pähkitään yhdessä, miten teidän tuotekehitystänne saataisiin ketteröitettyä!

Blogisarjan seuraavassa osassa pääsette käsiksi vaatimusmäärittelyyn. Käymme läpi kuinka Asetuksen yleisiä turvallisuus – ja suorituskykyvaatimuksia tulee lähestyä ja miten pääsette täyttämään näitä omassa ohjelmistotuotteessanne.

Skippasitko blogisarjan ensimmäisen osan? Osa 1: Määrittele laitteelle käyttötarkoitus ja riskiluokitus