UNA PoC-yhteenveto CGI Aino Virtanen

Transkriptio

1 UNA PoC-yhteenveto CGI Aino Virtanen

2 PoC-toteutusten vastuulliset toimittajat/asiakasorganisaatiot sekä sisällölliset painopisteet

3 Mitä PoC sisälsi PoC-toiminnallisuus - hahmoteltiin UNA:n modulaarista rakennetta tekniikkariippumattomasti siten, että toiminnalliset moduulit voidaan toteuttaa keskenään riippumattomasti - tarkastelun kohteena tiedonhallinta ja integraatiot - testattiin, mihin asti riittävät käytössä olevat operatiivisten järjestelmien nykyiset integraatiot ja niiden tietosisällöt - kokeilu tehtiin ilman perusjärjestelmiin tehtäviä muutoksia PoC-ympäristön geneeriseksi malliksi muodostui seuraava rakenne: - tietomalli - postgresql avoimen lähdekoodin relaatiotietokanta - tietoallas - MDM (mm. käyttöoikeuksien hallinta, koodistot, nimikkeistöt, palveluntuottajat ja palvelupaketit) - tiedonhallinnan palvelut (integraatio)

4 Mitä saatiin tulokseksi konkretisoituneet asiat Modulaarinen rakenne Monitoimittajamalli Tekniikkariippumaton Järjestelmäriippumaton Avoin integraatiomalli PoC:n pääpaino: tarkentaa tiedonhallinnan merkitystä ja rooleja UNAn ensimmäisiä ydintehtäviä on mahdollistaa eri järjestelmien mahdollisuus toimia yhteen, jolloin seuraavat asiat konkretisoituivat: 1. Integraatiokyvykkyyden vaatimukset 2. Tietomalli ja tiedon yhteismitallisuus 3. Mikä on jatkossa tapa hoitaa tiedon integraatiota ja mikä on nykyisten asiakas- ja potilastietojärjestelmien integraatiokyvykkyys 4. Mitä erilaisia tietovarantoja tarvitaan eri käyttötarkoituksiin

5 1. Integraatiokyvykkyyden vaatimuksista Se, miten helposti tarvittava tieto on hyödynnettävissä, tulee ratkaisemaan toiminnallisuuksien ja käyttöliittymien rakentumisen jatkossa Nykyisten järjestelmien integraatiokyvykkyys paranee jatkuvasti kansallisten kehittämishankkeiden, esim ODA, uusien integraatiovaatimusten kautta Integraatiokyvykkyyteen vaikuttavia tekijöitä ovat tietomalli, tiedon yhteismitallisuus ja itse integraatioratkaisu miten yhteismitalliseksi tieto voidaan tuottaa mikä on sovellusten kyky yhteentoimivuuteen noudattamalla yhteisiä käsite/termistömäärityksiä (tiedon ymmärtäminen) miten joustavaksi integrointiratkaisu on mahdollista toteuttaa

6 2. Tietomalli ja tiedon yhteismitallisuus Jotta yhteentoimivuusstandardi vastaa semanttisen yhteentoimivuuden haasteisiin, niin: Standardien dokumentointi on yksinkertaista ja ymmärrettävää Standardien on oltava käyttöönotettavissa helposti ja nopeasti PoC:ssa testattiin HL7v2.1 sanomastandardia, joka tällä hetkellä on käytetyin Vaatimuksia tiedon yhteismitallisuuden varmistamiseksi: valitun tietomallin on oltava irrallaan sovelluksista tietomallin on pystyttävä kommunikoimaan ulospäin avoimesti eli puhutaan avoimesta tietomallista tietomallin on pystyttävä jakamaan tietoa yhteismitallisesti eli kommunikoimaan usealla eri tietorakenteella ja yhteentoimivuusstandardilla tietomallin on tuettava yhteentoimivuusstandardeja - historia, nykyisyys, tulevaisuus tietomallin on mukauduttava yhteentoimivuuden vaatimuksiin tietoa yhdistellään eri lähteistä ja eri aikakauden rakenteista ja standardeista Ilman em. ominaisuuksia kyseinen järjestelmä jää yksinäiseksi saarekkeeksi PoC:ssa testattiin HL7 v2.1 sanomastandardia - tietosisältö tapahtumatietoa kliininen tieto Kannasta

7 3. Mikä on jatkossa tapa hoitaa tiedon integraatiota Jatkossa tiedonhallinnan palvelurajapintojen on tuettava yleistä, järjestelmäriippumatonta ja avointa integraatiokäyttöä Tämä tarkoittaa, että monoliittisen ESB-ratkaisun sijaan tulee olla globaalit tiedonhallinnan palvelut ESB-alustan rooli on ollut toteuttaa integraatioita perinteisesti, eli Hub and spoke - integraatio Enterprise service bus (ESB) -integraatio Järjestelmien tulee jatkossa tuottaa tarvittavat tiedot palvelurajapintojen kautta yhteismitallisesti muiden saatavaksi -> teknologia- ja toimittajariippumattomuus Tämä tarkoittaa, että monoliittisen ESB-ratkaisun sijaan tulee olla globaalit tiedonhallinnan palvelut, joissa järjestelmät ja komponentit tarjoavat itse tiedonhallinnan palveluja käyttävät muiden tarjoamia palveluja myös nykyisten aptj:en Järjestelmien väliset riippuvuudet ovat löysiä esim. FHIR-palvelurajapinta-toteutukset tukevat järjestelmäriippumatonta ja avointa integraatiokäyttöä ja Rest-arkkitehtuuri globaalia, skaalautuvaa, muunneltavuutta

8 4. Mitä erilaisia tietovarantoja tarvitaan eri käyttötarkoituksiin Käyttötarkoitus Datan lähde Datan luonne Tekniikka PoC: Tapahtu matieto, tällä hetkellä ptj OPERATIIVINEN Päivittäinen toiminta Operatiivisten järjestelmien tietokannat Arkistoratkaisut Organisaatiokohtaiset tietovarannot Relaatiotietokannat OPERATIIVINEN TAPAHTUMAN KÄSITTELY Prosessinohjaus Toiminnanohjaus Reaaliaikainen tapahtumatieto Tapahtumatieto Publish and Subscribe, EventDriven ANALYSOINTI, TILASTOINTI, TIEDON JATKOKÄYTTÖ TIETOALLAS PoC:ssa todettiin tietoallasratkaisun parantavan UNA ekosysteemin muutosjoustavuutta - esim. tietomallin laajennuksen yhteydessä muutos vaikuttaa myös historiatiedon osalta Tiedonhallinnan tukeminen tarvelähtöisesti Koottu eri lähteistä Tieto eri formaateissa BigData, useita formaatteja Ei rakenteistettu Suuret tietomassat, striimaava data Hadoop, HDFStiedostorakenne, virtualisointi DATA WAREHOUSE, TIETOVARASTOT Raportointi, analytiikka, louhinta, ennustaminen, toiminnan suunnittelu Yhdistely eri lähteistä Keskitettyjä tietovarantoja tai aihetietokantoja Rakenteistettu Tapahtumadata DataVault, tähtimallit, normalisointi YHTEISET TIETOVARANNOT REKISTERIT ARKISTOT HAKEMISTOT Tilannetieto Tiedon elinkari Operatiiviset tietokannat Tiedon elinkaari yhteisiä palveluja, kuten käyttöoikeuksien hallinnan, koodistot, nimikkeistöt, palveluntuottajat ja palvelupaketit Luokitus, koodisto, masterdata Tiedon säilytys Pysyvä, muuttumaton historiatieto PoC:ssa todettiin yhteiseksi osaksi tarvittavan Master Data Management ratkaisun, joka tarjoaa UNAekosysteemille PoC: kliininen tieto saadaan Kantaarkistosta Tiedon hakeminen, löytyminen Hajautettu tieto Esim. asiakirjapohjai nen tieto Metadataanalyysityökalut Lohkoketjuteknologia Arkistotietokannat XDSinfrastruktuuri

9