Vieraskynä -blogin kirjoittaja Hanna Pohjonen (Tkt) avaa yhtä näkökulmaa, jolla tällä hetkellä maailmalla lähestytään APTJ-kehittämistä. Hanna on Terveydenhuollon johdon konsultti Rosaldo Oy:stä ja myös openEHR-säätiön nimeämä Suomen openEHR Ambassador. Hanna on konsultoinut noin 30 eri maassa erityyppisissä alueellisissa ja kansallisissa eHealth-projekteissa.
Tämän blogin julkaisupäivälle (25.3.2020) alunperin suunniteltu OpenEHR Day Nordics ja openEHR Workshop for Social Care järjestetään suunnitellusti Helsingissä poikkeusolojen helpotettua. Ilmoitamme ajankohdasta sen varmistuttua.
Monoliitista moduuleihin
Toimittaja- ja teknologiariippumaton openEHR-tietomalli on mullistamassa asiakas- ja potilastietojärjestelmämarkkinan (APTJ-markkinan). openEHR-tietomalli tekee eri toimittajien sovelluksista semanttisesti yhteensopivia. Uuden sukupolven APTJ ei ole enää yhden toimittajan tuottama monoliitti, jossa käyttöliittymä, toiminnallinen logiikka, tietovarasto, tietomalli ja työnkulku ovat samassa toimittajakohtaisessa ohjelmistossa. Jatkossa APTJ voi pilkkoutua helpommin useaan toiminnalliseen moduuliin, jotka voidaan hankkia monelta eri toimittajalta.
Modulaarisuus on mahdollista, koska openEHR-pohjaisessa APTJ-kokonaisuudessa käyttöliittymä, toiminnallinen logiikka, tietovarasto ja tietomalli ovat erotettuja selkeästi toisistaan. Jokainen toiminnallinen moduuli tallentaa tietonsa yhteiseen tietovarastoon avoimen openEHR-tietomallin mukaisesti standardi API-rajapinnan kautta. Toinen moduuli voi käyttää tätä tietoa välittömästi tietosuojarajoitukset huomioiden. Tällä tavalla terveydenhuollon organisaatio voi saada joustavuutta hankintaprosessiinsa: voidaan hankkia juuri se toiminnallisuus, joka tällä hetkellä on tarpeen ja juuri siltä toimittajalta, jolla on sopivin moduuli. Sen sijaan, että pitäisi ostaa kaikenkattava monoliitti, voidaankin rakentaa APTJ erilaisista toiminnallisuuksista.
Käyttäjälle moduulien tarjoamat toiminnallisuudet näkyvät yhä useammin yhtenäisen käyttökokemuksen kautta. Käyttäjästä tuntuu kuin hän käyttäisi yhtä järjestelmää. Yhtenäisen käyttökokemuksen voi toteuttaa siihen erikoistunut taho tai vaikkapa moduulien päätoimittaja. Yhtenäinen käyttökokemus toteutetaan yleensä käyttäjärooleittain. Moduulien integrointi toisiinsa tapahtuu sekä tietovaraston että prosessityökalujen (asiakaspolun ohjaus) kautta, eikä ole enää tarvetta lukuisiin vaikeasti hallinnoitaviin integraatioihin tai tiedon migraatioon moduulien vanhentuessa. APTJ-kokonaisuutta voidaan rakentaa hallitusti ja kustannustehokkaasti ja muutokset ovat ketteriä.
Oheisessa kuvassa on vertailtu molempia lähestymistapoja tiiviistetysti.
Miksi uusi lähestymistapa?
Perinteiset järjestelmät eivät kykene täyttämään käyttäjien muuttuvia tarpeita eivätkä mukautumaan uusiin toimintamalleihin. Tarvitaan uusia joustavampia lähestymistapoja. Asiakaskeskeisyys vaatii, että pystymme rakentamaan yli organisaatioiden meneviä asiakaspolkuja. Tietoa on pystyttävä hyödyntämään täysimääräisesti yli organisaatio- ja järjestelmärajojen, eikä vain katselemaan eri lähteistä tullutta tietoa. Tällä tarkoitetaan mm. päätöksenteon tuen, analytiikan ja automatiikan hyödyntämistä. Ajankohtaisena tarpeena on myös populaatiotason analytiikka, joka onnistuakseen vaatii tiedon harmonisoinnin semanttisella tasolla. Järjestelmän osat on pystyttävä hankkimaan toisiinsa yhteensopivina usealta eri toimittajalta, koska yksikään toimittajista ei voi olla kaikkien erikoisalojen asiantuntija.
Mitä hyötyjä uudenlaisesta arkkitehtuurista ja semanttisesti yhtenevästä tietomallista?
Kun tieto on eriytettynä erilliseen tietovarastoon ja käytetään standardirajapintoja, tietojen hyödyntäminen on helpompaa ja se voi tapahtua myös muiden kuin APTJ:n toimittaneen yrityksen toimesta ja myös muilla kuin heiltä ostettavilla työkaluilla. Kun tallennetun tiedon merkitys on yhtenevä, tietoja pystytään analysoimaan myös muissa samaan tietomalliin tukeutuvissa järjestelmissä.
Kun moduulit on toteutettu openEHR:n periaatteita hyödyntäen, järjestelmää voidaan täydentää uusilla moduuleilla tarpeen mukaan ja käytössä olleen moduulin tilalle voidaan hankkia vastaava toiselta samoihin standardeihin sitoutuneelta toimittajalta. APTJ:n vaihtaminen voidaan toteuttaa hallitummin ilman raskasta migraatiota – aikaa ja kustannuksia säästäen. Myös riski tiedon menettämisestä on pienempi. Moduulien ollessa pienempiä ja erikoisaloille kohdennettuja, kehittämistyö on nopeampaa ja moduulit voidaan toteuttaa paremmin kutakin erikoisalaa palveleviksi.
Uudet innovaatiot osaksi APTJ-kokonaisuutta
openEHR-pohjainen APTJ pystyy ottamaan käyttöön uusia innovatiivisia toiminnallisuuksia ketterästi, kun uudet toiminnallisuudet voivat hyödyntää yhteistä tietovarastoa ja alustan yhteisiä teknisiä palveluja. Tämä luo mahdollisuuksia pienille eri alojen erityisosaajille. Tällaisia innovatiivisia moduuleja voisivat olla esimerkiksi nuorisolle suunnattu mielenterveyden moduuli, hammaskirurgian moduuli, lasten ensihoidon moduuli tai vaikkapa vanhemmille suunnattu lapsen kehitystä seuraava sovellus. Toiminnalliset APTJ-moduulit kilpailevat parhaimmilla oivalluksilla siitä, miten käyttää openEHR-tietovaraston tietoa älykkäästi ja innovatiivisesti. Innovaatiot voivat tulla myös käyttäjäorganisaatiolta ja niitä voidaan kehittää ketterästi yhdessä toimittajien kanssa
Innovaatioiden synnyttämiseen ja hyödyntämiseen tarvitaan ekosysteemiajattelua, jossa eri toimittajat täydentävät toisiensa tarjoomaa. Tämä tarkoittaa uudenlaista lähestymistapaa myös hankintaorganisaatioissa, koska innovatiivinen niche toimittaja on harvoin ehtinyt hankkia lukuisia mittavia referenssejä tai tyypillisen hankintavaatimuksen mukaista liikevaihtoa. Toisaalta kansainvälinen openEHR-tietomalli luo pienille moduulitoimittajille mahdollisuuden kansainvälistyä helpommin ja toimia osana kansainvälisiä APTJ-kokonaisuuksia.
Asiakaspolun ohjauksen moduuli
Uusin openEHR-määrittely koskee monen organisaation yli meneviä asiakaspolkuja – niiden mallintamista ja ohjaamista. Monimutkaiset asiakaspolut tai niiden osat voidaan mallintaa ja polun toteutumista voidaan seurata visuaalisesti. Polku itsessään voi sisältää automatiikkaa ja päätöksenteon tukea polun haarautumiskohdissa. Se voi myös käyttää ulkoisia päätöksenteon tuen moduuleja. Tavoitteena on, että samalla asiakaspolun ohjauksen moduulilla voidaan hallita asiakkaan kaikki SOTE-polut ja niiden toteutumista voidaan seurata reaaliaikaisesti koostenäkymässä. Perinteisessä järjestelmässä asiakaspolun ohjaus on APTJ:n sisällä ja rajoittuu ainoastaan kyseisen järjestelmän asiakkuuksiin.
Vanhan ja uuden rinnakkaiseloa
Uudenlaiset APTJ-projektit – esimerkiksi Skotlannissa – ovat lähteneet rakentamalla ensin alueellinen tai kansallinen openEHR-tietovarasto, jonne vanha tieto siirretään perinteisistä järjestelmistä sitä mukaa, kun asiakas tulee aktiiviseksi eli hakeutuu hoitoon. Migrointi voidaan myös suorittaa kerralla. Samassa yhteydessä tehdään tiedon harmonisointi openEHR-tietomalliin. Kaikki uusi tieto tallennetaan suoraan tietovarastoon openEHR-tietomallin mukaisena.
Tämän jälkeen APTJ-toiminnallisuudet rakennetaan vaiheittain moduuleina tietovaraston ja yhteisten teknisten palvelujen päälle. Vanhojen järjestelmien perustoiminnallisuuksia käytetään siihen asti, kunnes niitä ei enää tarvita. Osa vanhoista järjestelmistä voi elää pitkäänkin rinnakkaiseloa. Pitää myös muistaa, että kaikki järjestelmät eivät muutu openEHR-pohjaisiksi ja kommunikoivat esim. HL7 FHIR -standardilla.
Hanna Pohjonen
