RegOps – lääkinnällisen ohjelmiston ketterä kehitys
Lääkinnällisen laitteen tai ohjelmiston kehitys on Euroopassa säädeltyä EU 2017/745 -regulaation eli MDR-asetuksen myötä. Toisaalta regulaatio ei tuo kovinkaan paljoa lisätyötä ohjelmistojen kehitykseen – verrattuna siihen, kuinka ohjelmistokehitys kuuluisi muutenkin tehdä. Kuinka regulaatiosta voidaan ottaa kaikki hyöty irti niin, ettei se tunnu taakalta?
Helpoin tapa täyttää MDR-asetuksen (Medical Device Regulation) vaatimukset ohjelmistokehitykselle on hyödyntää ISO 13485-, IEC 62304-, ISO 14971- ja IEC 62366-1 -standardeja. Tuotteesta ja käyttötarkoituksesta riippuen saatetaan toki tarvita muitakin standardeja.
Perinteinen vesiputousmalli
Kun standardeja sovelletaan toimintamalleiksi, saattaa syntyvä prosessi lipsahtaa helposti perinteisen vesiputousmallin puolelle. Vesiputousmallissa määritellään ensin lääkinnällisen laitteen käyttötarkoitus ja vaatimukset. Tämän jälkeen suunnitellaan ja dokumentoidaan ohjelmiston arkkitehtuuri sekä rajapinnat. Kun kaikki suunnitelmat on vihdoin saatu tehtyä ja katselmoitua, luovutetaan ohjelmisto toteutusvaiheeseen. Tässä vaiheessa päästään vihdoin kirjoittamaan koodi, kuten aiemmassa vaiheessa on suunniteltu.
Ohjelmiston toteutuksen jälkeen kirjoitetaan vielä verifioivat testit. Puhdas testiraportti ja ohjelmisto viedään validointivaiheeseen kliinikoille. Lisäksi käytettävyydestä on muistettava tehdä käytettävyystestit IEC 62366-1 -standardin mukaisesti sekä mallintaa potilasturvallisuusriskit ISO 14971 -standardin mukaisesti.
Vesiputous vai SCRUM?
Perinteisessä vesiputousmallissa suunnittelu-, katselmointi-, toteutus-, verifiointi- ja validointivaiheet tehdään koko ohjelmistolle isoina askelina. Pahimmillaan ohjelmiston dokumentointi laaditaan vasta jälkikäteen regulaation vaatimukset täyttäväksi. Lisäksi lääkinnällisen ohjelmiston kehitystiimin jäsenet työskentelevät eriaikaisesti tai he joutuvat tekemään pitkiä aikoja tehtäviä omien kompetenssialueidensa ulkopuolella. Tämä syö tiimin tehokkuutta tai pahimmillaan aiheuttaa henkilöstössä turhautumista – ainakin niiden ohjelmistosuunnittelijoiden näkökulmasta, jotka tykkäävät koodata.
Ketterä kehitys ratkaisee vesiputousmallin ongelmia ja ennen kaikkea nopeuttaa yksittäisen muutoksen läpimenoaikaa. Yksi yleisesti käytetty ketterän kehityksen viitekehys on SCRUM, jossa kehitys etenee sykleittäin sprinteissä. Yksi sprintti kestää muutaman viikon ja aina sprintin ajaksi tiimi valitsee työjonosta tehtävät ja tavoitteet.
Sprintin päätteeksi ohjelmistosta muodostuu uusi iteraatio, tuotantokelpoinen uusi versio. Ohjelmistokehittäjän näkökulmasta sprintissä voi keskittyä kehittämiseen – projektikohtainen prosessi toki edellyttää, että suunnittelua, dokumentaatiota ja testaamista on tehtävä. Sprintin demossa on oltava tavoitteiden mukaista näytettävää ja se rytmittääkin ohjelmistokehittäjän tekemistä sopivasti.
RegOps
Kun perinteiseen ohjelmistokehitykseen yhdistetään ohjelmistokehityksen ja testauksen lisäksi tuotannon ylläpito, puhutaan DevOpsista (yhdistelmä sanoista development ja operations). Käytännössä tämä tarkoittaa, että kehitystiimin tehtäväksi annetaan myös tietojärjestelmän ylläpito. DevOpsia voidaan hallita SCRUM-viitekehyksessä, kunhan ennakoimattomille ylläpitotehtäville tehdään varaus kehitystehtävien lomaan.
Lääkinnällisen ohjelmiston tapauksessa, kun mukaan lisätään vielä regulaatiovaatimusten täyttäminen, on RegOps-määritelmä valmis. RegOpsin mukaisesti tarvitaan siis vaatimusten määrittelyä, suunnitelmien tekoa, potilasturvallisuusriskien kartoitusta sekä näiden kaikkien katselmointia. Ja pitäähän ohjelmisto myös koodata, testata sekä katselmoida toteutus. Voisiko tämän kaiken tehdä ketterästi vaikkapa SCRUM-viitekehyksessä?
Scrummaten maaliin
Lääkinnällisen ohjelmiston ketterä kehitys voidaan rakentaa SCRUM-viitekehyksessä katselmointien ympärille, kuten kuvassa 1. esitetään.
Sprintin aloitus
Sprintti aloitetaan valitsemalla työjonosta sopiva määrä tehtäviä samalla hieman tarkentaen niitä. Atostekin projekteissa listan tehtävät ovat yleensä asiakkaan vaatimusten mukaisia lääkinnällisen laitteen ohjelmiston tuotekehitystehtäviä, ja ne on nostettu sprinttiin yhdessä asiakkaan tuoteomistajan kanssa. Ne ovat uusia ominaisuuksia tai muutoksia olemassa oleviin ominaisuuksiin. Toisaalta ne voivat olla myös bugiraporttien selvittelyä ja sitä kautta korjauksia koodiin.
Joissain tapauksissa toteutamme Atostekilla korkean tason vaatimusten mukaisia tehtäviä, jotka on pilkottu pienemmiksi, jotta ne mahtuvat sprinttiin. Sprintin tehtävät on tarkennettu sille tasolle, että tehtävän kuvauksesta selviää, mitä tulee tehdä ja mikä on tehtävän valmiuden määritelmä.
Katselmointien kautta toteutukseen
Keskellä sprinttiä katselmoidaan ja hyväksytään koko tiimin kanssa lääkinnällisen ohjelmiston päivitetyt vaatimukset, arkkitehtuurisuunnitelmat, yksikkösuunnitelmat, rajapintakuvaukset, riskitaulukot sekä muut tarpeelliset suunnitelmat. Tässä suunnittelukatselmoinnissa jokainen tiimin jäsen pääsee esittelemään omat suunnitelmansa ja suunnittelukatselmoinnista tuotetaan virallinen katselmointipöytäkirja ISO 13485 -standardin vaatimuksia täyttämään.
Tämän jälkeen hyvin suunnitellut ominaisuudet toteutetaan, testataan sekä julkaistaan sisäisesti. Sprintin demo toimii julkaistun version toteutuskatselmointina.
Riippuen sprintissä tehtyjen muutosten laajuudesta ja ennenkaikkea niihin liittyvistä riskeistä, on ohjelmisto vielä validoitava ja mahdollisesti hyväksytettävä ilmoitetulla laitoksella ennen tuotantoon julkaisua. Vähäisten muutosten tapauksessa ilmoitetulle laitokselle riittää yleensä pelkkä ilmoitus. Sen jälkeen uusi versio voidaan siirtää validaatiotarkastelun kautta tuotantoon.
Entä jos kaikki ei mene kuin Strömsössä?
Aina kaikki ei kuitenkaan mene suunnitelmien mukaan. Jokin listan tehtävä saattaa osoittautua työläämmäksi kuin on ajateltu. Tai ehkä joku tiimiläisistä saa flunssan, eikä kaikkea ehditä suunnittelemaan sprintin puolivälin suunnittelukatselmointiin mennessä valmiiksi. Osa suunnitelmista jää tällöin keskeneräisyyden vuoksi katselmoimatta, eikä niiden kanssa voida edetä toteutusvaiheeseen.
Toteutustehtävien ja muiden tehtävien loppuessa voidaan sprinttiin nostaa työjonosta uusia ominaisuuksia suunniteltavaksi, jolloin tilanne tasapainottuu. Aina on myös mahdollista pitää toinen suunnittelukatselmointi saman sprintin aikana, jos alkuperäinen haluttu ominaisuus on kriittinen sprintin tavoitteen kannalta.
Moniosaajatiimi vai monipuoliset työtehtävät?
Kuinka regulaatiosta sitten saadaan kaikki mahdollinen hyöty irti? RegOps-menetelmällä ohjelmistosuunnittelijoiden työnkuva monipuolistuu, ja yhden ominaisuuden voi antaa työntekijälle alusta loppuun asti vietäväksi. Halutun ominaisuuden perusteella hän päivittää vaatimusmäärittelyn, arkkitehtuurisuunnitelman, rajapinnat ja tarvittaessa yksikkösuunnitelmat. Lisäksi hän esittelee ominaisuuden riskienhallintapalaverissa sekä suunnitelmien katselmoinnissa.
Uuden toteutettavan ominaisuuden mahdollisia vaikutuksia potilasturvallisuuteen pohditaan koko tiimin kesken. Toki projektipäällikkö ja/tai laatupäällikkö tukevat työtä pyydettäessä. Kun suunnitelmat on hyväksytty, asia on kirkkaana mielessä eikä toteutuksessa mene kauaa.
Ohjelmistosuunnittelija voi aloittaa automaattitestien kirjoittamisen ja hyödyntämisen jo kehityksen aikana, tällöin kehitykseen saadaan testeistä täysi hyöty. Regulaatio ei olekaan enää taakka vaan tehtävät ovat sitä samaa, mitä koulussakin jo opetettiin. Ja mikä parasta – jokaisessa sprintissä pääsee suunnittelemaan, koodaamaan sekä ylläpitämään tuotantojärjestelmää. Se on monelle atostekilaiselle asian ydin, parasta mitä saa tehdä!
Kun ohjelmistosuunnittelija osallistuu vaatimusten, suunnitelmien ja testien tekoon sekä katselmointeihin ketterän prosessin osana, hän täyttää samalla niin lääkinnällisen ohjelmiston standardien vaatimukset kuin hyödyntää myös yliopisto-opintonsakin. Laadukkaasti tehdystä työstä jää hyvä mieli kaikille osapuolille!
