ISO&IEC PT-82304-1 ja 62304 V. 2 kokous Tokiossa 14.-17.5.2014


Projektiryhmä (PT) 82304-1 laatii standardia 82304-1Health Software - Part 1: General requirements for product safety. Sen on tarkoitus koskea kaikkien terveydenhoitokäyttöön laadittavien ohjelmistojen tuotantoa koko ohjelmiston elinkaaren ajalta poislukien sulautetut lääkintälaitteiden ohelmistot. Tavoitteena on saada standardi valmiiksi vuonna 2015.

Hallinnollisia asioita

Puheenjohtaja Patty Krantz (PK) kertasi asioiden hallinnollista edistymistä organisaatioissa. IEC 62A:n ja ISO/TC210:n yhteistyökohde lääkintälaiteohjelmistojen elinkaaristandardi IEC 62304 on hallinnollisesti siirretty ISO/TC210:ltä ISO/TC215/JWG7:ään. Nähtiin tärkeäksi, että ISO/TC215:n ekspertit voisivat osallistua.version 2 tuottamiseen, koska ohjelmisto-osaamista on enemmän TC215:ssä kuin TC210:ssa. Kohta aletaan kutsua eksperttejä version 2 projektiryhmään.

Lääkintälaitteiden regulointiuutisia

Koska tulevan standardin on tarkoitus sopia lääkintälaitteiden ohjelmistojen sääntelyyn, on syytä olla perillä siitä, mitä sääntelypuolella tapahtuu. International Medical Device Regulators Forumissa (IMDRF) on hiljattain aloittanut Software as a Medical Device (SaMD) ryhmä, jossa PK:kin on jäsenenä. Sen materiaalia on jo luettavissa internetissä osoitteessa http://www.imdrf.org. Ryhmän tarkoituksena on yhdenmukaistaa globaalisti terveydenhuollossa käytettävien ohjelmistojen sääntelyä mm. ohjelmistotuottajien kustannusten vähentämiseksi. Yksi oleellisimmista asioista on lääkintälaitteen määritelmä, joka rajaa sen, mitä ohjelmistojakin sääntely koskee. Tämänhetkinen IMDRF:n määritelmä on hyvin lähellä EU:n lääkintälaitedirektiivin määritelmää. Peter Jordan (PJ) kritisoi IMDRF:n SaMD-dokumentin tilannetta siitä, että nyt tehdään ikään kuin paikkaa lääkintälaitteiden sääntelyyn, kun ohjelmistot jossain vaiheessa vahingossa unohdettiin. PJ:n mielestä pitäisi määritellä tavoitetila, johon sääntelyn pitäisi päästä ja välttää tätä SaMD-ryhmän erillistä sääntelyprojektia. SaMD-ryhmän dokumenttiin osoitteessa http://www.imdrf.org/consultations/cons-smd-samd.asp pyydetään palautetta 31.5.2014 mennessä. PK pyysi tutustumaan ko. dokumenttiin ja kommentoimaan sitä.

Toinen PT:n johtajista Peter Linders (PL) esitteli EU:n Green Paperia mHealth-asioista. Se löytyy osoitteesta https://ec.europa.eu/digital-agenda/en/public-consultation-green-paper-mobile-health Sitä jotkut olivat jo lukeneet, mutta pohdittiin, pitäisikö 82304-1-projektiryhmän ottaa siihen yhteisesti kantaa. Määräaika on 3.7.2014. PT ei välttämättä pyri vastaamaan kaikkiin esitettyihin kysymyksiin, vaan vain niihin, jotka ovat lähinnä ryhmän työtä. Perustettiin pieni ryhmä valmistelemaan projektiryhmän vastausta. Tähän liittyy myös EU:n Komission 24.6.2014 mHealth webinaari, josta saa tietoa osoitteesta https://ec.europa.eu/digital-agenda/en/news/free-european-commission-webinar-mhealth

PL esitteli myös  AHWP TC WG 1:n dokumenttia Medical Device Software Regulation, Software Qualification and Classification toukokuulta 2014. Sen pitäisi tulla internettiin ja 82304-1-projektiryhmälle kommentoitavaksi muutamassa viikossa. Tämän raportin laatijoiden jäsenmaina ovat lähinnä joukko kehitysmaita, jotka edustavat 2-3 miljardia ihmistä maapallolla.

Lounastauolla (PL) kertoi, että EU:n standardeihin perustuva lääkintälaitteiden reguloinnin uusi lähestymistapa (new approach) on pikku hiljaa murenemassa. Tämä johtuu siitä, että EU:n komission yksikkö, joka on vastuussa harmonisoitujen standardien listasta, ei ole uudistanut listaa vuoden 2010 jälkeen. Koska standardeja päivitetään ja vanhat versiot samalla lakkaavat olemasta voimassa, ei monille alueille enää ole olemassa harmonisoitua standardia. Teollisuuden keskustelut Komission kanssa eivät ole johtaneet toivottuun edistymiseen. Europarlamenttivaalien jälkeen kuluu muutama kuukausi ennen kuin alueen komissaari on valittu ja tutustunut tehtäväänsä riittävästi voidakseen panna asioita toimeen.

Toshiaki Nakazato (TN) esitteli Japanin lääkeasiain lain uudistusta, sillä se koskee myös lääkintälaitteita ja terveydenhuollon ohjelmistoja. Vain japaninkielinen ehdotus on kommentoitavana toukokuun 2014 loppuun saakka. Tarkoitus on parantaa tuoteturvallisuutta. Myös laatujärjestelmiä koskeva osuus muuttuu. Vaikka osin säännöstö tulee olemaan ISO 13485:n mukainen, siinä tulee olemaan japanilaisia erityisvaatimuksiakin. Markkinoilletulo edellyttää laatujärjestelmän tarkistuttamista. Ulkomaalaisia valmistajia koskee oma rekisteröitymisjärjestelmänsä. Laatujärjestelmä pitää tarkistuttaa tuoteperheittäin, ei enää tuotteittain. Myös terveydenhuollon stand-alone-ohjelmistot tulevat sääntelyn piiriin. Määritelmä siitä, mikä ohjelmisto on lääkintälaite, on vielä keskustelunalainen. Päätös lienee valmis lokakuussa 2014. Lain pitäisi tulla voimaan marraskuussa 2014. Japanin esitys uudistuksestaan löytynee soitteesta http://www.imdrf.org/

82304-1:n kenttätestaus kesällä 2014

PL  pyrkii löytämään muutamia yrityksiä, jotka kokeilisivat toteuttaa 82304-1:n yrityksessään kesäkuun 2014 dokumenttiversion pohjalta. IEC:n copyright voi hieman hankaloittaa tätä prosessia, mutta siitä päästään ehkä yli. Movendos Tampereelta mainittiin yhdeksi mahdolliseksi testaajaksi, jos yrityksellä on siihen kiinnostusta. Testausjakson ajankohta vain on suomalaisten lomakauden kannalta hieman huono: 15.6.-15.9.2014, mutta tätä ei oikein voida muuttaa, koska standardoinnin aikataulu painostaa. Vapaaehtoiset suomalaiset firmat voivat ilmoittautua allekirjoittaneelle. Testaajalta edellytetään vapaamuotoista raporttia standardin toimivuudesta käytännössä ja erityisesti sen ongelmakohdista.

Esitys nykyaikaisesta ohjelmistonkehityksestä

Vincent McCauley (VM) Medical Software Industry Association (MSIA) of Australiasta piti esityksen moderneista ohjelmistonkehitystekniikoista. SOA on nykyään keskeinen arkkitehtuuri ohjelmistotuotannossa. Sen avulla säästytään osasta ohjelmistotuotannosta, kun voidaan käyttää valmiita palveluita. Web Services on keskeinen teknologia. Client/Server kytkentä voi olla löysempi tai tiukempi. Terminologiat ja ontologiat tulee huomioida. Pysyväistallennus-asiat täytyy huolehtia terveydenhuollon järjestelmissä. SOAssa on Service Functional Model (SFM), joka sisältää alustariippumattoman mallin (PIM) ja alustariippuvan osan (PSM). Palveluja ei yleensä toteuteta kokonaan, vaan siitä toteutetaan osa, profiili. Palvelut esitetään usein OWL:llä ja UML:llä. RESTful ja Web Services (SOAP) ovat vaihtoehtoisia toteutustapoja. Ohjelmistokomponentit ovat laajentuneet tavanomaisista moduleista APIen kautta alustoille kuten Facebook, Google, Microsoft, Android ja Apple. Näissä kytkentä voi olla löysempi tai tiukempi. Ohjelmiston ylläpitoon menee enemmän aikaa kuin sen tuotantoon. Siksi pyritään yhteen ohjelmistokokonaisuuteen, josta voidaan tuottaa versioita eri alustoille. Sovellutuksia voidaan myös konfiguroida dynaamisesti ajonaikaisesti joko datalähtöisesti tai käyttölähtöisesti. Konfigurointia voidaan siis tehdä eri tasoilla ja näiden variaatioita tulee siten helposti monta. Tämä tulee ottaa huomioon 82304-1:n vaatimuksia määriteltäessä. Esimerkisi konformanssitestauksessa käytetty ohjelmistokokonaisuus ei useinkaan ole juuri se sama, joka otetaan käyttöön. Kun pohditaan, mitä verifioidaan ja validoidaan, täytyy ottaa tämä uusi kompleksisuus huomioon. Verifioidaanko siksi mallia, jotakin profiilia vai mitä.

82304-1:n muutosehdotusten käsittelyä

82304-1:n toiseen CD:hen oli saatu paljon kommentteja. PK ja PL olivat käyneet niistä helpoimmat jo läpi ja keskityttiin keskustelemaan hankalimmista kohdista. Standardin nimeä oli ehdotettu muutettavaksi, mutta päätettiin jättää se ennalleen. USAsta oli tullut ehdotus, että alimman riskiluokan ohjelmistot vapautettaisiin 62304:n, 62366:n ja 14971:n vaatimuksista.  Keskusteltiin turvallisuusluokituksen käytöstä standardissa, koska oli ehdotettu, että eritysesti "vaarattomien" mobiiliterveyssovellutusten tekijöiden ei tarvitsisi tutustua 62304:n, 62366:n ja 14971:n vaatimuksiin. Päädyttiin siihen, että nämä sovellutukset ovat 62304:n luokassa A ja tätä uokkaa koskevien vaatimusten mukaan pitää toimia. 82304:n luvun 4 otsikointia ja alaotsikointia muutettiin saatujen palautteiden takia.

Validaatiokappale 6 otettiin lähempään tarkasteluun ja se muuttui merkittävästi ruotsalaisten toiveen takia. Ruotsalaiset toivoivat yksinkertaisempaa menettelyä "vaarattomille" sovellutuksille. Tärkein muutos oli, että ei edellytetä enää, että jokaista vaatimuskohtaa varten olisi oma testinsä, vaan tiettyjen dokumenttien dokumentoitu vertailu voi riittää. VM koitti saada vaatimuksiin lievennyksiä, koska kaikkea ei ole mahdollista testata esim. middlewaren tapauksessa. Selvitetään, voidaanko validointia jotenkin helpottaa turvallisuusluokan A ohjelmistotuotteille.

Keskusteltiin myös siitä, kuinka tarkaan verkotetussa ympäristössä toimivan ohjelmiston turvallisuusvaatimukset kohdassa 7.2.3.2 tulee tehdä samoiksi kuin IEC 60101-1:n kohta 14.13, jotta ohjelmistontoimittajan ei tarvitse tältä osin täyttää kahden erilaisen standardin vaatimuksia. Sanapari IT network korvataan paikoitellen sanoilla operating environment, jotta se kattaisi paremmin ohjelmistojen toimintaympäristön.

Käytiin läpi saatuja muitakin kommentteja ja hyväksyttiin niistä lähinnä pieniä parannuksia tekstiin. Kappaleeseen 4 tuli kuitenkin jonkin verran muutoksia ohjelmstotuotteiden vaatimuksiin. Kappaletta 5 ohjelmistorprosessista muutettiin siten, että normatiivisen standardin ISO/IEC 62304 kautta on riskienhallintastandardia ISO 14971 noudatettava kokonaan ilman poikkeuksia. Laadittiin Compliance-kappale, jossa määritellään, miten standardin vaatimustenmukaisuus osoitetaan.

Alkaa näyttää siltä, että yrityksen, joka haluaa täyttää standardin 82304-1 vaatimukset, tulee täyttää myös standardien IEC 62304, IEC 62366, ISO 14971 ja ISO 13485 vaatimukset, vaikka kyseessä olisi vähän riskejä sisältävä luokan A sovellutusohjelma. Jotkut haluaisivat tehdä 82304-1-standardista mahdollisimman lyhyen, kun taas toiset haluaisivat liiteosiin hieman selvitystä siihen, mitä varsinaisessa, standardin vaatimusosassa oikeastaan tarkoitetaan. Ilman näitä tarkempia selvityksiä konsulteille syntyy työtilaisuuksia, kun he kertovat asiakkailleen, mitä standardia noudattavien yritysten itse asiassa pitää tehdä.

TN korosti, että IEC 62366 on tärkeä pitää normatiivisena standardina 82304-1:ssä. Asiasta keskusteltiin, koska eräs näkökanta oli, ettei aivan kaikkea 62366:sta tarvitsisi noudattaa. Norbert Pauli (NP) korosti, että projektiryhmän olisi syytä käyttää nimenomaan valmistumassa olevaa uutta versiota 62366:sta. Keskusteltiin myös 14971:n tekemisestä normatiiviseksi. VM piti ongelmallisena, että ohjelmistotoimittajille tulisi yhtäkkiä 82304-1.n myötä lisäksi noudatettavaksi setti 62304, 62366, 14971 ja 13485, koska se tulis liian kalliiksi. Katsottiin myös, mitä ISO 12207:2008 Systems and software engineering — Software life cycle processes  sisältää ja voisiko se olla vaihtoehtoinen tapa toteuttaa laadukkaita ohjelmistoja. Sitäkin ollaan kuitenkin päivittämässä. PL spekuloi, että jos 14971:ä ei tehtäisi normatiiviseksi, 14971:stä voitaisiin ehkä poimia osia, joista tulisi normatiivinen liiteosa 82304-1:een. Pienryhmä jää pohtimaan 62366:n ja 14971:n mukaanottoasiaa.

Terveydenhuollon ohjelmistojen turvallisuusstandardit - keskustelu tulevaisuudensuunnitelmasta

Lokakuussa 2012 perustettiin ISO/TC215:ssä keskusteluryhmä (ad hoc group on software) suunnittelemaan, mitä ohjelmistojen turvallisuusstandardeja mahdollisesti vielä täytyisi laatia 82304-1:n ja 17791:n tultua valmiiksi. Tältä ryhmältä tuli sen sisäiseen käyttöön luonnos raportista, johon 82304-1-projektiryhmällä oli nyt mahdollisuus tutustua ja kommentoida sitä. Keskusteluryhmä ei ole vielä päässyt siihen vaiheeseen, että se osaisi esittää uusia standardeja laadittavaksi. Loppuraporttia tältä ryhmältä odotetaan lokakuussa 2014.

Keskustelu 62304:n päivityksestä

Oli tarkoitus keskustella myös 62304:n version kaksi tuottamisesta  ja siitä, mitä pävitysvaatimuksia siihen kohdistuu 82304-1:n suunnalta, mutta 82304-1:een liittyvät asiat veivät käytännössä melkein koko ajan. 62304 kuuluu ISO:ssa nyt TC215/JWG7:lle. Kohta lähetetään kutsu liittyä 62304:n päivitysryhmän jäseneksi.

Ehdotettiin, että luokan A ohjelmistojen valmistajien olisi helpompi käyttää standardia, jos kaikki luokan A ohjelmistojen vaatimukset keskitettäisiin alkuosaan. Tämä tietäisi suurehkoa rakenteellista muutosta. Sherman Eagles haluaisi mennä 12207:n mukaiseen rakenteeseen. VM ihmetteli, miten 62304:ssä mainittu arkkitehtuurin verifiointi oikein voidaan tehdä. PL sanoi, että tämä on monelle ongelmakohta. VM sanoi, että, jos käyttää esimerkiksi Googlen alustaa, verifiointi on hyvin ongelmallista, koska dokumentteja alustasta ei ole käytettäväissä. Siksi luokan C sovellutusta ei ehkä voida rakentaa Googlen alustalle nykyisen 62304:n tiukimman tulkinnan mukaan. NP sanoi, ettei näin tiukasti tarvitse standardia tulkita, koska siinä on käsite SOUP, software of unknown provenance (kohta 5.3.3), joka tulee kyseseen esimerkiksi käyttöjärjestelmän kohdalla. "Interenet on SOUP". VM muistutti, että terveydenhuollon ohjelmistijakin tulee päivittää melko usein kuoodistojen päivittyessä ja määräysten muuttuessa puhumattakaan allaolevasta Windows-käyttöjärjestelmästä. VM muistutti myös, että jokaiseen järjestelmään voidaan murtautua, kun riittävästi resursseja satsataan siihen (NSA). Näitä riskejä ei ole riittävästi huomioitu 62304:2006:ssa. PK sanoi, että kettereien menetelmien huomioonotto ei ole kovin keskeistä 62304:n päivityksessä. Niiden osalta laaditaan ehkä informatiivinen liiteosa tai vain viitataan kirjallisuusluettelossa dokumenttiin AAMI TIR45:2012, Guidance on the use of AGILE practices in the development of medical device software, jota USA:n FDAkin suosittelee. VM otti esiin oppivien ja älykkäiden järjestelmien mahdollisuudet terveydenhuollossa, sillä nykyisessä mallissa ne ovat ongelmallisia, koska näihin tekniikkoihin perustuvan tietokoneohjelman toiminta ei ole täysin ennustettavissa.

IEC Guide 63

NP halusi tuoda esiin, että uusi luonnos IEC Guide 63:sta on ilmestynyt, Guide to the development and inclusion of safety aspects in International Standards for medical devices. Tämä ohje on suunnattu standardien laatijoille ja sitä tulisi lukea Guide 51:n kanssa. NP halusi, että luonnosta kommentoitaisiin ja kommentit lähettettäisiin hänelle 10.7.2014 mennessä.

Seuraavat kokoukset

ISO/TC215 kokoontuu 6.-10.10.2014 Berliinissä. PT kokoontuu sen yhteydessä Berliinissä 10.-11.10.2014. Lisäksi 12.6.2014 pidetään puhelinkokous Suomen aikaa klo 14.

Alpo Värri 23.5.2014