GMP ja automaatio-ohjelmistot – ei sijaa mokailulle

Lääke- ja terveystuotannossa yksi käsite nousee jatkuvasti esiin: Good Manufacturing Practice eli GMP. Alan toimijat kyllä tuntevat sen yleensä hyvin, koska GMP määrittelee, millä periaatteilla tuotteita valmistetaan.

Automaatiojärjestelmien kohdalla GMP nähdään usein dokumentaation, auditointien ja validointien kautta. Vähemmälle huomiolle jää se, että suuri osa GMP-vaatimusten toteutumisesta tapahtuu käytännössä ohjelmiston logiikassa. Se ratkaisee, mitä käyttäjä voi tai ei voi tehdä ja missä vaiheessa järjestelmä sallii tuotannon etenemisen.



Oikeastaan koko Tricyclen idea pohjaa GMP-vaatimuksiin: pyrimme tekemään softan, joka ei anna käyttäjälle mahdollisuutta tehdä vääriä asioita. Siinä se kaikessa yksinkertaisuudessaan. Mikäli halajat tarkempaa tietoa tästä kirjainyhdistelmästä, jatkahan lukemista! 

GMP ja tuotanto

GMP:n keskeinen ajatus on simppeli: tuotteen valmistuksen on oltava hallittua, dokumentoitua ja jäljitettävää. Jokainen tuotantoerä pitää pystyä jälkikäteen seuraamaan niin, että voidaan osoittaa mitä materiaaleja käytettiin, millä prosessilla tuote valmistettiin ja millaisissa olosuhteissa tuotanto tapahtui.

Tuotantoprosessissa ei siis ole sijaa epäselvyyksille ja joka vaiheesta täytyy jäädä jälki. Jos jokin menee väärin, se käsitellään poikkeamana ja sen syy selvitetään ennen kuin tuotettu materiaali voidaan vapauttaa käyttöön tai markkinoille.

Poikkeamat eivät ole pelkkä hallinnollinen asia, vaan niiden selvittäminen voi pysäyttää tuotantoa selvittelyn keston ajaksi. Vakavimmissa tilanteissa jopa koko tuotantoerä voidaan joutua hylkäämään, vaikka itse tuotteessa ei olisi lopulta mitään vikaa. Vielä hankalammaksi tilanne muuttuu, jos virhe havaitaan vasta sen jälkeen, kun tuotteita on jo toimitettu ja niitä joudutaan vetämään takaisin.

Ennen kaikkea GMP:llä pyritään siis ehkäisemään virheitä etukäteen ja näin takaamaan potilasturvallisuus.

Kun ohjelmisto ei päästä tekemään “tyhmyyksiä”

Automaatiojärjestelmän merkitys korostuu erityisesti tilanteissa, joissa tuotantoprosessissa on useita vaiheita ja paljon käyttäjän tekemiä syötteitä. Jos järjestelmä sallii virheellisen toiminnan, se johtaa väistämättä poikkeamiin.

Intuitiivisesti suunniteltu ohjelmisto sen sijaan ohjaa käyttäjän toimintaa niin, että prosessi etenee oikeassa järjestyksessä eikä kriittisiä vaiheita voi ohittaa.

Tyypillinen esimerkki liittyy materiaalitietoihin. GMP-ympäristössä tuotantoerää ei voi aloittaa ilman, että käytettävät materiaalit on tunnistettu ja dokumentoitu. Jos ohjelmisto sallii erän käynnistämisen ilman näitä tietoja, virhe syntyy helposti. Kun taas sisäänrakennettu logiikka estää startin ennen materiaalitietojen syöttämistä, koko ongelmaa ei pääse syntymään.

Toinen käytännön tilanne liittyy materiaalien hyväksyntään. Tuotantolinjalle ei saa päätyä materiaalia, joka ei kyseiseen tuotteeseen kuulu. Kun järjestelmä tarkistaa materiaalin automaattisesti ja estää väärän käytön, vältetään tilanteet, jotka muuten johtaisivat poikkeamaselvityksiin.

Mainitun kaltainen ohjelmiston logiikka ei ole suora GMP-vaatimus ohjelmistokehittäjälle. Se on kuitenkin Tricyclelle keskeinen tapa varmistaa, että tuotantoympäristö toimii niiden toimintaehtojen mukaisesti, joissa loppuasiakaskin joutuu toimimaan.

Jäljitettävyys koskee myös ohjelmistokehitystä

Samat GMP-periaatteet ulottuvat myös automaatiojärjestelmien ohjelmistokehitykseen. Keskeinen vaatimus on, että kaikki muutokset ohjelmistoon ovat jäljitettävissä. On pystyttävä vastaamaan kysymyksiin siitä, mitä muutettiin, miksi muutos tehtiin ja milloin se tapahtui. Sillä on suora yhteys tiedon eheyteen ja muutoshallintaan.

Versionhallinta on käytännössä tärkein työkalu tämän toteuttamisessa: jokainen versio sisältää tiedon siitä, mitä ohjelmistossa on muutettu ja mistä syystä. Me käytämme Git-versionhallintaa: sen ansiosta ohjelmiston kehityshistoria säilyy kokonaisuudessaan, ja tarvittaessa voidaan palata tarkasti mihin tahansa aiempaan versioon.

Uudet ohjelmistoversiot tallennetaan Git-järjestelmään kommenttien kanssa. Kommenteissa kuvataan, mitä ohjelmistossa on muutettu ja miksi muutos on tehty. Git-lokiin muodostuu näin koko kehityshistoria selityksineen.

Vaikka GMP ei suoraan määrää, millä tavalla koodi täytyy kirjoittaa, selkeästi jäsennelty ja hyvin kommentoitu ohjelmisto helpottavat käytännössä kaikkea muutosten hallinnasta auditointiin.

Eipäs lähdetä sooloilemaan!

GMP-maailman perusperiaatteita on, että tuotantojärjestelmiä ei muuteta spontaanisti kesken käytön. Muutokset kulkevat hallitun prosessin kautta.

Muutostarve on ensin tunnistettava ja dokumentoitava. Sen jälkeen muutos toteutetaan ohjelmistoon, testataan ja dokumentoidaan ennen kuin uusi versio otetaan käyttöön tuotannossa. Testit tehdään usein yhteistyössä tuotannon tai laatuorganisaation kanssa.

Lisäksi GMP-ympäristössä järjestelmät tarkastetaan säännöllisesti auditoinneissa.

Yllättävän konkreettisesti näkyvä GMP

Vaikka GMP mielletään helposti sääntelyksi ja dokumentaatioksi, tuotannon arjessa se näkyy ennen kaikkea käytännön toimintatapoina. Automaatiojärjestelmät ovat eräitä keskeisimpiä työkaluja näiden toimintatapojen toteuttamisessa.

Meistä hyvän ohjelmiston – ja koko automaatiokokonaisuuden – on tehtävä oikeiden asioiden tekemisestä helpompaa ja väärien tekemisestä mahdotonta. Ja jos järjestelmä joskus pistää stopin tekemiselle, syy löytyy yleensä siitä, että se tekee juuri sitä mitä sen pitääkin.