Affinity Domainin perustaminen KVARKKI-arkkitehtuurissa

Transkriptio

1 Affinity Domainin perustaminen KVARKKI-arkkitehtuurissa

2 Sisällysluettelo Käytetty sanasto... 2 Johdanto... 4 Affinity Domain tasoiset toiminnallisuuteen sekä tietosisältöön liittyvät vaatimukset... 4 Affinity Domain kohtaisesti säilytettävät tietosisällöt... 4 Affinity Domainiin Kvarkki-kokonaisuudessa kuuluvat aktorit... 4 IHE-aktoreiden tukemat IHE-profiilit optioineen... 5 Käytettävät koodistot... 7 Käytettävät metadatarakenteet... 7 Palvelutapahtumatunnuksen välittäminen... 8 Potilaan tunnistaminen... 8 Pääsynhallinta ja lokittaminen... 8 Arkiston hallinnan periaatteet ja säilytysaikojen hallinta... 9 Muutostilanteiden huomioiminen... 9 Ympäristön tietoturva- ja laadulliset vaatimukset... 9 Tietojen luottamuksellisuus... 9 Hallinnollinen tietoturva... 9 Toiminnallinen tietoturva... 9 Tekninen tietoturva... 9 Liittymismalli: XCA Gatewayt ja liikennöinti... 9 Tunnisteiden muodostamissäännöt Tietoliikenneratkaisut Konfiguraatioiden ja muutosten hallinta Saatavuus ja SLA Tietovarastojen varmistus Hajautetulla mallilla toimivan Affinity Domainin perustaminen ja liittäminen Kvarkki-kokonaisuuteen Sopimukset Liittymisprosessin edellytykset (12)

3 Käytetty sanasto Termi Selite Viittaus IHE XDS.b Cross Enterprise Document Sharing. IHE IT-Infrastructure domainin määritys, joka sisältää perustransaktiot asiakirjojen kuvailutietojen ja itse asiakirjojen hakuun sekä niiden rekisteröintiin ja repositorioon tallentamiseen. XDS.b käsitetään tässä kuvauksessa synonyyminä XDS:lle, käytännössä XDS.b on uusi sukupolvi XDSmäärityksestä, joka sisältää mm. web services -rajapinnat. IHE XDS-I.b XDS-rekisteri XDSrepositorio Affinity Domain Assigning Authority IHE XCA Cross Enterprise Document Sharing for Imaging. Vastaava kuin XDS.b, mutta erikoistettu kuvantamisen materiaalille eli laajentaa XDS.b:tä. Käytännössä tarjoaa DICOM WADO (RAD-55), DICOM Query/Retrieve (RAD-16) ja web services pohjaisen Retrieve Imaging Document Set (RAD-69) transaktiot. Paikka johon XDS-dokumentit rekisteröidään. Tänne kohdistetaan XDS.b profiilin transaktioista ITI-18 (Registry Stored Query) sekä ITI-42 (Register Document Set). Rekisteri määrittää yhden Affinity Domainin alueen eli näin ollen määrittyy homecommunityid:llä. Paikka johon XDS-dokumentit tallennetaan. Tänne kohdistetaan XDS.b profiilin transaktioista ITI-43 (Retrieve Document Set) sekä ITI-41 (Provide and Register Document Set). Kullakin repositoriolla on oma repositoryuniqueid. Yhden XDS-rekisterin laajuinen alue, toiselta nimeltään home community. Voi palvella useaa repositoriota. Henkilötunnuksia hallinnoiva taho. Käytännössä Suomessa Väestörekisterikeskus ( ), mutta tilapäisten henkilötunnuksien osalta kansallinen käytäntö on vielä sopimatta. Affinity Domain tyypillisesti määrittelee käytettävissä olevat Assigning Authorityt. Cross Community Access. Laajentaa XDS.b-transaktioiden käytön Affinity Domainien välille. IHE XCA-I Cross Community Access for Imaging. Laajentaa XDS-I.b transaktioiden käytön Affinity Domainien välille. IHE BPPC IHE XUA IHE ATNA IHE CT IHE PIX IHE IOCM Basic Patient Privacy Consents. Malli suostumuksen hallinnan toteutukseen pohjautuen dokumenttien XDS-metadataan ja kiinteisiin pääsynhallintapolitiikkoihin, joita voidaan dokumentteihin liittää. Cross Enterprise User Assertion. Mahdollistaa käyttäjän tietojen ja hakutilanteen tietojen välittämisen Document Consumerilta Registrylle tai Repositoriolle (Document Sourcelle). Luonnosversiossa oli nimellä XUA++. Audit Trail and Node Authentication. ATNA-profiilin tuki pakottaa lokittamaan kaikki toiminteet laitteella, velvoittaa IHE CT käyttöön sekä asettaa vaatimuksia tietoturvaratkaisuille. Consistent Time. Käytännössä NTP-aikapalvelun hyödyntäminen ATNA Secure Nodeilla. Patient Identity Cross Referencing. Tarjoaa välineet potilaan yksilöintiin mahdollisesti eri tunnisteilla. Suomessa tietyssä mielessä ei niin relevantti, koska käytettävissä yksilöllinen ja kansallinen henkilötunnus. Toisaalta tilapäiset ja vanhat (sukupuolenvaihdostapauksissa ainakin) henkilötunnukset aiheuttavat sen, että yhdellä tunnisteella ei pärjätä kuitenkaan. Imaging Object Change Management kuvaa transaktiot kuvantamisen aineiston muutoshallinnalle. Pääosin DICOM-pohjaisten =Cross- Enterprise_Document_Sharing =Crossenterprise_Document_Sharing_for_Ima ging =Cross- Enterprise_Document_Sharing amework/upload/ihe_rad_tf_sup pl_xca-i_rev1-1_ti_ pdf =Basic_Patient_Privacy_Conse nts =Cross- Enterprise_User_Assertion_%28XUA% 29 =Audit_Trail_and_Node_Authen tication =Consistent_Time =Patient_Identifier_Cross- Referencing =Imaging_Object_Change_Man 2 (11)

4 DICOM PACS DICOM WA- DO Modaliteetti XDS-katselin DICOMarkisto Imaging Document Source Imaging Document Consumer Image Manager/Archive rajapintojen soveltamisohjeita. IOCM specifies how one actor communicates local changes applied on existing imaging objects to other actors that manage copies of the modified imaging objects in their own local systems. Digital Imaging and Communications in Medicine. Siirtoprotokolla, tiedostomuoto sekä transaktiot kuvantamistutkimusten käsittelyyn ja välittämiseen standardissa muodossa. Picture Archiving and Communication System. Tarkoitettu kuvantamistutkimusten käyttöä tukevaan tallennukseen ja jakeluun. Käytännössä PACS-toteutuksissa on myös pitkäaikaisempaa säilytystä tukevia ominaisuuksia, mutta modernien arkkitehtuurimallien mukaisesti käytetään lähinnä operatiivista käyttöä ja puolipitkän aikavälin arkistointia varten. Web Access to DICOM Objects, http get protokollan yli toimiva kuvien siirtomekanismi. XDS-maailmassa RAD-55. Kuvantamislaite, esim. x-ray angiography, ultrasound, mammography, endoscopy. (Yleensä) selainpohjainen ohjelmisto, jolla kyetään hyödyntämään XDS-rajapintojen yli rekisteristä, repositorioista ja DICOMarkistosta löytyviä aineistoja. Eri toimittajien ratkaisut tukevat vaihtelevissa määrin eri IHE-profiileja. IHE-termi Document Consumer ja Imaging Document Consumer. Kvarkki-osajärjestelmä, johon DICOM-muotoiset kuvantamistutkimukset tallennetaan. DICOM-arkisto on XDS-I Imaging Document Source mukainen. Imaging Document Source on XDS-I mukainen IHE-aktori, joka tarjoaa tarvittavat rajapinnat kuvantamistutkimuksien arkistointiin ja luovuttamiseen. Imaging Document Consumer on IHE-aktori, joka hakee Imaging Document Sourcesta löytyviä kuvantamistutkimuksia siten että ne ovat ammattihenkilön katseltavissa. IHE-aktori, joka tarjoaa kuvantamisaineiston käsittelyyn tarvittavat toiminnot ammattihenkilölle (avainkuvien merkkaamisen ym). Käytännössä toteutuu PACS-ratkaisulla tai voi olla integroituna Imaging Document Sourceen. agement OM 3 (11)

5 Johdanto Tässä dokumentissa kuvataan KVARKKI-arkkitehtuurin mukaisen Affinity Domainin perusteet. KVARKKIarkkitehtuurissa Affinity Domaineja voi olla kahdenlaisia keskitetty KVARKKI Affinity Domain sekä mahdollisesti useita hajautettuja aluekohtaisia Affinity Domaineja. Hajautetuista kukin huolehtii itse alueelliseen Affinity Domainiin kuuluvien toimijoiden tuottamien kuvantamistutkimusten säilyttämisestä ja jakamisesta sekä tähän liittyen luovutuksenhallinnasta kansallisten palveluiden avulla. Suomalaisissa Affinity Domain -toteutuksissa esimerkiksi henkilöiden yksilöinti perustuu yhteiseen Väestörekisterikeskuksen tuottamaan tietoon, ja luovutuksenhallinnan periaatteet ovat yhtäläiset. Näiltä osin Affinity Domainien väliset erot ovat pienempiä kuin useissa kansainvälisissä toteutuksissa. Erotuksena keskitettyä Kvarkkia tutkimusten säilytyksessä hyödyntävälle kunkin itsenäisen Affinity Domainin toteuttajalle jää vastuulleen mm. seuraavat tehtävät: - luovutuksenhallinnan järjestäminen Affinity Domainien välisessä luovutuksessa (pohjautuen Tiedonhallintapalvelun luovutuksenhallinnan asiakirjoihin ja näitä tietolähteenä käyttäviin palveluihin) - luovutusten raportointi luovutusilmoituksilla Kanta-luovutuslokille - säilytysajan hallinta ja tutkimusten hävittäminen säilytysajan päätyttyä - XCA-yhdyskäytävän sekä sitä palvelevien XDS-rekisteri-, repositorio- ja DICOM-arkiston ylläpitäminen - tutkimusten muutostenhallinnan (ml. kuvailutietojen muutosten) järjestäminen DICOM-arkistoon - käytön lokittaminen Kanta-määritysten mukaisesti Affinity Domain tasoiset toiminnallisuuteen sekä tietosisältöön liittyvät vaatimukset Affinity Domain kohtaisesti säilytettävät tietosisällöt Tietosisällön osalta Affinity Domain -kohtaisesti voidaan säilyttää vaiheistusasetuksen ulkopuolisia tietosisältöjä sekä kuvantamisen tutkimuksia (DICOM-muotoiset), koska valittu arkkitehtuurimalli on niiden osalta hybridi. Muu kuvantamisen tietosisältö eli kertomusasiakirjat ovat keskitettyyn Kantaan tallennettavia. Vanhojen potilasasiakirjojen osalta tallennus voi tapahtua keskitettyyn Kantaan tai alueelliseen arkistoon. Affinity Domainiin Kvarkki-kokonaisuudessa kuuluvat aktorit Kvarkki-arkkitehtuuri määrittelee IHE XDS(-I) mallin mukaisesti vähintään seuraavat Affinity Domain kohtaisesti toteutettavat IHE aktorit (mikäli ko. rooli edellytetään myös keskitettyyn Kvarkkiin arkistoivalta toimijalta on tämä mainittu suluissa): Document Registry Document Repository Imaging Document Source Image Manager / Archive (edellytetään myös keskitetyn mallin toimijalta) Imaging Document Consumer (edellytetään myös keskitetyn mallin toimijalta) XCA Initiating Gateway XCA Responding Gateway Initiating Imaging Gateway Responding Imaging Gateway ATNA Audit Record Repository ATNA Secure Node (kukin XDS-arkkitehtuurin osanen toimii tässä roolissa) Time Server 4 (11)

6 Time Client (kukin XDS-arkkitehtuurin osanen toimii tässä roolissa, edellytetään myös keskitetyn mallin toimijalta) Change Requester (IOCM) (edellytetään myös keskitetyn mallin toimijalta) Riippuen tulevista linjauksista koskien tilapäisten yksilöintitunnisteiden toteutustapaa, myös seuraavien aktoreiden tarve harkitaan kansallisella tasolla uudelleen: Patient Identifier Cross-reference Consumer (edellytetään myös keskitetyn mallin toimijalta) Patient Identifier Cross-reference Manager Patient Identity Source (edellytetään myös keskitetyn mallin toimijalta) Tämän lisäksi riippuen alueellisesta XDS-infrastruktuurista voi olla käytössä myös muita IHE-rooleja. Keskitettyyn tai alueelliseen Kvarkkiin kuvantamistutkimuksia arkistoivina toimijoina liittyvien organisaatioiden suositellaan hyödyntävän kuvantamistutkimusten tuottamisen prosessissa IHE radiologian workflow -profiileja. Profiilit täydentävät Kvarkki-viitekehystä myös toteutettaessa Kvarkki-liittymisestä johtuvia toimintamallien muutoksia. IHE-aktoreiden tukemat IHE-profiilit optioineen Kvarkki kokonaisuutena toimii XCA-I profiilin mukaisesti, alla oleva kaavio kuvaa tätä. XDS.b XDS-I.b 5 (11)

7 XCA XCA-I Affinity Domainin sisällä Kvarkki toimii XDS-I profiilin mukaisesti. Se mahdollistaa joitakin lisätransaktioita ja mm. DICOM-protokollan ja WADOn käyttöä. Toimijan sisäisessä tai Affinity Domain tasolla yhteisessä kuvantamisen järjestelmien kokonaisuudessa on mahdollista hyödyntää myös muita IHE radiologian profiileja. Käyttämistä Kvarkki ei edellytä eikä käyttötapaa ohjeista. Erityisesti scheduled workflow profiilin tarkastelu voi helpottaa Kvarkki liittymisvaatimusten toteuttamisen suunnittelua ja selventää esimerkiksi PACSin roolia Image Manager / Image Archive aktorina. 6 (11)

8 Käytettävät koodistot Kussakin Affinity Domainissa tulee ottaa käyttöön seuraavat kuvantamistutkimuksia ja yleisesti kansallista arkkitehtuuria koskevat koodistot ja rekisterit: - Rekisterinpitäjärekisteri - SOTE-organisaatiorekisteri - THL toimenpideluokitus Kvarkki-metatietomallissa käytettäväksi määritellyt mm. asiakirjoja luokittelevat koodistot Kuvantamistutkimukselle itsessään ei viedä rekisterinpitäjätietoa tai palvelun järjestäjän organisaatiotietoja DI- COM-tageihin. Kvarkki DICOM-arkisto noutaa arkistoinnissa nämä tiedot Kanta-arkistosta palvelutapahtumalta ja asettaa ne kuvantamistutkimuksen sisältökuvaukselle metatiedoiksi. THL toimenpideluokitus on kansallinen standardi, jonka mukaisesti tehdyt tutkimukset luokitellaan ja tästä ei saa poiketa. Toimenpideluokituksen koodituksen perusteella tuotetaan XDS-metatietomalliin mm. tieto anatomisesta alueesta. Kyseisen tiedon sijainti ja käyttötapa DICOM-tutkimuksella on kuvattu teknisissä määrittelyissä ja Kvarkki metatietomallissa. Käytettävät metadatarakenteet Käytettävien metadatarakenteiden pitää olla kussakin XDS-rekisterissä vastaavat, jotta samoilla kyselyperiaatteilla voidaan hakea kaikista Affinity Domaineista yhtäläisesti tietoa. Metadatamääritykset on kuvattu Kvarkkimäärittelyssä. Määrittelyiden ulkopuolisten laajennusten käyttöä ei ole estetty, mutta niiden tulee noudattaa kansainvälisiä XDS-määrityksiä ja mahdollisia kansallisia linjauksia. 7 (11)

9 On huomattava että kuvantamistutkimuskokonaisuuden asiakirjojen lisäksi samoihin XDS-rekistereihin rekisteröidään myös muita potilasasiakirjoja joko kansallisten tai alueellisten ratkaisujen mukaisesti. Näillä tulee olla käytössä yhteinen metatietomalli, sen periaatteiden mukaan mahdollisilla asiakirjatyyppikohtaisilla metatiedoilla täydennettynä. Palvelutapahtumatunnuksen välittäminen Palvelutapahtumatunnus on erikoistapaus kaikista Kanta- ja Kvarkki-arkkitehtuurissa käytetyistä metatietoelementeistä ja on keskeisin käsite nivomaan yhteen tietosisältöjä ja toiminnallisuuksia. Tämän vuoksi kaikissa potilasasiakirjoissa pitää olla palvelutapahtumatunnus. Palvelutapahtumatunnuksen välittäminen potilastietojärjestelmästä erinäisiin kuvantamisen järjestelmiin voi perustua esimerkiksi HL7 V2.x sanomaliikenteeseen ja/tai minimikontekstinhallintaan (erillinen HL7-määritys). Kvarkki-arkkitehtuuri ei määrittele tarkkoja alueellisia käytäntöjä tähän, vaan ainoastaan edellyttää, että kuvantamistutkimus ja sitä vastaavat palvelutapahtuma, lähete, tutkimuspyyntö, tutkimusasiakirja ja lausunto nivoutuvat palvelutapahtumatunnuksella yhteen. Potilaan tunnistaminen Potilaan tunnistaminen perustuu Väestörekisterikeskuksen myöntämään viralliseen henkilötunnisteeseen. Mikäli virallista henkilötunnistetta ei ole käytettävissä, voidaan potilas tunnistaa tilapäisellä yksilöintitunnisteella. IHE XDS ympäristössä henkilön yksilöintiin käytetään HL7 CX tietotyyppiä, jonka mukaisesti ilmaistuna henkilötunnus A on seuraavanlainen: A^^^& &ISO tarkoittaa Väestörekisterikeskuksen (Assigning Authority) virallista henkilötunnusta. Vastaava solmuluokka tarkoittaa tilapäistä yksilöintitunnistetta organisaation myöntämänä A^^^& &ISO Tilapäisen yksilöintitunnisteen muodostamisperusteet ohjeistaa THL. Tilapäisellä yksilöintitunnisteella Kvarkkiin arkistoidut kuvantamistutkimuskokonaisuuden asiakirjat ovat vain tuottaneen rekisterinpitäjän omassa käytössä. Tilapäisen yksilöintitunnisteen osalta kukin liittyjä on velvollinen huolehtimaan omasta tilapäisten tunnisteiden yksilöllisyydestä, hallinnasta sekä menettelyistä tilapäisen tunnisteen virallisen vastineen selvittyä. Tunnisteen päivittäminen Kvarkkiin tekee asiakirjojen luovuttamisen mahdolliseksi. Liittyjän on järjestettävä tilapäisen yksilöintitunnisteen osalta ilmoitussanoman (patient identity feed sanoman patient merge muoto) lähettäminen Kvarkki-rekisteriin ja DICOM-arkistoon kun tilapäisen tunnisteen virallinen vastine saadaan selville. Vaihtoehtoisesti tämän voi toteuttaa alueellinen Affinity Domain, riippuen toimijakohtaisesta tai alueellisesta tilapäisten yksilöintitunnusten hallintatavasta. Myöhemmin tulee käyttöön kansallinen ratkaisu ja toimintamalli. IHE PIX/PDQ profiileille ei ole Kvarkki-kokonaisuuden näkökulmasta ainakaan laajemmin havaittu tarvetta. Pääsynhallinta ja lokittaminen Kansallisen arkkitehtuurin mukaiset pääsynhallinnan toiminnalliset ja tekniset perusteet on kuvattu Kantamäärittelyissä. Kvarkki-pääsynhallintapalvelun periaatteet ja teknisen ratkaisun kuvaus on esitetty teknisessä Kvarkki-määrityksessä. Kunkin Affinity Domainin pitää pohjata pääsynhallintaan liittyvät periaatteet näihin määrityksiin. Mikäli luovutuksella saatuja tutkimuksia säilytetään alueella, pitää myös näiden pääsynhallinta alueellisessa ympäristössä ratkaista potilastietojen luovuttamiseen liittyvän lainsäädännön mukaisesti. Kaikista Affinity Domainissa kansallisiin potilaan suostumukseen tai alueellisiin informointitietoihin pohjautuvista hauista pitää arkistoida luovutusilmoitus Kanta-järjestelmään Kanta-määritysten mukaisesti Affinity Domainin sisällä velvoitetaan ylläpitämään käyttölokia potilastietojen käytöstä kansallisten määrittelyiden mukaisesti. 8 (11)

10 Arkiston hallinnan periaatteet ja säilytysaikojen hallinta Kuvantamisen tekstimuotoisten asiakirjojen (kuvantamisen kertomusasiakirjat) säilytysaikoihin liittyvät reunaehdot ja mekanismit hoidetaan Kanta-arkistossa. Itse kuva-aineistojen (kuvantamistutkimukset) osalta pääosa tutkimuksista säilytetään 12 vuotta, mutta tiettyjen aineistojen osalta säilytysaika voi olla 20 vuotta tutkimuksesta tai 120 vuotta potilaan syntymästä tai 12 vuotta potilaan kuolemasta. Kukin Kvarkki-arkisto toteuttaa kuvantamistutkimusten säilytyksenhallinnan ja hävityksen Kanta- ja Kvarkkimäärittelyiden mukaisesti. Muutostilanteiden huomioiminen Kukin rekisterinpitäjä on velvollinen huolehtimaan sekä rekisteritietojen että asiakirjatietojen korjaustoimenpiteistä ja jokaisessa Affinity Domainissa pitää olla toteutettuna tarvittavat mekanismit muutostilanteiden käsittelyyn: Potilastiedon päivittämisen mekanismi rekisteriin ja DICOM-arkistoon/PACS:iin Kuvantamisen kertomusasiakirjojen päivittämisen mekanismit Potilastiedon arkistoon IOCM-profiilin mukainen tutkimustietojen korjaaminen ja muutoksen propagointi DICOM-arkistoon Kuvantamistutkimusten metatietojen päivittämisen mekanismit o Esimerkiksi manuaalitoimenpiteet Ympäristön tietoturva- ja laadulliset vaatimukset Tietojen luottamuksellisuus Hallinnollinen tietoturva Kuvantamisen aineistoja yhteiskäytössä kansallisen Kvarkki-arkiston kanssa käsittelevät ja välittävät tietojärjestelmät kuuluvat Kanta-lainsäädännön mukaisen sertifioinnin piiriin. Toiminnallinen tietoturva Toiminnallisen tietoturvan osalta kuvantamiskokonaisuuteen kuuluu kaikki lainsäädännössä kuvatut periaatteet sekä Kanta-määrittelyissä tarkennetut vaatimukset. Kuvantamiseen liittyviä erityispiirteitä ovat suuret aineiston koot, jotka johtavat potentiaalisesti mittaviin hakuihin ja toisaalta kuvantamisen PACS-järjestelmien nykytila, jossa lainsäädännön pääsynhallintaan liittyvät linjaukset eivät välttämättä toteudu varsinkaan alueellisissa ratkaisuissa. Kvarkkimäärittelyt huomioivat kuvantamisen erityispiirteet Kvarkki osajärjestelmien osalta, ja asettavat Affinity Domainille vaatimuksia. Kuvantamistutkimusten tuottamiseen ja hyväksikäyttöön liittyy lisäksi muita toimijoiden toiminnallisen tietoturvan vaatimuksia, joiden osalta ei vielä ole kuvantamisen erityispiirteet huomioon ottavia soveltamisohjeita. Toiminnallisen tietoturvan varmistamisen välineenä ovat mm. yhteistestaus sekä olennaiset vaatimukset ja niihin liittyvä tarkistusmenettely. Osapuolet ovat velvoitettuja varmistumaan kunkin potilastietoja käsittelevän järjestelmän osalta olennaisten vaatimusten täyttymisestä. Tekninen tietoturva Tietojen välityksessä käytetään Kanta-arkkitehtuurissa kuvattuja tekniikoita eli kahdensuuntaista TLSliikennöintiä VRK:n tuottamiin palvelinvarmenteisiin pohjautuen. Affinity Domain -alueella tulee järjestää toimijoiden välillä vastaavat tai vastaavan tasoiset teknisen tietoturvan ratkaisut. Liittymismalli: XCA Gatewayt ja liikennöinti Kukin Affinity Domain muodostaa aiemmin esiteltyjen lisäksi erityisesti seuraavat aktorit: - XCA Initiating Gateway (XDS-pyyntöjen välitys kullekin Affinity Domainille) - XCA Responding Gateway (XDS-pyyntöihin vastaaminen kysyvälle Affinity Domainille) - XCA Initiating Imaging Gateway (XDS-I pyyntöjen välitys kullekin Affinity Domainille) 9 (11)

11 - XCA Responding Imaging Gateway (XDS-I pyyntöjen välitys kysyvälle Affinity Domainille) Yhteydet järjestetään sanomaliikennetasolla Affinity Domain XCA-yhdyskäytävien välillä suoraan peer-to-peer. Tietoliikenteen osalta voidaan käyttää sopivinta ratkaisua (full mesh tyyppiset verkkoratkaisut osapuolten välillä, olemassa olevien Kanta-yhteyksien hyödyntäminen tai suorat peer-to-peer MPLS- tai vastaavat yhteydet). Sanomaliikennetasoinen havainnekuva on esitetty alla ja se pätee erillisten XCA- sekä XCA-I yhdyskäytävien osalta (havainnekuvassa kuvattu vain XCA; XCA-I:n osalta Registryn/Repositoryn korvaa Kvarkin DICOMarkisto). Tunnisteiden muodostamissäännöt Kukin Affinity domain vastaa tunnistekäytäntöjen noudattamisesta Kvarkki-kokonaisuudessa. Seuraavaan listaukseen on koottu Kvarkki-sanomaliikenteessä olennaisia tunnisteita ja niiden muodostussäännöt: homecommunityid: Käytetään OID-muotoista tunnistetta, max. 64 merkkiä. Affinity Domain voi käyttää tässä SOTE-rekisterin mukaista palvelujen antaja tasoista OID-koodia. XDS-pyyntöjen tunnisteet (sanomatunnisteet): Kukin Affinity Domain huolehtii sanomatunnusten globaalista uniikkiudesta. Voidaan hyödyntää organisaation y-tunnusta osana sanomatunnisteiden muodostusta. Palvelinvarmenteet (Subject-osion Serial Number): Kanta-määritysten liityntäpiste-ohjeistuksien mukaan repositoryuniqueid: Käytetään OID-muotoista tunnistetta, max. 64 merkkiä. Affinity Domain vastaa tunnisteen globaalista uniikkiudesta. Voidaan antaa esim. palvelun järjestävän tahon Y-tunnuksen alle. Tietoliikenneratkaisut Tietoliikenneratkaisujen osalta tarvitaan kullekin Affinity Domainille tarvittavat yhteydet kuhunkin toisen Affinity Domainin XCA-yhdyskäytävälle. Yhteyksien nopeusluokka tulee vastata kansallisesti vaadittua laatutasoa. Yksittäisiä vikaantuvia komponentteja ei tietoliikenneinfrastruktuurissa saa olla vaan tietoliikenneyhteydet ja tietoliikenteen aktiivilaitteet on kahdennettava ja näiden osalta failover-toiminnallisuus on oltava määritelty ja testattu. Konfiguraatioiden ja muutosten hallinta Kvarkki-arkistojen konfiguraatiota kokonaisuutena koordinoi Kela. Koordinoinnin piiriin kuuluvat mm. käyttävien IHE-profiilien määritys ja alueiden sekä Kelan merkittävät Kvarkki-järjestelmien vaihdot ja versionnostot. 10 (11)

12 Kela järjestää yhteistestausmahdollisuuden ja laatii testien hyväksymiskriteerit. Käyttöympäristöjen laitteistovaihdot ja vastaavat toimenpiteet suunnittelee ja koordinoi kustakin Kvarkki installaatiosta vastaava organisaatio. Suunnitelluista käyttökatkoista tiedotetaan Kelan järjestämää menettelyä käyttäen etukäteen. Kustakin Kvarkkiinstallaatiosta vastaava organisaatio vastaa omalta osaltaan konfiguraation kirjanpidosta ohjelmistojen, laitteistojen ja niiden konfigurointien sekä tietoliikennekonfiguraation osalta. Saatavuus ja SLA Saatavuusvaatimukset ja muut ei-toiminnalliset vaatimukset asetetaan kansallisesti. Kela julkaisee vaatimukset Kanta-määrityksinä. Alueellisen Affinity Domainin osalta sopimus sisältää myös vaaditun palvelutason (saatavuus ja vasteajat), suunniteltujen huoltokatkojen periaatteet sekä muut palvelutasoa koskevat periaatteet. On huomioitava, että kuvantamisen kokonaisuudessa ei ole järkevä esittää vaatimuksia siten, että kiinnitetään sanomamääriä sekunnissa johtuen aineiston suuresta ja vaihtelevasta koosta. Käytännössä tulisi kiinnittää verkon laatuattribuutteja liityntäpisteestä toiseen. Tietovarastojen varmistus Kustakin Kvarkki-installaatiosta vastaava organisaatio vastaa riittävän tasoisista varmistusmekanismeista, jotta Kvarkkiin arkistoituja potilastietoja ja lakisääteisiä lokeja ei menetetä laiterikoissa tai muissa häiriötilanteissa. Varmuuskopioiden palautusmenettely tulee olla toteutettuna ja testattuna. Hajautetulla mallilla toimivan Affinity Domainin perustaminen ja liittäminen Kvarkkikokonaisuuteen Sopimukset Affinity Domain vastuutaho tekee sopimuksen liittymisestä Kvarkki/Kanta-palveluntarjoajan (Kelan Kantapalvelut) kanssa. Kukin Kvarkkiin liittyvä toimija tekee sopimuksen sen Kvarkki-domainin hallinnoijan kanssa, johon domainiin toimija arkistoi kuvantamistutkimuksensa. Tähän kuuluu myös sisältöprofiileista sopiminen ei-dicommuotoisen, ei-kanta-vaiheistukseen kuuluvan aineiston osalta. Toimijan käyttämät liityntäpisteet määritellään osana sopimusta. Palvelunjärjestäjä ja palveluntuottaja tekevät sopimuksen ostopalveluista. Sopimuksen tulee sisältää Kvarkkipääsynhallinnan konfiguroinnissa tarvittavat tiedot. Liittymisprosessin edellytykset Liittymisprosessi jakautuu alueelliseen ja kansalliseen osaan. Alueellinen osa kattaa terveydenhuollon toimijan liittymisen alueellisen Kvarkki-domainin käyttäjäksi. Kansallinen osa kattaa domainin liittämisen kansalliseen Kvarkki-kokonaisuuteen. Liittymisprosessi alueellisessa domainissa noudattaa organisaation liittymisprosessia Kanta-arkistoon tai keskitettyyn Kvarkkiin sertifiointeineen. Affinity Domainin perustaminen edellyttää kuitenkin liittymisprosessin osalta lisävaatimusten täyttämistä ja erityisesti sertifiointi tehdään ulkopuolisen tahon toimesta eikä organisaation itseauditointina. Terveydenhuollon toimijan liittymisen sertifiointi alueellisessa prosessissa on validi vain kun alueellinen domain on liitettynä osaksi kansallista Kvarkki kokonaisuutta ja osana sertifiointia on kansallinen yhteistestaus. 11 (11)