Töövõtuleping nr 3-9/5047-6

TIS sündmuspõhise andmevahetuse andmekvaliteedi valideerimise ja kontrollimise lahenduse

väljatöötamine

Lepingu osa viitenumber 306710 004 005 000

Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009770, aadress Pärnu

mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm ja

Nortal AS (edaspidi täitja), registrikood 10391131, aadress Harju maakond, Tallinn, Lasnamäe

linnaosa, Lõõtsa tn 6, 11415, keda esindab volikirja alusel Olga Golubeva,

edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/5047-1 alusel käesoleva

töövõtulepingu (edaspidi leping) alljärgnevas:

1. Lepingu sõlmimise alus ja ese ning dokumendid

1.1. Leping sõlmitakse minikonkursi „TIS sündmuspõhise andmevahetuse andmekvaliteedi

valideerimise ja kontrollimise lahenduse väljatöötamine" (riigihanke viitenumber 315210)

raames esitatud eduka pakkumuse esitanud pakkujaga (Täitja) arendustööde tegemiseks

(edaspidi Tööd), vastavalt Lepingus ja selle lisades toodule.

1.2. Lepingu ese on riigihanke „TIS sündmuspõhise andmevahetuse andmekvaliteedi

valideerimise ja kontrollimise lahenduse väljatöötamine“ alusdokumentides (minikonkursi

viitenumber 315210) olevas tehnilises kirjelduses nimetatud tööd.

1.3. Lepingu dokumendid koosnevad käesolevast Lepingust ja Lepingu lisadest.

1.4. Lepingu tööde maht on maksimaalselt 197 000 (sada üheksakümmend seitse tuhat) eurot

käibemaksuta.

1.5. Lepingu lahutamatuteks lisadeks Lepingu sõlmimise hetkel on:

1.5.1 Lisa 1 Tehniline kirjeldus;

1.5.2 Lisa 2 Tööde üleandmise-vastuvõtmise akti vorm;

1.5.3 Lisa 3 Pakkumus (ei allkirjastata koos lepinguga).

1.6. Lepingut rahastatakse programmist „EST2EHDS“, grandi kood: 9T80-MU21-EST2EHDS.

2. Töö üleandmise ja vastuvõtmise tingimused

2.1. Täitja annab Tehnilise kirjelduses (Lisa 1) punktis 4.1.3 ja 4.2.3 kirjeldatud tööd üle hiljemalt

15.03.2027.

2.2. Täitja annab Tehnilises kirjelduses (Lisa 1) punktis 4.3.3 ja 4.4.4 kirjeldatud tööd üle

hiljemalt 31.03.2027.

2.3. Töötunni põhise lepingu korral esitab täitja eelmise kuu töötundide ajaaruande, mis sisaldab

teostatud töötunde ja nende jooksul teostatud töid. Ajaaruanne esitatakse allkirjastatult

hiljemalt järgmise kalendrikuu 5. tööpäeval. Viimane ajaaruanne esitatakse koos aktiga.

2.4. Tööde tulemused ja vajadusel lepingu täitmise käik dokumenteeritakse ning hallatakse tellija

dokumendihalduskeskkonnas ja/ või koodihalduskeskkonnas (näiteks wiki, gitlab).

2.5. Tarne on hankelepingu alusel teostatud tööde paketina üleandmine, mis on toodangusse

paigaldamiseks korrektselt konfigureeritud ja koodihalduskeskkonda lisatud. Täitja lisab

tarne kirjelduse ja spetsifikatsiooni dokumendihalduskeskkonda. Täitja esitab tarne kohta

tarneteatise, lisades tarnega seotud testimise juhendi ja vastavalt hankelepingule

automaattestid.

2.6. Üleantavad tööd, v.a analüüsitööd, tuleb täitja poolt enne tellijale üle andmist testida,

koostada testiraportid ja testilood.

2.7. Täitja annab tööd üle omalt poolt allkirjastatud aktiga.

2.8. Tellitavad tööd antakse vastuvõtutestimiseks üle vastavalt lepingu tehnilises kirjelduses

kokkulepitud tingimustele.

2.9. Tellija võtab tööd vastu akti allkirjastamisega pärast edukat vastuvõtutestimist.

2.10. Koos töödega antakse üle nõuetekohane dokumentatsioon, kommenteeritud

lähtekood, intellektuaalomandi õigused ja muu hankelepingus kokkulepitu.

2.11. Tööd loetakse nõuetekohaselt teostatuks, kui tööd vastavad hankelepingule,

vastuvõtutestid on vigadeta läbitud ja tööd on aktiga tellija poolt vastu võetud.

2.12. Tellija võib tööd vastu võtta, kui töödes esineb üksikuid ja tellija jaoks väheolulisi

pisivigasid, mis fikseeritakse aktis. Tellija poolne pisivigadega tööde vastuvõtmine ei vabasta

täitjat kohustusest vead kõrvaldada ning üle anda vigadeta tööd. Tellijal määrab mõistliku

tähtaja pisivigade parandamiseks.

2.13. Tellijal on õigus keelduda tööde vastuvõtmisest kui tööd ei vasta esitatud nõuetele või

töödes esineb muid vigu.

2.14. Kui tellija esitab vastuväited töödele, peab täitja tööd parandama tellija poolt

määratud mõistliku tähtaja jooksul. Kui täitja ei ole tellija antud tähtaja jooksul kõrvaldanud

avastatud vigu, võib tellija tööd ise parandada või lasta seda teha kolmandatel isikutel ja nõuda

täitjalt selleks tehtud mõistlike kulutuste hüvitamist tingimusel, et puudused on objektiivselt

tuvastatavad ja nende eest vastutab täitja, tellija vastuväited ja parandamisvajadus on

põhjendatud. Juhul, kui hiljem selgub, et puuduste eest ei vastuta siiski täitja, kannab vastavad

kulud tellija.

2.15. Alates teisest kordustestimisest võib tellija kordustestidega seotud kulutused (tellija

kulutatud tööaeg ja/või tellija testimispartnerite poolt esitatud arvete alusel) täitjalt välja nõuda

või tasaarvestada, kui kordustestimise vajadus oli tingitud puudustest, mille eest vastutab täitja.

3. Vigadest teavitamine ja veaparanduste teostamine

3.1. Tellija teavitab avastatud rakenduse ja tarkvara vigadest täitjat esimesel võimalusel, tehes

kande tööde halduskeskkonda või muul kokkulepitud viisil. Tellija registreerib vea, märkides

võimalusel vea põhjuse, eeldatava vea parandamise tähtaja ning kriitilisuse, märkides lisaks, kui

tegemist on garantiilise tööga ja suunab selle täitjale.

3.2. Täitja võib omalt poolt avastatud vigadest tellijat teavitada, tehes kande tööde

halduskeskkonda. Täitja registreerib vea, märkides võimalusel vea põhjuse, eeldatava vea

parandamise tähtaja ning kriitilisuse, märkides lisaks, kas tegemist on garantiilise tööga ning

suunab selle tellijale. Tellija määrab edasise lahenduse käigu.

3.3. Täitja garanteerib tellijale teenindusajal veakahtluste korral veaallika tuvastamiseks vajaliku

konsultatsiooni.

3.4. Täitja on kohustatud veaparanduse teostama vähima võimaliku aja jooksul.

3.5. Maksimaalsed lahendusajad ja vigade eristamise kriitilisuse astmed:

3.5.1. kriitiline viga – tarkvaral põhinev teenus või süsteem ei toimi ega ole kasutatav.

Näiteks on andmed rikutud; esineb kasutajasessioonide ebanormaalne katkemine; probleem

mõjutab süsteemi käideldavust ja andmete terviklikkust; mõjutatud on enamus tarkvara

kasutajatest; tõsine finantsmõju. Lahendusaeg 8 tundi;

3.5.2. häiriv viga – tarkvaraga seotud probleem ei sega teatavate reservatsioonide järgimisel

igapäevast töötamist; mõjutatud ei ole kõik tarkvara kasutajad; väiksema tähtsusega

funktsionaalsused pole käideldavad, kasutatavad või süsteemi jõudlus on madalamal

maksimaalsest nõudest. Lahendusaeg 16 tundi;

3.5.3. pisiviga - väikesed puudused minimaalse mõjuga tööde kasutajatele või klientidele;

kosmeetilised probleemid (ekraanikomponendid on nihkes, kuid see ei takista komponendi

eesmärgipärast kasutamist); pikaajaline vastukaalu kasutamine kasutajatele vastuvõetav.

Lahendusaeg 40 tundi.

3.6. Kui veaparandus ei ole objektiivsetest asjaoludest tulenevalt võimalik maksimaalse

lahendusaja jooksul, kohustub täitja sellest tellijat informeerima kirjalikku taasesitamist

võimaldavas vormis, näidates ära põhjused, miks veaparandus ei ole nimetatud aja jooksul

võimalik ning esitades töö teostamise tähtaja, mille jooksul täitja on reaalselt võimeline vea

parandama.

3.7. Kui täitja annab vigade parandamise järgselt üle tööd, milles tellija vastuvõtutestimise käigus

esineb jätkuvalt vigu (teistkordne vigadega tööde üleandmine), võib tellija otsustada, kas anda

täitjale uus tähtaeg vigade parandamiseks või kõrvaldada vead ise või kolmanda isiku kaasabil,

vähendades täitjale makstavat tasu võrdeliselt vigade parandamiseks tehtud kulutustega.

4. Lepingu hind ja maksmine

4.1. Lepingu täitmine toimub töötunnipõhisel arvestusel, tellija tasub üksnes lepingu alusel

tellitud ja teostatud töötundide eest.

4.2. Ühe töötunni maksumuseks lepingu täitmisel on 55,39 (viiskümmend viis eurot ja

kolmkümmend üheksa senti.maksumus sõnadega) eurot käibemaksuta.

4.3. Täitja esitab tellijale e-arve igakuiselt. Arvel tuleb märkida riigihanke nimetus, lepingu osa

viitenumber, lepingu number ja kontaktisiku andmed.

5. Poolte vahelised teated ja kontaktisikud

3.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist.

3.2. Tellija kontaktisikuks lepingu täitmisel on Helena Laur, tel +372 7943 900, e-post

[email protected] või tema asendaja.

3.3. Täitja kontaktisikuks lepingu täitmisel on Leila Ong, projektijuht, tel. +372 5141073,

[email protected] või tema asendaja.

Garantii

3.4. Täitja annab hankelepingu alusel teostatud töödele garantii 12 kuud. Garantii hakkab

kehtima hetkest, millal tellija võtab töö toodangukeskkonnas kasutusele. Kui tellija ei võta

tööd toodangukeskkonnas kasutusele 3 kuu möödumisel alates tööde vastuvõtmisest, algab

garantii nimetatud aja möödumisel. Kui arendustöö teostatakse ja võetakse vastu

etappidena, algab lisaks eeltoodule tööle kui tervikule 12-kuuline garantii tervikliku töö

toodangukeskkonnas kasutuselevõtmisest või toodangukeskkonnas kasutusele võtmata

jätmisel 3 kuu möödumisel alates tervikliku töö vastuvõtmisest.

3.5. Garantiiga on hõlmatud kõik garantii tähtaja jooksul tarkvaras ilmnevad vead ja

mittevastavused, mis ei ole tekkinud tellija või kolmandate osapoolte tegevuse tagajärjel.

Garantiiga on hõlmatud ka kõigi tööde muudatused ja modifikatsioonid, mis on tehtud täitja

poolt ja mis ei ole oluliselt muutnud varasemalt tehtud tööd.

3.6. Täitja kõrvaldab garantii kehtivuse ajal töödes avaldunud vead ja mittevastavused tasuta,

sealhulgas uuendab või asendab kõik seonduvad dokumendid.

3.7. Täitja on kohustatud garantii korras teostama eelkõige järgmist:

3.7.1. vea ilmnemisel vea otsimine, lokaliseerimine, veaolukorrale lahenduse leidmine ja vea

parandamine;

3.7.2. vea põhjuste analüüs ja ettepanekute tegemine ennetavate meetmete kasutusele

võtuks kirjalikku taasesitamist võimaldavas vormis;

3.7.3. vea parandamisega seoses paigaldamise ja seadistamise tugi ning sellega seotud

konsultatsioonid.

3.8. Tellija määrab võimalusel, milline on vea kriitilisuse aste või kas tegemist on muu

garantiikohustusega hõlmatud puudusega ning võib määrata vea kõrvaldamiseks tähtaja,

lähtudes hankelepingus fikseeritud vigade kriitilisuse astmetest.

3.9. Reageerimis- ja lahendusaeg hakkab kulgema tellija poolt teate välja saatmise hetkest.

3.10. Kui täitja tõendab, et kõrvaldatud viga ei olnud garantiiga hõlmatud, hüvitab tellija täitja

kantud otsesed kulud seoses nimetatud vea kõrvaldamisega. Kulude hüvitamisel võetakse

aluseks hankelepingus, mille raames teostatud töödes on viga ilmnenud, fikseeritud lepingu

täitmise ühe töötunni hind.

3.11. Tellija tagab täitjale kaasabi garantiikohustuse alla käivate vigade kõrvaldamisel tellija

võimekuse ja võimaluste piires.

3.12. Kui täitja ei suuda vigasid kokkulepitud tähtajaks kõrvaldada, võib tellija nimetatud ise

kõrvaldada või korraldada nende kõrvaldamise kolmanda isiku kaasabil, teavitades sellest

täitjale. Tellijal on õigus täitjalt nõuda kõigi kulutuste hüvitamist, mis tekkisid seoses

eelkirjeldatud viisil vea kõrvaldamisega, kui tegemist oli garantiiga hõlmatud veaga.

3.13. Garantii kaotab kehtivuse, kui tellija muudab lähtekoodi, välja arvatud tööde osale, mida ei

ole muudetud ning tellija suudab eristada lähtekoodis tehtud muudatusi.

4. Lõppsätted

4.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja kehtib kuni lepingu tähtaja

lõpuni või kuni poolte poolt oma lepinguliste kohustuste täitmiseni.

4.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu

muudatustest ja pakkumusest.

5. Poolte allkirjad

Tellija: Täitja:

1

Lisa 1

Tehniline kirjeldus

TIS sündmuspõhise andmevahetuse andmekvaliteedi valideerimise ja kontrollimise

lahenduse väljatöötamine

1. Üldine

Hanke eesmärk on sõlmida töövõtuleping täitjaga, kes hakkab teostama arendus- ja

analüüsitöid TIS sündmuspõhise andmevahetuse andmekvaliteedi valideerimise ja

kontrollimise lahenduse välja töötamiseks.

Lepingut rahastatakse välisvahenditest, programmist „EST2EHDS“, grandi kood: 9T80-MU21-

EST2EHDS.

1.1. Mõisted ja lühendid

Mõisted

 Andmekvaliteedi dimensioon – rahvusvaheliselt standardiseeritud kategooria, mis

kirjeldab andmete spetsiifilist omadust (nt täielikkus, reeglipärasus) ja ühendab äri-

ning tehnilise vaate andmekvaliteedile.

 Esmased andmed (Primary data) – andmed, mis kogutakse otse nende tekkekohas ja

sisestatakse süsteemi esmakordselt; terviseandmete kontekstis kõik, mis on otseselt

seotud patsiendi diagnoosimise ja ravimisega.

 Teisesed andmed (Secondary data) – esmastest andmetest tuletatud, agregeeritud

või muul viisil töödeldud andmed, mida kasutatakse uues kontekstis (nt teadustöö,

statistika, poliitikakujundamine).

 Üleminekuperiood – ajavahemik uue ärireegli kehtestamisest kuni selle täieliku

jõustumiseni, mille jooksul reegli rikkumine ei lükka andmeid tagasi, vaid

tagastatakse hoiatus-tüüpi veateade.

 FHIR ressurss – FHIR standardi väikseim iseseisev andmeühik (nt Patient,

Observation), mille kaudu terviseandmeid struktureeritakse ja vahetatakse.

 FHIR profiil – FHIR baasressursi kitsendus, mis kehtestab konkreetse kasutusjuhtumi

(nt Eesti tervishoiukontekst) jaoks kohustuslikud väljad ja väärtused.

Lühendid

 API (Application Programming Interface) – liides, mille kaudu süsteemid omavahel

andmeid vahetavad.

 CDA (Clinical Document Architecture) – dokumendipõhine terviseandmete

struktureerimise standard, mis on täna TIS-is kasutusel.

 EHDS (European Health Data Space) – Euroopa terviseandmeruum, millega kooskõla

on käesoleva hanke laiem eesmärk.

 FHIR (Fast Healthcare Interoperability Resources) – HL7 poolt väljatöötatud

terviseandmete vahetuse standard, millele TIS üle minemas on.

2

 HL7 (Health Level Seven International) – rahvusvaheline terviseinfo

standardiorganisatsioon, mis haldab muuhulgas FHIR standardit.

 IG (Implementation Guide / juurutusjuhend) – FHIR profiilide ja reeglite masinloetav

tehniline kirjeldus.

 JSON (JavaScript Object Notation) – struktureeritud andmevahetusformaat, mida

kasutatakse muuhulgas FHIR sõnumite esitamiseks.

 MPI (Master Patient Index) – patsiendi üldandmete teenus.

 PoC (Proof of Concept) – kontseptsiooni tõestus; käesoleva hanke aluseks olnud

varasem katseprojekt.

 SJV – seire- ja valideerimismoodul.

 TAI – Tervise Arengu Instituut.

 TEHIK – Tervise ja Heaolu Infosüsteemide Keskus.

 TerK – Tervisekassa.

 TIS – Tervise infosüsteem.

 TTO – tervishoiuteenuse osutaja.

 XML (Extensible Markup Language) – märgistuskeel, millel CDA standard põhineb.

 XSD (XML Schema Definition) – XML-dokumendi struktuuri kirjeldav skeem, mille

alusel toimub CDA valideerimine.

2. Hetkeolukord

Täna toimub Eestis tervishoiuteenuste andmevahetus veel valdavalt dokumendipõhiselt.

Kasutusel on CDA standard, mis on XML-il põhinev standard kliiniliste dokumentide

struktureerimiseks. Tervishoiuteenuse osutajatel on kohustus edastada dokumente tervise

infosüsteemi (TIS) andmekogusse, mida haldab ja arendab TEHIK. Andmete edastamist

reguleerivad Tervishoiuteenuste korraldamise seadus, Tervise infosüsteemi põhimäärus ja

Sotsiaalministri 17. septembri 2008. a määrus nr 53 "Tervise infosüsteemi edastatavate

dokumentide andmekoosseisud ning nende säilitamise tingimused ja kord". Antud

seadusandlikud aktid kohustavad tervishoiuteenuste osutamisel edastama andmeid Tervise

infosüsteemi (allikas).

Andmevahetuse korraldamiseks on TEHIK avaldanud teabekeskuse

lehel andmevahetusvormingud – CDA-l põhinevad detailsed tehnilised juhendid, mis

täpsustavad iga tervisedokumendi tehnilise struktuuri ja sisu.

2.1. CDA dokumentide valideerimine

Dokumentide vastu võtmisel TIS-i on andmekvaliteedi tagamiseks

kehtestatud andmekontrollid, mida rakendatakse osaliselt seire- ja valideerimismoodulis

(SJV) ning osaliselt kesksüsteemis. Valideerimine ei toimu kõigi dokumentide lõikes ühtlaselt

ning kontrollid on kehtestatud ainult väikesele osale dokumentidest. Näiteks ei ole vigaste

dokumentide tagasilükkamist defineeritud hambaravikaardil, mistõttu on väga keeruline

tagada nii sisulist kui ka vormilist hambaravi teenuste toorandmete andmekvaliteeti. Lisaks

on CDA dokumentide valideerimine piiritletud konkreetse dokumendi kontekstiga.

3

Sissetuleva dokumendi puhul ei ole võimalik teostada dokumentide üleseid kontrolle, mis

eeldaksid andmete võrdlemist patsiendi varasemate dokumentidega. Dokumentide üleseid

kontrolle saab teostada vaid tagantjärgi andmelaos, kui andmed on juba vastu võetud ja TIS-

i salvestatud.

Andmekontrollide vähesel rakendamisel on ajalooliselt olnud erinevaid põhjuseid, näiteks on

äriomanikud eelistanud andmehõivet (võetakse vastu maksimaalselt palju andmeid,

sõltumata sellest, kas andmed vastavad kokkulepitud nõuetele) andmekvaliteedile (vastu

võetakse ainult sisuliselt ja vormiliselt korrektsed andmed). Samas tuleb mõista, et ootused

andmekvaliteedile ongi ajas kasvanud ja mitte iseenesest, vaid otsese vastusena tehnoloogia

ja andmekasutuse arengule. Suurenenud on süsteemide ristsõltuvus (viga ühes süsteemis võib

tekitada ahelreaktsiooni, mis võimendub üle kogu ökosüsteemi), automatiseerimise määr

(üha enam otsuseid on vaja teha andmete pealt automaatselt, ilma inimese sekkumiseta),

kasutajate ootused (andmete kvaliteet ja kättesaadavus on otseses sõltuvuses patsientide

usaldusega tervishoiusüsteemi vastu) ning teisese andmekasutuse vajadus.

Dokumendipõhisel andmevahetusel on seega tänases kontekstis erinevaid puudujääke. Sageli

ei ole andmed piisavalt hästi struktureeritud: vabateksti väljadele sisestatakse erinevat

infot, mõnikord ka tundlikke isikuandmeid, mistõttu seda on keeruline analüüsida ja

masintöödelda. Kuna TTO-del on kasutusel erineva ülesehitusega infosüsteemid, siis ei

pruugi erinevatelt TTO-delt pärinev info omavahel ühilduda, paratamatult tekivad

arusaamatused andmete tõlgendamisel. Ka andmete uuendamine on keerukas, kuna iga

muudatuse jaoks tuleb luua uus dokument. (allikas: Sündmuspõhise andmevahetuse

dokumenteerimise analüüs). Esineb andmete dubleerimist, kuna erinevad teenusepakkujad

võivad edastada andmeid osaliselt kattuvate dokumentidena. Andmed võivad jääda TTO

infosüsteemi "kinni", kuna avatud dokumenti ei saadeta TIS-i kohe, vaid mõnikord alles

haigusjuhtumi lõppedes, mis võib võtta kuid või isegi aastaid. Seetõttu võib jääda kriitiline

informatsioon patsiendi kohta teistele tervishoiuasutustele kättesaamatuks, mis võib

omakorda viia valede raviotsusteni. Taolistele andmekvaliteedi probleemidele on

tähelepanu juhtinud ka 2025. aasta riigikontrolli audit. Seega võib kokkuvõtlikult öelda, et

senine dokumendipõhine andmevahetus ei ole enam piisav tänapäevaste andmevajaduste

rahuldamiseks ning ei võimalda ka piisavalt keerukat andmete valideerimist.

4

2.2. FHIR andmevahetusstandardi kasutuselevõtt

Eesti tervishoiu digitaalseks kaasajastamiseks ning andmete liikumise ja kättesaadavuse

parandamiseks on riiklikult otsustatud üle minna rahvusvahelisele andmevahetusstandardile

HL7 FHIR. Uue standardi kasutuselevõtt aitab lihtsustada tervishoiutöötajate

dokumenteerimiskoormust ning tagada reaalajalähedane ja turvaline andmevahetus

erinevate süsteemide vahel. Erinevalt dokumendipõhisest CDA standardist käsitleb FHIR

terviseandmeid väikeste, iseseisvate ja omavahel seostatud ressurssidena (nt Patient,

Observation). See lähenemine võimaldab andmeid valideerida ja uuendada granuleeritud

tasemel ja reaalajas või reaalajalähedaselt, mis on andmete kvaliteedi ja kättesaadavuse

seisukohalt fundamentaalne muutus paremuse poole.

Täna on juba mitmed uued FHIR standardil põhinevad teenused TEHIKus loomisel. Esimene

TTO-de jaoks kasutusvalmis FHIR standardil põhinev teenus on patsiendi üldandmete teenus

(MPI), mis toob kõik patsiendi kohta käivad ja erinevates registrites sisalduvad üldandmed

(sh haridustase, eestkoste, hooldusõigus, töövõime, puudeinfo jne) ühte teenusesse kokku.

See teenus tagab, et kõik osapooled kasutavad alati kõige ajakohasemat ja kvaliteetsemat

infot.

Euroopa terviseandmeruumi määrus (EHDS) seab liikmesriikidele eesmärgi tagada turvaline

ja standardiseeritud ligipääs terviseandmetele nii kvaliteetsemate piiriüleste

tervishoiuteenuste pakkumiseks (esmane andmekasutus) kui ka teadusuuringuteks ja

poliitikakujundamiseks (teisene andmekasutus). FHIR on kujunenud Euroopa Liidus

peamiseks tehniliseks standardiks, mille abil EHDS-i eesmärke ellu viia. See tähendab, et

Eesti üleminek FHIR-ile ei ole mitte ainult kohalik kaasajastamine, vaid ka strateegiline

samm, mis tagab meie valmisoleku piiriüleseks koostööks ja osalemiseks üleeuroopalises

terviseandmeruumis. Nende eesmärkide saavutamise ja piiriülese koostöö aluseks on

süsteemne, mõõdetav ja standarditele vastav andmekvaliteet.

2.3. Andmekvaliteet kui mõõdetav eesmärk

Andmekvaliteet on määr, mille ulatuses andmete olemasolevad omadused vastavad

nõudmistele (ISO 8000-2). Ainuüksi uue standardi kasutuselevõtt ei taga automaatselt

paremat andmekvaliteeti. Kvaliteedi süstemaatiliseks tagamiseks ja pidevaks parendamiseks

on vaja luua raamistik, mis muudab andmekvaliteedi mõõdetavaks ja halduse läbipaistvaks.

Selle saavutamiseks tugineme uutes FHIR teenustes rahvusvaheliste parimate praktikate

põhjal kokku pandud riiklikule andmekvaliteedi juhisele ning järgime Quantumi projekti

tulemeid. Meie andmekvaliteedi haldamise ja seire strateegia tugineb standardiseeritud

andmekoosseisule (FHIR profiilid), dünaamilistele ärireeglitele ning andmekvaliteedi

mõõdikutele. Soovime luua süsteemi, mis võimaldaks erinevate teenuste andmekvaliteeti

pidevalt seirata ja võrrelda, anda äriomanikele sisulist tagasisidet teenuste toimimise kohta

ning viia ellu sihistatud parendustegevusi.

Selle asemel, et hinnata andmeid abstraktsel skaalal "head või halvad", kasutatakse

andmekvaliteedi süstemaatiliseks juhtimiseks ja mõõtmiseks andmekvaliteedi dimensioone.

Dimensioonid on rahvusvaheliselt standardiseeritud kategooriad või vaatenurgad, mis

kirjeldavad andmete spetsiifilisi omadusi – näiteks kas andmed on esitatud (Täielikkus) ning

kas need vastavad kokkulepitud formaadile (Reeglipärasus). Dimensioonid toimivad ühise

keelena äripoole, kes tunnetab eesmärke ja probleeme, ning IT-poole, kes realiseerib

tehnilised reeglid, vahel. Sidudes iga tehnilise valideerimisreegli konkreetse dimensiooniga,

saame rutiinsetest vealogidest luua arusaadavaid ja juhtimisotsuseid toetavaid mõõdikuid.

Dimensioone on võimalik rakendada ka proaktiivselt juba andmete süsteemi sisenemise

5

hetkel. See tähendab, et strateegilised andmekvaliteedi dimensioonid "tõlgitakse"

operatiivseteks, masinloetavateks reegliteks (nt kardinaalsuse nõue tagab täielikkuse,

terminoloogia kontroll tagab semantilise täpsuse).

2.3.1. Reeglite juurutamine

Ärireeglitel põhineva valideerimissüsteemi strateegiline eesmärk on luua kohanduv ja ajas

arenev süsteem, mitte staatiline reeglite kogum. Tervishoiu nõuded, kliinilised praktikad ja

äriloogika muutuvad pidevalt. Meie süsteem peab suutma nende muutustega sujuvalt ja

kontrollitult kaasas käia, tagades samal ajal teenuse stabiilsuse ja TTO-de sujuva töö. Selle

saavutamiseks on kriitilise tähtsusega nii äri- kui andmekvaliteedi reeglite elutsükli haldus,

mis võimaldab meil reegleid ajas jälgida, versioonida ja kontrollitult juurutada. Tulevikus

on plaanis selle protsessi toetamiseks kasutusele võtta spetsialiseeritud haldustööriist (nt

andmekataloog või andmekvaliteedi platvorm).

Uute ärireeglite kasutuselevõtt ei tohi olla järsk ja partneritele ootamatu. Selleks plaanime

rakendada standardiseeritud juurutamisprotsessi, mis tagab sujuva ülemineku. Kui äriomanik

otsustab kehtestada uue ärireegli, teavitatakse kõiki TTO-sid ja tarkvarapartnereid sellest

muudatusest piisava ajavaruga. Enne reegli täielikku jõustamist

rakendame üleminekuperioodi. Selle perioodi vältel käitub valideerimissüsteem järgmiselt:

 Reegli rikkumine ei lükka andmeid tagasi. Andmed võetakse vastu, et tagada teenuse

katkematus.

 Andmeid saatvale süsteemile tagastatakse hoiatus-tüüpi veateade. See annab TTO-

dele signaali, et nende andmed ei vasta peagi jõustuvale nõudele.

 Kõik hoiatused logitakse kesksesse vealogide süsteemi, mis võimaldab meil

monitoorida, kui paljud partnerid uue reegli kasutusele võtnud on ja kes vajavad

täiendavat tuge. Logide seiramine üleminekuperioodil võiks tulevikus moodustada

esmaste andmekvaliteedi mõõdikute olulise osa.

2.3.2. Esmase ja teisese andmekvaliteedi eristamine

Esmased andmed (Primary data) on andmed, mis kogutakse otse nende tekkekohas ja

sisestatakse süsteemi esmakordselt. Need on toorandmed otse allikast. Terviseandmete

kontekstis mõistame esmase kasutusena kõike, mis on otseselt seotud patsiendi

diagnoosimise ja terviseprobleemide lahendamisega täna ja tulevikus. Seega mõistame

esmase andmekasutusena mitte ainult andmete sisestamist, vaid ka seda, kui üks TTO

asutuses A kasutab patsiendi ravimiseks andmeid, mida on sisestanud teine TTO asutuses B.

Teisesed andmed (Secondary data) on andmed, mis on tuletatud, kopeeritud, agregeeritud

või muul viisil töödeldud esmastest andmetest. Need on andmed, mida kasutatakse uues

kontekstis, sageli eemal nende algsest tekkekohast. See hõlmab teadustööd,

poliitikajuhtimist, rahvatervise seiret, statistikat, kvaliteedijuhtimist, teenuste

planeerimist, arveldamist, õppetööks kasutamist jne. Siin ei ole fookus enam üksikul

patsiendil, vaid patsientide grupil või populatsioonil. Terviseandmed teiseseks kasutuseks on

enamasti agregeeritud ja anonümiseeritud.

Teisene andmekvaliteet ei saa olla parem kui esmane. Viga, mis tehakse andmete

sisestamisel, kandub edasi ja sageli võimendub teisesel kasutusel, kallutades statistikat ja

uuringute tulemusi. Käesolev projekt keskendub esmase andmekvaliteedi tagamisele

toorandmete vastuvõtmisel, mõistes, et see on kõige olulisem investeering kogu andmete

väärtusahela kvaliteeti. Kuigi andmelaos saab teostada teatud andmete puhastamist, ei ole

seal võimalik parandada äriloogika vigu, mis on algandmete vastuvõtmisel kontrollimata

jäänud. Luues toorandmetele ranged ja mõõdetavad filtrid juba nende vastu võtmisel,

6

tagame, et teisese andmekasutuse projektid (nagu Quantum) toimivad tehniliselt

usaldusväärsel vundamendil.

2.4. Andmekvaliteedi tagamine Tervise infosüsteemis

2.4.1. Tänane olukord FHIR teenuste valideerimisel

FHIR profiilid koos nende ümber konteksti loovate juurutusjuhenditega moodustavadki juba

andmekvaliteedi peamised nõuded/baasreeglistiku. Käesolevas etapis on vaja jõuda

lahenduste ja kokkulepeteni, et kõigis teenustes toimuks TIS-i vastu võetavate andmete

profiilide vastu valideerimine ühistel alustel, mis muudaks andmekvaliteedi võrreldavaks ja

mõõdetavaks. Praegu puudub ühtne lahendus, mis tagaks, et kõik teenused valideerivad

FHIR standardis TIS-i saadetavaid sõnumeid FHIR profiilide vastu ühtsete reeglite alusel. See

viib ebajärjepideva andmekvaliteedi, dubleeritud arendustöö ja raskesti hallatava

veakäsitluseni ning puudub teenuste ülene vaade andmekvaliteedi reeglitele ja vigadele.

Andmehõive ning andmekvaliteedi mõõtmine ja partneritele ühtse tagasiside andmine on

raskendatud. Profiilide valideerimine peaks olema peamine ja kõige kuluefektiivsem kiht

semantilise koostöövõime ja andmete baaskvaliteedi tagamiseks.

Terminoloogia kasutamise ja valideerimise põhiliseks tööriistaks on TEHIKu

terminoloogiaserver, kuid siingi puuduvad teenuste ülesed kokkulepped, kuidas

valideerimine vastu terminoloogiaserverit toimub. Lisaks on olemas väliste registrite

loendid, mida ei ole terminoloogiaserverisse toodud, kuid mida upTIS teenustes kasutatakse.

Äriloogikat valideeritakse igas mikroteenuses eraldi ning äriloogilised kontrollid on

kirjutatud teenuste lähtekoodi. Selline lahendus ei ole jätkusuutlik, kuna ärireeglite

dokumenteerimine on ebaühtlane, puudub võimalus erinevate reeglite vastu eksimist

võrreldavaks ja mõõdetavaks muuta, reeglites muudatuste tegemine nõuab teenuse

lähtekoodi muutmist, mis võib tähendada katkestusi teenuse toimimises. Selle olukorra

parandamiseks oleme läbi viinud turu-uuringu erinevate valideerimistööriistade kohta ning

seejärel ärireeglite valideerimise PoC-i (Proof of Concept), mille raames katsetasime läbi

erinevaid äriloogilisi reegleid ja nende valideerimist ühe teenuse sees ja erinevate teenuste

vahel.

Veakäsitlus ja logimine. Uue teenuse loomisel dokumenteeritakse süsteemianalüüsi etapis

teenuse veakoodid ja veateated, kuid puudub selge eristus andmekvaliteedi vigade ja

tehniliste/autoriseerimise jm vigade vahel. Vigade raskusastmete kasutamisele pole tehtud

läbivaid kokkuleppeid. See peegeldub ka vealogides, kus hetkel ei ole võimalik

andmekvaliteedi vigu muudest vigadest selgelt eristada ega kategoriseerida.

2.4.2. Andmevahetusstandardite võrreldavus

Kontseptuaalselt on andmekvaliteedi tasemed CDA ja FHIR-i standardite puhul sarnased.

Mõlemad järgivad sama loogikat: alustatakse tehnilisest vundamendist ja liigutakse kihiti

ülespoole sisulise ja ärilise loogika poole. Ühe käsitlusena võib välja tuua kolm taset:

Tase 1: FHIR standardi valideerimine: kas ressurss vastab FHIR baasstandardi

spetsifikatsioonile? (CDA-s võrreldav schema valideerimisega).

Tase 2: Profiili valideerimine: kas sõnumi struktuur ja sisu vastab FHIR profiilile, mis on FHIR

baasstandardi põhjal Eesti konteksti ja kasutusjuhu jaoks kohandatud? (CDA-s võrreldav

schematroni ja loendite kasutamise valideerimisega).

7

Tase 3: Ärireeglite valideerimine: kas sõnum vastab äriloogikale? Äriloogika võib olla ühe

ressursi põhine või hõlmata ka mitut erinevat ressurssi. (CDA-s osaliselt lahendatud

schematroni valideerimisega, kuid ärireeglite rakendamine piirdub ühe dokumendi siseste

kontrollidega – puudub võimalus valideerida vastu olemasolevaid andmeid teistes

dokumentides).

Siiski tuleb arvesse võtta CDA ja FHIR standardite valideerimisel tehnilisi ja semantilisi

erinevusi. CDA vead (põhinedes XSD ja Schematroni valideerimistel) on dokumendikesksed,

samas kui FHIR-i vead (OperationOutcome) on ressursikesksed ja granuleeritumad. Ka CDA

ja FHIR-i vealogide otsene võrdlemine võib olla eksitav ja ei anna terviklikku pilti, takistades

süsteemsete, tehnoloogiast sõltumatute andmekvaliteedi probleemide tuvastamist.

3. Hankelepingu eesmärk ja ese

Hankelepingu eesmärk on tellida täitjalt analüüsi- ja arendustöid, mille tulemusel valmib

lahendus sündmuspõhise andmevahetuse korras Tervise infosüsteemi saadetud sõnumite

valideerimiseks ja kontrollimiseks. Tellija ja täitja koostöös töötatakse välja

andmekvaliteedi valideerimisega seotud veakäsitluse, logimise, monitooringu ja reeglite

avaldamise põhimõtted.

4. Tellitavad tööd

Hankelepingu raames tellitakse tööd neljas etapis. Kõikide etappide töid saab teostada

paralleelselt.

4.1. Sõnumite valideerimine vastu FHIR baasstandardit ja kehtestatud FHIR profiile

Töö teostajal tuleb läbi viia süsteemianalüüs ning selle järgselt realiseerida arendustööd,

mille tulemusel valmib FHIR andmevahetusstandardil Tervise infosüsteemi edastatud

sõnumite kontrollimise ja valideerimise lahendus, mis valideerib sõnumid FHIR baasstandardi

ja kehtestatud FHIR profiilide vastu.

Varasemalt läbi viidud kontseptsiooni tõestuse (Proof of Concept, PoC) projekti raames loodi

ja testiti Java.põhise andmekvaliteedi reeglite valideerimise lahendust, mis võimaldab

valideerimist FHIR ressursi tüübi alusel, kasutab reeglimootorit ning tagastab vead FHIR

OperationOutcome kujul. Loodav lahendus peab võtma arvesse PoC raames testitud

valideerimise lahendust, selle tulemeid ja järeldusi. Proof of Concept dokumentatsioon on

kättesaadav TEHIKu wiki keskkonnas: FHIR andmekvaliteedi valideerimise PoC

4.1.1. Nõuded lahendusele

Esmalt kontrollitakse, et TIS-i saadetavad FHIR ressursid vastaksid rahvusvahelisele FHIR

baasstandardile. Süsteem peab lükkama tagasi kõik ressursid, mis ei vasta FHIR

põhistruktuurile (nt vigane JSON/XML). Edasisele valideerimisele suunatakse ainult

tehniliselt korrektsed ressursid.

Järgnevalt valideeritakse ressursid vastu kehtestatud FHIR profiile. Kõik sissetulevad

ressursid peavad olema tehniliselt ja süntaktiliselt korrektsed. Profiilide vastu valideerimisel

tuleb eristada kaht mõõdet: milline reegel rikuti (veatüüp) ja kus rikkumine paikneb (vea

kontekst). Iga logikirje peab võimaldama mõlemat mõõdet eraldi agregeerida nii ühe teenuse

kui teenuste ülesel tasandil.

Profiilide valideerimisel peab olema võimalik tuvastada vigane andmeväli, vajadusel

tagastada kasutajale veateade ning vigade esinemisel logida viga maha selgelt eristataval

8

kujul, mis sisaldab infot veatüübi, seotud andmevälja, vea raskusastme ja muude vajalike

parameetrite kohta koos kõigi vajalike metaandmetega nagu näiteks andmete edastamiseks

kasutatava tarkvara nimetus ja tarkvara versioon.

Tervishoiutöötaja peab alati saama teada, kas andmed võeti TIS-i vastu või mitte – sõltumata

sellest, kas viga on tema poolt parandatav, või on tegemist tarkvara veaga.

Süsteemianalüüsi käigus kooskõlastatakse täitja poolt TTO-dega tingimused, millele peab

vastama vigade arusaadav ehk inimloetav kuju. TTO-dega kooskõlastuse töörühma valmistab

ette tellija.

Veatüübid

Eristada tuleb vähemalt järgmisi veatüüpe:

 Kohustuslikkuse valideerimisel

o kontrollitakse, kas kohustuslik andmeväli on täidetud;

o valideerimise ebaõnnestumisel tagastatakse kasutajale arusaadav veateade

ning logidesse tekib kirje, mis on eristatav kohustuslikkuse veana.

 Kardinaalsuse valideerimisel

o kontrollitakse, kas andmevälja kordsus on lubatud vahemikus (miinimum- ja

maksimumkordsus)

o valideerimise ebaõnnestumisel tagastatakse kasutajale arusaadav veateade

ning logidesse tekib kirje, mis on eristatav kardinaalsuse veana.

 Andmetüüpide valideerimisel

o kontrollitakse, kas kasutatud on õiget andmetüüpi;

o valideerimise ebaõnnestumisel tagastatakse kasutajale arusaadav veateade

ning logidesse tekib kirje, mis on eristatav andmetüübi veana.´

 Fikseeritud väärtuste valideerimisel

o kontrollitakse, kas väli sisaldab profiilis sätestatud fikseeritud väärtust;

o valideerimise ebaõnnestumisel tagastatakse kasutajale arusaadav veateade

ning logidesse tekib kirje, mis on eristatav fikseeritud väärtuse veana.

 Loendite (terminoloogia) valideerimisel

o peab olema võimalik kontrollida, kas on kasutatud õiget loendit;

o peab olema võimalik kontrollida, kas väärtus sisaldub loendi kehtivas

versioonis;

o peab olema võimalik kontrollida koodi ja nimetuse omavahelist kooskõla.

Analüüs peab sealjuures arvestama, et ühele koodile võib olla määratud mitu

kehtivat nimetust (nt sünonüümid), ning kirjeldama, millistel juhtudel ja

tasanditel kooskõla kontrollitakse (nt koodi ja ühe nimetuse vastavus/koodi

ja nimetuse vastavus lubatud nimetuste hulgast/ainult koodi valideerimine)

ning tooma välja, kuidas erinevad kasutusjuhud mõjutavad süsteemi

käitumist.

o valideerimise ebaõnnestumisel tagastatakse kasutajale arusaadav veateade

ning logidesse tekib kirje, mis on eristatav terminoloogia veana.

o dokumenteerida tuleb, kuidas valideeritakse ja millisel kujul tagastatakse

kasutajale veateade:

 TEHIKu terminoloogiaserveri loendite vastu;

 FHIR-standardi siseste loendite vastu;

 kuidas lahendada võimalikud erijuhtumid nagu samal ajal kehtivad

koodide versioonid jm

9

Juhul kui töö käigus tuvastatakse selliseid veatüüpe või olemasolevate veatüüpide

alamjuhte, mida ülaltoodud nimekirjas ei ole, kuid mis on andmekvaliteedi vaatest olulised,

tuleb need eristatavana välja tuua ja kirjeldada.

Vigade asukoht struktuuris

Sama veatüüp (nt kardinaalsus või terminoloogia) võib tekkida struktuuri eri kohtades, nii

ressursi enda väljal kui ka sügavamal, näiteks laiendi või korduva andmeelemendi sees.

Selleks et vigu oleks võimalik üles leida ja logides eristada, tuleb logida ka vea asukoht

struktuuris. See võimaldab agregeerida vigu ka asukoha põhjal.

Eristada tuleb näiteks, aga mitte ainult:

 Tavalist andmevälja (viga ressursi otseses elemendis);

 Laiendi viga (extension ehk viga laiendi sees, sh olukord, kus kasutatud on tundmatut

või lubamatut laiendit);

 Korduva andmeelemendi alamkirjet (viga on slice'i konkreetses kirjes, sh olukord,

kus kirjet ei ole võimalik ühtegi määratletud alamkirjesse paigutada);

 Viidatud profiili viga (viga on delegeeritud alamprofiili või viidatud ressursi

sihtprofiilis).

Juhul kui töö käigus tuvastatakse selliseid vea asukohti struktuuris või nende alamjuhte,

mida ülaltoodud loendis ei ole, kuid mis on andmekvaliteedi vaatest olulised, tuleb need

eristatavana välja tuua ja kirjeldada.

Invariantide ehk FHIRpath reeglite realiseerimine

Invariantide valideerimisel

 peab olema võimalik hinnata profiilis määratud FHIRpath-invariante konkreetse

ressursi suhtes ning tõlgendada tulemust kolmeväärtuselise loogika alusel

(true/false/empty).

 valideerimise ebaõnnestumisel tagastatakse kasutajale arusaadav veateade ning

logidesse tekib kirje, mis on eristatav FHIRPath-invariandi veana. Dokumenteerida

tuleb, kuidas valideerimine toimub ja millisel kujul veateade kasutajale

tagastatakse.

4.1.2. Töö tulemid

Läbi on viidud ja dokumenteeritud süsteemianalüüs, mille raames täpsustatud arenduse

tehniline lahendus ning kooskõlastatud TTO-dega veateadete inimloetav kuju ja API

täiendused veateadete tagastamiseks.

Arendustööde tulemusel on valminud ja üle antud tehniline lahendus, millega ühtlustatakse

FHIR sõnumite valideerimine FHIR serveris, ning selle kohta käiv dokumentatsioon.

Teostatud on kuni 6 andmevälja ulatuses API täiendusi ning üle antud sellega seonduv

dokumentatsioon.

Välja arendatud FHIR sõnumite valideerimise lahendus on implementeeritud neljas FHIR

teenuses: allergiaandmete teenus, patsiendi üldandmete teenus, patsiendi elulõpu

tahteavaldus, tervishoiutöötaja ja -asutus (sh analüüsi-, arendus- ja dokumenteerimistööd

kirjeldatud teenustes).

4.1.3. Tööde üleandmine

Punktis 4.1.2 kirjeldatud süsteemianalüüs on valminud ja üle antud hiljemalt 14.12.2026

10

Punktid 4.1.2 kirjeldatud tulemite lõplik üleandmise tähtaeg on 15.03.2027.

Tööde üleandmisele järgneb tellija poolt tööde vastuvõtmise aeg ning vajadusel täitja poolt

paranduste teostamine, kui ilmneb, et tööd ei ole teostatud nõuetekohaselt. Paranduste

tegemisel lähtutakse hankelepingus sätestatud tingimustest.

Täitjal on vajadusel kohustus lepingu perioodil tutvustada tehtud arendusi tellija poolt

korraldatud koosolekutel või üritustel

4.1.4. Projektiplaan

Käesoleva töö läbiviimiseks esitab pakkuja projektiplaani, milles näidatakse arendustsüklite

põhiselt ära teostatavad tööd, tööde ajaline kestus ning tööde maht. Arvestada tuleb, et

pakkumusega esitatav projektiplaan on hinnanguline ja ei ole siduv. Projektiplaan

vaadatakse koostöös arendajaga enne tööde alustamist üle ning kinnitatakse kirjalikku

taasesitamist võimaldavas vormis. Poolte kokkuleppel võib arendustööde käigus tulenevalt

agiilse arenduse põhimõtetest projektiplaanis toodud tegevuste järjestuses (ja sellest

tulenevalt ka vaheetappide töömahus) teha muudatusi, kui see ei mõjuta lepingu eesmärgi

täitmist ning lõpptähtaega. Projektiplaani sellised muudatused ei ole hankelepingu

muudatused, kui sellest ei muutu hankelepingu punktis 2.1 toodud projekti lõpptähtaeg ning

minikonkursi alusdokumentides ja tehnilises kirjelduses soovitud saavutatav eesmärk. Tööde

akteerimine ja arveldamine toimub arendustsüklite alusel.

Arendus-

tsükkel

Töö sisu Tsükli kestus

(kuud)

Töömaht (tundides)

4.2. Sõnumite valideerimine vastu ärireegleid jõustavaid andmekvaliteedi reegleid

Tööde teostajal tuleb läbi viia süsteemianalüüs ning selle järgselt realiseerida arendustööd,

mille tulemusel valmib FHIR andmevahetusstandardil TIS-i edastatud sõnumite kontrollimise

ja valideerimise lahendus, mis valideerib sõnumeid ärireeglitest tulenevate andmekvaliteedi

reeglite vastu.

Loodud tehniline lahendus tuleb juurutada kahes kuni neljas teenuses (täpsustatakse

tellijaga koostöös tööde käigus).

4.2.1. Nõuded lahendusele

Eelnevalt läbiviidud PoC katsetas Java-põhise reeglimootori võimekust rakendada keerulisi,

ressursiüleseid ja kontekstipõhiseid ärireegleid sissetulevatele FHIR-sõnumitele. Loodava

toodangulahenduse süsteemianalüüsi ja arendustööde raames tuleb võtta arvesse FHIR Java

validaatori arhitektuuri, kuid lahendust võib vajadusel kohandada, kui see on tehniliselt või

äriliselt põhjendatud. Oluline on skaleeritavus ning arhitektuurse jätkusuutlikkuse

11

tagamine. Proof of Concept dokumentatsioon on kättesaadav TEHIKu wiki keskkonnas: FHIR

andmekvaliteedi valideerimise PoC

Andmevoog

 Modelleerida tuleb FHIR andmete valideerimise elustsükkel: andmete liikumine

alates süsteemi jõudmisest, läbi FHIR struktuurivalidaatori ja äriloogika validaatori

kuni lõpptulemuse tagastamiseni ja logimiseni.

 Lahendada tuleb teenuste ja ristsõltuvuste haldus: pöördumine teiste mikroteenuste

või väliste komponentide poole ning mõõta erinevaid parameetreid (nt

ressursimahukus, aeg, vead). Ebaõnnestumiste korral defineerida arusaadavad

veateated.

Tehniline arhitektuur ja jõudlus

 Arhitektuurimudeli loomine: koostada tuleb lahenduse tehnilise arhitektuuri joonis,

mis visualiseerib süsteemi loogilised kihid ja nende omavahelised seosed.

 Lahendus peab olema optimaalselt modulaarne. Uute äri- ja andmekvaliteedi reeglite

lisamine, muutmine ning arhiveerimine peab olema teostatav teenuse tööd

katkestamata ja valideerimismootori tuumikloogikat muutmata.

 Päringute ressursikasutuse analüüs, vahemälu kasutamise vajaduse ja asünkroonsete

päringute rakendamise vajaduse välja selgitamine ja rakendamine süsteemis.

Ärireeglite elutsükkel

 Tehniline lahendus peab toetama ärireeglite ja andmekvaliteedi reeglite süsteemi

ärilist ülesehitust, kuid vajadusel võib pakkuda ka süsteemi kohandusi, kui töö käigus

peaks selguma vajadusi (nt seni ettenägematuid sõltuvusi või piiranguid) ärilise

ülesehituse muutmiseks.

 Tehniline lahendus peab toetama uute reeglite sujuvat juurutamist ja

üleminekuperioodide haldust.

Piloot-teenustes juurutamine ja testimine

 Lahendus tuleb juurutada ning läbi testida kahes kuni neljas piloot-teenuses. Sobivad

teenused lepitakse töö käigus kokku koostöös tellijaga.

o Piloot-teenuste ärireeglite ja andmekvaliteedi reeglite kaardistamine ja

dokumenteerimine malli alusel (Andmekvaliteedi reeglite implementeerimise

protsess)

o Realiseerida ärireeglite ja andmekvaliteedi reeglite valideerimine teenustes.

Invariantide ehk FHIRpath reeglite käsitlemine

Süsteemianalüüsi käigus peab käsitlema invariantide kasutamist ning hindama, kas see

sobitub ülejäänud valideerimissüsteemiga, st kas invariantide rikkumisi saab logida sama

eristatavuse tasemega (veatüüp, andmeväli, raskusaste jm) ja veateateid tagastada sama

inimmõistetavalt kui teiste veatüüpide puhul. Kuna invariandid võimaldavad profiilis

rakendada lihtsamat, ühe profiili põhist äriloogikat, peab analüüs andma soovituse, millal

invariandi kasutamine profiilis on õigustatud ja millal tuleks sama loogika rakendamine viia

pigem äriloogika validaatorisse. Soovitus võib käsitleda muuhulgas:

 logimise ja veateadete ühtsust (kas invariandi viga on kasutajale sama arusaadav kui

muud veatüübid);

 hallatavust (kus reeglit on lihtsam muuta ja versioonida);

 jõudlust (kas invariandi valideerimine vs eraldi äriloogika kontroll on ressursikulu

poolest erinev)

4.2.2. Töö tulemid

12

Läbi on viidud ja dokumenteeritud süsteemianalüüs, mille raames täpsustatud arenduse

tehniline lahendus.

Süsteemianalüüsi käigus on võrreldud FHIRpath invariante ärireeglite realisatsiooniga,

dokumenteeritud järeldused ja soovitused.

Arendustööde tulemusel on valminud ja üle antud tehniline lahendus, millega luuakse

ärireegleid jõustavate andmekvaliteedi reeglite valideerimise lahendus, ning selle kohta käib

dokumentatsioon.

Loodud lahendus on implementeeritud kahes kuni neljas teenuses (kooskõlastatakse tellijaga

tööde käigus).

4.2.3. Tööde üleandmine

Punktis 4.2.2 kirjeldatud tulemite lõplik üleandmise tähtaeg on 15.03.2027

Tööd teostatakse tunnipõhisel arvestusel.

Tööde üleandmisele järgneb tellija poolt tööde vastuvõtmise aeg ning vajadusel täitja poolt

paranduste teostamine, kui ilmneb, et tööd ei ole teostatud nõuetekohaselt. Paranduste

tegemisel lähtutakse hankelepingus sätestatud tingimustest.

Täitjal on vajadusel kohustus lepingu perioodil tutvustada tehtud arendusi tellija poolt

korraldatud koosolekutel või üritustel

4.2.4. Projektiplaan

Käesoleva töö läbiviimiseks esitab pakkuja projektiplaani, milles näidatakse arendustsüklite

põhiselt ära teostatavad tööd, tööde ajaline kestus ning tööde maht. Arvestada tuleb, et

pakkumusega esitatav projektiplaan on hinnanguline ja ei ole siduv. Projektiplaan

vaadatakse koostöös arendajaga enne tööde alustamist üle ning kinnitatakse kirjalikku

taasesitamist võimaldavas vormis. Poolte kokkuleppel võib arendustööde käigus tulenevalt

agiilse arenduse põhimõtetest projektiplaanis toodud tegevuste järjestuses (ja sellest

tulenevalt ka vaheetappide töömahus) teha muudatusi, kui see ei mõjuta lepingu eesmärgi

täitmist ning lõpptähtaega. Projektiplaani sellised muudatused ei ole hankelepingu

muudatused, kui sellest ei muutu hankelepingu punktis 2.2 toodud projekti lõpptähtaeg ning

minikonkursi alusdokumentides ja tehnilises kirjelduses soovitud saavutatav eesmärk. Tööde

akteerimine ja arveldamine toimub arendustsüklite alusel.

Arendus-

tsükkel

Töö sisu Tsükli kestus

(kuud)

Töömaht (tundides)

4.3. Veakäsitlus, logimine ja monitooring

Eesmärk on defineerida terviklik, standardiseeritud ja auditeeritav dokumentatsioon FHIR-

andmevahetuse veakäsitluseks ja logimiseks. Dokumentatsioon tagab, et kõik vead saavad

13

selgelt kategoriseeritud, suunatud õigele osapoolele parandamiseks ning nende elutsükkel

on jälgitav. Lisaks tuleb luua kuluefektiivne logimise strateegia, mis võimaldab teostada

andmekvaliteedi analüütikat ilma süsteemi üle koormamata.

Veakäsitluse eeltöö on dokumenteeritud PoC: Andmekvaliteedi reeglite

valideerimistulemused

4.3.1. Töö raames käsitletavad teemad

Üldine vigade semantika ja kategoriseerimine

Dokumenteerimisel tuleb hakata eristama andmevigu süsteemi vigadest. Vigade kataloogis

tuleb tekitada selge eristus andmekvaliteedi vigade, süsteemi vigade, autoriseerimise vigade

vahel, ning luua tuleb seda jõustav tehniline lahendus. Ühtlasi tähendab see eristust, millisel

juhul saab TTO veateate ja millisel juhul on mõeldud info arendajale (võivad ka kattuda).

Näide:

"Eesti isikukood peab olema 11-kohaline" – on andmekvaliteedi nõue, mis on inimloetav ja

andmete sisestajale mõistetav, parandatav (andmekvaliteedi viga).

"Päringus puudub päis 'x-road-id" – ei ole andmete sisestajale mõistetav ega parandatav

(tehniline viga).

Andmekvaliteedi vigade kategoriseerimine

Eristada tuleb

 andmekvaliteedi vigade raskusastmeid ning luua täpsustav dokumentatsioon selle

kohta, mis juhtudel milliseid raskusastmeid kasutatakse.

 vigade kategooriaid nagu äriloogika vs profiili valideerimine, samuti täpsemaid

kategooriaid nagu andmete kohustuslikkus, terminoloogia jne (vt ka ptk 4.1).

 üleminekuajal rakendatavaid reegleid (uue reegli kasutuselevõtt olemasolevas

teenuses), mis esialgu tagastavad kasutajale hoiatusteate ning üleminekuaja

lõppedes veateate.

Leida tuleb lahendus edge-case juhtumite jaoks, kus tavaolukorras on tegemist kohustusliku

reegliga, kuid teatud juhtudel peab olema võimalik kohustuslikust reeglist mööda minna ning

vajadusel anda kasutajale hoiatusteade põhimõttel "kas oled kindel, et need andmed on

õiged?" (Näiteks patsiendi sool põhinevad valideerimisreeglid peavad olema piisavalt

paindlikud, et arvestada olukordadega, kus patsiendi juriidiline sugu ei pruugi vastata tema

bioloogilistele riskiteguritele).

Vigade elutsükkel ja idempotentsus

Auditeeritavalt peab olema võimalik kindlaks teha, kas ja millal varasemalt ebaõnnestunud

andmeedastus on edukalt parandatud ja uuesti saadetud. Süsteem peab suutma vältida

andmete dubleerimist olukorras, kus sama päring saadetakse mitu korda. Äriliselt on oluline

tagada andmete auditeeritavus ja luua võimekus mõõta vigade parandamise kiirust ja

edukust.

4.3.2. Tööde tulemid

Valminud on dokumentatsioon ja tehniline lahendus, milles on koostöös tellijaga välja

töötatud veakäsitluse, logimise ja monitooringu põhimõtted.

Valminud on täiendatud vigade kataloogi mall.

Analüüsitud on TTO-le vigade tagasisidestamise võimalusi, äriprotsessi ja lahendust. Tulemid

on dokumenteeritud.

14

4.3.3. Tööde üleandmine

Punktis 4.3.2 kirjeldatud tulemite lõplik üleandmise tähtaeg on 31.03.2027

Tööd teostatakse tunnipõhisel arvestusel.

Tööde üleandmisele järgneb tellija poolt tööde vastuvõtmise aeg ning vajadusel täitja poolt

paranduste teostamine, kui ilmneb, et tööd ei ole teostatud nõuetekohaselt. Paranduste

tegemisel lähtutakse hankelepingus sätestatud tingimustest.

Täitjal on vajadusel kohustus lepingu perioodil tutvustada tehtud arendusi tellija poolt

korraldatud koosolekutel või üritustel

4.4. Reeglite inimloetava avaldamise automatiseerimine

PoC-i raames töötati välja äriloogiliste reeglite implementeerimise protsess, mis muuhulgas

paneb aluse ka reeglite haldusprotsessile, sh inimloetavale avaldamisele. Täiendada

eelnevalt loodud analüüsi reeglite valideerimise tehnilise lahenduse alusel.

Reeglid peavad lisaks tehnilistele osapooltele (arendajad, arhitektid), kes kasutavad

põhiliselt juurutusjuhendeid, olema kättesaadavad ka mitte-tehnilistele osapooltele nagu

äriomanikud, teenuse kasutajad (TTO-d), teisesed andmekasutajad (TAI, TerK, Terviseamet

jt). Reeglite avaldamisel tuleb lähtuda järgmistest põhimõtetest:

 Inimloetavas esituses filtreeritakse välja liigne FHIR-spetsiifiline tehniline müra.

 Äriline arusaadavus: Väljund peab selgelt kirjeldama reegli ärilist vajadust, elustsükli

staatust ning seotust andmekvaliteedi dimensiooniga.

 Tehniline jälgitavus: inimloetav reegel ja masinloetav FHIR profiil peavad olema

omavahel üheselt seotud, võimaldades lugejal vajadusel liikuda ärilisest kirjeldusest

tehnilise teostuse juurde

4.4.1. FHIR profiilidest reeglite avaldamine

Kui masinloetav baas on FHIR juurutusjuhendite (Implementation Guides) näol juba olemas,

siis inimloetaval kujul me profiilipõhiseid reegleid täna ei avalda. Analüüsi raames tuleb

kirjeldada protsess ja lahenduse arhitektuur, kuidas tagatakse inimloetavate reeglite

automatiseeritult avaldamise võimekus. Kirjeldatud automaatika peab tagama, et äripoolele

suunatud dokumentatsioon genereeritakse hetkel kehtiva masinloetava sisu pealt,

vähendades manuaalset dubleerimist ning hoides ära info aegumise.

4.4.2. Ärireegleid jõustavate andmekvaliteedi reeglite avaldamine

Analüüsida, mis kujul on võimalik ärireegleid jõustavaid andmekvaliteedi reegleid

automatiseeritult avaldada ühtses vormis koos FHIR profiilidest tulenevate reeglitega.

4.4.3. Tööde tulem:

Analüüs ja dokumentatsioon, mis kirjeldab FHIR profiilidest ja äriloogilikast tulenevate

reeglite automatiseeritud avaldamist.

4.4.4. Tööde üleandmine

Punktis 4.4.3 kirjeldatud tulemite lõplik üleandmise tähtaeg on 31.03.2027

15

Tööd teostatakse tunnipõhisel arvestusel.

Tööde üleandmisele järgneb tellija poolt tööde vastuvõtmise aeg ning vajadusel täitja poolt

paranduste teostamine, kui ilmneb, et tööd ei ole teostatud nõuetekohaselt. Paranduste

tegemisel lähtutakse hankelepingus sätestatud tingimustest.

Täitjal on vajadusel kohustus lepingu perioodil tutvustada tehtud arendusi tellija poolt

korraldatud koosolekutel või ürituste

5. Tööprotsess

5.1. Punktis 4 kirjeldatud tööde tööprotsess

Punktis 4 kirjeldatud tööde osas toimub lepingu täitmine töötunnipõhisel arvestusel.

Töötunnid logitakse meeskonnaliikme poolt tööde halduskeskkonnas Jira minimaalse

sagedusega 1 kord nädalas. Tööaja arvestuse väikseim samm on 15 minutit.

Punktis 4.1 ja 4.2 kirjeldatud tööd teostatakse projektiplaani alusel. Projektiplaani

koostamise ja kooskõlastamise tingimused on kirjeldatud tehnilise kirjelduse punktides

4.1.4. ja 4.2.4. Tööde teostamise protsess lepitakse kokku tellija ja täitja vahel enne

arendustööde alustamist ning kinnitatakse kirjalikku taasesitamist võimaldavas vormis koos

projektiplaaniga.

Vastavalt raamlepingu lisaks olevas Kodukorras sätestatule, kuulub tellija poolt

tasustamisele üksnes reaalselt töö teostamiseks kulutatud efektiivsed töötunnid, mis loovad

tellijale otsest väärtust.

Arendamisel kasutatakse agiilse arendusprotsessi põhimõtteid lähtuvalt raamlepingu lisaks

olevas kodukorras sätestatud põhimõtetest ning tellija ja täitja vahelistest töökorralduse

kokkulepetest.

16

5.2. Nõuded meeskonnale

Minikonkursi tulemusel sõlmitava hankelepingu täitmisel peab Täitja tagama meeskonna, kuhu kuuluvad vähemalt järgmised rollid: üks arhitekt, üks HL7 FHIR analüütik, vähemalt kolm Java back-end arendajat, üks testija ja üks projektijuht. Sealjuures võib HL7 FHIR analüütik täita ka projektijuhi rolli või vastupidi.

Meeskonda peab kuuluma vähemalt üks Java back-end arendaja nende Java back-end arendajate seast, kelle pakkuja esitas raamlepingu pakkumuses nimeliselt võtmeisikuna. Nimetatud Java back-end arendaja peab olema hankelepingu täitmise alustamisest alates hankelepingu täitmisse reaalselt kaasatav ja kättesaadav.

Muud minikonkursi meeskonnaliikmed ei pea olema raamlepingu pakkumuses nimeliselt esitatud isikud. Isikute kohta, keda ei esitatud nimeliselt raamlepingu pakkumuses, esitab pakkuja andmed minikonkursi pakkumuses raamhankes ettenähtud meeskonna ühise CV vormil.

HL7 FHIR analüütik esitatakse nimeliselt minikonkursi pakkumuses ning ta peab vastama minikonkursi dokumentides HL7 FHIR analüütikule kehtestatud nõuetele. HL7 FHIR analüütik ei pea olema raamlepingu pakkumuses nimeliselt esitatud isik.

5.3. Nõuded arendustöödele

Arendustööde teostamisel tuleb lähtuda raamlepingus viidatud tellija poolt kodulehel

avaldatud nõuetest (mh mittefunktsionaalsed nõuded, IT profiil, automaattestide nõuded).

Vastavalt hankelepingule tuleb üleantavad tööd täitja poolt enne üle andmist testida. Täitja

poolt tuleb koostada testiraportid, testilood ning esitada testitulemused. Testitulemustest

peab selguma, kuidas arendusnõuded on täidetud. Testid peavad olema automatiseeritud ja

korduvkäivitatavad TEHIKu poolt.

Vastavalt hankelepingule antakse koos töödega üle nõuetekohane dokumentatsioon. Täitja

poolt tuleb dokumenteerida:

 lahenduse arhitektuur koos lahenduse toimimise kirjelduse ja

interaktsiooniskeemidega;

 andmemudel koos andmeväljade kirjeldusega;

 paigaldus- ja administreerimisjuhendid;

 testid ja nende tulemid.

Ülaltoodud loetelu dokumenteerimisvajadustest võib töö käigus täieneda

(mittefunktsionaalsetes nõuetes sätestatud tingimustest lähtuvalt).

Tehisintellekti abil loodud või töödeldud dokumentatsioon peab enne tellijale üleandmist

olema täitja poolt toimetatud ja valideeritud. Täitja vastutab dokumentatsiooni kvaliteedi

ja korrektsuse eest.

Dokumenteerimine peab toimuma TEHIKu Wiki keskkonnas.