Näkökulma
Sama nimi alkaa tarkoittaa eri asioita, kun jokainen raportti määrittelee käsitteen itse.
Raportointityökalussa semanttinen malli rakennetaan usein yhtä raporttikokonaisuutta varten. Seuraavassa kokonaisuudessa käynti, hoitojakso tai asiakas määritellään uudelleen, hieman eri tavalla.
Mistä on kyse
Semanttinen malli on ketju, joka sitoo toimintaa kuvaavan käsitteen siihen dataan, josta luku lopulta syntyy. Ketjussa on neljä osaa: käsite, määritelmä, laskenta ja fyysinen data. Malli kuvaa organisaation toimintaa, kuten käyntejä, hoitojaksoja ja asiakkaita, eikä yksittäistä raporttia. Siksi yhteiset käsitteet kuuluu määritellä tietoalustalla, jolta jokainen raportti lukee samat määritelmät.
Aloitamme ketjusta, koska semanttisella mallilla tarkoitetaan alalla kolmea asiaa: raportointityökalun tietomallia ja mittareita, tietoalustan mittarikerrosta sekä semantiikkaa sanan varsinaisessa merkityksessä. Raportointityökaluissa termi tarkoittaa yleensä tietomallia, jonka varaan raportit rakennetaan, ja usein jokaiselle raporttikokonaisuudelle syntyy oma mallinsa. Power BI:ssä tämä merkitys korostuu, koska Microsoft nimesi vuonna 2023 tietojoukot semanttisiksi malleiksi.
Kun ketju pitää, sama mittari tuottaa saman luvun, lukipa sitä raportti, rajapinta tai tekoälyagentti. Määritelmän muutos on silloin tapahtuma, jolla on päivämäärä ja tekijä, ja historian voi laskea uudelleen. Jokaisen luvun voi jäljittää sääntöön, dataan ja siihen, kuka määritelmän hyväksyi.
Mikä menee pieleen
Pahimmillaan mallia rakennetaan samaan aikaan kahdessa paikassa toisistaan tietämättä: raportointityökalussa ja tietoalustalla. Jos tietoalustan mallinnus aloitetaan olemassa olevista raporteista, ristiriidat kopioituvat mukana.
- Sama luku on eri raporteissa erisuuruinen, ja ero selvitetään käsin joka kerta.
- Luottamus siirtyy luvuista ihmisiin, koska vain yksi tai kaksi tietää, miten mittari todellisuudessa lasketaan.
- Johdolle tehdään oma virallinen raportti, koska muihin ei luoteta.
- Määritelmän muutos ei näy missään, eikä historiaa voi laskea uudelleen.
- Logiikka pitää lukea kaavasta, ja tieto lähtee tekijän mukana.
- Tekoälyagentti vastaa vakuuttavasti, mutta vastaukseen ei voi luottaa.
Kaikkien kuuden takana on sama puute: käsitteellä ei ole omistajaa. Kun ketään ei ole nimetty päättämään, päättää se, joka on lähimpänä koodia. Datainsinööri tekee silloin määrittelypäätöksiä, jotka kuuluvat toiminnan asiantuntijalle.
Miten ajattelemme
Raportointityökalu jää, määritelmä siirtyy tietoalustalle
Tavoitetilassa raportointityökalu jää käyttöön. Määritelmä siirtyy sen ulkopuolelle tietoalustalle, ja siellä määritelmällä on kolme osaa: käsitemalli muunnossääntöineen, datakontrakti ja mittarikerros. Datakontrakti kertoo käsitteen merkityksen, omistajan, laatusäännöt ja elinkaaren vaiheen. Mittarikerroksessa jokaista mittaria hallitaan omana objektinaan, ja raportit, rajapinnat ja tekoälyagentit lukevat mittarin sieltä.
Raja kertoo, kumpi luku on virallinen
Tietoalustan kolme osaa rajataan omaksi alueekseen. Rajan sisällä oleva mittari on organisaation luku. Raportissa laskettu mittari jää rajan ulkopuolelle, ja se on raportin oma luku. Nykyisiä raportteja ei tarvitse purkaa.
Tavoite on, että jokaisella käsitteellä on omistaja datatiimin ulkopuolella
Määritelmä ilman omistajaa näyttää viralliselta, vaikka se ei ole sitä. Siksi tavoittelemme, että toiminnan asiantuntija vastaa tärkeästä käsitteestä ja sen datakontraktista ennen kuin käsite mallinnetaan.
Yksi käyttötapaus ja muutama mittari kerrallaan
Johannes Hovi kirjoittaa, että semanttisen kerroksen vaikein osa ei ole teknologia. Hänkin kuvaa yhteyden käsitteestä fyysiseen dataan ja neuvoo aloittamaan yhdestä käyttötapauksesta ja muutamasta mittarista. Olemme samaa mieltä. Kaikkia käsitteitä ei määritellä kerralla, vaan ensimmäiset mittarit toteutetaan ja katsotaan, pitääkö tulos. Käsitteiden määrittelystä tulee näin osa tavallista työtä.
Määritelmä viedään koodiin asti
Hovin neuvoihin lisäämme yhden vaatimuksen. Määritelmä kirjoitetaan datakontraktiksi, joka kulkee koodin mukana ja tarkistetaan automaattisesti. Kontrakti versioidaan ja testataan samassa putkessa kuin data. Datakatalogi on näkymä ketjuun, ja määritelmä itse on koodissa. Tavoite on, että käsite pysyy totena, vaikka järjestelmät sen alla vaihtuvat.
Tähän käytämme Data as Software -menetelmää, jossa tietotuotanto tehdään kuten ohjelmisto. Länsi-Uudenmaan hyvinvointialueella datakontraktit määrittelevät ydindatan laatusäännöt ja omistajuuden, ja ne kulkevat koodin mukana kehityksestä tuotantoon. Hyvinvointialueen asiakastarina näyttää, että määritelmän voi viedä koodiin. Mittarikerroksesta ja käsitteiden omistajista tarina ei kerro.
Mitä teemme
| Palvelu | Mitä se tässä tarkoittaa |
|---|---|
| Määrittely | Nimetyt omistajat ja päätösrytmi käsitteille: kuka päättää määritelmästä ja miten muutos hyväksytään |
| Data as Software | Käsite määritellään yhdessä paikassa, datakontrakti kulkee koodin mukana, ja testit ajetaan joka kerta |
| Tietoalusta | Alusta voidaan suunnitella niin, että raportit, rajapinnat ja tekoälyagentit lukevat määritelmät samasta paikasta |
Liittyvät sivut: Tekoäly tuotantokäyttöön · Artikkeli: Tekoäly ei skaalaudu terveydenhuollossa ilman semanttista tietopohjaa
Kenelle
Tietojohtajille, data-arkkitehdeille ja johdon raportoinnista vastaaville hyvinvointialueilla, sairaaloissa ja kansallisissa sosiaali- ja terveydenhuollon organisaatioissa. Aihe on ajankohtainen, kun tietoalustaa rakennetaan raportoinnin rinnalle tai kun tekoälyagentin pitäisi antaa samat luvut kuin johdon raportti.
Asiantuntija: Antti Brunni, toimitusjohtaja
Käydään 30 minuutissa läpi yksi teille tärkeä mittari: missä sen määritelmä on, kuka siitä päättää ja mistä luku syntyy.