In vitro -diagnostiikkatuotteiden tuotantolaitteiden vaatimusmäärittely

In vitro -diagnostiikkatuotteiden tuotantolaitteiden vaatimusmäärittely

Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten.

Espoossa 7.11.2020

Valvoja: Professori Esko Niemi Ohjaaja: DI Juha Korhonen

Diplomityön tiivistelmä

TekijäVille Paakkunainen

Työn nimiIn vitro -diagnostiikkatuotteiden tuotantolaitteiden vaatimusmäärittely Maisteriohjelma Mechanical Engineering KoodiENG25 Työn valvojaEsko Niemi

Työn ohjaaja(t)Juha Korhonen

Päivämäärä 7.11.2020 Sivumäärä131 KieliSuomi

Tiivistelmä

Diplomityön tavoitteena on tutkia In vitro -diagnostiikkatuotteiden tuotantolaitteiden vaatimusmäärittelyä osana laitehankinnan prosessia. Työn osana selvitetään mahdolli- suuksia kastolevypakkaamon kehitykseen, sekä muodostetaan parhaiden käytäntöjen mukainen vaatimusmäärittely automaatiolaitteelle, jolla pyritään parantamaan kastole- vypakkaamon työskentelyolosuhteita.

In vitro -diagnostiikka-ala asettaa monia viranomaisvaatimuksia diagnostisten testien tuotannolle. Tutkimuksessa selvitetään miten nämä viranomaisvaatimukset vaikuttavat itse tuotantolaitteiden vaatimusmäärittelyyn. Lisäksi tutkimuksessa tarkastellaan miten vaatimukset ylipäätään tulisi määritellä toimialasta riippumatta, ja mikä vaatimusten rooli on.

Selvitysten perusteella muodostettiin vaatimusmäärittelylle pohja, jota testattiin käytän- nössä suorittamalla vaatimusmäärittely uudelle tuotantolaitteelle. Tämän määrittelyn pe- rusteella pyydettiin toimittajilta alustavat tarjoukset laitteesta.

Tutkimuksen lopputuloksena on selvää, että vaikka teoriassa selkeälle vaatimusten mää- rittelylle on hyvin tarkat ohjeet, on niiden noudattaminen käytännössä hyvin hankalaa.

Työn lopputuloksena muodostettu pohja vaatimuslistalle on koostettu eri lähteiden par- haita käytäntöjä mukaillen. Vaikka uusi pohja toimikin käytännössä erittäin hyvin tarpei- den kommunikoinnissa asiakkaan ja toimittajan välillä, nähdään että kaikki vaatimukset eivät silti ole täysin yksiselitteisiä.

AvainsanatIn vitro -diagnostiikka, tuotantolaitteet, vaatimusmäärittely, URS, User Re- quirements Specification

equipment

Master programme Mechanical Engineering CodeENG25 Thesis supervisorEsko Niemi

Thesis advisor(s) Juha Korhonen

Date7.11.2020 Number of pages131 LanguageFinnish

Abstract

The aim of the master’s thesis is to study requirement specification as part of the equip- ment acquisition process for In vitro -diagnostic products production equipment. As part of the study possibilities for dipslide manufacturing development are mapped, and re- quirement specification is formed for an automation equipment using best practices in requirement capturing. The aim for the automation device is to enhance the ergonomics in dipslide manufacturing.

In vitro -diagnostic test manufacturing environment is highly regulated. This study inves- tigates how those regulations affect the requirements specification process for the actual production equipment. Additionally, this study investigates how requirements should be defined, and what is their role in other manufacturing environments.

Based on the findings, a document template was formed to be used in requirements spec- ification. This was tested in practice by forming a specification sheet for a new production equipment. Preliminary offers were requested from several suppliers based on this spec- ification.

The conclusion of the study is that although in theory it is quite clear how well-defined requirements should be formed, putting this theory into practice is often difficult. As a result from this study, a template for requirement capturing based on best practices from several sources was formed. This template worked well as a mean of communication be- tween the supplier and customer, but individual requirements were still deemed not un- ambiguous.

KeywordsIn vitro -diagnostic, production equipment, Requirements Specification, URS, User Requirements Specification

Alkusanat

Diplomityön tarkoituksena oli tutkia vaatimusmäärittelyä osana laitehankinnan proses- sia diagnostiikkayrityksessä. Selvityksen ohella tarkasteltiin kastolevypakkaamon toimin- nan tehostamista. Työn valvomisesta tahdon kiittää Aalto-yliopiston professori Esko Nie- meä. Ohjaajana toimi diagnostiikkayrityksen Projektit ja kehitys osaston päällikkö Juha Korhonen. Tahdon erityisesti kiittää sekä valvojaa että ohjaajaa jatkuvasta kannustami- sesta ja tuesta. Diagnostiikkayritystä tahdon kiittää mielenkiintoisesta aiheesta, sekä työn rahoituksesta. Kiitokset myös kaikille muille yrityksen työntekijöille tuesta sekä työssä että opintojen loppumetreillä.

Lisäksi tahdon kiittää vanhempiani opintojeni tukemisesta, sekä tietenkin rakasta vai- moani, joka järjesti kiireisen perhe-elämänkin keskellä minulle mahdollisuuden saattaa tämä työ loppuun.

Vantaa 7.11.2020 Ville Paakkunainen

Sisällysluettelo

Tiivistelmä Abstract Alkusanat

Sisällysluettelo ...5

Lyhenteet ...7

1 Johdanto ...8

1.1 Työn tausta ...8

1.2 Tutkimuskysymykset ...8

1.3 Työn tavoite ...8

1.4 Rajaus ...8

1.5 Yrityksen kuvaus ...8

1.6 Työn rakenne...9

2 Käyttäjävaatimukset... 10

2.1 URS:n rooli ... 10

2.1.1 GxP ... 10

2.1.2 Validointi ... 10

2.1.3 URS ... 12

2.2 Viranomaisvaatimukset ... 12

2.2.1 Yleistä ... 12

2.2.2 Suomen lainsäädäntö ... 13

2.2.3 EU-direktiivi ... 13

2.2.4 IVDR ... 14

2.2.5 ISO 13485 ... 15

2.2.6 FDA ... 16

2.3 URS rakenne ... 17

2.3.1 SRS ... 17

2.3.2 GAMP 5 ... 18

2.4 Muut teollisuudenalat ... 21

2.4.1 Requirements list tuotekehityksessä ... 21

2.4.2 SRS ohjelmistokehityksessä ... 22

3 URS-templaatin kehitys ... 24

3.1 Diagnostiikkayrityksen käyttämä malli ... 24

3.2 Miten vaatimukset tulisi määritellä ... 25

3.2.1 Vaatimusten määritys ... 25

3.2.2 Luokittelut ... 26

3.2.3 Jäljitettävyys ... 27

3.2.4 Yleisiä virheitä vaatimusten määrittelyssä ... 27

3.3 Use case ... 28

3.3.1 Tyypilliset virheet ... 28

3.3.2 Ongelmat hankintaprojektin aikana ... 29

3.4 Esille nousseet kehityskohteet ... 30

3.5 Benchmarking ... 31

3.5.1 Yritys 1 ... 31

3.5.2 Yritys 2 ... 32

3.5.3 Emoyhtiö... 32

3.6 Uusi URS-malli ... 33

4 Kastolevypakkaamon kehitys ... 35

4.1 Aineiston keräys ... 35

4.2 Prosessin nykytilan kuvaus ... 35

4.2.1 Kastolevyprosessi ... 35

4.2.2 Kastolevypakkaamon laitteet ... 36

4.2.3 Kastolevypakkaamon henkilöstö ja roolit ... 37

4.2.4 Sairauspoissaolot ... 38

4.3 Layout-suunnittelu... 39

4.3.1 Nykyinen layout ... 39

4.3.2 Suunnittelun lähtökohdat ja reunaehdot ... 40

4.3.3 Layout vaihtoehdot ... 40

4.4 Tarjottimien purkulaitteen toiminnalliset vaatimukset ... 42

4.4.1 Prosessin asettamat vaatimukset ... 42

4.4.2 Optiot ... 43

4.5 Purkulaitteen tarjoukset ... 44

4.5.1 Tarjousten arviointi ... 44

4.5.2 Arvoanalyysi ... 45

4.5.3 Investointilaskelmat... 46

5 Johtopäätökset ... 48

5.1 URS-templaatti ... 48

5.2 Kastolevypakkaamon layout ... 48

5.3 Tarjottimien purkulaite ja toimittajan valinta ... 48

5.4 Jatkotutkimukset ... 49

Lähdeluettelo ... 50

Liiteluettelo ... 52

Lyhenteet

cGMP current Good Manufacturing Practice

FDA Food and Drug Administration

FDS Functional Design Specification

FMEA Failure Mode and Effects Analysis

FS Functional Specification

GAMP Good Automated Manufacturing Practice

GxP Good x Practice

IEEE Institute of Electrical and Electronics Engineers

RFID Radio Frequency Identification

RFP Request for Proposal

RTM Requirements Traceability Matrix

SDS Software Design Specification

SRS Software Requirements Specification

URS User Requirements Specification

1 Johdanto

1.1 Työn tausta

Tämän diplomityön aiheena on In vitro -diagnostiikkatuotteiden tuotantolaitteiden vaatimus- määrittely. Termi In vitro tulee latinasta, ja kirjaimellisesti käännettynä tarkoittaa ”lasissa”. Eli kun puhutaan In vitro -diagnostiikasta, tarkoitetaan tällä diagnostista testiä, joka suoritetaan kehon ulkopuolella, kuten esimerkiksi lasiastiassa. Näiden testien toiminnalle on omat tarkasti määritellyt viranomaisvaatimuksensa jotka niiden tulee täyttää, mutta tässä työssä keskitytään vaatimuksien hallintaan näiden testien tuotannossa käytettävien tuotantolaitteiden osalta.

Tarve työlle syntyi diagnostiikkayrityksen halusta kehittää laitehankintaprosessia. Erityisesti URS, eli User Requirements Specification -dokumentti oli noussut selkeäksi ongelmakohteeksi muutamassa edellisessä laitehankintaprojektissa. Ongelmakohtia olivat vaatimusten tulkinnan- varaisuus sekä ongelmat asiakkaan ja toimittajan yhteisymmärryksessä.

Koska päivitettyä mallia haluttiin myös testata käytännössä, tehtiin osana diplomityötä myös vaatimuslista pakkauskoneen automaattiselle täyttäjälle. Tämän prosessivaiheen oli selkeästi havaittu tuottavan terveysongelmia operaattoreille sen fyysisen kuormittavuuden takia. Tämän selvityksen yhteydessä tutkittiin myös mahdollisia layout-muutoksia liittyen kastolevypakkaa- moon, joilla voitaisiin tehostaa tilan käyttöä. Tälle oli tarvetta, koska kastolevytuotanto vie suu- rimman osan tehtaan pinta-alasta, vaikka on liikevaihdollisesti vain pieni osa tuotteista.

1.2 Tutkimuskysymykset

Tutkimuskysymyksiksi määritettiin:

 Mikä on URS:n rooli tuotantolaitteiden validoinnissa?

 Mikä on URS:n rooli osana laitehankinnan prosessia?

 Miten viranomaisvaatimukset määrittävät URS:n rakennetta ja vaatimuksia?

 Mitä URS:n pitäisi sisältää?

 Miten vaatimukset pitäisi määritellä?

Näiden kysymysten pohjalta lähdettiin selvittämään, onko nykyisessä mallissa jotain vikaa, ja kuinka sitä voitaisiin parantaa.

1.3 Työn tavoite

Työn tavoitteena oli tehdä yleinen URS-templaatti yritykselle, jota voidaan jatkossa hyödyntää osana laitehankintaa. Lisäksi tavoitteena oli tehdä vaatimusmäärittely pakkauslinjan automaat- tiselle täyttäjälle, tehdä muutama vaihtoehtoinen ehdotus layoutista ja pyytää alustavat tarjouk- set toimittajilta.

1.4 Rajaus

Itse laitehankintaprojekti jätettiin työn ulkopuolelle. Lisäksi muuta validointia ei tutkittu kovin tarkasti osana kirjallisuuskatsausta. Layout-suunnitelmien osalta rajoitettiin tutkittava alue kas- tolevypakkaamoon.

1.5 Yrityksen kuvaus

Tämän diplomityön rahoittanut yritys oli työn suorituksen aikaan osa suurempaa yhtiötä, jonka pääasiallisena toimialana on lääkkeiden valmistus. Myöhemmin yritys irrotettiin emoyhtiöstä, ja tänä päivänä yritys on itsenäinen yhtiö. Tässä työssä käytetään irtautuneesta yrityksestä ni- meä Diagnostiikkayritys, ja aikaisemmasta emoyhtiöstä käytetään nimeä Emoyhtiö.

Diagnostiikkayritys on suomalainen diagnostiikka-alan yritys, joka toimittaa diagnostisia tes- tejä maailmanlaajuisesti. Testejä on saatavilla sekä kliiniseen diagnostiikkaan, että hygienian seurantaan.

Diagnostiikkayritys työllistää yli 300 henkeä. Sen pääkonttori ja tuotanto sijaitsevat Suomessa.

Lisäksi yrityksellä on paikallistoimistoja pohjoismaissa, Keski-Euroopassa ja Aasiassa.

1.6 Työn rakenne

Johdannon jälkeen toisessa kappaleessa lähdettiin liikkeelle vaatimusmäärittelylistan, eli URS:n, roolista osana validointia. Tämän jälkeen tarkasteltiin tarkemmin viranomaisvaatimuk- sia, jotka vaikuttavat vaatimusmäärittelyyn In vitro -diagnostiikka-, eli IVD-alalla. Tämän jäl- keen suoritettiin kirjallisuuskatsaus, jonka tarkoituksena oli tutkia, miten vaatimukset tulisi määritellä toimialasta riippumatta.

Kolmannessa kappaleessa pyrittiin keräämään kehitysideoita vaatimusten määrittelyyn. Kehi- tysideoita kerättiin tutustumalla vanhaan laitehankintaprojektiin, jonka vaatimusmäärittelyn epäonnistuminen toimi myös taustana tämän työn aiheelle. Lisäksi tässä kappaleessa kerättiin yhteenvetona kehityskohteita sekä laitetoimittajilta että yrityksen sisältä. Kappaleen viimei- sessä osassa suoritettiin benchmark-vierailu kahden eri yrityksen luona ja vertailtiin vaatimus- ten määrittelyä.

Neljännessä kappaleessa testattiin uudelleen muotoiltua URS:ia käytännössä. Tämän osana teh- tiin vaatimusmäärittely tarjottimien automaattiselle purkulaitteelle kastolevypakkaamoon ja pyydettiin toimittajilta alustavat tarjouspyynnöt laitteesta. Kappale alkaa kastolevypakkaamon toiminnan nykytilan kuvauksella, jonka jälkeen tutkitaan mahdollisia layout-muutoksia. Tämän jälkeen esitetään kuinka vaatimuslista muodostettiin, jonka jälkeen esitellään toimittajien alus- tavat konseptit ja tarjoukset.

Viimeisessä kappaleessa esitetään yhteenvetona kaikki johtopäätökset. Ensin mitä muutoksia URS-templaattiin tehtiin, sitten mitä suositellaan kastolevypakkaamon layoutille ja lopuksi suositus automaattisen purkulaitteen toimittajasta.

2 Käyttäjävaatimukset

Kirjallisuudessa ei olla juurikaan käsitelty tuotantolaitteiden vaatimusmäärittelyä IVD-alalla laajemmin. Ohjelmistokehityksen osalta löytyy paljon materiaalia vaatimusten määrittelystä ja elinkaaren hallinnasta. Myöskin tuotekehityksessä vaatimuslistalla on iso rooli. Samat perus- periaatteet ja yleiset ongelmat kuitenkin koskevat myös lääkinnällisten laitteiden valmistusta.

Suurimpana eroavaisuutena muihin teollisuudenaloihin ovat erittäin tarkat viranomaismääräyk- set koskien validointia, eli varmistusta että laite täyttää tuotteen sille asettamat vaatimukset.

2.1 URS:n rooli

GxP tai GMP ovat termejä, jotka viittaavat voimassa oleviin viranomaisvaatimuksiin. GMP tulee sanoista Good Manufacturing Practice, ja GxP:llä tarkoitetaan, että valmistustapojen li- säksi on muitakin osa-alueita, joilla hyödynnetään ohjeistusta. Esimerkiksi GLP, Good Labo- ratory Practices. On olemassa myös merkintä cGMP, jolla tarkoitetaan current Good manufac- turing Practice. Tällä halutaan korostaa, että toimintaa täytyy kehittää jatkuvasti (ISPE 2020).

Näiden vaatimusten tarkoitus on varmistaa, että valmistajat huolehtivat tuotteiden turvallisuu- desta. Vaatimusten seuraaminen on tarkkaan säädeltyä, ja niiden noudattamattomuus voi johtaa sanktioihin. Vaatimuksia laativat esimerkiksi Euroopan tasolla Euroopan komissio ja Ameri- kassa Food and Drug Administration, eli FDA. Viranomaisvaatimuksia on tarkasteltu tarkem- min luvussa 2.2.

Kun puhutaan laitteesta tai järjestelmästä joka on GxP:n vaatimusten mukainen, tarkoitetaan että se vastaa kaikkiin viranomaisvaatimuksiin (ISPE 2008).

Vaatimuksiin kuuluu tyypillisesti:

 tallenteiden säilyttäminen,

 henkilökunnan pätevyyksien hallinta,

 puhtausvaatimukset,

 laitteiden verifiointi,

 prosessivalidointi,

 reklamaatioiden käsittely (ISPE 2020).

Itse vaatimukset on usein ilmaistu hieman tulkinnanvaraisesti, joten tämä antaa valmistajille vapauden toteuttaa tarvittavat kontrollit parhaaksi katsomallaan tavalla. Tämä mahdollistaa tie- tyn vapauden, mutta myös tarkoittaa, että valmistajan täytyy itse tulkita vaatimukset oikein (ISPE 2008).

2.1.2 Validointi

Tässä työssä pyritään tarkastelemaan validointia lähinnä tuotantoprosessin ja tuotantolaitteiden näkökulmasta. FDA määrittelee, että prosessivalidointi tarkoittaa dokumentoitua todistusta, että jokin tietty prosessi tuottaa johdonmukaisesti suurella varmuudella tuotteita, jotka täyttävät sille asetetut määritykset ja laatutavoitteet (ISPE 2008).

Laitteiden validointi on määritelty melko samalla tavalla; objektiivisen todistusaineiston kautta saatu varmuus siitä, että laite täyttää sille asetetut vaatimukset. Vaihtoehtoisesti myös; syste- maattinen lähestymistapa, jolla varmistetaan, että tuotantojärjestelmät tai laitteet ovat asianmu- kaisia käyttöön nähden, ja että ne ovat oikein asennettu ja toimivat oikein (ISPE 2008).

Kuten myös aikaisemmin todettiin, varsinaiset säädökset jättävät tietyn tulkinnan vapauden, miten tulokset todistetaan. Yksi lääketeollisuudessa usein käytetyistä lähestymistavoista on va- lidoinnin v-malli, joka on esitelty GAMP-, eli Good Automated Manufacturing Practices-oh- jeistuksessa.

GAMP on ISPE:n, eli International Society for Pharmaceutical Engineeringin alainen komitea, joka kehittää jatkuvasti GMP ohjeistusta erityisesti lääketeollisuutta ajatellen. Vaikka ohjeistus ei ole suoraan lainsäädännöllisesti sitova, pyritään yleisesti näitä ohjeistuksia kuitenkin noudat- tamaan. Viimeisin versio ohjeistuksesta on GAMP 5. Tässä työssä on tarkasteltu sekä edellistä että viimeisintä versiota ohjeistuksesta.

Kuva 1. V-malli validoinnista (Apprisia 2020).

Kuvassa 1 on esitetty SAP:n tulkinta validoinnin V-mallista osana konfiguroitavan ohjelmiston validointia. Malli on suoraan GAMP:in mukainen (ISPE 2008). Ensimmäisessä vaiheessa lop- pukäyttäjä muodostaa käyttäjävaatimukset (URS), joista voidaan johtaa järjestelmän toiminnal- liset vaatimukset. Tämän pohjalta järjestelmän toimittaja voi muodostaa vaatimukset ohjelmis- ton suunnittelulle. Näiden eri tasoisten vaatimusten pohjalta suoritetaan eri tasoista testausta, jossa viimeinen ja tarkin taso on validoida, että määritetyt käyttäjävaatimukset toteutuvat.

Vaikka tässä käsitellään ohjelmiston testausta, pätevät täysin samat periaatteet myös tuotanto- laitteille.

Kuten kuvasta 1 havaitaan, URS:n määrittäminen on avainasemassa, kun mietitään validointi- kokonaisuutta. Ilman vaatimusten määrittelyä ei voida validoida, että vaatimukset täytetään (McDowall 2005).

2.1.3 URS

Kuten edellisessä kappaleessa todettiin, validoinnin tarkoitus on saada dokumentoitu todistus siitä, että tuote täyttää sille asetetut laatuvaatimukset. Tämä vaatimus tulee GxP- säädöksistä.

FDA asettaa raamit validoinnille, mutta yritykset itse päättävät miten validoinnit dokumentoi- daan. URS on kaikista validointiin liittyvistä dokumenteista tärkein, mutta silti tyypillisesti ylenkatsotuin.

EU:n GMP ohjeistus määrittelee URS:n listaksi vaatimuksia, jotka tulee täyttää, että voidaan toteuttaa järjestelmä, joka sopii tarkoitukseensa. Lisäksi ohjeistus mainitsee, että prosessin tässä vaiheessa luodaan pohja tuotteen laadulle ja mitigoidaan GMP-riskit hyväksyttävälle tasolle.

URS toimii myös referenssinä koko validointiprosessille. (Euroopan komissio 2015, liite 15).

GAMP 4 määrittelee yksinkertaisesti, että URS kuvaa mitä systeemin tulee tehdä. Lisäksi to- detaan, että URS saattaa olla myös osa sopimusta, joten se voi olla toimittajan ja asiakkaan välinen sopimus toimituksen sisällöstä. URS on yleensä loppukäyttäjän kirjoittama, mutta se on mahdollista toteuttaa myös muiden toimesta. URS on myös laatuhallinnon tarkastama ja hyväksymä dokumentti (ISPE 2004).

URS katselmoidaan ja hyväksytään sisäisesti, ennen kuin se lähetetään potentiaalisille toimit- tajille. Tarkasti määritelty URS:

 selventää kaikki vaatimukset laitetoimittajille,

 mahdollistaa tarjousten formaalin arvioinnin,

 varmistaa jäsennellyn esitystavan vaatimuksille,

 toimii pohjana testauksille ja hyväksynnälle ja tätä kautta validoinnille (McDowall 2005).

Lopullisen URS:n tulisi olla täydellinen, realistinen, yksiselitteinen ja testattava (McDowall 2005). Hyvin määritellyn vaatimuslistan avulla saadaan kommunikoitua yhteistyökumppanille tarkasti mitä ominaisuuksia laitteella tai järjestelmällä tulee olla, sekä muodostetaan alustava käsitys siitä, kuinka sitä tullaan testaamaan niin, että voidaan osoittaa, että kaikki viranomais- vaatimukset täytetään.

2.2 Viranomaisvaatimukset

IVD-testien tuotantoon vaikuttaa huomattava määrä viranomaissääntelyä. Tässä kappaleessa on tarkasteltu mitä vaatimuksia viranomaisvaatimukset saattavat asettaa tuotantolaitteiden vaati- musmäärittelylle.

2.2.1 Yleistä

Globaaleilla markkinoilla toimittaessa vaikuttavat tuotteeseen useat eri viranomaisvaatimukset.

IVD-testejä käsitellään lakiteknisesti Suomessa terveydenhuollon laitteena (myös lääkinnälli- nen laite), joten Suomessa tulee ottaa huomioon Suomen laki terveydenhuollon laitteista ja tar- vikkeista (629/2010). Suomessa vaatimusten mukaisuutta valvoo Valvira (Ståhlberg 2015).

Euroopan tasolla tärkeimpiä viranomaisvaatimuksia ovat vanha Euroopan parlamentin ja neu- voston direktiivi 98/79/EY in vitro-diagnostiikkaan tarkoitetuista lääkinnällisistä laitteista, sekä uusi asetus (EU) 2017/746, joka korvaa vanhan direktiivin siirtymäajan jälkeen. Laadunhallin- tajärjestelmän osalta noudatetaan Euroopan osalta standardia ISO 13485. Lisäksi on olemassa erikseen EU:n määrittämä GMP-ohjeistus lääkinnällisten tuotteiden osalta.

Amerikan markkinoilla ylin valvova elin on FDA. FDA tunnustaa ISO 13485-standardin, mutta se ei silti takaa vaatimustenmukaisuutta Amerikassa toimiessa. Tämä vaatii vielä toistaiseksi paikallisen auditoinnin.

2.2.2 Suomen lainsäädäntö

Suomen lainsäädäntö on yksi selkeimmin tulkittavista Euroopan tasolla (Ståhlberg 2015). Kun tarkastellaan lain olennaisia kohtia vaatimusten, dokumentoinnin ja laadun osalta, havaitaan että tärkein kohta on lain kuudes pykälä olennaisista vaatimuksista;

”Terveydenhuollon laitteen tulee täyttää sitä koskevat olennaiset vaatimukset. Aktiivisiin im- plantoitaviin terveydenhuollon laitteisiin sovelletaan AIMD-direktiivin liitteen I vaatimuksia, in vitro -diagnostiikkaan tarkoitettuihin laitteisiin sovelletaan IVD-direktiivin liitteen I vaati- muksia ja muihin laitteisiin MD-direktiivin liitteen I vaatimuksia.

Terveydenhuollon laite täyttää olennaiset vaatimukset silloin, kun se on suunniteltu, valmistettu ja varustettu sitä koskevien kansallisten standardien mukaisesti, jos nämä standardit on annettu yhdenmukaistettujen standardien nojalla, joita koskevat viittaukset on julkaistu Euroopan unio- nin virallisessa lehdessä. Olennaiset vaatimukset voidaan täyttää myös muutoin kuin edellä tar- koitettuja standardeja noudattamalla.

Laitteen tulee olla käyttötarkoitukseensa sopiva ja sen tulee käyttötarkoituksensa mukaisesti käytettynä saavuttaa sille suunniteltu toimivuus ja suorituskyky. Laitteen asianmukainen käyttö ei saa tarpeettomasti vaarantaa potilaan, käyttäjän tai muun henkilön terveyttä tai turvallisuutta.

Sosiaali- ja terveysalan lupa- ja valvontavirasto voi antaa tarkempia määräyksiä olennaisten vaatimusten sisällöstä. ” (Laki terveydenhuollon laitteista ja tarvikkeista 629/2010 § 6).

Suomen lainsäädännössä käytetään siis termiä ”Oleelliset vaatimukset”, jotka on IVD-laitteiden osalta määritetty EU:n direktiivin liitteessä 1. Näitä tarkastellaan tarkemmin seuraavassa kap- paleessa. Lisäksi voidaan tulkita, että laite täyttää vaatimukset, jos se on valmistettu standardeja noudattaen. Vaatimusten täyttämisestä on kirjoitettu myös yhdeksännessä pykälässä: CE- merkinnällä valmistaja osoittaa, että terveydenhuollon laite täyttää sitä koskevat olennaiset vaa- timukset. Kun laite saatetaan markkinoille, se on varustettava CE-merkinnällä (Laki terveyden- huollon laitteista ja tarvikkeista 629/2010 § 9).

2.2.3 EU-direktiivi

Vanha EU:n direktiivi Euroopan parlamentin ja neuvoston direktiivi 98/79/EY in vitro-diag- nostiikkaan tarkoitetuista lääkinnällisistä laitteista on ollut voimassa jo vuodesta 1998. Vaikka uusi regulaatio astui voimaan jo 2017, on siirtymäaikaa vaatimusten osalta vuoteen 2022 saakka (Fimea 2020).

Kuten aikaisemmassa kappaleessa todettiin, määritettiin oleelliset vaatimukset, jotka laitteen tulee täyttää tämän direktiivin liitteessä 1. Lisäksi liitteessä 3 käsitellään vaatimustenmukai- suutta, liitteessä 4 laatujärjestelmää ja liitteessä 7 tuotannon laadunvarmistusta.

Liite 1 on jaettu yleisiin vaatimuksiin, sekä suunnittelua ja valmistusta koskeviin vaatimuksiin.

Yleisten vaatimusten olennaisin osa on tiivistetty ensimmäiseen kohtaan;

Laitteet on suunniteltava ja valmistettava siten, että ne eivät suunnitelluissa olosuhteissa ja tar- koituksessa käytettyinä suoraan tai välillisesti vaaranna potilaiden terveydentilaa, käyttäjien ja

mahdollisesti muiden henkilöiden terveyttä ja turvallisuutta eivätkä omaisuutta (Euroopan par- lamentin ja neuvoston direktiivi 98/79/EY, liite 1).

Lisäksi liitteen yksi kohdassa kaksi käsitellään standardien käyttöä (vrt. Suomen laki tervey- denhuollon laitteista):

Valmistajan valitsemien laitteiden suunnittelua ja rakennetta koskevien ratkaisujen on oltava turvallisuuden yhdentämistä koskevien periaatteiden mukaisia yleisesti tunnustettu alan kehitys huomioon ottaen. Valitakseen sopivimmat ratkaisut valmistajan on sovellettava seuraavia peri- aatteita annetussa järjestyksessä:

 poistettava tai vähennettävä siinä määrin kuin mahdollista vaarat (jo suunnittelu- ja val- mistusvaiheessa huomioon otettu turvallisuus),

 toteutettava tarvittaessa aiheelliset suojelutoimenpiteet vaarojen osalta, joita ei voida poistaa,

 tiedotettava käyttäjille jäljellä olevista vaaroista, jotka johtuvat suojelutoimenpiteiden riittämättömyydestä (Euroopan parlamentin ja neuvoston direktiivi 98/79/EY, liite 1).

Tärkeää on käsite vaarojen vähentämisestä siinä määrin kuin mahdollista.

Suunnittelua ja valmistusta koskevat vaatimukset on jaoteltu eri osa-alueisiin. Kuitenkin kohta 1.1. tiivistää vaatimusten yleisen hengen:

Laitteet on suunniteltava ja valmistettava siten, että saavutetaan A osassa ’Yleiset vaatimukset’

tarkoitetut ominaisuudet ja suorituskyky (Euroopan parlamentin ja neuvoston direktiivi 98/79/EY, liite 1). Tuotantolaitteiden ja valmistusprosessin tulee siis toimia niin että tuotteet säilyttävät suorituskykynsä.

Liitteessä 3 todetaan että valmistajan on toteutettava tarpeelliset toimenpiteet varmistaakseen, että valmistusprosessi on valmistettaville tuotteille tarkoituksenmukaisten laadunvarmistuksen periaatteiden mukainen (Euroopan parlamentin ja neuvoston direktiivi 98/79/EY, liite 3). Käy- tännössä tämä on suora viittaus laadunhallintajärjestelmään, jota käsitellään liitteessä 4. Ylei- sesti laatujärjestelmällä tarkoitetaan järjestelmää, jolla varmistetaan, että direktiivissä asetetut vaatimukset täyttyvät. Lisäksi tuotantolaitteiden osalta tulee huomioida, että laatujärjestelmässä tulee kuvata tarkastus- ja laadunvarmistusmenetelmät valmistusvaiheessa, sekä ennen tuotan- toa, tuotannon aikana ja tuotannon jälkeen suoritettavat asianmukaiset testit ja kokeet, niiden suoritustiheys ja käytettävä testauslaitteisto (Euroopan parlamentin ja neuvoston direktiivi 98/79/EY, liite 4).

Yhteenvetona direktiivi ei siis määritä millään tavalla tuotantolaitteiden vaatimuksia, mutta to- teaa että käytössä tulee olla laatujärjestelmä, jolla varmistetaan, että laite (eli tuotantolaitteen näkökulmasta lopputuote) täyttää sille asetetut oleelliset vaatimukset.

2.2.4 IVDR

Uusi EU:n regulaatio IVD-tuotteille (IVDR) tuli voimaan 26.5.2017. Tämä korvaa aiemmin käytössä olleen direktiivin, jota käsiteltiin edellisessä luvussa.

Sisältö muuttuu huomattavasti laadunhallintajärjestelmän ja dokumentaation osalta. Lisäksi

’olennaiset vaatimukset’ vaihtuu terminä ’turvallisuus ja suorituskykyvaatimuksiin’. Turvalli- suus- ja suorituskykyvaatimukset ovat samankaltaiset kuten aiemmassa direktiivissä, mutta niitä on tarkennettu huomattavasti.

Liite 1 jaotellaan edelleen yleisiin vaatimuksiin ja suunnittelua ja valmistusta koskeviin osiin.

Yleisissä vaatimuksissa uutena on riskienhallinta, jota pidetään yllä koko laitteen elinkaaren

ajan. Turvallisuus- ja suorituskykyvaatimuksissa taas merkittävin uudistus on tarkennus ohjel- mistojen osalta. Lisäksi liitteeseen 1 on lisätty vaatimuksia myös laitteen mukana toimitettavien tietojen osalta, jotka tulee ottaa huomioon pakkausmateriaaleja suunnitellessa (Euroopan par- lamentin ja neuvoston asetus (EU) 2017/746, liite 1).

Liitteessä kaksi käsitellään teknisiä asiakirjoja. Kohdassa 3.2 todetaan että markkinoille saatta- misen yhteydessä tulee toimittaa tiedot, joiden avulla on mahdollista ymmärtää laitteen valmis- tusprosessit, kuten laitteen tuotanto, kokoaminen, tuotteen lopputestaus ja valmiin laitteen pak- kaaminen (Euroopan parlamentin ja neuvoston asetus (EU) 2017/746, liite 2). Lisäksi teknisten asiakirjojen tulee sisältää asiakirjoja (esim. validointitodistukset) siitä että laite täyttää liitteen 1 vaatimukset. Lopuksi on määritelty myös asiakirjat tuotteen tarkastukseen ja validointiin liit- tyen. Tämä ei kuitenkaan aseta tuotantolaitteiden vaatimusmäärittelylle suoria dokumentaatio- vaatimuksia, pois lukien tilavalidoinnit liittyen steriileihin tuotteisiin. (Euroopan parlamentin ja neuvoston asetus (EU) 2017/746, liite 2).

Yhteenvetona direktiivi määrää, että lopputuotteen tulee täyttää sille asetetut vaatimukset, joka tulee pystyä dokumentoinnin kautta todistamaan. Tuotantolaitteiden näkökulmasta tulee pystyä osoittamaan, että sekä laitteet ja tuotantoprosessi on suunniteltu niin että lopputuote täyttää sille asetetut vaatimukset.

2.2.5 ISO 13485

Direktiiveissä linjataan, että tuotteet tulee valmistaa standardit huomioon ottaen ja että yrityk- sellä on käytössä laatujärjestelmä. Näiden direktiivien pohjalta on laadittu standardi ISO 13485, joka määrittelee laadunhallintajärjestelmän vaatimukset terveydenhuollon laitteiden valmistuk- sessa.

Tuotantolaitteiden näkökulmasta standardin olennaisin osa on kappale tuotteen toteuttamisesta.

Tuotteen toteuttamisen suunnittelu on määritelty seuraavasti:

 Organisaation on suunniteltava ja kehitettävä prosessit, joita tarvitaan tuotteen toteutta- miseen.

 Tuotteen toteuttamisen suunnittelun on oltava yhdenmukainen laadunhallintajärjestel- män muiden prosessien vaatimusten kanssa.

 Organisaation on dokumentoitava yksi tai useampia prosesseja tuotteen toteuttamista koskevien riskien hallitsemiseksi.

 Riskinhallintatoimenpiteitä koskevia tallenteita on ylläpidettävä.

 Tuotteen toteuttamisen suunnittelussa organisaation on määritettävä soveltuvin osin o tuotteen laatutavoitteet ja -vaatimukset

o prosessien ja asiakirjojen määrittelyn tarve ja tuotekohtaiset resurssitarpeet, mu- kaan lukien infrastruktuuri ja työympäristö

o tuotekohtaiset erityistarpeet, jotka koskevat todennusta, kelpuutusta, seurantaa, mittausta, tarkastusta ja testausta, käsittelyä, varastointia, jakelua ja jäljitettä- vyyttä, sekä tuotteen hyväksymiskriteerit

o tallenteet, joita tarvitaan osoittamaan, että tuotantoprosessit ja niissä syntyvät tuotteet täyttävät asetetut vaatimukset.

 Suunnittelun tulokset on dokumentoitava organisaation toimintatapoihin soveltuvassa muodossa (SFS 2016).

Tuotteen vaatimuksiin liittyen todetaan, että organisaation on katselmoitava tuotteeseen liitty- vät vaatimukset. Katselmuksessa on varmistettava, että tuotevaatimukset on määritelty ja do-

kumentoitu. Lisäksi eroavuudet selvitetään, mikäli vaatimukset poikkeavat aikaisemmin esite- tystä, ja varmistetaan että organisaatio kykenee täyttämään vaatimukset. Katselmuksen tulok- sista ja toimenpiteistä on pidettävä tallenteita (SFS 2016).

Tuotannon valvontaan liittyen mainitaan seuraavaa:

Tuotantoa ja palveluiden tuottamista koskevat menettelyt on suunniteltava ja toteutettava, ja niitä on seurattava ja valvottava, jotta varmistetaan, että tuote vastaa määrittelyjä. Tarpeen mu- kaan tuotannon valvonnan on sisällettävä mm.

 asiakirjat, jotka liittyvät tuotteen hallintaa koskeviin menettelyihin ja menetelmiin

 infrastruktuurin vaatimukset

 prosessiparametrien ja tuoteominaisuuksien seurannan ja mittaamisen toteutusta koske- vat tiedot

 seuranta- ja mittauslaitteiden saatavuus ja niiden käyttö

 määriteltyjen toimintojen käyttö merkitsemiseen ja pakkaamiseen

 toimenpiteet tuotteen luovuttamiseksi, toimittamiseksi ja toimituksen jälkeisten toimin- tojen

 toteuttamiseksi (SFS 2016).

Erityisesti infrastruktuurin vaatimukset ja prosessiparametrien seuranta tulisi huomioida jo osana tuotantolaitteen vaatimusmäärittelyä.

Yhteenvetona voidaan todeta, että myöskään ISO 13485-standardi ei tarkemmin määritä doku- mentoinnin tasoa, eikä aseta suoria vaatimuksia tuotantolaitteiden vaatimusmäärittelylle, vaikka joitain vaatimuksia voidaan tuotannon valvonnan pohjalta johtaakin. Kuitenkin stan- dardi määrittää, että laitteen valmistusprosessin tulee olla validoitu, ja dokumentoinnin avulla tulee pystyä osoittamaan, että tuote täyttää sille asetetut vaatimukset.

2.2.6 FDA

ISO 13485 on globaali standardi, mutta Amerikan markkinoilla toimiessa on hyvä huomioida erikseen myös FDA:n säädökset. Laatujärjestelmiin liittyen FDA:lla on säädös 21 CFR 820, joka määrittää pakolliset laadunhallintajärjestelmät. Tämä on hyvin samankaltainen kuin ISO 13485, mutta tämän täyttäminen ei vielä oikeuta saamaan laitteita Amerikan markkinoille.

Vuonna 2018 FDA tosin ilmoitti, että pyrkii harmonisoimaan sisällön ISO 13485-standardin kanssa (FDA 2018).

Tuotantolaitteiden osalta merkityksellinen on alaosa G, jossa käsitellään tuotanto- ja prosessi- kontrolleja. Myös tässä säädöksessä todetaan yleisesti, että tuotantoprosessi tulee määrittää niin, että lääkinnällinen laite täyttää sille asetetut vaatimukset ja yleisiä standardeja tulee nou- dattaa (FDA 21 CFR 820.70).

Tuotteen asettamien vaatimusten lisäksi myös tuotantolaitteille asetetaan vaatimuksia. Tuotan- tolaitteiden tulee olla vaatimustenmukaisia. Lisäksi laitteiden tulee olla hyväksyttävästi suun- niteltuja, rakennettuja, sijoitettuja ja asennettuja, jotta niitä voidaan huoltaa, säätää, puhdistaa ja käyttää. Laitteille tulee suunnitella ja dokumentoida ennakkohuolto-ohjelma, jolla varmiste- taan, että laitteet täyttävät vaatimukset. Lisäksi laitteet tulee katselmoida säännöllisesti, jotta varmistutaan että huollot on suoritettu ja laitteet toimivat edelleen vaatimusten mukaisesti (FDA 21 CFR 820.70).

Säädöksessä käsitellään myös prosessin validointi. Säädöksen mukaan, mikäli lopputuotteen suorituskykyä ei voida täysin todentaa prosessin jälkeen, tulee prosessi validoida sillä tarkkuu- della, että tuotteen laatu voidaan todentaa. Mikäli prosessissa havaitaan poikkeamia, katselmoi- daan prosessi ja validoidaan tarvittaessa uudestaan (FDA 21 CFR 820.75).

Toinen FDA:n säädös, joka tulisi ottaa huomioon on 21 CFR Part 11 joka käsittelee elektronisia tallenteita ja allekirjoituksia. Tämä asettaa varsin tiukat määritykset elektronisille tallenteille.

Ydinajatuksena on, että kaikista muutoksista on olemassa jälki, joka voidaan yhdistää yksiselit- teisesti tiettyyn käyttäjään.

Yhteenvetona FDA:n säädös 21 CFR 820 on ainoa viranomaisvaatimus, joka selkeästi vaatii, että tuotantolaitteiden vaatimukset on dokumentoitu. Myös tulee todistaa, että itse tuotantolait- teet on asianmukaisesti suunniteltu, rakennettu ja asennettu. Lisäksi prosessivalidoinnille on tarkemmat määritykset kuin EU:n direktiivissä, mutta tämä ei sinänsä vaikuta tuotantolaitteiden vaatimusmäärittelyyn. Part 11 säädöksestä voidaan myös johtaa suoria vaatimuksia, mikäli tuo- tantolaitteissa on minkäänlaisia käyttäjäoikeuksia, tunnistautumista tai tallenteiden ylläpitoa.

2.3 URS rakenne

URS:n rakenteeseen ei ole olemassa yksiselitteistä ohjeistusta. Jokaisella yrityksellä ja toi- mialalla on oma tapansa ryhmitellä vaatimukset. Seuraavissa kappaleissa käsitellään mahdolli- sia rakenteita eri lähteissä.

2.3.1 SRS

Ohjelmistojen kehityksessä käytetään vaatimuslistasta termiä SRS, eli Software Requirement Specification. IEEE, eli Institute of Electrical and Electronics Engineers, on kehittänyt standar- deja ohjelmistojen vaatimusten hallintaan. Itse standardia käsitellään tarkemmin luvussa 2.4.2.

Tässä luvussa keskitytään standardin mukaan tehtyyn esimerkkirakenteeseen;

1. Muutoshistoria 2. Johdanto

a. Tarkoitus

b. Dokumentin käytännöt c. Kohdeyleisö ja lukuohjeet d. Tuotteen laajuus

e. Viittaukset 3. Yleiskuvaus

a. Tuotteen kuvaus

b. Tuotteen toiminnallisuudet c. Käyttäjäryhmät

d. Käyttöympäristö

e. Suunnittelun ja implementoinnin reunaehdot f. Käyttäjän dokumentaatio

g. Oletukset ja riippuvuudet 4. Ulkoisten rajapintojen kuvaus

a. Käyttöliittymät

b. Laitteiden väliset rajapinnat c. Ohjelmistojen väliset rajapinnat d. Kommunikointirajapinnat 5. Järjestelmän ominaisuudet

a. Järjestelmän ominaisuus 1 b. Järjestelmän ominaisuus 2 jne.

6. Muut ei toiminnalliset vaatimukset

a. Suorituskykyyn liittyvät vaatimukset b. Turvallisuuteen liittyvät vaatimukset c. Tietoturvaan liittyvät vaatimukset

d. Ohjelmiston laatuvaatimukset e. Menettelytavat

7. Muut vaatimukset 8. Liite A: Sanasto 9. Liite B: Analyysimallit

10. Liite C: Päätettävien asioiden lista (rick4470 2020).

Alussa on selkeä johdantokappale, sekä kappale, jossa määritellään yleiskuvaus tarkoituksesta, johon järjestelmä tulee. Yleiskuvauksessa myös määritellään suunnittelun reunaehtoja. Tämän jälkeen on erillinen kappale, jossa määritellään tarkasti kaikki käytettävät rajapinnat.

Rajapintojen kuvauksen jälkeen alkaa varsinainen ominaisuuksien määrittely. Toiminnallisille ja ei-toiminnallisille vaatimuksille on omat kappaleensa (vrt. toiminnalliset ja tekniset vaati- mukset). Suurimpana erona Diagnostiikkayrityksen käyttämään mallin voidaan pitää validointi- , ja osittain dokumentointivaatimusten puuttumista.

2.3.2 GAMP 5

Tärkein lähde URS:n rakennetta tutkiessa tässä työssä on GAMP5, eli Good Automated Manu- facturing Practices 5. Tämä on käytännössä ainoa lähde kirjallisuudessa, joka kuvaa tarkasti mahdollisen esimerkkirakenteen URS:sta, joka on suunniteltu niin että siinä huomioidaan kaikki GxP vaatimukset.

Yleiset osiot

GAMP 5:n mukaan URS tyypillisesti sisältää vähintään seuraavat osiot:

 toiminnalliset vaatimukset,

 datan käsittelyyn liittyvät vaatimukset,

 tekniset vaatimukset,

 rajapintojen vaatimukset,

 ympäristön vaatimukset,

 suorituskyvyn vaatimukset,

 käytettävyyteen liittyvät vaatimukset,

 turvallisuuteen liittyvät vaatimukset,

 huoltoon liittyvät vaatimukset,

 viranomaisvaatimuksiin liittyvät vaatimukset,

 elektronisen datan migraatio,

 reunaehdot,

 elinkaaren vaatimukset (ISPE 2008).

URS tulisi aloittaa johdannolla, jossa ilmaistaan selkeästi kenen tekemä ja miksi on tehty. Li- säksi johdannossa tulisi käsitellä suhde muihin dokumentteihin ja sopimuksellinen status.

Johdannon lisäksi URS:n tulisi sisältää myös kappale projektin taustatiedoista. Tämän tulisi selvittää mitä varten laite/ohjelmisto hankitaan ja mikä on sen suhde muuhun prosessiin. Lisäksi projektin laajuus ja sen aiheuttamat GxP-vaatimukset tulisi käydä ilmi tästä kappaleesta (ISPE 2008).

Toiminnalliset vaatimukset

Toiminnalliset vaatimukset ovat käsitteenä laaja. Nämä sisältävät toiminnot, datan käsittelyn, tekniset vaatimukset, rajapinnat ja ympäristön. Prosessia voidaan tarkentaa prosessikaavioilla

tarpeen vaatiessa. Erityishuomiona myös GxP-kriittiset parametrit tulisi merkitä selkeästi ja mahdollisesti myös tuoda esille vallitsevaa regulaatiota (ISPE 2008).

Toimintojen osalta tulisi kartoittaa kaikki toiminallisuudet, jotka vaikuttavat prosessin automa- tisointiin. Näitä ovat:

 laskennat,

 turvallisuus,

 pääsyoikeudet,

 Audit Trail, eli kirjausketjun aukottomuus,

 elektroniset allekirjoitukset,

 muodostuvat raportit tai tiedostot,

 yksiselitteiset virheviestit (ISPE 2008.)

Datan käsittelyn osalta vaatimuksissa tulisi kiinnittää huomiota erityisesti potilasturvallisuu- teen, laatuun ja tietojen eheyteen vaikuttaviin asioihin. Erityisesti seuraavat tulisi huomioida:

 elektronisten tallenteiden määrittely,

 datan määrittely (muuttujat, formaatti, kriittiset parametrit, rajat, tarkkuus jne.),

 tarvittavat kentät,

 datan siirto,

 datan syöttö ja muokkaaminen,

 varmuuskopiointi,

 arkistointi,

 turvallisuus (ISPE 2008).

Teknisten vaatimusten osalta tulisi huomioida, että etenkin suorituskykyyn liittyvät vaatimuk- set ovat mitattavia ja yksiselitteisiä. Teknisiin vaatimuksiin liittyvät ainakin seuraavat:

 muutokset prosessissa (aloitus, lopetus, virtakatko, testi, sammutus),

 ongelmatilanteista palautuminen,

 nopeus ja kapasiteetti,

 käsittelyyn liittyvät vaatimukset (esim. liikuteltavuus, lastaus),

 laitteiston vaatimukset,

 konfigurointi (ISPE 2008).

Rajapinnat tulisi määritellä tarkasti. Käsiteltävät osa-alueet ovat:

 käyttöliittymät,

 rajapinnat toisten järjestelmien kanssa,

 rajapinnat laitteiden kanssa (esim. sensorit) (ISPE 2008).

Ympäristö, jossa laitetta tai ohjelmistoa käytetään, tulisi myös olla määritelty. Tähän liittyen tulisi käsitellä:

 layout,

 fyysiset olosuhteet (lämpötila, kosteus, puhtausluokat),

 fyysinen turvallisuus,

 hyödykevaatimukset (esim. sähkö, vesi) (ISPE 2008).

Reunaehdot

Reunaehdot, joiden puitteissa joudutaan toimimaan, tulisi määrittää tarkasti. Asiat, jotka tulisi ottaa huomioon reunaehtoja kartoittaessa:

 yhteensopivuus niin olemassa olevien laitteiden/järjestelmien kanssa kuin yrityksen re- gulaatiopolitiikan kanssa,

 käyttöaste,

 luotettavuus, eli vaatimus toiminta-ajalle,

 sallittu huoltojen kesto,

 työtavat,

 operaattoreiden taidot,

 laajennettavuus,

 tulevat kehityskohteet,

 odotettu käyttöikä,

 pitkän aikavälin tuki (ISPE 2008).

Elinkaaren vaatimukset

Kaikki vaatimukset, jotka vaikuttavat toimittajan kehitystyöhön tai validointiin tulisi määrittää tässä osiossa. Turhaa toistoa tulisi välttää, mikäli nämä asiat on jo määritelty muualla. Tällaisia asioita ovat muun muassa:

 kehitysvaatimukset (minimivaatimukset toimittajalle),

 projektin ja laadun hallinta,

 pakolliset suunnittelutavat,

 testien määrittely (data, kuormitus, simulaatiot),

 hyväksyntätestaus,

 toimitus,

 dokumentaatio,

 työkalut,

 käyttäjien koulutus,

 hyväksynnän jälkeinen tuki (ISPE 2008).

Muut osiot

Varsinaisten vaatimusten lisäksi olisi hyvä tehdä myös listaus käytetyistä lyhenteistä. Lisäksi URS:n tulisi selkeä hyväksyntäsivu. Hyväksyntä tulisi olla minimissään prosessin omistajilta.

Muita hyväksyjiä voivat olla esimerkiksi järjestelmän omistaja ja laatupuoli (ISPE 2008).

Kun URS on hyväksytty, tulisi kaikki muutokset suorittaa muutoksenhallinnan kautta. Muutos- ten jälkeen dokumentti tulee hyväksyä uudelleen (ISPE 2008).

URS:n ei tulisi sisältää seuraavia asioita:

 järjestelmän yksityiskohtaista konfigurointia tai suunnittelua,

 implementoinnin yksityiskohtia,

 projektin aikataulua,

 hintaa,

 projektin organisaatiota (ISPE 2008).

Järjestelmän konfigurointi ja implementoinnin yksityiskohdat liittyvät siihen, kuinka vaatimuk- siin vastataan. Tämä määritellään tyypillisesti ohjelmiston toiminnallisella kuvauksella, eli Functional Design Spesificationilla (FDS). Lisäksi implementoinnin yksityiskohtia ei tyypilli- sesti tunneta projektin alussa tarpeeksi tarkasti, koska ne riippuvat paljon toimitettavan järjes- telmän rakenteesta (ISPE 2008).

Projektin aikataulu ja kustannukset voidaan liittää osaksi tarjouspyyntöä, mutta URS:n osalta nämä eivät ole varsinaisia vaatimuksia toimitettavalle laitteelle tai järjestelmälle (ISPE 2008).

2.4 Muut teollisuudenalat

Vaatimuslistaa käytetään myös muilla teollisuudenaloilla. Tässä kappaleessa tarkastellaan vaa- timusten määrittelyä osana tuotekehitysprosessia, sekä ohjelmistojen kehityksessä.

2.4.1 Requirements list tuotekehityksessä

Tuotekehityksessä sovelletaan systemaattista lähestymistapaa vaatimusten hallintaan, jota käy- tetään osana tuotekehitystä. Tästä prosessin vaiheesta käytetään nimitystä suunnittelun spesifi- kaatiot (Pahl et al. 2007).

Kuvassa 2 on esitelty prosessi vaatimusten johtamiselle. Ensimmäisessä vaiheessa selvitetään ja dokumentoidaan selkeät vaatimukset, jotka johdetaan tuotteen suunnittelusta. Toisessa vai- heessa käytetään erityisiä tekniikoita, joilla tarkennetaan näitä vaatimuksia. Tässä vaiheessa voidaan esimerkiksi miettiä kaupallisia vaatimuksia tai asiakkaasta riippuvia teknisiä vaatimuk- sia. Viimeisessä vaiheessa näistä muodostetaan selkeä vaatimuslista (Pahl et al. 2007).

Kuva 2 Vaatimusten johtaminen tuotekehityksessä (Pahl et al. 2007. Kuva 5.1).

Vaatimuksia tarkennettaessa olisi olennaista, että vaatimukset olisivat mitattavia. Esimerkiksi

”tehon tulisi olla yli 20 kW”. Lisäksi tulee erottaa toisistaan toiveet ja vaatimukset. Vaatimuk- set tulee täyttää kaikissa olosuhteissa, ja näiden määrittelyssä tulisi ottaa huomioon, että mittaus ja testaus ovat erityisen tärkeitä. Vaatimukset tulisi myös kirjoittaa niiden osastojen termeillä, jotka vastaavat konstruktion toteutuksesta. Vaatimukset ja toivomukset tulee lisäksi tarkentaa määrällä ja laadulla (Pahl et al. 2007).

Kuva 3. Vaatimusten luokittelu (Pahl et al. 2007. Kuva 5.2).

Kuvassa 3 on esitelty esimerkkivaatimus yrityksen sisäiseen vaatimuslistaan. Heti alussa on eritelty, onko kyseessä vaatimus vai toivomus. Lisäksi on eritelty vastaava ryhmä. Jaottelu ta- pahtuu osasysteemien mukaan, laajoissa kokonaisuuksissa voidaan jaotella moduuleittain (Pahl et al. 2007).

Suurimpana erona URS:n ja tuotekehityksessä käytetyn vaatimuslistan välillä voidaan pitää nii- den lakiteknistä statusta. Vaatimuslistalla ei pyritä todistamaan, että tuote täyttää vaatimukset, vaan se on työkalu, jolla varmistetaan, että näin tapahtuu. Lisäksi tuotekehityksessä vaatimus- lista on usein valmistajan yrityksen sisäinen työkalu, jolla pyritään kommunikoimaan vaati- mukset osastojen välillä. Kuitenkin sen tarkoitus on hyvin samankaltainen; varmistetaan että kaikki osapuolet ymmärtävät toimituksen sisällön.

2.4.2 SRS ohjelmistokehityksessä

Aikaisemmassa kappaleessa käsiteltiin IEEE:n esimerkkirakenne SRS:n osalta. Tässä kappa- leessa käsitellään tarkemmin itse standardin sisältöä.

Vaatimusten määrittely on erittäin olennainen osa ohjelmistojen kehitystä, jossa suuri osa työstä tehdään täysin asiakkaan vaatimusten perusteella. IEEE Std 830-1998 pyrkii kuvaamaan tavat, joilla määrittää hyvä SRS osana ohjelmiston kehitystä.

SRS-dokumentin avulla asiakas kuvaa tarkasti mitä järjestelmällä tulee saavuttaa ja toimittaja ymmärtää asiakkaan vaatimukset. Sillä saavutetaan seuraavat hyödyt:

 Saavutetaan sopimuksellinen pohja toimituksen sisällöstä toimittajan ja asiakkaan vä- lillä.

 Vähennetään kehitystyötä.

 Mahdollistetaan tarkkojen aikataulu- ja kustannusarvioiden tekeminen.

 Saavutetaan pohja validoinnille ja verifioinnille.

 Nopeutetaan ohjelmiston siirtoa toisille asiakkaille.

 Mahdollistetaan tulevien kehityskohteiden listaus (IEEE 1998).

Dokumentin tulee kuvata mitä järjestelmän pitäisi tehdä. Sen voi tehdä joko toimittaja, asiakas, tai molemmat yhteistyössä. Tulisi huomioida, että dokumenttiin ei listata vaatimuksia suunnit- telulle, tai projektiin liittyviä asioita. Dokumentin tulisi olla:

 paikkansa pitävä,

 yksiselitteinen,

 täydellinen,

 johdonmukainen,

 luokiteltu,

 mitattava,

 muokattava,

 jäljitettävä (IEEE 1998).

Kuten muillakin teollisuuden aloilla, on tärkeää, että saavutetaan yhteisymmärrys sisällöstä toi- mittajan ja asiakkaan välillä. Standardi painottaakin yhteistyötä, koska asiakas ei tyypillisesti ymmärrä ohjelmiston kehitysprosessista tarpeeksi, jotta osaisi tehdä hyödynnettävän vaatimus- listan. Toimittaja taas ei ymmärrä asiakkaan prosessia sillä tasolla, joka vaadittaisiin, että saa- vutetaan vaatimukset täyttävä järjestelmä. Tämän takia standardi suositteleekin, että SRS teh- täisiin aina yhteistyössä (IEEE 1998).

3 URS-templaatin kehitys

Tässä luvussa käsitellään miten kerättiin kehityskohteet URS-templaatille, ja kuinka muodos- tettiin parhaiden käytäntöjen pohjalta uusi pohja dokumentille. Luku jakautuu useaan osaan.

Ensin esitellään Diagnostiikkayrityksen URS:n alkuperäinen rakenne. Tämän jälkeen tehdään yhteenveto siitä, miten vaatimukset tulisi määritellä, sekä mitä kehitysideoita saatiin toimitta- jilta, kirjallisuustutkimuksen osana ja työn ohjaajan kokemuksen perusteella. Tämän jälkeen tarkastellaan yhtä epäonnistunutta hankintaprojektia, ja mitä virheitä sen vaatimusmäärittelyssä tehtiin. Lopuksi suoritettiin benchmark-vierailut kahden yrityksen luona, ja pyrittiin vertaile- maan vaatimusmärittelyn prosesseja keskenään. Näiden tietojen pohjalta muodostettiin parhai- den käytäntöjen mukainen templaatti, jota käsitellään viimeisessä kappaleessa.

3.1 Diagnostiikkayrityksen käyttämä malli

Alla on esitelty Diagnostiikkayrityksen alkuperäinen URS:issa käytetty rakenne.

1. Johdanto

2. Prosessin yleiskuvaus 3. Toiminnalliset vaatimukset

a. Prosessin vaatimukset b. Prosessin mittausparametrit

c. Prosessin mittaus- ja ohjausparametrit d. Ohjausjärjestelmän yhteiset vaatimukset e. Toimintatilat

f. Virheilmoitukset ja hälytykset g. Suojalukitukset

h. Käyttöoikeussuojaukset i. Liittymät

j. Keskeytykset

k. Sähköisen tiedon käsittely i. Järjestelmän GxP-tiedot ii. Raportointi

iii. Tietojen varmistus ja säilytys 4. Yleiset tekniset vaatimukset

5. Validointivaatimukset

a. Validoinnit ennen käyttöönottoa

b. Validisuuden ylläpitoon vaadittavat menettelyt 6. Toimittajalle asetetut laatuvaatimukset

7. Järjestelmän dokumentointivaatimukset a. Toimittajalta vaaditut dokumentit b. Tilaajalta vaaditut dokumentit 8. Liitteet

9. Muutoshistoria

Alkuperäisellä templaatilla vaatimukset luokiteltiin ainoastaan GxP-kriittisyyden perusteella.

Tässä tapauksessa GxP-kriittiset kohdat olivat vaatimuksia, ja muut kohdat enemmän tai vä- hemmän toivomuksia. Lisäksi käytössä oli teksti ”OPTION” jolla on merkattu vaatimuksia, jotka olisivat hyödyllisiä, mutta jotka eivät ole laitteen perustoimintojen kannalta tärkeitä. Nii- hin ei olla valmiita panostamaan rahallisesti.

3.2 Miten vaatimukset tulisi määritellä

Aikaisemmissa luvuissa on jo sivuttu sitä, millainen hyvä vaatimus on. Tässä kappaleessa on tarkoitus tehdä yhteenveto siitä, millainen on hyvä vaatimus, miten se tulisi luokitella, millainen jäljitettävyys dokumentissa tulisi olla, ja millaisia virheitä vaatimusten määrittelyssä tyypilli- sesti tehdään.

3.2.1 Vaatimusten määritys

Tyypillinen tiivistelmä siitä millainen on hyvä vaatimus, saadaan englanninkielisestä lyhen- teestä SMART.

SMART:

 Specific,

 Measurable,

 Achievable,

 Realistic,

 Testable (ISPE 2008).

Tällä pyritään ilmaisemaan, että olennaista on, että vaatimus on tarkka, mitattava, saavutettava, realistinen ja testattava.

Tämän lisäksi vaatimuksille annetaan usein myös seuraavat tarkenteet:

 Kaikki vaatimukset ilmaistaan tiiviisti erikseen. Vaatimuksen pituuden tulisi olla mak- simissaan 250 sanaa.

 Vaatimuksien tulee olla johdonmukaisia. Listan ei pidä sisältää toistoa eikä ristiriitaisia vaatimuksia.

 Vaatimusten ei pidä kertoa, miten se tullaan toteuttamaan.

 Jokaisen vaatimuksen pitää olla testattavissa.

 Kaiken pitää olla ymmärrettävissä ja selkeää kaikille osapuolille. Vaatimukset eivät si- sällä jargonia ja niitä selvennetään tarvittaessa.

 Vaatimukset on luokiteltu sen mukaan, onko kyseessä vaatimus vai toivomus.

 Vaatimuslista on muutoshallinnan piirissä.

URS on hyvä, jos jokaiselle vaatimukselle on vain yksi tulkinta ja järjestelmä täyttää vaati- mukset. Tämä vain valitettavasti harvoin onnistuu (McDowall 2005).

Kuva 4. Hyvin muotoillut vaatimukset (IEEE 1998).

Kuvassa 4 on esitelty vaatimuksen tarkennusprosessi. Alkuun saadaan alustava vaatimus. Tätä tarkennetaan järjestelmän ominaisuuksien, ehtojen ja rajoitteiden pohjalta, jonka jälkeen saa- daan hyvin muodostettu vaatimus.

Itse vaatimusten lisäksi vaatimusten määrittelyn aikana tulisi huomioida myös seuraavat asiat:

 Kaikkien dokumenttien tulisi olla muutostenhallinnan piirissä, ja jokaisessa dokumen- tissa olla selkeä muutoshistoria.

 Toimittajien vertailu ja tarvittaessa auditointi. Jokaisella toimittajalla tulisi olla voi- massa laadunhallintajärjestelmä.

 Toimittajan tulee toimittaa tarkat kuvaukset laitteen/järjestelmän toiminnasta. Doku- mentaation taso tulisi määrittää.

 Käyttäjäkoulutus tulee sopia ja määrittää toimittajan kanssa.

 Tulee järjestää suunnittelun katselmointi, jonka aikana varmistetaan, että kaikki vaati- mukset täytetään. Jo tässä vaiheessa olisi hyvä huomioida jäljitettävyys.

 Vaatimuksia ei välttämättä pystytä täyttämään kokonaan, tämä tulisi huomioida.

 URS:n ensimmäisen version ei tarvitse olla täydellinen. Vaatimuksia tarkennetaan, kun niistä tiedetään paremmin.

 URS:n ei tule olla ainoastaan pakollinen osa dokumentaatiota, vaan tärkeä kommuni- koinnin väline.

 Vaikka URS tehtäisiin yhteistyössä, yritys, joka on sääntelyn alainen, on vastuussa siitä (LearnaboutGMP 2020).

3.2.2 Luokittelut

Useimmat lähteet mainitsevat, että luokittelu on erittäin tärkeää vaatimusten toteuttamisen kan- nalta. Tyypillinen malli on esimerkiksi IEEE:n standardissa esitetty kolmiportainen malli;

 Pakollinen. Laitetta ei voida hyväksyä käyttöön, mikäli tämä vaatimus ei toteudu.

 Tärkeä. Vaatimus on toiminnan kannalta oleellinen, mutta sen toteutumattomuus ei vält- tämättä estä laitteen hyväksymistä.

 Optio. Valinnainen ominaisuus, joka saattaisi tuoda lisäarvoa laitteen käyttöön (IEEE 1998).

Toinen mahdollinen lähestymistapa on erottaa toisistaan vaatimukset ja toivomukset. Toivo- muksille voidaan vielä määrittää erikseen prioriteetti

Tällöin mallin mukainen luokittelu olisi:

 vaatimukset,

 toivomukset,

o erittäin tärkeä, o keskinkertainen,

o vähemmän tärkeä (Pahl et al. 2007).

Vaatimukset ilmaistaan mielellään numeroina, tai mahdollisimman tarkasti sanallisesti. Mikäli on vaikea ymmärtää jonkin vaatimuksen tarvetta, voidaan tarvittaessa viitata tavoitteisiin, tai vaatimuksen lähteeseen (Pahl et al. 2007).

Kuvassa 5 on esitelty mistä lähteistä lopulliset laitevaatimukset johdetaan IVD- tuotantolaitteiden vaatimusmäärittelyssä. Kuvan perusteella voitaisiin vaatimusten mahdolli- siksi lähteiksi määritellä:

 Tuotevaatimukset. Tämä tarkoittaa GxP vaatimuksia, joten tästä lähteestä tulevat vaati- mukset ovat aina pakollisia.

 Riskianalyysi. Riskianalyysin pohjalta voidaan tehdä erilaisia vaatimuksia esimerkiksi kappaleiden käsittelyyn liittyen.

 Kaupalliset vaatimukset. Tämä liittyy ominaisuuksiin kuten kapasiteetti.

3.2.3 Jäljitettävyys

Useat lähteet mainitsevat hyvän URS:n ominaisuudeksi jäljitettävyyden. Tähän ei kuitenkaan liity suoria viranomaisvaatimuksia, paitsi että tunnistetut riskit täytyy dokumentoidusti miti- goida mahdollisimman pieniksi.

Koska tunnistetut riskit täytyy testata ja dokumentoida, on vaatimukset kirjoitettava niin että niihin voidaan viitata yksilöllisesti. Tämä tarkoittaa sitä, että jokaisella vaatimuksella on oma tunnisteensa.

Jäljitettävyys eri dokumenttien välillä saavutetaan helpoimmin niin kutsutulla jäljitettävyys- matriisilla. Tämä on tyypillisesti erillinen dokumentti, esimerkiksi Excel-taulukko, johon kerä- tään vaatimusten yksilölliset tunnisteet URS:issa, ja merkitään missä validointitestien (tai mui- den dokumenttien) kohdassa tätä on käsitelty.

3.2.4 Yleisiä virheitä vaatimusten määrittelyssä

Vaikka on melko selkeä konsensus siitä, millainen hyvä vaatimus on, tapahtuu silti vaatimusten määrittämisessä usein virheitä. Tyypillisimpiä näistä ovat:

 Vaatimuksia ei ymmärretä samalla tavalla osapuolten kesken.

 Kaikki tarvittavat osapuolet eivät ole olleet mukana määrittelemässä vaatimuksia.

 Vaatimus on ilmaistu monitulkintaisesti, tai niin että sitä ei voi mitata.

Kuva 5. Laitevaatimusten johtaminen.

 Mikäli vaatimuksia ei luokitella, ei välttämättä keskitytä tarpeeksi kriittisiin vaati- muksiin.

 Alkuperäistä laajuutta ryhdytään laajentamaan ilman muutoksenhallintaa.

 Ei ole implementoitu muutoksenhallintaprosesseja, jolloin muutokset saattavat jäädä huomioimatta ja arvioimatta.

 Kirjoitetaan useita vaatimuksia yhteen vaatimukseen (LearnaboutGMP 2020).

3.3 Use case

Yksi laitehankintaprojekti, joka vaikutti suuresti tämän aiheen valintaan yrityksessä, oli kork- kien annostelulinja. Linjalla annostellaan korkkeihin pieni määrä reagenssia, etiketöidään korkki ja punnitaan se. Vaatimusten tulkinnassa oli suuria erimielisyyksiä osapuolten välillä ja näitä selviteltiin vuosien ajan. Tässä kappaleessa tarkastellaan ensin mitä tyypillisiä virheitä saatetaan havaita vaatimusten määrittelyssä, jonka jälkeen käydään läpi laitteen hankinnassa mukana olleiden henkilöiden lausunnot yksittäisten vaatimusten erilaisista tulkinnoista.

3.3.1 Tyypilliset virheet

Yleisenä huomiona ainoa luokittelu, jota URS:issa on käytetty, on ’GxP’. Käytännössä tämä voisi tarkoittaa, että vain nämä vaatimukset ovat pakollisia, ja vain nämä validoidaan. Tämä saattaa aiheuttaa ongelmia keskittymisessä muihin kriittisiin vaatimuksiin. Lisäksi muutosten hallinta on toteutettu suoraan dokumenttiin, mikä tekee dokumentista hieman sotkuisen usean iteraatiokierroksen jälkeen.

Vaatimuksista löytyi useita kohtia, jotka eivät olleet täysin yksiselitteisiä ja mitattavia. Esimer- kiksi:

 Kappaleiden käsittelyn tulee olla sulavaa.

 Toimenpiteiden tulee olla riittäviä, jottei staattinen sähkö aiheuta ongelmia.

 Osan vaihtoon kuluva aika tulee minimoida.

 Toimittajan tulee optimoida hylkäysprotokolla kustannustehokkaalla tavalla.

 Nopeus voi hidastua 100 prosenttisella tarkastuksella.

 Tuotantolinja kestää, ja pystyy palautumaan hyödykekatkoksista.

 Osien tulee olla kestäviä.

Lisäksi löytyi kohtia, jotka sisälsivät useita vaatimuksia. Esimerkiksi vaakojen osalta oli yh- dessä vaatimuksessa määritelty, että niiden tulee sisältää automaattinen säätöjärjestelmä, joka käynnistyy automaattisesti erän aloituksen yhteydessä. Tätä tulee pystyä käyttämään myös ma- nuaalisesti. Lisäksi vaakojen tulee sisältää valmiudet päivittäistarkastukseen, rajapinnat kalib- roinnille ja huollolle, ja vaakojen suorituskyky pitää pystyä visualisoimaan. Nämä toiminnot ovat GxP-kriittisiä, eli ne täytyy testata. Käytännössä tämä vaatii useita testejä, mikä johtaa vaatimusten sekavaan jäljitettävyyteen.

Alkuperäinen URS sisälsi myös useita vaatimuksia samasta aiheesta, jotka oli kuitenkin jo pois- tettu tästä versiosta. Nämä oli merkitty URS:iin poistetuiksi hieman eriävillä käytännöillä, ku- ten näkyy kuvassa 6.

Kuva 6. Vaatimusten poisto dokumentista.

Selkeästi esiin nousevat virheet URS:issa siis ovat epämääräisesti ilmaistut vaatimukset, puut- teelliset luokitukset, sekä vaatimukset jotka sisälsivät useita kohteita. Luokitusten merkintä oli myös hieman ristiriitaista. Mikäli vaatimus oli optio, kirjoitettiin se suoraan vaatimus kenttään, kun taas GxP-kriittisyys merkittiin kriittisyys kenttään.

3.3.2 Ongelmat hankintaprojektin aikana

Yllä olevassa kappaleessa käsiteltiin millaisia virheitä vaatimusten määrittelyssä tehtiin. Tähän kappaleeseen kerättiin listaa ongelmista, joita havaittiin hankintaprojektin aikana. Erityistä huo- miota tulee myös kiinnittää siihen, että projektihenkilöstö vaihtui projektin aikana useaan ker- taan, mikä ennestään vaikeutti vaatimusten tulkintaa.

Alkuperäisessä URS:issa oli määritelty vaatimus, että lateksin tulee olla korkin pohjalla. Näin ei kuitenkaan testien mukaan ollut, joten annostelua muutettiin niin, että pilli menee nesteeseen.

Tämä aiheutti sen, että korkkeja piti hylätä eri tavalla kuin aikaisemmin, jota varten toimittaja toimitti uudet parametrit. Kokeissa kuitenkin havaittiin, että korkit eivät hylkäänny oikein. Toi- mittajan mukaan tälle ei ollut toimitettu tarkkoja vaatimuksia. Tätä ei voitu vaatia URS:issa, koska vaatimusta muutettiin projektin aikana.

Samoin myös etiketöinnin vaatimukset määriteltiin vasta hankintaprojektin aikana. Kokeissa kuitenkin korkkien halkaisijat heittivät 0,2 mm, joka johti päällekkäin olevan osan ja datamat- riisin välisen valkoisen osan mittaheittoon. Pahimmissa tapauksissa oli millien heittoja. Toisella muotilla valmistetut korkit taas jäivät mekaanisesti jumiin linjastoon. Tietoa korkkien halkaisi- joista ei ollut URS:ia määritettäessä. Tämä johti erimielisyyksiin korvauksista toimittajan kanssa.

Yksi esimerkki, joka liittyi dokumentoimattomiin vaatimuksiin, oli osien pesussa käytettävä laatikko. Tämä oli keskusteltu läpi toimittajan kanssa, mutta vaatimusta ei ollut kirjattu mihin- kään. Lopulta toimittaja toimitti epämääräisen levyn, joka ei soveltunut lainkaan käyttötarkoi- tukseen.

Reagenssin annostelussa oli useita ongelmia koko projektin ajan. Alkuperäiset vaatimukset oli- vat, että korkkeihin pitää pystyä annostelemaan 50-100 mikrogramman määriä yhden prosentin tarkkuudella. Todellisuudessa kahden prosentin tarkkuus oli tuotteen toiminnan kannalta riit- tävä, mutta yrityksen kokemusten mukaan kannattaa aluksi vaatia liian tiukkoja rajoja, jotta niitä voidaan muokata löyhemmiksi, mikäli valmistaja ei pääse rajoihin. Tämä lähestymistapa on vähintäänkin kyseenalainen, mutta osoittautui tässä projektissa toimivaksi.

Reagenssien annostelutarkkuuden ongelmien takia lähes koko alkuperäinen pumppuasema jou- duttiin uusimaan. Sekä asiakas että toimittaja testasivat kymmeniä pumppumalleja, kunnes asi- akkaan toimesta löydettiin sopiva. Toimittaja ei ollut halukas käyttämään tätä pumppumallia, joten sitä jouduttiin vaatimaan. Lisäksi tälläkään pumppumallilla ei päästy täysin eroon annos- telun ongelmista. 100 mikrogramman annostelu ei toiminut, ellei linjan nopeutta hidastettu huo- mattavasti. Muuten reagenssi roiskui korkkien seinämille, mikä oli vaatimusten vastaista.

Yhteenvetona suurimmat ongelmat hankintaprojektin aikana näyttivät liittyvän puutteellisiin lähtötietoihin ja annostelulinjan rakenteellisiin muutoksiin projektin aikana. Vaikka on selvää, että joitain ongelmia olisi voitu välttää vaatimusten täsmällisemmällä määrittelyllä, oli URS:n muutoshallinnalla suurempi rooli tämän projektin onnistumisen kannalta. Lisäksi tulee huomi- oida, että olennaiset vaatimukset oli kuitenkin määritelty tarpeeksi tarkasti, jotta ongelmat ha- vaittiin validointitesteissä.

3.4 Esille nousseet kehityskohteet

Luokittelun tarpeellisuus nousi esille lähes jokaisesta lähteestä. Lisäksi ilmi tuli mahdollinen poikkeamalistaus, jonka ideana on, että toimittaja voisi jotenkin ilmoittaa pystytäänkö vaati- mukseen vastaamaan.

Yleisenä huomiona useista lähteistä ilmeni, että vaatimukset tulisi ilmaista tiiviisti ja selkeästi.

Siihen miten tämä saavutettaisiin ei kuitenkaan ollut selkeää ohjetta. Vaatimusten määrittelyn yhteydessä tulee myös huomioida, että ei oteta kantaa miten vaatimus tulisi toteuttaa, vaan an- netaan arvo johon tulee yltää. Poikkeuksena tähän voidaan kuitenkin mainita suositeltujen kom- ponenttitoimittajien lista.

Yrityksen sisällä on selkeästi noussut esille, että suositeltujen komponenttien toimittajien lista voisi olla hyödyllinen. Sen lisäksi että kunnossapidolla on enemmän kokemusta tietyistä kom- ponenteista, on myös hankintaprojekteissa kertynyt kokemusta joistakin teknologioista.

Yleisellä tasolla myös tavoitteiden tekeminen toimittajille selkeäksi auttaa niiden saavuttami- sessa. Johdanto ja taustatieto kappaleissa olisi hyvä kertoa tarpeeksi prosessista, jotta toimitta- jalla olisi selkeä kuva tavoitteista. Tämä myös selkeyttää kuvaa minkä takia jokin vaatimus on olemassa ja selkeyttää mahdollista toteutustapaa.

Muutoshallinnan tueksi tulisi määrittää selkeä tapa, jolla ilmaista, että vaatimusta on muutettu.

Tämä tulee tarpeelliseksi, mikäli iteraatiokierroksia tehdään useita. Toisaalta taas tämä vie pal- jon tilaa itse templaatista.

Templaatin formaatille annettiin useita vaihtoehtoja. Selkeimmät työkalut olivat Word tai Ex- cel. Excelissä voitaisiin suodattaa ja järjestellä vaatimuksia kronologisesti tai vaiheen mukaan.

Toisaalta taulukkoa on hankalampi muotoilla, ja erityisen vaikeaa on esittää muuta kuin teksti- pohjaista taustatietoa toimittajalle. Yksi mahdollinen tapa ratkaista tämä olisi muodostaa erilli- nen jäljitettävyysmatriisi Excel-muotoon.

Tilaluokitusten osalta on tullut epäselvyyksiä toimittajien kanssa. Diagnostiikkayrityksessä ja Emoyhtiössä käytettiin erilaisia tilaluokituksia, joko kirjaimia tai numeroita. Emoyhtiön tila- luokitukset perustuvat ISO 14644-1 standardiin. Diagnostiikkayrityksessä tehtiin tarkoituksella omat tilaluokitukset ja ilmaistiin että luokitus ”vastaa standardia”. Tämä johtuu siitä, että ei haluta sitoutua standardin vaatimustenmukaisuuteen.

Kaupallisen puolen vaatimusten osalta on yrityksessä havaittu, että toimittajien kanssa on ollut ongelmia tuen saamisessa. Jatkossa haluttaisiin tehdä jonkinlainen palvelusopimus jokaisen lai- tetoimittajan kanssa. Tälle olisi mahdollista lisätä oma kappaleensa, tai jopa tietyt vaatimukset osaksi URS:ia.

3.5 Benchmarking

Benchmarking yrityksiksi saatiin 2 yritystä, jotka toimivat eri teollisuuden aloilla. Yritykset olivat Yritys 1, joka toimi myös lääkinnällisten laitteiden toimialalla, sekä Yritys 2, joka toimii elektroniikkateollisuudessa.

Ennen vierailua laadittiin alustava lista kysymyksistä, jotka käytiin yrityksen kanssa läpi. Tär- keimmät läpikäytävät asiat olivat:

 vakiotemplaatin käyttö,

 rakenne,

 vaatimusten luokittelu,

 poikkeamat ja optiot,

 vaatimusten selkeän määrittelyn käytännöt,

 versionhallinta ja jäljitettävyys,

 validointi,

 URS:n sopimuksellinen rooli.

Varsinaisten benchmark yritysten lisäksi Diagnostiikkayrityksen pohjaa verrattiin Emoyhtiön pohjaan. Emoyhtiö tuottaa lääkkeitä, joka on vielä säännellympää toimintaa kuin IVD-ala.

3.5.1 Yritys 1

Tärkein vierailu tehtiin Yritys 1:n tiloihin. Yritys työskentelee samalla teollisuudenalalla, mutta ei ole tuotteiltaan kuitenkaan Diagnostiikkayrityksen kilpailija. Tämä mahdollisti avoimen kes- kustelun. Yritysten bisnesmalli eroaa kuitenkin hiukan toisistaan. Siinä missä Diagnostiikkayri- tys valmistaa omia tuotteita, on Yritys 1 sopimusvalmistaja, joka tuottaa tuotteita muille yrityk- sille.

Yritys 1:n URS:ia on kehitetty jonkun verran viime vuosina. Muutoksilla on pyritty hakemaan vaatimusten mitattavuutta. Myös luokitukset on tehty GAMP 5 mallia mukaillen. Muita viran- omaismääräyksiä tai ohjeistuksia ei ole juurikaan otettu huomioon muutoksia tehdessä.

URS oli rakenteeltaan hyvin samantyyppinen kuin Diagnostiikkayrityksen käyttämä malli.

Suurimpana poikkeuksena oli, että yritys käyttää täysin vakioitua pohjaa missä kaikki mahdol- liset vaatimukset ovat jo valmiina. Vaatimuksia poistetaan ja muokataan tarpeen mukaan. Yk- sinkertaisemmille manuaalilaitteille on tulossa oma, vähän kevyempi templaatti. Templaatti oli myös toiminnan mukaan jaoteltu, kuten Diagnostiikkayrityksessä. Toistoa tulisi paljon, jos vaa- timukset olisi järjestetty kronologisesti. Samaan tapaan kuin Diagnostiikkayrityksen pohja, myös Yritys 1:n malli sisälsi paljon erillisiä liitteitä ja listasi tarkasti validointivaatimukset.

Vaatimukset oli luokiteltu kolmeen tärkeyden luokkaan; mandatory, beneficial ja nice to have.

Pohjassa ei ollut erillistä toimittajan täytettävää kohtaa, jossa olisi mahdollisuus ilmaista pys- tyykö toimittaja vastaamaan vaatimukseen. Jos pakollista vaatimusta ei voida toteuttaa, tarvi- taan erillinen dokumentti sen hyväksymiseksi. Functional Specification dokumentilla taas voi- daan perustella miksi Beneficial tai Nice to have-luokituksen vaatimuksen toteutus ei onnistu.

Lisäksi pohjassa oli validointiin liittyen erillinen luokittelu ’dokumentointi’ ja ’dokumentointi