Arkkityyppi voi olla myös APTJ-arkkitehtuurin ydin

Arkkityyppi sukelsi esille Aleksis Kiven päivänä 10.10.2020 HS:n kulttuurisivulta otsikolla "Aleksis Kiven arkkityypit heijastuvat nykypäivään". Seitsemän veljestä ovat tyyppeinä erilaisia ja vastaavia henkilötyyppejä löytyy nykyajasta. Otin selvää, mitä käsite arkkityyppi oikein tarkoittaa. Wikipedian mukaan tarkoittaa hahmon, asian tai käsitteen alkumuotoa ja mallia. Arkkityypit ovat osa taiteen, kirjallisuuden ja psykologian - psykiatrian käsitemaailmaa. Ne esiintyvät kaikissa kulttuureissa, uskonnoissa ja historian osissa sekä uskomuksissamme.[i]

Arkkityyppi osana openEHR-käsitteistöä on työmaailmassa esiinnoussut käsite. Ensin on suomennettava tämä open EHR - käsite, eli avoin elektroninen (sähköinen) potilaskertomus. Laajemmin puhutaan APTJ:stä eli asiakas- ja potilastietojärjestelmästä sisältäen sekä sosiaalihuollon että terveydenhuollon.  OpenEHR:n sanansaattaja Hanna Pohjonen kertoo blogikirjoituksessaan, mistä on kyse. [ii]

Yritän tehdä tiivistyksen, mistä selviää myös arkkityypin käsite tässä openEHR-yhteydessä:

  • Modulaarisuus on mahdollista, koska openEHR-pohjaisessa APTJ-kokonaisuudessa käyttöliittymä, toiminnallinen logiikka, tietovarasto ja tietomalli ovat selkeästi erotettu 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.
  • 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.

OpenEHR:n toiminnallinen idea on tiivistetysti seuraava:

  • openEHR on loikka kattaviin hoito- ja palvelusuunnitelmiin – työkaluihin, jotka tukevat lääkärin päätöksentekoa, parantavat käytettävyyttä ja helpottavat kliinisten tietojen kirjaamista. Valmiit ja muokattavat mallipohjat toimivat hoitoa tukevina ja ohjaavina protokollina. Kirjauksia voidaan automaattisesti hyödyntää osana potilaan hoitosuunnitelmaa. Reaktiiviset, tapahtumakohtaiset sekä toistuvat kirjaukset jäävät historiaan.[iii]
  • WWW.openehr.org/.-sivustolla vielä kerrotaan: openEHR koostuu avoimista spesifikaatiosta, kliinisistä malleista ja ohjelmistoista, joita voidaan käyttää standardien luomiseen sekä tieto- ja yhteentoimivuusratkaisujen rakentamiseen. Tällä hetkellä puuttuu virallinen kansainvälinen standardointielin/-yhteisö. Tosin kansallisia viitemalleja on kyllä olemassa.  

Arkkityyppi openEHR-maailmassa: OpenEHR:n perusteluteksteissä arkkityypit ovat tapa lisätä toimialueen semantiikkaa tietomalleihin, samalla kun vältetään loputon kasvu ja ylläpito. Näin tapahtuisi, jos mallinnukseen käytettäisiin oppikirjaa. Mitä tämä sitten tarkoittaa? Selvitin sitä menemällä OpenEHR-sivustolle. Löysin seuraavia selvennyksiä tästä lähteestä ja muista vastaavista:

  • Arkkityypin ominaisuutena on uudelleenkäytettävyys, tavoitteena openEHR-ekosysteemissä saavuttaa arkkityypistä de facto-standardi; arkkityyppi olisi osa arkkityyppien kirjastoa, jota sitten voitaisiin käyttää kussakin openEHR-pohjaisessa APTJ:ssä; tästä käytetään yleisesti esimerkkinä verenpaineen mittaamista ja sen tietomallia. 
  • Arkkityypit ovat yhteensopivia Snomed-CT:n kanssa sekä keskeisten terveydenhuollon luokitusten kanssa, kuten ICD-10.
  • Arkkityyppien pitäisi olla julkista aineistoa; kansainvälisesti näin on; kaikki yhteisön läpikäymät ja hyväksymät arkkityypit ovat kuvattuna openEHR:n sivuston kirjastossa [iv]; julkaistuja on tällä hetkellä 115 ja saamani tiedon mukaan suomennettuja noin 50.
  • Arkkityypit on luokiteltu viiteen kategoriaan: 1. Action / toiminta (esim. hoitosuunnitelma, prosessi). 2. Evaluation / arviointi (esim. terveysriskit, alkoholin kulutus, tupakointi, asuminen, tulot). 3. Observation / havainto (esim. kipuluokitus, aivohalvauksen riskiluokitus, verenpaine, kehon painoindeksi. 4. Instruction / ohje (esim. hoitosuunnitelman ohje, lääkemääräysohje jne.). 5.Admin / hallinto (esim. hoitoepisodin määritelmä, potilaan hoitoon pääsy, kiireellisyysluokitus; hallinnolla tässä yhteydessä tarkoitetaan potilashallintoa).
  • Arkkityypit liittyvät toisiinsa templaateilla (”sapluunoilla”), jotka ovat näkymiä arkkityyppeihin; templaatteja voidaan siis rakentaa arkkityyppien avulla; niitä voi olla valmiina kirjastossa tai ne voidaan "räätälöidä" APTJ:n käyttötarkoituksiin erikseen.
  • Arkkityypit määritellään sisällön tai teeman perusteella (esim. verenpaine); templaatit tarjoavat tavan käyttää tiettyä joukkoa arkkityyppejä sekä niistä tiettyjä rajoitettuja osioita (arvot, termit jne.).
  • Viitemalli on arkkityyppien ja templaattien taustalla stabiili standardoiva osio; viitemalliin on kirjattu arkkityyppiluokat sekä 21 dataelementtiä (kuten aikaan ja dokumentaatioon liittyviä dataelementtejä); nämä kaikki on hyväksytty openEHR-ekosysteemissä. 

Arkkityyppeihin perustuvaa arkkitehtuuria on myös kritisoitu, osin aiheesta osin tietysti aiheetta. Tiukimmat kritiikit ovat mielestäni aiheettomia ja liittyvät siihen, että tämä on ollut pienen piirin puuhastelua. Kun nyt tutkailin esimerkkien valossa läpi arkkityyppejä, niin jokaista on ollut valmistelemassa suuri joukko eri maiden asiantuntijoita. Myös arkkityypeissä on runsaasti sellaisia, jotka ovat jo muutenkin yleisesti hyväksyttyjä, kuten vaikkapa toiminnan osalta prosessin määrittely, arvioinnin osalta terveysriskit, havainnon osalta kehon painoindeksi, ohjeiden osalta lääkemääräys, hallinnon osalta kiireellisyysluokitus. Yleisenä kritiikkinä on esitetty, että openEHR ei ole standardi. Niin, se ei ole arkkitehtuurikokonaisuutena standardi, mutta se sisältää runsaasti yhteensopivia elementtejä standardien ja luokitusten kanssa, kuten ICD-10-tautiluokitus tai Snomed-CT tai erilaiset arviointeihin ja havainnointeihin liittyvät mittarit / indeksit. Kritiikki kohdistuu myös openEHR:n avoimuuteen. Tietojen avoimuus ja vertailukelpoisuus riippuu siitä, mitä arkkityyppejä on integroitu osaksi APTJ:tä ja miten nuo integroidut osiot on ohjeistettu sekä toiminnallisesti yhdistetty osaksi palvelu- ja hoitoprosesseja. Toimittaja-/sovelluskohtaisissa APTJ-ratkaisuissa ei ole minkäänlaista yhteistä käytännettä.  Näin sama tieto on eri toimittajien templateissa aivan eri paikoissa. Tämänhetkisen aiheeseen tutustumisen perusteella en uskalla todeta, onko openEHR-arkkitehtuuri yhteensopiva HL-7-standardien kanssa. Tältä osin on myös esitetty kritiikkiä ja puoltavia puheenvuoroja. Ja lopuksi on väitetty, että openEHR ei ole "vendor neutral"eli ajaudutaan myyjän loukkuun. Alustaratkaisun pitää olla yhteensopivan openEHR-arkkitehtuurin kanssa. Alustoja on saatavilla täysin avoimina ratkaisuina tai maksullisina. Alustan päälle on voitu rakentaa jo toiminnallisuutta, joka on sitten myös ajautumista myyjän loukkuun. Toisaalta ratkaisu mahdollistaa laajennukset, jotka voidaan erikseen kilpailuttaa. 

Omat huoleni /kommenttini koskien tätä vertailua liittyvät seuraaviin asioihin:

  • Siirtyminen perinteisestä mallista /järjestelmästä (monoliittisesta järjestelmästä) openEHR-järjestelmään on haastava ja pitkäkestoinen työ; myös hyvät esimerkit ovat vähissä.
  • Alustaratkaisut perinne- ja openEHR-järjestelmissä eivät ole yhteensopivia, eli suoraan perinnejärjestelmän päälle ei voi kunnolla rakentaa openEHR-toiminnallisuutta.
  • Arkkityypit ovat ainakin osittain suuren joukon muodostamia de facto-standardeja. Niitä pitäisi voida hyödyntää myös perinnejärjestelmissä - itseasiassa kysynkin, miksi ei voisi?
  • Arkkityypit muodostavat mielestäni hajanaisen toiminnallisuuksien joukon, jossa kokonaisuuden hallinta jää askarruttamaan mieltäni; jos seuraa arkkityyppien valmisteluprosessia, voi havaita pari oleellista asiaa: 1) kokonaismäärästä merkittävästi suurempi osa on eriasteisessa valmisteluvaiheessa verrattuna valmiisiin , 2) vain osa arkkityypeistä on suomennettu eikä suomentaminenkaan ole pelkkää google -kääntäjän työtä vaan vaatii lokalisointia eli soveltamista Suomen oloihin (lainsäädäntö, toimintakäytännöt jne.).

Otsikkoni ("Arkkityyppi voi olla myös APTJ-arkkitehtuurin ydin") on joltain osin haastava, mutta arkkityyppejä voitaisiin kansallisesti lokalisoiden ottaa standardeiksi ja näin sisällyttää eri järjestelmiin. Tätä varten pitäisi olla se mandaatilla toimiva taho, joka osallistaa kenttää vahvasti, eikä vain anna ylhäältä määräyksiä. Saadaanko aikaan päätös kansallisesta standardointitahosta? Mandaatti sopisi kyllä hyvin THL:n tehtäviin. Toimintatapa voisi muistuttaa HL-7-yhteisön standardointitapaa.

 

[i] Arkkityyppi – yleinen määritelmä: https://fi.wikipedia.org/wiki/Arkkityyppi; https://www.storyboardthat.com/fi/articles/e/arkkityypit

[ii] Hanna Pohjonen: Mitä modulaarinen openEHR-pohjainen APTJ tarkoittaa ja miten se eroaa perinteisestä mallista. https://unaoy.fi/blogit/mita-modulaarinen-openehr-pohjainen-aptj-tarkoittaa-ja-miten-se-eroaa-perinteisesta-mallista/

[iii] TietoEvry /uutishuone: OpenEHR on avain tiedon joustavaan hyödyntämiseen. https://www.tieto.com/fi/uutishuone/kaikki-uutiset-ja-tiedotteet/blogi/2018/openehr-on-avain-tiedon-joustavaan-hyodyntamiseen/

[iv] kansainvälinen arkkityyppikirjasto, CKM - Clinical Knowledge Manager: https://ckm.openehr.org/ckm/;

kansallinen vastaava kirjasto puuttuu Suomesta.

Olli Nylander, vanhempi asiantuntija

Arkkityyppi ja openEHR arkkitehtuurimalli