Lääkintälaiteohjelmiston markkinoille saattaminen asetuksen mukaan, osa 1

helmikuu 9, 2021

Kirjoittelin aikaisemmin kolmiosaisen blogisarjan aiheesta ”Medical Devices – rekisteröinti ja markkinoille saattaminen for dummies”. Nyt onkin hyvä aika syventää tätä aihepiiriä, kun uusi lääkintälaiteasetus (myöh. MDR, Medical Device Regulation) kolkuttelee jo nurkan takana ja tietoja sen käytännön soveltamisesta alkaa jo jonkin verran olemaan saatavilla. Tässäpä siis samassa hengessä, mutta hieman syvemmälle sukeltaen ja erityisesti lääkintälaiteohjelmistoihin (SaMD, Software as a Medical Device) keskittyen, opas uuden asetuksen mukaisen tuotteen markkinoille saattamiseen. Päällekkäisyyksiä on toki jonkin verran, sillä tietyt perusasiat on syytä tuoda aina esille tätä kokonaisuutta käsiteltäessä ja yhtä lailla opasta voi toki soveltaa myös muihinkin kuin ohjelmistotuotteisiin.

Kuten aikaisemmassa blogisarjassani kirjoitin, koko prosessin tulisi aina alkaa markkinaselvityksestä ja sen pohjalta laaditusta suunnitelmasta, mille markkinoille tuotetta viedään ja missä järjestyksessä. Tältä pohjalta laaditaan edelleen regulaatiostrategia, jossa tunnistetaan kunkin tuotteen regulatoriset vaatimukset kullakin markkinalla ja laaditaan suunnitelma niiden täyttämiseksi. Toisaalta, regulatoriset vaatimukset voivat myös määritellä tuote- ja markkinastrategiaa, eli prosessi on kaksisuuntainen. Yhtä lailla tärkeää on huomioida myös loppukäyttäjien tarpeet alusta pitäen. Tämä blogi käsittelee aihetta vain EU:n näkövinkkelistä, mutta onkin syytä muistaa, että kullekin markkinalle on omat vaatimuksensa, jotka tulee huomioida jo alkuvaiheessa!

Nämä ohjeet soveltuvat pääosin myös IVD-laitteisiin, mutta selvyyden vuoksi puhun yleisesti lääkinnällisistä laitteista.

Blogisarjan ensimmäisessä osassa määritellään tuotekohtaiset vaatimukset ja varmistutaan riittävistä resursseista.

1. Määrittele laitteelle käyttötarkoitus ja luokittelu

Käyttötarkoituksen määrittely on aina valmistajan vastuulla ja käyttötarkoitus, yhdessä tuotteen ominaisuuksien kanssa, määrittää myös tuotteen luokituksen. Edelleen, käyttötarkoitus on isossa osassa määriteltäessä riskienhallintatoimenpiteiden laajuutta. Kuten edellisessä blogissani kirjoitin, jos käyttötarkoitus määritellään liian suppeaksi, helpotat toki tuotteen riskienhallintaa, mutta samalla rajaat potentiaalisia käyttäjiä ja käyttökohteita ulos, pienentäen siten potentiaalista markkinaa.

On myös hyvä muistaa, että tuotteen käyttötarkoitusta voi myöhemmin myös laajentaa. Tuotteen voi siis viedä markkinoille suppeammallakin käyttötarkoituksella ja myöhemmin, kun tuotteesta, sen käyttökohteista, käyttäjäryhmistä tai käyttöpaikasta on saatu riittävästi uutta (kliinistä) tietoa, voidaan tämä laajennettu käyttötarkoitus tuoda osaksi tuotetta. Tämä edellyttää luonnollisesti ilmoitetun laitoksen tarkastusta muuttuneiden ominaisuuksien osalta, mutta on hyvä keino viedä tuote markkinoille mahdollisimman varhaisessa vaiheessa.

Käyttötarkoitusta määriteltäessä on hyvä dokumentoida seuraavat vaiheet:

  1. Perustelut sille, että tuote on lääkinnällinen laite
  2. Tuotteen käyttötarkoituksen, käyttöolosuhteiden ja käyttäjäryhmien mahdollisimman huolellinen tunnistaminen ja kuvaus.
  3. Tuotteen luokittelun määritteleminen suhteessa lääkintälaiteasetukseen.

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. Oma suositukseni on, että jo kehityksen alkuvaiheessa tehtäisiin 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.

On kuitenkin hyvä muistaa, että etenkin lääkintälaiteohjelmistomaailmassa pätee vanha sanonta: Sitä ei ole tapahtunut, jos sitä ei ole dokumentoitu. 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ää.

Yhtenä pienehköä parranpärinää aiheuttaneena lisäyksenä direktiiviin nähden on syytä nostaa myös artiklassa 10 mainittu valmistajan taloudellinen velvollisuus tuotevirheistä aiheutuneiden vahinkojen korvaamiseen. Tämä on merkittävä lisäys etenkin pienten yritysten kannalta. Vakuutusyhtiöt kiittävät!

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 -prosessi) 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.

3. Tunnista tuotteen yleiset turvallisuus- ja suorituskykyvaatimukset

Kaikkien tuotteiden on tuoteluokasta riippumatta täytettävä yleiset turvallisuus- ja suorituskykyvaatimukset (General safety and performance requirements, GSPR), jotka on kuvattu MDR:n liitteessä I.

Aloita luvusta I (Yleiset vaatimukset), jotka koskevat kaikkia valmistajia tuotteesta riippumatta. Vaatimukset 1-9 on siis täytyttävä kaikissa tapauksissa ja nämä liittyvät hyvin vahvasti laitteen riskienhallintaan. Siksi hyvä käytäntö onkin aikaisemmin mainitsemani alustavan riskienarvioinnin toteuttaminen jo suunnitteluvaiheessa tunnistamalla mahdollisimman laajasti potentiaalisia laitteeseen, sen suunnitteluun tai käyttöön liittyviä riskitekijöitä. Tällä tavoin voit jo suunnittelun ja kehityksen aikana vaikuttaa siihen, että mahdolliset riskit valmiissa tuotteessa ovat mahdollisimman vähäiset ja että niiden ilmaantumiseen on voitu varautua. Tässä vaiheessa on hyvä laatia jo ensimmäinen versio myös markkinoille saattamisen jälkeisen valvonnan suunnitelmasta (post-market surveillance plan).

Kappaleesta II eteenpäin valmistajan on tunnistettava ne vaatimukset, jotka tuotetta koskevat, sekä perusteltava (tai ainakin kyettävä perustelemaan), miksi jokin vaatimus ei kosketa juuri kyseistä laitetta. Laadi lista laitetta koskevista vaatimuksista ja mieti jo alkuvaiheessa, kuinka kukin vaatimus saadaan täytettyä.

Kukin vaatimus täytetään tyypillisesti jotakin (harmonisoitua) standardia noudattaen, ja tämä todennetaan edelleen teknisten asiakirjojen tai laadunhallinnan dokumentaation avulla. Valmistajan onkin pidettävä yllä ajantasaista listaa tuotetta/valmistajaa koskevasta lainsäädännöstä, ohjeistosta ja standardeista.

Huomionarvoista on myös, että laitetta saattavat koskea myös muut direktiivit ja asetukset, joiden vaatimukset on niin ikään kyettävä täyttämään! Tällaisia ovat esimerkiksi koneita, sähkölaitteita, kemikaaleja ja lääkkeitä koskevat asetukset ja direktiivit.

Liitteen I kappale III käsittelee pakkausmerkintöjä ja käyttöohjeita (laitteen mukana toimitettavat tiedot). Huomaa erityisesti erot ja yhtäläisyydet ”merkintöjen”, ”pakkauksessa annettavien tietojen”, ”käyttöohjeiden” ja ”käyttäjälle annettavien tietojen” välillä.

Tuotteen yleisiä turvallisuus- ja suorituskykyvaatimuksia täytettäessä syntyvät siis:

  1. GSPR -checklist, jossa kuvataan, mitkä vaatimukset tuotetta koskevat, mitä standardia tai ohjeistusta noudattaen vaatimus on täytetty ja missä teknisessä asiakirjassa vaatimuksen täyttäminen kuvataan.
  2. Kattava käsitys vaadittavan teknisen dokumentaation laajuudesta, minkä voi tehdä esimerkiksi alustavan dokumenttirekisterin muotoon.
  3. Rekisteri valmistajaa ja tuotetta koskevasta lainsäädännöstä, standardeista ja ohjeistuksesta, jota valmistajan on ylläpidettävä ja joiden muutosten vaikutukset toimintaan tulee selvittää ja kuvata.

Kasven kehittämä QAiRA -pilvipalvelu tuo helpotusta valmistajaa koskevien standardien ja lainsäädännön seurantaan ja hallintaan sisältäen keskeiset tiedot lähes 2 000 eri asiakirjasta. Tulemme jatkossa integroimaan palveluumme myös lukuisia vaatimusten täyttämistä helpottavia työkaluja, sisältäen mm. helppokäyttöisen GSPR -checklistin, jolla näiden vaatimusten täyttämistä on helppo seurata ja todentaa esimerkiksi ilmoitetulle laitokselle. Katso lisää www.qaira.io!

Blogisarjan seuraavassa osassa päästään valmistelemaan teknisiä asiakirjoja sekä tuotteen markkinoille saattamista.

Rosa Tengvall

Lead Quality Engineer