Leping

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:  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. 1   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. 2 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. 3  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 4 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, 5 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). 6 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 7 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 8 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 9 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- Töö sisu Tsükli kestus Töömaht (tundides) tsükkel (kuud) 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 10 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 11 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- Töö sisu Tsükli kestus Töömaht (tundides) tsükkel (kuud) 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 12 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. 13  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 14 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. 15  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. 16  Tööde /teenuste üleandmise -vastuvõtmise akt Sisu Lähtudes Tervise ja Heaolu Infosüsteemide Keskuse , keda esindab /lepingus märgitud kontaktisik/ (edaspidi tellija ) ja /ettevõtja nimi/, keda esindab /lepingus märgitud kontaktisik/ (edaspidi täitja ) vahel päev.kuu.aasta sõlmitud hankelepingu nr ___ annab täitja üle ja võtab tellija vastu teostatud tööd. Käesoleva aktiga annab täitja tellijale üle tööd /teenused , mis täitja on teostanud vastavalt hankelepingule ja tellija võtab käesolevas aktis nimetatud tööd /teenused vastu. Tellija annab täitjale üle töödega /teenustega seonduva dokumentatsiooni. Üleantud dokumentatsioon asub ........ . Tellija kinnitab, et tema või tema esindajad on käesolevas aktis nimetatud tööd /teenused üle vaadanud ning see vastab hankelepingule. Käesolev akt on täitjale tasu maksmise aluseks. Poolte vaheline arveldamine toimub hankelepingu alusel vastavalt käesolevas aktis sisalduvatele andmetele. Käesoleva akti pooled kinnitavad, et aktis sisalduvad andmed on nende parima teadmise kohaselt õiged. Akteeritavad tööd /teenused Nr Tööde /teenuste loetelu Tunnid Maksumus km-ta 1 2 KOKKU Tööde /teenuste üleandmise tähtaeg Tööd /teenused on üle antud päev.kuu.aasta /etappide puhul ka etapid/. Tööd /teenused teostati tähtaegselt. Puudustega tööde /teenuste nimekiri Puuduseid töös /teenustes ei esine./Esinevad järgmised puudused töös /teenustes : ____; ____; Puuduste põhjendus. Puuduste kõrvaldamise tähtaeg on päev.kuu.aasta . Poolte allkirjad Tellija: Lepinguline kontaktisik /allkirjastatud digitaalselt/ Täitja: Lepinguline kontaktisik /allkirjastatud digitaalselt/