ISO&IEC PT-62304 Software lifecycle processes Frankfurt 3.-5.10.2016

Paikalla Saksan VDE:n tiloissa Frankfurtissa oli noin 26 henkeä ympäri maailmaa. Puheenjohtajana toimi Patty Krantz-Zuppan (PKZ) Medtronic-yhtiöstä USAsta. Rich de la Cruz USAsta tuli toiseksi projektin vetäjäksi PKZ:n rinnalle.

Kokouksen tarkoituksena oli käsitellä ne lukuisat kommentit (66-sivuinen dokumentti), joita standardin 62304 version kaksi ensimmäiseen komitealuonnokseen oli saatu. 13 maata 19:stä tukee esitettyä standardiluonnosta, mutta muutosesityksiä on paljon.

Keskusteltiin standardin numerosta.Koska 62304:ä kehitetään IEC:n ja ISO:n yhteistyönä, sen numeron pitäisi olla 80000-sarjassa. Numero 62304 on tunnettu ja se on harmonisoitu standardi EU:ssa ja siihen on viitattu monessa paikassa. Numeron muuttaminen voisi tehdä standardista vähemmän tunnetun. Vaihtoehtoinen numero olisi 82304-2. Asiaa täytyy selvitellä IEC/TC62:n johdosta, mutta projektiryhmä kannatti numeron pitämistä samana.

Aikaisemmin, 62304:n ensimmäistä versiota kehitettäessä oli sovittu, että jatkossa 62304:n kehityksessä otettaisiin huomioon ISO 12207:n uudet versiot, jotta 62304 olisi samassa linjassa yleisstandardin 12207 kanssa. Tämä tarkoittaa, että ne prosessit, joita 62304:ssä kuvataan, olisivat yhteensopivia 12207:n kanssa, mutta kaikkia 12207:n prosesseja ei ole pakko sisällyttää 62304:ään.

Tarkoitus on, että 62304:ää ei jaeta kahteen osaan (ohjelmistokehitys ja ylläpito eri standardeissa) vaan pidetään kaikki mukana yhdessä 62304:ssä. Annex C:hen ehdotettiin viittauksia myös standardeihin, jotka eivät koske regulaation alaisia lääkintälaitteita, vaan liittyvät muuten aihepiiriin. Kommenttien perusteella täytyy vielä keskustella siitä, miten viitataan riskienhallintastandardiin ISO 14971. Reguloitujen ohjelmistojen osalta tämä standardi on käytännössä pakollinen, mutta muiden osalta kevyempi prosessi tai 31000-sarjan mukainen riskienhallinta voisi olla mahdollinen.

Itävallasta oli tullut kommentti, joka tyrmäsi koko standardin filosofian. Kommentissa esitettiin, että nykyversio on liian sidoksissa reguloituihin lääkintälaitteisiin ja se vaatii liikaa ei-reguloiduilta terveyteen liittyviltä ohjelmistoilta, joita voidaan kehittää esim. avoimen lähdekoodin menetelmillä. Toinen ongelma on se, että ei-reguloiduille ohjelmistoille on tyypillistä tiheä päivitystahti, mitä on vaikea toteuttaa nykytyyppisellä 62304:llä. Itävallan kommentista puuttui ehdotus, miten standardia pitäisi muuttaa. Toisaalta USAsta oli tullut kommentti, että vaatimustasoa pitäisi tulisi päinvastoin nostaa FDA:n luokan A ohjelmistoille. Sherman Eagles (SE) totesi, että ohjelmistonkehitysteknologiat ovat kehittyneet siinä määrin (open sourcen laaja käyttö), että 62304 ei oikein ota tätä hyvin huomioon. Britannian ehdottama PAS 277 olisi paremmin tämän mallin mukainen. Tässä vaiheessa projektiryhmä päätyi siis hylkäämään kummatkin ehdotukset.

SE sanoi, että riskipohjainen lähestymistapa olisi entistä oleellisempaa ottaa käyttöön. FDA.lla ei ole aikaa käydä tarkasti läpi luokan A tuotteita, mutta niiden tuottajien riskianalyysimenetelmän läpikäynti riittää. SE totesi, että on tiettyjä asioita, joita kaikkien terveysohjelmistojen kehitysmenetelmien tulee täyttää. Reguloitujen ohjelmistojen tulee täyttää myös tiettyjä lisävaatimuksia. Kommentoitiin, että emme voi kirjoittaa standardia jonkun regulaattorin vaatimusten mukaan, vaan tarkoitus on määritellä parhaat käytännöt terveysalan ohjelmistojen laadintaan.

62304:ssä on luokka A, joka on tarkoitettu ohjelmistoille, jotka eivät voi aiheuttaa vahinkoa. Tässä luokassa vaatimukset ovat pienimmät. Jotta tiedettäisiin, kuuluuko ohjelma tähän luokkaan, täytyisi tehdä jonkinlainen riskianalyysi joka tapauksessa.

Ehdotettiin, että vähennettäisiin luokkien määrää kahteen: A ja nykyistä C:tä vastaava luokka. Kuulemma hyvin harva yritys käyttää luokan B vaatimuksia ohjelmistoilleen, vaan noudatetaan suoraan luokan C vaatimuksia, jos A:ta ei voida käyttää. Keskustelussa päädyttiin kuitenkin pitämään mukana myös luokka B.

Käytiin pitkä keskustelu ohjelmistojen luokittelun päätöspuusta luokkiin A, B ja C. Osa toivoi todennäköisyyksien huomioimista päätöksenteossa. Esimerkkinä oli tilanne, jossa analyysin mukaan ohjelmiston takia tapahtuu kuolemantapaus kerran 20000 vuodessa. Kysymys on, millainen päätöspuu olisi, jotta tämän ohjelmiston ei tarvitsisi päätyä luokkaan C.

Termit HARM, LEGACY SOFTWARE, SECURITY, SOFTWARE SYSTEM, SOFTWARE UNIT, SOUP, TRACEABILITY aiheuttivat keskustelua, mutta merkittäviä muutoksia ei tehty.

Termin HARM määritelmä vaikuttaa moneen asiaan ja siksi se on tärkeä. Jos se on liian kattava, moni ohjelmisto päätyy turhaan johonkin muuhun luokkaan kuin A. Keskustelussa nousi esiin tavoite, että rajataan HARM vain alueelle INJURY eli selkeään terveyshaittaan potilaalle. Keskustelun jälkeen päätettiin ottaa mukaan termi HARM sen laajemmassa merkityksessä, joka sisältää myös vahingot yksityisyyden suojalle ja ympäristölle.

LEGACY SOFTWAREn kohdalla tehtiin joitakin pieniä täsmennyksiä vaatimuksiin.

SOFTWARE SYSTEMin määritelmää ei muutettu olellisilta osiltaan.

SECURITYn osalta pitäydyttiin samassa määritelmässä kuin FDIS 82304-1:ssä, koska standardit liittyvät toisiinsa, vaikka SECURITYlle on muitakin määritelmiä.

SOFTWARE UNITin määritelmää oli pyydetty parantamaan. Varsinaista määritelmää ei muutettu, mutta sen selitystä Annexissa päätettiin täydentää. Sekaannusta voi aiheuttaa se, että tämän määritelmän SOFTWARE UNIT ei ole se kohde, jota testataan software unit testing -osassa, vaikka näin olisi loogista ajatella.

SOUP-teemiä oli kritisoitu Itävallassa, koska se ikäänkuin halventaa open source -ohjelmistokehitystä. Johtuen projektiryhmän jäsenten taustaorganisaatioista, open source -näkökulma ei saanut ymmärrystä ja hyväksyntää ja niin kommenttia ei aiheuttanut toimenpiteitä.

TRACEABILITYn osalta vaihdettin vuodelta 1998 peräisin olevaan määritelmään sanan PRODUCT tilalle sana DELIVERABLE. ISO 9000:ssa vuodelta 2015 olisi myös ollut määritelmä TRACEABILITYlle, mutta siihen ei haluttu siirtyä.

Päätettiin siirtää kohta 4.1, jossa mainittiin tarve noudattaa paikallisia lakeja ja määryksiä pois normatiivisesta osasta johdanto-osaan. Muussa tapauksessa joku auditoija olisi saattanut vaatia 4.1:n perusteella dokumentaatiota siitä, mitä lakeja ja määräyksiä on otettu huomioon ohjelmistossa.

Keskusteltiin riskienhallintaprosessin tarpeesta ja kattavuudesta. Erityinen puheenaihe oli tietoturvan huomioimisen laajuus. Osa ei pitänyt asiaa yleisesti tärkeänä muuten kuin potilasturvallisuuteen liittyen (hyökkäys ohjelmistoa kohtaan ei saa aiheuttaa potilasvahinkoa), mutta osan mielestä tietoturva tulee huomioida myös tätä laajemmin. Päätettiin sisällyttää prosessin vaatimuksiin potilasturvallisuuden, tietoturvan ja käytettävyyden huomioonotto. Tietoturvan huomioonoton laajuus jäi auki.

Keskusteltiin ohjelmistojen riskiluokittelukaavioista. Pohdittiin, miten voisi ottaa paremmin huomioon todennäköisyyksiä vahingoille riskiluokituksissa, jotta ohjelmisto ei turhaan päätyisi luokkaan, jossa vaatimukset ohjelmiston tuotantoprosessille ovat turhan tiukat.

LEGACY-ohjelmistojen riskienhallinta aiheutti myös keskustelua. Pohdittiin, mikä on se minimitaso, jota valmistajilta pitää vaatia, kun he ottavat käyttöön tällaisia vanhoja ohjelmistoja osana isompaa kokonaisuutta.

Kohtaan 5.3 Software ARCHITECTURAL design tuli luokan C ohjelmistoille lisävaatimus kuvata ohjelmiston dynaaminen käyttäytyminen. Tämä muutos aiheuttaa myös muutoksen listaan kohdassa 5.5.4 Additional SOFTWARE UNIT acceptance criteria.

Luvussa 6 on käytetty termejä "modification" ja "change". On pyydetty tarkistamaan, tarkoittavatko nämä samaa asiaa, mutta se ei kokouksen aikana selvinnyt. Yritetään kysyä asiaa projektiryhmän entiseltä jäseneltä Peter Jacksonilta, joka hallitsee brittienglannin.

Monet kommentit eivät päätyneet täsää vaiheessa ajanpuutteen vuoksi lainkaan koko ryhmän käsittelyyn. Helpoimmat ratkaisiin pienryhmissä ajan säästämiseksi. Projektiryhmäläiset tulevat kuitenkin saamaan katsottavakseen kaikki tehdyt muutokset, jotta voivat kommentoida niitä. Loppuja kommentteja tullaan käsittelemään syksyn mittaan verkkokkouksissa.

Aikataulu
Koska projektiryhmän kello nollattiin 2016, projektiryhmällä on runsaasti aikaa tuottaa uusi versio. Kesäkuuhun 2017 mennessä pitäisi tuottaa uusi CD, kesäkuussa 2018 CDV ja FDIS kesäkuussa 2019. Uskotaan, että projektiryhmä toimii tätä nopeammin. Uusi CD tulee ehkä jo maaliskuussa 2017.

Alpo Värri, TTY/Signaalinkäsittely, 13.10.2016