Leping

Saatja: Mehis Hakkaja <[email protected]> Saaja: Bret Rand Teema: Re: Andmekontrolli mooduli turvatestimine Tere. Tagastan soovitud TT_60 täidetud ja allkirjastatud pakkumuse. Parimat, Mehis Hakkaja Clarified Security OÜ - "We break security to bring clarity" CEO/Owner/Founder [email protected] <mailto:[email protected]> mobile: (+372) 56244264 phone: (+372) 603 66 44 Lõõtsa 12, Tallinn 11415, Estonia www.clarifiedsecurity.com <http://www.clarifiedsecurity.com> On Tue, May 26, 2020 at 4:23 PM Bret Rand <[email protected] <mailto:[email protected]> > wrote: Tere! Järgmine aasta on vaja hakata andmekontrolli mooduli turvatestimist tegema ja selles osas küsiks pakkumust. Pakkumust ootan uue raamlepingu alusel RHR’s 200595. Maksimaalne eelarve turvatestimiseks on koos käibemaksuga 21 580 eur. <https://www.tehik.ee/> <https://www.tehik.ee/> <https://www.tehik.ee/> Bret Rand Testimise juht <mailto:[email protected]> [email protected] Usume, et meie töö suudab säästa inimeste aega, et nemad saaksid keskenduda olulisele Hankeleping nr 3-9/2266-1 Tervise ja Heaolu Infosüsteemide Keskus (edaspidi: Tellija), registrikood 70009770, aadress Uus- Tatari 25/Veerenni 13, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold ja Clarified Security OÜ (edaspidi: Täitja), registrikood 1216540, aadress Lõõtsa 12, keda esindab juhatuse liige Mehis Hakkaja. edaspidi koos või eraldi nimetatud ka pooled või pool, sõlmisid käesoleva lepingu (edaspidi: hankeleping) alljärgnevas: Käesolev hankeleping sõlmitakse projekti „TTO-s ja TEHIKus rakendatav TIS andmekontrollimoodul“ (projekti number 2014-2020.12.03.19-0610) raames ja rahastatakse struktuurtoetuste vahenditest majandus- ja taristuministri 15. aprilli 2015. a määruse nr 31 „Avalike teenuste pakkumise arendamiseks toetuse andmise tingimused ja kord“ alusel. 1. Hankeleping on sõlmitud riigihankes „Infosüsteemide turvatestimine“ (viitenumber riigihangete registris 200595) 31.12.2018 sõlmitud raamlepingu NR. 3-9/1607-1 alusel. 2. Hankelepingu täitmisel lähtuvad pooled, riigihanke hankedokumentidest, raamlepingus kokkulepitud tingimustest, riigihanke pakkumusest ning hankelepingust, pakkumuse esitamise ettepanekust ning vastavast täitja esitatud pakkumusest. 3. Hankelepingu alusel teostatavad tööd: 3.1. Andmekontrolli mooduli OWASP ASVS Level 2 testimise metoodika alusel vastavalt punktis 8.1 toodud tingimustele. 4. Töötundide maht 156 tundi. 5. Tööde teostamise tähtaeg 30.04.2021, töödega alustatakse pärast lepingu allkirjastamist. 6. Tööde maksumus on 17 940 eurot, millele lisandub käibemaks. 7. Vajadusel muud tingimused: 7.1. Infosüsteemidele ligipääsemiseks tuleb suhelda Tellija kontaktisikuga, kelleks on testimise juht Bret Rand (e-posti aadress [email protected] ). 8. Lepingule on allkirjastamisel lisatud: 8.1. Lisa 1. TT_60-Andmekontrolli moodul.docx 8.2. Lisa 2. Andmekontrollimooduli visioon.docx 8.3. Lisa 3. Re Andmekontrolli mooduli turvatestimine.msg. Tellija: Täitja: (allkirjastatud digitaalselt) (allkirjastatud digitaalselt)  Testimistaotlus Tervise ja Heaolu Teabekeskus Infosüsteemide Keskus Testmistaotluse nr.: TT_60 Algatamise 04.01.2021 kuupäev: Seotud Projekti number: muudatusettepanekud: Tähtsus: Oluline Algataja nimi: Bret Rand Tähtaeg: 30.04.2021 Ametikoht/roll: Testimise juht Organisatsioon: Tervise ja Heaolu Infosüsteemide Keskus Sisukord 1 Projekti sisu2 1.1 Testitava teenuse kirjeldus2 1.1.1 Eesmärgid2 1.1.2 Tehniline arhitektuur kokkuvõtlikult3 1.1.3 Lisad6 1.1 Projekti mõjud teistele projektidele/muudatustele6 1.2 Projekti- ja tooteriskid7 2 Testimise kirjeldus7 2.1 Testimise eesmärk ja ulatus7 2.2 Testimise edukriteerium7 2.3 Testimise osapooled ja osamäär7 3 Testimistööde teostamine8 3.1 Testkeskkonna andmed8 3.2 Testimise ajakava8 3.3 Testimisel osalejad8 3.4 Testimise töömaht ja maksumus (pakkumus)9 1  Testimistaotlus Tervise ja Heaolu Teabekeskus Infosüsteemide Keskus 1 Projekti sisu 1 Testitava teenuse kirjeldus TEHIK haldab Tervise infosüsteemi (TIS), millesse edastatakse X-tee kaudu andmeid TTO-de (tervishoiuteenuste osutajate) infosüsteemidest. Andmete esitajaid on ligi tuhat ning enne TIS-i salvestamist tuleb andmetele teha struktuuri ja sisu õigsuse kontroll, et tagada nende kvaliteet. Elektroonilisi dokumente saabub TIS-i ligikaudu 11 – 13 miljonit aastas ning neist umbes 1 miljon tagastatakse veateadetega kui vastuvõtuks mittekõlblikud. Praegu tehakse kvaliteedikontrolli eelmisest kümnendist pärit valideerimismooduliga, mis kahjuks ei taga piisavat andmekvaliteeti. Tervise Arengu Instituut, mis viib läbi regulaarseid uuringuid TIS-i statistikaks kasutatavate andmete kvaliteedi kohta on tuvastanud, et olemasolevate andmete pealt ei saa üles ehitada korrektset statistikat, mis tingib vajaduse koguda sarnaseid andmeid ka TAI-sse ja Eesti Haigekassasse. Lisaks on 10 aasta jooksul välja arendatud hulk e-teenuseid, mis omakorda põhinevad TIS andmetel ning mille korrektne toimimine sõltub samuti TIS andmete kvaliteedist. Andmekvaliteedi probleemi lahendamiseks algatas TEHIK uue masinmõistetavatel reeglitel põhineva andmekontrollimooduli loomise, mis kõrvaldab olemasoleva süsteemi puudused ning võimaldab teostada andmekontrolli tunduvalt täiuslikumalt. Luuakse vahetatavatest komponentidest keskkond, mis võimaldab ilma rakenduse arhitektuuri muutmata lisada uusi andmekontrolli meetodeid ja eemaldada vajaduse kaotanud meetodeid. Uus teenus töötab X-tee taristul samuti kui vana. 1.1.1 Eesmärgid Uus andmekontrolli keskkond võimaldab: − Andmekirjeid TTO-dest kontrollimiseks vastu võtta vastavate liideste kaudu; − andmekontrolli kanali mõlemas otsas (TTO-s ja TIS-is) samade reeglite alusel, st on olemas meetodid ühiste andmekontrollireeglite tsentraalseks haldamiseks ning TTO-d peavad saama vähemalt kasutada andmekontrolli keskkonda teenusena üle võrgu või andmekontrollimoodulit paigaldatuna oma keskkonda. TTO-del ei peaks enam olema vajadust iseseisvalt andmevahetusvormingute kontrolle välja töötada; − TTO-de arendusmeeskondadel kasutada andmekirjete interaktiivset testkeskkonda vastavate liideste kaudu; − kontrollida andmete struktuuri nii HL7 poolt väljastatud XSD-de alusel (siia kuuluvad CDA, V3 ja FHIR, viimane on sama standardi uuem versioon), samuti Eesti jaoks kohandatud struktuure spetsiifiliste XSD-de alusel; − teha andmete reeglitele vastavuse kontrolli (null, not null, suurem, väiksem, kaasnev, klassifikaatoritele vastav jms.); − lisada uusi andmekontrollimeetodeid ning eemaldada kehtivuse kaotanud meetodeid. 2  Testimistaotlus Tervise ja Heaolu Teabekeskus Infosüsteemide Keskus 1.1.2 Tehniline arhitektuur kokkuvõtlikult cmp 01. Andmekontrollimoodul Logid Andmekontrollimoodul ANDMEKONTROLLI REEGLITE TEEK (2) REEGLITE API-AK MOOTOR (1) REDAKTOR (4) (REST) TESTRAKENDUS (5) REEGLITE VAATUR (3) API-TR Veeb-TR API-RV Veeb-RV API-RE Veeb-RE (REST) (REST) (REST) Joonis 1 Andmekontrollimooduli komponendid ja liidesed 1) Andmekontrolli mootor 2) Andmekontrolli reeglite teek 3) Andmekontrolli reeglite haldusliides / vaatur 4) Andmekontrolli reeglite redaktor 5) Reegliteekide automaatse sünkroniseerimise arendused 6) Andmete vastuvõtja 7) Testrakendus Andmete vastuvõtja võtab X-teelt vastu TTO infosüsteemist saadetud andmed (tänases mõistes XML dokumendid ja päringud, päringute vastused võivad olla väga mahukad XML dokumendid) ja edastab need andmekontrolli mootorile (1). Andmekontrolli mootor (1) teeb temale saadetud andmetele kontrollid võttes aluseks tema juures asuva andmekontrolli reeglite teegis (2) talletatud andmekontrolli reeglid või reeglite komplektid. Koos andmetega peavad saabuma ka viited kontrollidele või on saadetud andmetest vajalikud kontrollid või kontrollide komplektid otseselt järeldatavad. Tänases mõistes on reeglite teegiks XML Schematroni (.sch) failide kogum. Andmekontrollimoodul võib olla installeeritud mitmes erinevas kohas. Sellisel juhul on iga installatsiooni juures ka andmekontrolli reeglite teek (2). Tagamaks, et kõikides andmekontrolli reeglite teekides oleks sama reeglite komplekt, on üks andmekontrolli reeglite teek keskne teek, milles hallatakse üldkehtivaid andmekontrolli reegleid ja millest need reeglid levitatakse sünkroniseerija (6) abil teistesse teekidesse. Sünkroniseerijat (6) ei ole toodud joonisel 1, see on leitav joonisel 4. Kui keskne teek välja arvata, võib igas teegis olla ka lokaalne reeglite komplekt, mida kasutab andmete kontrollimisel ainult selle teegi juures asuv andmekontrolli mootor. Seda lokaalset andmekontrolli reeglite komplekti haldab selle konkreetse andmekontrolli mootori haldur andmekontrolli reeglite redaktoriga (4). Neid reegleid ei sünkroniseerita teiste andmekontrolli mootorite juures asuvatesse reeglite teekidesse. 3  Testimistaotlus Tervise ja Heaolu Teabekeskus Infosüsteemide Keskus Andmekontrolli reeglite haldamiseks saab kasutada ka API-liidest, mille kaudu saab teeki lisada uusi reegleid ja lugeda, kustutada ning asendada olemas olevaid reegleid. Andmekontrolli reeglid on avaandmed, st piiranguteta vaatamiseks ligi pääsetavad kõikidele soovijatele. Reeglite vaatamiseks on iga andmekontrolli reeglite teegi juures andmekontrollireeglite vaatur (3). Iga andmekontrollimooduli juures on andmekontrolli testrakendus (5), mis on kasutatav kahe liidese, veebi- ja API- liidese kaudu. Selle eesmärk on võimaldada rakendusse saadetud andmete kontrollimist vastavalt TEHIK-us kehtestatud standarditele ja keskse teegi kontrollidele. Testrakenduse poole pöördumisel tagastades kontrollitavate andmete täielik veaanalüüs. Veebiliidese kaudu saab andmeid analüüsida viisil, kus ühte pika teksti lahtrisse tõstetakse analüüsitavad andmed ja teise väljastatakse täielik veaanalüüs. API-liides töötaks analoogselt – liidesesse saadetakse andmed ja sealt tagastatakse täielik veaanalüüs. Liidese nimetus Kirjeldus Logid Selle liidese kaudu pöördutakse rakenduse poole, mis kogub andmekontrolli mootori logisid ja tegeleb nende analüüsiga. Eristatakse töö tegevusteks tehtud andmekontrolle ja testimise otsatarbel tehtud andmekontrolle. Igal juhul logitakse pöördumise teinud asutus, kasutaja, dokumendi/päringu/vastuse tüüp (standard so mida tehti), pöördumise aeg, vastuse aeg, vigade loend ja viide andmetele (dokumendile) mille kontrollimise kohta logi tehti. API-AK Selle liidese kaudu saab teha kolme erinevat toimingut: - kontrollida andmete vastavust standardile (struktuur ja andmete vastavust piiridele/loenditele); - kontrollida andmete alamosa vastavust standardile. Selles alamosaks on tavaliselt kas XML- või JSON-alampuu aga võib olla ka terviku mingi muu alam-andmegrupp, mis on reeglites kirjeldatud ühtse tervikuna. - ühe andmeelemendi kontrollimine (NOT NULL, vahemik, klassifikaator, pikkus, muster jms). Andmeelemendi kontrolli reeglite valimiseks tuleb osutada standardis olevale andmeelemendile, mille reeglite alusel kontrolli teostada soovitakse. Tegemist on liidesega, mille kaudu tehakse reaalsete, töös tekkivate andmete kontrolli. Andmekontrollimootor (1) suudab vahet teha tunnuse alusel. See, millist toimingut tehakse ja millist reeglit kontrollimiseks kasutatakse määratakse liidese poole pöördumisel. Liidese vastuseks on alati kas OK st vigu polnud või nii täielik vigade loend kui võimalik. Liides on lahendatud REST protokolli alusel. API-TR See liides teeb kõike seda sama, mida liides API-AK selle vahega, et ei töödelda reaalseid andmeid vaid testandmeid. Andmekontrollimootor (1) suudab vahet teha tunnuse alusel. 4  Testimistaotlus Tervise ja Heaolu Teabekeskus Infosüsteemide Keskus Liides on lahendatud REST protokolli alusel. Veeb-TR See liides teeb kõike seda sama, mida teeb API-TR liides, kuid see on lahendatud veebiliidesena, mida saab integreerida erinevatesse veebirakendustesse ja portaalidesse. Liides vahendab läbi testrakenduse päringut andmekontrolli mootorile (1). Määra saab, millist päringu varianti kasutatakse (üks kolmest) ja millist reeglit kasutatakse. Visuaalse liidese kaudu antakse ette kontrolli reegel (kui seda pole kirjeldatud kontrollitavates andmetes) ja kontrollitavad andmed. Tagasi saadakse veateadete loend nii inim- kui masinmõistetaval kujul. API-RV Selle liidese kaudu saab pärida reeglite teegis (2) olevaid andmekontrolli reegleid. Realiseeritud on järgmised funktsioonid: - anna temaatiliste jaotiste loend (puuna interpreteeritaval kujul). - anna esimese taseme temaatiliste jaotiste loend. - anna selgelt viidatud temaatilise jaotise all olevasse alam-puusse kuuluvate temaatiliste jaotiste loend (puuna interpreteeritaval kujul). - anna selgelt viidatud temaatilise jaotise all oleva järgmise taseme temaatiliste jaotiste loend. - anna kõigi kehtivate reeglite loend; vaikimisi tänane kuupäev aga võib anda ette ka mingi teise (mineviku) kuupäeva; filtreerida peab olema võimalik ka temaatilise jaotisega, kuhu kuuluvaid reegleid soovitakse saada; - anna selgelt viidatud reegli kõikide versioonide ja kehtivusaegade loend. - anna selgelt viidatud reegli kehtiv kirjeldus. - anna selgelt viidatud reegli määratud versiooni kirjeldus. Seejuures reegliteks on siin ainult terviklikud reeglite komplektid. Kui vaja on alamosa tuleb terve reegel välja lugeda ja sealt ise vajalik osa üles leida. Liides on lahendatud REST protokolli alusel. Veeb-RV See liides teeb kõike seda sama, mida teeb API-RV liides, kuid see on lahendatud veebiliidesena, mida saab integreerida erinevatesse veebirakendustesse ja portaalidesse. API-RE Selle liidese kaudu saab hallata reeglite teegis (2) olevaid andmekontrolli reegleid. Realiseeritud on järgmised funktsioonid: - lisa uus temaatiline jaotis (juur-jaotis või alamjaotis teise temaatilise jaotise alla) - muuda temaatilise jaotise nimetust; - sule temaatiline jaotis; - lisa temaatilise jaotise alla uus andmekontrolli reegel; - lisa andmekontrolli reegli uus versioon; 5  Testimistaotlus Tervise ja Heaolu Teabekeskus Infosüsteemide Keskus - muuda andmekontrolli reegel kehtetuks. Liides on lahendatud REST protokolli alusel. Veeb-RE See liides teeb kõike seda sama, mida teeb API-RE liides, kuid see on lahendatud veebiliidesena, mida saab integreerida erinevatesse veebirakendustesse ja portaalidesse. Andmekontrollimooduli soovitav ISKE tase on K1T1S0. K1 – käideldavuse vahemik 90% - 99% ja maksimaalne lubatud ühekordse katkestuse pikkus teenuse töö ajal kuni 24 tundi. T1 – info allikas, selle muutmise ja hävitamise fakt peavad olema tuvastatud. Info õigsuse, täielikkuse, ajakohasuse kontrollid erijuhtudel ja vastavalt vajadusele. S0 – avalik info. Juurdepääsu teabele ei piirata (st. lugemisõigus kõigil huvitatutel, muutmise õigus määratletud terviklikkuse nõuetega). Tehnoloogiad ja raamistikud on valitud TEHIK-u IT profiilis https://wiki.sm.ee/display/AV/IT-Profiil nimetatud tehnoloogilistest eelistustest. 1. Andmebaasid: A. Andmebaasi mootoriks on tõenäoliselt Postgre. 2. Rakendused: A. Rakendusserveri tarkvaraks on Tomcat embedded versioon. B. Rakendus töötab konteineris (Docker). C. Süsteemi kasutajate hulk on suurusjärgus ~1000, pöördumiste arv ~15 miljonit aastas. D. Kasutajaliidesed põhinevad tõenäoliselt Reactil. E. Süsteemsed liidesed kasutavad REST tehnoloogiat. Andmekontrollimooduli põhjalikumalt kirjeldatud visioon on kirjeldatud dokumendis Lisa 2. Andmekontrollimooduli visioon.docx , mis on lisatud turvatestimistaotluse dokumendile. 1.1.3 Lisad 1. Lisa 2. Andmekontrollimooduli visioon.docx. 1.1 Projekti mõjud teistele projektidele/muudatustele Projekt/Muudatus Sõltuvuse iseloom Märkused (ressurss/tulemid/ajakava) Teabekeskus (Tervise Tulemid / ajakava TIS standardiloome keskkond, Infosüsteemi mis peaks valmima jaanuaris andmeedastusstandardite 2021 on üheks süsteemiks, mis loomise keskkond) toodab sisendit andmekontrollimoodulile. 6  Testimistaotlus Tervise ja Heaolu Teabekeskus Infosüsteemide Keskus 1.2 Projekti- ja tooteriskid Projekti tooteriskid on sellised riskid, mida saab maandada testimisega. Risk, riski tüüp (toote/projekti), esinemise tõenäosus, mõju, maandamise strateegia. Risk Riski tüüp Riski Mõju Maandamise strateegia (toote/projekt) esinemise tõenäosus Andmekontrollimooduli toote keskmine suur Turvatestimisel leitud vead liidese kaudu rikutakse parandatakse andmete terviklikkust 2 Testimise kirjeldus 2.1 Testimise eesmärk ja ulatus Punkti 1 kirjeldatud rakendusele mõeldud funktsionaalsuse turvatestimine viiakse läbi vastavalt järgmistele tingimustele. 1. Metoodilise testimise käigus tuleb hinnata kõiki potentsiaalseid turvavigu ning need testraportis detailselt välja tuua koos võimalike lahenduste soovitustega. a. Eraldi tuleb siin tähelepanu pöörata rünnetele maja seest ja väljaspoolt majast – st milline on oht, kui ründaja pääseb TEHIK’u sisevõrku. b. Tuleb arvestada, et TEHIK’u kasutaja võib rakendust kasutada nii sisevõrgu kui VPN’i kaudu. 2. Kontrollitakse, et testitava rakenduse võimalike haavatavuste kaudu ei ole võimalik juurde pääseda andmetele, mis asuvad väljaspool testitava rakenduse funktsionaalsust. 3. Turvatestimine peab olema tehtud OWASP ASVS level 2 testimise metoodika alusel. 4. Testimise lõppedes esitletakse tulemusi tellijale ja tellija poolt kaasatud arendajale. Turvatestimise ajakava soov: 1. Esmane turvatestimine võiks alustada alates 04.01.2021 ja ei peaks olema nii mahukas kui lõplik turvatestimine. 2. Lõplik turvatestimine võiks alustada alates 19.04.2021. 2.2 Testimise edukriteerium Testitavad objektid Edukriteeriumid/Meetrika Rakendus koos liidestega Rakenduse avalikes liidestes ei ole üldtuntud turvaauke, mis võimaldaksid ründajal rakendusse sisse murda ja teha selles mingeid äriloogika vastaseid tegevusi. See kehtib ka sisevõrgust pöörduvate ründajate kohta. 2.3 Testimise osapooled ja osamäär Lihtsamatel juhtudel paari inimese nimed, kes osalevad testimises ja/või peavad tulemid kooskõlastama või vastu võtma. Keerulisematel juhtudel RACI maatriks. Kui testide läbiviimise eelduseks on koostöö TEHIKst väljapoole 7  Testimistaotlus Tervise ja Heaolu Teabekeskus Infosüsteemide Keskus jäävate osapooltega, siis tuleb ka nende osalus ära märkida. R – vastutav teostaja/juht A – vastutav vastuvõtja/tellija/omanik C – kohustusliku tagasiside allikas/kinnita/kooskõlastaja I – vabatahtliku tagasiside allikas/teavitatav <tühi> - ei osale Nimi/Teema Turvatesti läbi viimine, raporti koostamine Clarified Security OÜ R Tõnis Komp C Bret Rand C Lehor Meius A 3 Testimistööde teostamine 3.1 Testkeskkonna andmed Andmekontrollimoodul on paigaldatud küll erinevates asukohtades, kuid selle tsentraalne paigaldus asub TEHIKu testkeskkonnas. Testimisele kuulub ainult TEHIK-us asuv paigaldus. Testimisel olevad aadressid (hetkel ei ole teada, kui selgub, siis teavitame): 1. rakendus kõigi liidestega; 2. andmebaas; 3. logid; 4. lähtekood. Ligipääsude haldamine käib vastavalt kehtivale ligipääsude haldamise korrale. 3.2 Testimise ajakava Tarne Tähtaeg Koosseis Jaanuar 2021 2-3 töönädalat alates testimise võimalikust Esmane, piiratud mahus algusest turvatest, vt 3.3 Aprill 2021 3-4 töönädalat alates testimise võimalikust Lõplik turvatestimine, vt 3.3 algusest 3.3 Testimisel osalejad Organisatsioon Koosseis Roll Clarified Security OÜ Mehis Hakkaja Turvatestimise meeskonna ja projekti juht, raportite üle vaataja 8  Testimistaotlus Tervise ja Heaolu Teabekeskus Infosüsteemide Keskus Clarified Security OÜ Silvia Väli, Turvatestija vastutavas rollis (vähemalt 1 vastutav Andres Liiver, turvatestija, kes omab OSWE/GWAPT/CWAPT sertifikaati) ja vastavas rollis testimise kogemust Marko Belzetski, Anti Räis, Elar Lang, Clarified Security OÜ Liis Jaks, Turvatestija (kaasatakse vastavalt vajadusele ja sobilikkusele) Mihkel Raba, Rasmus Moorats TEHIK Bret Rand Tehniline tugi TEHIK Lehor Meius Projektijuht TEHIK Tõnis Komp Turvanõuded 3.4 Testimise töömaht ja maksumus (pakkumus) Ammendav ülevaade testimisega kaasnevatest kuludest. Moodul/tegevus Töömaht, Töö maksumus km- Töö maksumus km-ga ühik (h) ta (EUR) (EUR) Esmane, piiratud mahus turvatest 50 5750 6900 Lõplik turvatestimine ASVSv4.0 tase 2 106 12190 14628 alusel (sh vajadusel olulisemate leidude ületestid enne toodangusse minekut) 156 17940 21528 9  Andmekontrollimooduli visioon Versioon 1.5.4 Dokumendi eesmärk Dokumendi eesmärk on kirjeldada üldine visioon andmekontrollimooduli loomiseks. Siin esitatud seisukohti tuleb vaadelda funktsionaalsete nõuetena või omadustena, mitte otseste suunistena tehniliste lahenduste valikul. Pakkujal on vabadus valida ise sobivad komponendid ja tehniline lahendus, va. peatüki 1.1 lõigus oluline märkus sätestatu. Projekti alguses toimub esimese pooleteise kuu jooksul arendaja ja tellija ühistööna süsteemi detailprojekteerimine. Arvestada tuleb TEHIK-u IT profiilis nimetatud raamnõuetega. Olemasoleva olukorra ja probleemi kirjeldus Tervise ja Heaolu Infosüsteemide Keskus (TEHIK) haldab Tervise infosüsteemi (TIS) kesksüsteemi, mille üheks kliendile nähtavaks väljundiks on Patsiendiportaal (https://digilugu.ee/). Sellesse keskkonda annavad andmeid tuhatkond Eestis tegutsevat terviseteenuse osutajat (TTO). Andmed tekivad TTO-de infosüsteemides ja need vormindatakse üle X-tee TIS-i saatmiseks TEHIK-u poolt kehtestatud XML HL7 CDA dokumentideks, millede struktuurid on TEHIKu poolt Eesti vajadusi arvestavalt koostatud ja avalikustatud (http://pub.e-tervis.ee/). HL7 on globaalse mõjuga meditsiini valdkonna andmevahetuse standardite halduskeskus (https://www.hl7.org/) ja CDA on üks nende levinud standarditest (lühidalt saab lugeda siit https://en.wikipedia.org/wiki/Clinical_Document_Architecture). TIS-i saabumisel kontrollitakse iga saabunud XML dokumenti valideerimismoodulis (täiendavalt ka kesksüsteemis) ja alles pärast seda, kui dokument osutub vastuvõtukõlbulikuks, talletatakse see TIS andmebaasi. Mitte vastuvõtukõlbulike dokumentide saabumine logitakse ja nende mittesobilikkuse kohta saadetakse tagasilükkamise põhjust sisaldav teade dokumendi saatnud TTO-le. Selliseid tagasi lükatud dokumente ei talletata TIS-i. Valideerimismoodul jaguneb kontrolli teostuse mõttes kolmeks. XML struktuuri kontroll XSD-de vastu, XML Schematroni kontrollideks (üksikkontrollide koguhulk suurusjärk 2000, mis jaguneb 20-ne .sch faili vahel) ja klassifikaatorite väärtuste vastavuse kontrollideks (käibel on suurusjärk kuni 400 klassifikaatorit, millest 43 osalevad kontrollides). Kontrollide hulk on dokumendi liigiti erinev. Põhjused on ajaloolised. Suurt süsteemi arendatakse teemaprojektide kaupa, milledes on arenduse rõhuasetuse erinevad. See keskkond on küll tervikuna toimiv, kuid ei täida piisavalt hästi oma eesmärki, milleks on kvaliteetsete andmete kogumise tagamine. Põhjuseid on mitu: − konteineri struktuuri kontrollitakse konkreetsete olude jaoks liiga üldise HL7 CDA XSD-vorminguga ja selle tulemus ei anna kinnitust, et saadetud andmete struktuur vastab meie poolt kokkulepitule, kuna edastavad struktuurid on CDA alamhulgad (konkretiseeringud); − andmete sisu kontrolli reegleid on vähe ja neid pole rakendatud süstemaatiliselt, reeglite loomine on keeruline; − vigase kirje teate peale ei pruugi TTO enam õiget kirjet kunagi saata; − andmete kontroll kanali kahes otsas (TTO-s ja TIS-is) toimub erinevate reeglite alusel. Sellest tingituna ongi kontroll TIS otsas „üsna kerge“, kuna vastasel korral langeb vastu võetavate andmete hulk veelgi; − TTO-de infosüsteemide arendajate tehtud vead ei jõua piisavalt kiiresti neile tagasi; − TTO-de töötajate (meditsiinitöötajate) tehtud vead ei jõua tagasi nende töölauale või kui jõuavadki ei mäleta nad enam juhtumit ja ei oska parandusi teha; Dokumendi eesmärk on kirjeldada andmevahetusvormingute kontrolli keskkond (lühidalt „andmekontrolli keskkond“), mis lahendaks ülal toodud probleemid järgmisel viisil: − muuta kontroll kanali mõlemas otsas (TTO-s ja TIS-is) toimivaks samade reeglite alusel; − luua meetodid ühiste kontrollireeglite tsentraalseks haldamiseks ja poolte vaheliseks sünkroniseerimiseks, − luua võimalus samade meetoditega, millega on kirjeldatud tsentraalsed reeglid, kirjeldada ka täiendavaid lokaalseid kontrollireegleid,  − luua võimalus kontrollida andmete struktuuri nii HL7 CDA ja HL7 V3 struktuuri (XSD) alusel kui ka Eesti jaoks kohandatud struktuuride kontrollimiseks spetsiifiliste XSD-de alusel, − võimaldada lisaks HL7 CDA struktuuri kontrollile ka HL7 FHIR struktuuri kontrollimist (sama valdkonna uuem ja suurem andmeedastusvormingute haru). − võimaldada andmete reeglitele vastavuse kontrolli (null, not null, suurem, väiksem, kaasnev, klassifikaatoritele vastav jms.) − luua kontrollikeskkond, mida TTO-d saavad soovi korral paigaldada oma süsteemi, − luua kontrolli teenus, mida TTO-d saavad kasutada üle võrgu. Dokumendi skoop Käesoleva dokumendi skoobiks on kirjeldada loodava andmekontrolli keskkonna komponentmudel, komponentide piirpinnad (liidesed), erinevate komponentide funktsionaalsused, komponentide vahelised andmevood ja kasutusjuhud. Lisaks sellel moodustavad olulise osa uuest süsteemist andmete haldamise vahendid ja kirjelduste automaatgenereerimis- ning laadimisvahendid. Selleks antakse lühiülevaade loodavast terviksüsteemist, eraldatakse sealt loodavad komponendid ning kirjeldatakse nende olulised omadused, toimimine, seosed komponentide vahel ja seosed väljapoole loodavat süsteemi jäävate komponentidega. Arenduse sihtrühm Loodava vahendi kasutajateks on:  andmevahetus- ja andmepäringu standardite loojad,  andmehõivega tegelevad töötajad,  infosüsteemide arhitektid,  TTO-de tarkvara arendajad ja haldajad,  TTO-d (TTO-de infosüsteemid). 1. Andmekontrollimooduli üldine kirjeldus Visiooniliselt koosneb andmekontrollimoodul seitsmest osast: 1. andmekontrolli mootorist, 2. andmekontrolli reeglite teegist, 3. andmekontrolli reeglite vaaturist, 4. andmekontrolli reeglite redaktorist, 5. andmekontrolli testrakendusest, 6. andmekontrolli reeglite sünkroniseerijast, 7. andmete vastuvõtjast. Andmete vastuvõtja võtab X-teelt vastu TTO infosüsteemist saadetud andmed (tänases mõistes XML dokumendid ja päringud, päringute vastused võivad olla väga mahukad XML dokumendi) ja edastab need andmekontrolli mootorile (1). Andmekontrolli mootor (1) teeb temale saadetud andmetele kontrollid võttes aluseks tema juures asuva andmekontrolli reeglite teegis (2) talletatud andmekontrolli reeglid või reeglite komplektid. Koos andmetega peavad saabuma ka viited kontrollidele või on saadetud andmetest vajalikud kontrollid või kontrollide komplektid otseselt järeldatavad (näiteks dokumendi OID-i järgi). Tänases mõistes on reeglite teegiks XML Schematroni (.sch) failide kogum. Andmekontrollimoodul võib olla installeeritud mitmes erinevas kohas. Sellisel juhul on iga installatsiooni juures ka andmekontrolli reeglite teek (2). Tagamaks, et kõikides andmekontrolli reeglite teekides oleks sama reeglite komplekt, on üks andmekontrolli reeglite teek keskne teek, milles hallatakse üldkehtivaid andmekontrolli reegleid ja millest need reeglid levitatakse sünkroniseerija (6) abil teistesse teekidesse. Sünkroniseerijat (6) ei ole toodud joonisel 1, see on leitav joonisel 4. Kui keskne teek välja arvata, võib igas teegis olla ka lokaalne reeglite komplekt, mida kasutab andmete kontrollimisel ainult selle teegi juures asuv andmekontrolli mootor. Seda lokaalset andmekontrolli reeglite komplekti haldab selle konkreetse andmekontrolli mootori haldur andmekontrolli reeglite redaktoriga (4). Neid reegleid ei sünkroniseerita teiste andmekontrolli mootorite juures asuvatesse reeglite teekidesse. Andmekontrolli reeglite haldamiseks saab kasutada ka API-liidest, mille kaudu saab teeki lisada uusi reegleid ja lugeda, kustutada ning asendada olemas olevaid reegleid. Andmekontrolli reeglid on avaandmed, st piiranguteta vaatamiseks ligi pääsetavad kõikidele soovijatele. Reeglite vaatamiseks on iga andmekontrolli reeglite teegi juures andmekontrollireeglite vaatur (3). Iga andmekontrollimooduli juures on andmekontrolli testrakendus (5), mis on kasutatav kahe liidese, veebi- ja API- liidese kaudu. Selle eesmärk on võimaldada rakendusse saadetud andmete kontrollimist vastavalt TEHIK-us kehtestatud standarditele ja keskse teegi kontrollidele. Testrakenduse poole pöördumisel tagastades kontrollitavate andmete täielik veaanalüüs. Veebiliidese kaudu saab andmeid analüüsida viisil, kus ühte pika teksti lahtrisse tõstetakse analüüsitavad andmed ja teise väljastatakse täielik veaanalüüs. API-liides töötaks analoogselt – liidesesse saadetakse andmed ja sealt tagastatakse täielik veaanalüüs. cmp 01. Andmekontrollimoodul Logid Andmekontrollimoodul ANDMEKONTROLLI REEGLITE TEEK (2) REEGLITE API-AK MOOTOR (1) REDAKTOR (4) (REST) TESTRAKENDUS (5) REEGLITE VAATUR (3) API-TR Veeb-TR API-RV Veeb-RV API-RE Veeb-RE (REST) (REST) (REST) Joonis 1. Andmekontrollimooduli komponentstruktuur koos liidestega Liidese nimetus Kirjeldus Logid Selle liidese kaudu pöördutakse rakenduse poole, mis kogub andmekontrolli mootori logisid ja tegeleb nende analüüsiga. Eristatakse töö tegevusteks tehtud andmekontrolle ja testimise otsatarbel tehtud andmekontrolle. Igal juhul logitakse pöördumise teinud asutus, kasutaja, dokumendi/päringu/vastuse tüüp (standard so mida tehti), pöördumise aeg, vastuse aeg, vigade loend ja viide andmetele (dokumendile) mille kontrollimise kohta logi tehti. API-AK Selle liidese kaudu saab teha kolme erinevat toimingut: - kontrollida andmete vastavust standardile (struktuur ja andmete vastavust piiridele/loenditele); - kontrollida andmete alamosa vastavust standardile. Selles alamosaks on tavaliselt kas XML- või JSON-alampuu aga võib olla ka terviku mingi muu alam-andmegrupp, mis on reeglites kirjeldatud ühtse tervikuna.  - ühe andmeelemendi kontrollimine (NOT NULL, vahemik, klassifikaator, pikkus, muster jms). Andmeelemendi kontrolli reeglite valimiseks tuleb osutada standardis olevale andmeelemendile, mille reeglite alusel kontrolli teostada soovitakse. Tegemist on liidesega, mille kaudu tehakse reaalsete, töös tekkivate andmete kontrolli ja see peab andmekontrolli mootorile (1) aru saadav olema (sisaldama sellekohast tunnust). See, millist toimingut tehakse ja millist reeglit kontrollimiseks kasutatakse määratakse liidese poole pöördumisel. Reegli määramine on küll vajalik ainult andmete alamosa ja andmevälja kontrollil, sest terviklikes andmetes peab olema viide standardile, millest järelduvad üheselt kontrolli reeglid. Liidese vastuseks on alati kas OK st vigu polnud või nii täielik vigade loend kui võimalik. Kõiki vead peavad olema tõlgendatavad masinmõistetavalt ja interpreteeritavad inimmõistetavalt. Liides on lahendatud REST protokolli alusel. API-TR See liides teeb kõike seda sama, mida liides API-AK selle vahega, et ei töödelda reaalseid andmeid vaid testandmeid. See peab olema aru saadav andmekontrollimoodulile (1) (sisaldama sellekohast tunnust). Liides on lahendatud REST protokolli alusel. Veeb-TR See liides teeb kõike seda sama, mida teeb API-TR liides, kuid see on lahendatud veebiliidesena, mida saab integreerida erinevatesse veebirakendustesse ja portaalidesse. Liides vahendab läbi testrakenduse päringut andmekontrolli mootorile (1). Määrata peab saama, millist päringu varianti kasutatakse (üks kolmest) ja millist reeglit kasutatakse. Seda viimast küll ainult andme alamosa ja andmevälja kontrollil, sest terviklikus peab olema niigi asjakohane viide. Visuaalse liidese kaudu antakse ette kontrolli reegel (kui seda pole kirjeldatud kontrollitavates andmetes) ja kontrollitavad andmed. Tagasi saadakse veateadete loend nii inim- kui masinmõistetaval kujul. Viimane võib olla ka liidese kaudu valitav st. millises formaadis veateateid saada soovitakse. API-RV Selle liidese kaudu saab pärida reeglite teegis (2) olevaid andmekontrolli reegleid. Realiseeritud on järgmised funktsioonid: - anna temaatiliste jaotiste loend (puuna interpreteeritaval kujul). - anna esimese taseme temaatiliste jaotiste loend. - anna selgelt viidatud temaatilise jaotise all olevasse alam-puusse kuuluvate temaatiliste jaotiste loend (puuna interpreteeritaval kujul). - anna selgelt viidatud temaatilise jaotise all oleva järgmise taseme temaatiliste jaotiste loend. - anna kõigi kehtivate reeglite loend; vaikimisi tänane kuupäev aga võib anda ette ka mingi teise (mineviku) kuupäeva; filtreerida peab olema võimalik ka temaatilise jaotisega, kuhu kuuluvaid reegleid soovitakse saada; - anna selgelt viidatud reegli kõikide versioonide ja kehtivusaegade loend. - anna selgelt viidatud reegli kehtiv kirjeldus. - anna selgelt viidatud reegli määratud versiooni kirjeldus. Seejuures reegliteks on siin ainult terviklikud reeglite komplektid. Kui vaja on alamosa tuleb terve reegel välja lugeda ja sealt ise vajalik osa üles leida. Liides on lahendatud REST protokolli alusel. Veeb-RV See liides teeb kõike seda sama, mida teeb API-RV liides, kuid see on lahendatud veebiliidesena, mida saab integreerida erinevatesse veebirakendustesse ja portaalidesse. Kogu API-RV funktsionaalsus peab olema lahendatud mugava ja turvalise kasutajaliidesena. API-RE Selle liidese kaudu saab hallata reeglite teegis (2) olevaid andmekontrolli reegleid. Realiseeritud on järgmised funktsioonid: - lisa uus temaatiline jaotis (juur-jaotis või alamjaotis teise temaatilise jaotise alla) - muuda temaatilise jaotise nimetust; - sule temaatiline jaotis; - lisa temaatilise jaotise alla uus andmekontrolli reegel; - lisa andmekontrolli reegli uus versioon; - muuda andmekontrolli reegel kehtetuks. Liides on lahendatud REST protokolli alusel. Veeb-RE See liides teeb kõike seda sama, mida teeb API-RE liides, kuid see on lahendatud veebiliidesena, mida saab integreerida erinevatesse veebirakendustesse ja portaalidesse.  Kogu API-RE funktsionaalsus peab olema lahendatud mugava kasutajaliidesena. 1.1. Tsentraalselt paigaldatud andmekontrollimoodul Tsentraalselt, ühe ilminguna, paigaldatud andmekontrollimooduli komponentskeem näeb välja järgmine: cmp 02. Kesksüsteem TIS kesksüsteemi Seirerakendus ELK Stack . Andmekontrollimooduli paigaldatuna keskele Logid API-AK Andmete vastuvõtja (REST) Andmekontrollimoodul API-RE Seire ja valideerimise (REST) REST Standardite loomise moodul keskkond API-TR API-RV Veeb-TR Veeb-RV tegelikud andmed ainult kontrolliks (REST) (REST) andmed testandmed X-tee X-tee REST REST TTO infosüsteem TTO tarkvara arendaja Teabekeskus (1...N) arenduskeskkond Joonis 2. Tsentraalselt paigaldatud andmekontrollimoodul Legend: sinine – andmekontrollimoodul koos andmete vastuvõtjaga, hall – TEHIK-u keskkonnas paigaldatud TIS ja logide haldus, roosa – TTO-de ja nende partnerite keskkondades paigaldatud süsteemid, roheline – TEHIK-u keskkonnas paigaldatud metaandmete haldamise vahendid. Joonise selguse huvides ei ole siin näidatud andmekontrollimooduli sisemist struktuuri vaid ainult selle liidesed. Andmekontrollimooduli sisemine struktuur on esitatud joonisel 1. Andmekontrollimoodul peab logima kõiki selle kasutamise juhtumeid. Selleks saadetakse iga kontrolliakti ja ka ebaõnnestunud pöördumise kohta logikirje „seirerakendusse“. Seirerakendus kogub kokku kõik logid kokku ja võimaldab nende analüüsi. „TTO infosüsteemidel“ (terviseteenuse osutajate infosüsteemidel) on kesksüsteemiga võimalik saada ühendust kahel viisil – kas andmete edastamiseks või lihtsalt andmete kontrolliks. Esimesel juhul (andmete edastamisel) saadab „TTO infosüsteem“ andmed läbi X-tee „Andmete vastuvõtjasse“, mis saadab andmed kontrolliks andmekontrollimoodulisse, kus teostatakse kontroll ja kui tulemus on positiivne (luba edasi liikumiseks on olemas), siis saadetakse saadud andmed TIS-i rakendusserveri URL-le sõnumina/dokumendina (sama x- tee SOAP sõnum). TIS-i rakendusserver teeb keerukamad kontrollid enne andmete baasi salvestamist. Võimalik on tagasiside. TIS kesksüsteemi URL-li taga on load balancer, klaster ja webMethods + Oracle. TTO-le tagastatakse kas eduka andmekontrolli läbimise teade või veateated. Päringu korral päringu vastus, mis võib olla väga mahukas. Veateated võivad pärineda andmekontrollimoodulist või kesksüsteemist. Kesksüsteemi kriitiliste vigadega andmeid vastu ei võeta. Kriitiliste vigadega andmed säilivad logis, kus esitatud andmed on seostatavad veateadetega. Teisel juhul (andmekontroll) võib TTO infosüsteem saata andmed kontrollimiseks läbi X-tee otse „Andmekontrollimoodulile“ (andmekontrolli mootorile). Sellisel juhul tehakse ainult andmekontroll koos vigade tagastusega, kuid andmeid TIS-i ei edastata. Konkreetses TTO-s on see pöördumise meetod kasutusel ainult siis, kui nad ei ole endale paigaldanud oma andmekontrollimoodulit ja kasutavad süsteemi siseseks andmete valideerimiseks keskset andmekontrollimoodulit. Joonisel kujutatud „TTO tarkvara arendaja arenduskeskkonna“ all ei ole siin joonisel mõeldud TTO jaoks arendatavat tarkvara vaid tarkvara arendaja arenduskeskkonna osa, millega ta testib enda poolt loodud rakenduste abil koostatud andmete valideeruvust läbi masinliidese. Siin võib kasutada REST liidest kuna tegemist on testandmetega. Sama moodi saab REST liidest kasutades ehitada arendaja oma arenduskeskkonda ligipääsu andmekontrollireeglite vaatamiseks. Nende liideste kasutamine sõltub otseselt arendaja otsustest. „Teabekeskus“ on Sotsiaalministeeriumi haldusala infosüsteemide jaoks loodav metaandmete avaldamise keskkond, kuhu peab saama viia välja testrakenduse ja reeglite vaaturi veebiliidesed. Tegelikult võib selle koha peal seista mistahes veebirakendus või portaal, kus on vaja avaldada liidesed testrakendusele või valideerimisreeglite vaaturile. „Standardite loomise keskkond“ on rakendus, kus luuakse dokumentide edastamise standardid, päringute ja päringu vastuste standardid, klassifikaatorid ja OID-ide kirjeldused. Nende kirjelduste loomise käigus kirjeldatakse ka andmekontrollide kirjeldused. Nende kirjelduste alusel saab genereerida andmekontrollireeglid, mis sealt edastatakse „Andmekontrollimoodulisse“ (Reeglite teeki). Reeglite struktuur kirjeldatakse andmekontrollimooduli nõuetega. Kuna esialgu andmete kirjeldamise moodulit veel olemas ei ole (seda luuakse paralleelselt teise hanke raames) tekkib suure tõenäosusega situatsioon, kus andmekontrolli reegleid tuleb kirjutada käsitsi. Seepärast peab kirjelduse struktuur olema selline, mida on mugav jälgida ka inimesel (näit. XML või JSON). Oluline märkus: Täna kehtivas lahenduses jõuavad TTO-delt edastatud andmed X-tee-lt esimesena Seire ja valideerimise moodulisse, mis on iseseisev rakendus, mille kohane dokumentatsioon on hanke materjalide hulgas. Ülal oleval pildil paikneb see andmete vastuvõtja positsioonis. See rakendus tuleb selles positsioonis säilitada aga seda tuleb täiendada ühel või teisel viisil järgnevalt: (1) Seire ja valideerimise moodulisse tuleb lisada loogika, mis oskaks uued või selleks välja valitud sõnumid / dokumendid edastada kontrolliks andmekontrollimoodulile, ise sellekohased kontrollid jättes tegemata ja andmekontrollimoodulist saadud tagasisidele adekvaatselt reageerida. (2) Seire ja valideerimise moodul võtta uue andmekontrollimooduli ehitamisel aluseks ja kogu uus kasulik funktsionaalsus sinna sisse ehitada selliselt, et tervikust oleks eraldatav andmekontrollimoodul eraldi paigaldamiseks. Teisel variandil asenduks tänase seire ja valideerimise mooduli valideerimise osa täielikult andmekontrollimooduliga. Mõlema arengustsenaariumi korral, kui uus andmekontrollimoodul on üle võtnud kõik senised kontrollid ja seiramise funktsioonid on täielikult üle kolinud seirerakendusse, siis on võimalik tänane seire ja valideerimise moodul täielikult asendada andmekontrollimooduli ja seirerakendusega (ELK stack). Sõnumite / dokumentide eristumine toimub OID-i järgi, mis määrab üheselt ära standardi ja selle versiooni. 1.2. TTO-sse paigaldatud andmekontrollimoodul Suuremad TTO-d soovivad kindlasti paigaldada andmekontrollimooduli oma infotöötluskeskkonda. See ei ole küll kohustuslik aga võimaldab hallata oma infosüsteemi paremini. TTO haldusalasse harusüsteemina paigaldatud andmekontrollimooduli komponent skeem on järgmine:  cmp 03. Harusüsteem Andmete vastuvõtja Seirerakendus Seire ja valideerimise moodul . Andmekontrollimooduli harusüsteem X-tee logid Andmekontrollimoodul API-RE (REST) REST TTO infosüsteemi metaandmete süsteem REST API-AK (REST) Veeb-RV API-RV API-TR Veeb-TR (REST) TTO infosüsteem (REST) REST REST TTO tarkvara arendaja "Arendaja veeb" arenduskeskkond Joonis 3. TTO juurde paigaldatud andmekontrollimoodul (Legend: sinine – tsentraalne andmete vastuvõtjaga, mille taga on tsentraalne andmekontrollimoodul, lilla – TTO-s paigaldatud andmekontrollimoodul, roosa – TTO-de ja nende partnerite keskkondades paigaldatud süsteemid) TTO juurde paigaldatud andmekontrollimoodul töötab põhiosas samamoodi nagu tsentraalselt paigaldatud andmekontrollimoodul. Täpsustused ühenduste ja toimimise kohta on järgmised: - TTO infosüsteemi andmete kontroll toimub TTO-sse paigaldatud andmekontrollimoodulis; - siin ei ole TTO-delt andemete vastuvõtjat. Andmete saatmiseks Tervishoiu infosüsteemi peab TTO infosüsteem saatma andmed tsentraalselt paigaldatud andekontrollimooduli juures asuvasse andmete vastuvõtjasse läbi X-tee; - API-RE (andmekontrolli reeglite redaktor) liidesesse saab lülitada TTO infosüsteemi metaandmete kirjeldaja, kuid sellega ei pääse ligi tsentraalselt kirjeldatud andmekontrolli reeglitele vaid ainult TTO enda jaoks selle sama liidese kaudu loodud andmekontrolli reeglitele. - seirerakendus on TTO enda seirerakendus ja sinna logide saatmine ei ole kohustuslik st see võib puududa. - veebiliidesed Veeb-TR (testrakenduse veebiliides) ja Veeb-RV (reeglite vaaturi veebiliides) ei ole kasutamiseks kohustuslikud kuid soovikorral võib TTO infosüsteemi arendaja avada need oma veebi kaudu. Samas, kui TTO soovib oma sisemises protsessiloogikas kasutada sarnast andmete kogumise loogikat nagu kasutatakse TIS-is, siis võib TTOs kasutada kesksüsteemiga samasugust paigaldust. 1.3. TTO-sse paigaldatud andmekontrollimooduli varustamine reeglitega Kui TTO-sse on paigaldatud andmekontrollimoodul tuleb tsentraalse andmekontrollimooduli reeglite teegis olevad reeglid sünkroniseerida kõikidesse TTO-des paigaldatud andmekontrollimoodulite reeglite teekidesse. Reeglite sünkroniseerimine tuleb üles ehitada selliselt, et reeglite muudatuse järel tsentraalse andmekontrollimooduli reeglite teegis jõuaks need mõistliku aja jooksul TTO-des paigaldatud andmekontrollimoodulite reeglite teeki. See „mõistlik aeg“ võib olla erinevate TTO-de puhul erinev ja see lepitakse kokku tulenevalt konkreetse TTO vajadusest ja võimekusest. Joonis 4. Andmete sünkroniseerimine tsentraalse ja TTO andmekontrollimooduli reeglite teekide vahel (legend: sinine – keskne andmekontrollimoodul, lilla – TTO-s paigaldatud andmekontrollimoodul) Sünkroniseerimise protsess ei ole aga lihtne andmebaaside samasse seisu viimine. Võimalikud on kaks erinevat varianti. Reegel võidakse sünkroniseeritakse märgisega „koheseks kasutamiseks“. Üldjuhul tähendab see seda, et tegemist on äärmiselt lihtsa muudatusega ja ohtu süsteemi tõrgeteks selle reegli rakendamisel pole. Reeglid võidakse sünkroniseerida ka märgisega „proovi kasutuseks“. Sellisel juhul ei rakendata neid reegleid mujal, kui ainult testliidestes. See võimaldab TTO arendaja poolel teha ära eelneva testimise ja pärast seda kui testimine on olnud edukas märkida reegel testituks. See osapool, kellel on reegel testitud, hakkab andmeid vahetama kasutades ka juba seda uut kontrolli. Sellest teavitatakse ka tsentraalset moodulid, et see võib ka antud TTO puhul hakata rakendama seda andmekontrolli. Enamuses tuleb kasutada seda viimast meetodit. Lõplikult otsustab seda, kumba meetodit kasutatakse, kesksüsteemi haldur. Kõigi uute (või muudetud) reeglite tekkimisest sünkroniseerimise kaudu TTO andmebaasi tuleb teavitada TTO või selle arendaja esindajat. TTO poolel peab saama peatada reegli kasutamise, kui selgus siiski, et kehtivas konfiguratsioonis reegel takistab süsteemi tööd. Kesksüsteemi halduril peab olema reegli globaalse peatamise võimalus aga see tuleneb juba tema üldistest õigustest reeglite süsteemi haldamisel. Seega on meil siin kolm andmevoogu: - uute reeglite sünkroniseerimine kesksest rakendusest TTO rakendusse; - reeglite testi läbimisest ja TTO-s rakendamisest teatamine TTO süsteemist kesksüsteemi; - reegli testimise staatuse tagasi võtmine ja sellest kesksüsteemi teavitamine. Reeglite sünkroniseerimine võib toimuda nii lükka meetodil st kesksüsteem saadab ise muudatused kõikidesse harusüsteemidesse või tõmba meetodil st TTO-de andmekontrollimoodulid küsivad aegajalt kesksüsteemilt, kas uusi muudatusi on tekkinud. Süsteemi dünaamika seisukohalt tundub viimane viis otstarbekam – see võimaldab reeglite rakendamist juhtida TTO-de poolt. 1.3.1. Reeglite kasutusele võtmine andmekontrolli kesksüsteemiga liidestatud TTO-de infosüsteemides Kui TTOs ei ole paigaldatud oma andmekontrolli mootorit, siis kasutatakse selle infosüsteemis andmekontrolliks keskset andmekontrollimoodulit. See ei vähenda kuidagi ohtu, et uue andmekontrolli kirjeldamine ei tekita häireid TTO infosüsteemi töös. Ei ole aga mõttekas (ega isegi võimalik), et iga TTO hakkas aktsepteerima kõiki reegleid. Seepärast tuleb siin see aktsepteerimine lahendada tooteversioonide kaupa. Selleks peab olema keskses andmekontrollimoodulis teatmik selle kohta, millise toote millist versiooni konkreetne TTO kasutab. Selle peavad saama registreerida TTO-dele infosüsteeme müüvad/arendavad ettevõtted. Kui süsteemi tekkib uus reegel tuleb sellest teavitada TTO-de infosüsteemide arendajaid, kes peavad reegli konkreetse toote, konkreetse versiooniga ära testima ja märkima reegli testituks. Sellisel juhul hakatakse seda reeglit rakendama kõikides TTO-des, kus on selle konkreetse toote testitud või hilisem versioon. Konkreetse toote arendaja peab saama võtta „kasutuses“ märke tagasi ja viima selle staatusesse „testimisel“, kui reegli rakendamisest ikkagi probleeme tõusis. 1.3.2. Reeglite automaatne „testimise“ staatusesse tagasi viimine Kirjeldatavat meetodit ei rakendata süsteemi esimeses realisatsioonis, kuid tulevikule mõeldes peab süsteemis olema funktsionaalsus, mis jälgib uute reeglite rakendumist ja kui pärast mingi reegli rakendumist ei läbi ükski andmekomplekt (või on neid andmekomplekte „liiga palju“) enam andmekontrolli, siis langetama reegli „testimisel“ staatusesse tagasi. Jälgimine peab toimuma TTO-s paigaldatud andmekontrolli mootoris selle TTO andmete alusel ja kesksüsteemis toodete ja toote versioonide tasemel üle kõigi neid kasutavate TTO-de. Kui oli olemas eelmine reegel, mille uus reegel asendas, siis taastatakse eelmise reegli aktiivsus. See protsess ei tohi jälgida „testimisel“ staatuses reeglite kasutamist. 2. Komponentide kirjeldused 2.1. Reeglite teek Reeglite teegis hoitakse kõiki reegleid, mille alusel andmekontrolle tehakse. Soovitavate reeglite liikide loend on lisas 1. Esitatud loendit tuleb vaadelda indikatiivsena, kui vajaduste loendit. Mõne olemasoleva reeglite formalismi (näiteks XML Schematroni) kasutamisel on funktsionaalne ulatus läbiräägitav. Lubatav on ka realisatsiooni spetsiifikast tulenev jaotus. Näiteks klassifikaatoritele vastavuse kontrolle ei pruugi olla võimalik valitud formalismis optimaalne teostada. Projekti käigus tuleb välja töötada süntaks või võtta kasutusele mõni olemasolev, millega kirjeldatakse andmekontrolli reegleid. Tuleb arvestada, et kontrollitavad andmed on XML või JSON vormingus ja tuginevad HL7 standarditele CDA, V3 ja FHIR. Kesksüsteemi andmekontrollimooduli reeglite teegis on ainult need reeglid, mis on kirjeldatud TEHIK-us. Reeglite teeki hallatakse reeglite redaktoriga või läbi teegi enda kasutajaliidese. Reegleid peab saama teeki laadida ka otse failist. TTO-sse paigaldatud andmekontrollimooduli reeglite teegis on kahe skoobiga reegleid. Esiteks need reeglid, mis on kirjeldatud TEHIK-u poolt keskse andmekontrollimooduli reeglite teegis ja mis on sünkroniseeritud sealt TTO keskkonda. Ja teiseks need reeglid, mis konkreetne TTO on sinna oma vajaduste tarbeks pannud ja mida kasutab ainult nende infosüsteem. Selleks saab kasutada kas reeglite redaktori või oma haldamise keskkonda. Reeglite teek peab olema struktureeritud selliselt, et oleks võimalik eristada erinevate äriprotsesside/rakenduste vajadusteks kasutatavaid reegleid. Üldistatuna võib see struktuur välja näha selline: - Valdkond o Rakendus  Teema 1  Teema 1.1 o ...  Teema 1.1...1  Komplekt 1 o Reegel 1 o Reegel2 o ...  Komplekt 2 Reeglite teegi töö skoopi kuulub ka reeglite struktuur välja pakkumine. Struktuur peaks olema loodud selliselt, et sinna saaks hiljem lisada teiste valdkondade/rakenduste reegleid. Andmekontrollireeglid peavad olema pöördutavad iseseisvalt (st reeglil peab olema otse viide või identifikaator). Otsene viide peab olema kasutatav andmestruktuuride kirjelduse nendest kohtades, kus neid kontrolle rakendatakse. Andmekontrolli reegleid peab olema võimalik grupeerida koos kasutatavateks (st samale andmeelemendile või samale kohale rakenduvateks) reegliteks (Komplekt 1, Komplekt 2). Reegleid peab saama deaktiveerida ja aktiveerida koos selle jõustumise ajaga (aeg sekundi täpsusega). Reeglite teegis olevaid reegleid, mida on kord aktiveeritud, enam ei kustutata vaid versioneeritakse. Käibelt kõrvaldatud versioonid või reeglid peab saama märkida „maha jäetuks“. Siin peab samuti olema ajamärge sekundi täpsusega. 2.2. Reeglite redaktor Käesoleva projekti raames luuakse uus reeglite redaktor või võetakse kasutusele mõni olemasolev lahendus ja kohandatakse seda vajadustele, mis võimaldab reeglite teeki laadida otse või vahendatult reegleid, kirjutada reegleid üle ja kustutada neid. Reegleid peab olema võimalik valideerida (struktuur peab olema õige). Reeglite teeki ei tohi kirjutada vigaseid / mitte toimivaid reegleid. Reeglitena ei mõelda siin andmete struktuuride kirjeldusi vaid ainult andmekontrolli reeglite kirjeldusi. Reeglite redaktor keskendub andmekontrolli reeglite loomisele aga samas peab olema võimalik hallata reeglite struktuuri ning sellese reegleid lisada, uuendada ja eemaldada (kui reegel juba kasutusel, siis tähendab eemaldamine seisundit „maha jäetud“). Haldamine dubleerib kasutusmugavuse huvides osaliselt reeglite teegi funktsionaalsust. Andmestruktuuride kirjeldused luuakse TEHIK-us teise tarkvaraga (selle kohta hange käib) ja kirjutatakse läbi API liidese reeglite teeki või toimub seostamine mõnel teisel viisil. Oluline on aru saada täpselt, et millist kohta või omadust andmete struktuuris antud reegel või reeglite komplekt kontrollib. Tuleb arvestada ka olukorraga, kus andmete struktuuri kirjeldamise vahend puudub. Sellisel juhul peab olema võimalik reegleid kirjeldada võttes aluseks mõne XML näidise või reegleid kirjeldada redaktoris otsest seost loomata. Selliselt loodud reeglid peavad olema töövõimelised. Lubatav on luua andmete struktuuri salvestamiseks reeglite teeki minimaalne kasutajaliides, mille abil saab ühe pika tekstina reeglite teek esitada andmevahetuse struktuure, neid üle kirjutada ja eemaldada. Reeglite redaktor suhtleb reeglite teegiga eelistatult REST API liidese kaudu. 2.3. Reeglite vaatur Reeglite vaatur peab adapteeruma reeglite teegi struktuurile ja võimaldama mugaval ja arusaadaval kujul sirvida kõiki reegleid ja reeglite komplekte. Reeglite vaatur luuakse veebiliidesena või võetakse kasutusele mõni olemasolev ja kohandatud lahendus, mida on võimalik adapteerida nii veebirakendustesse kui veebilehtedele. Reeglite vaaturiga peab saama näha nii andmete struktuuri kirjeldusi kui ka andmekontrollireegleid. Kui andmete struktuuri kirjeldused puuduvad, siis ainult andmekontrollireegleid. Reeglite vaatur pärib reeglite teegist andmeid eelistatult läbi REST API liidese. 2.4. Sünkroniseerija Kesksüsteemi sünkroniseerija vahendab kesksüsteemi reeglite teegis olevad uued reeglid, reeglite muudatused ja reeglite kasutuselt kõrvaldamised harusüsteemide sünkroniseerijate kaudu harusüsteemide reeglite teekidesse. Harusüsteemidest vahendatakse kesksüsteemile andmeid reeglite kasutuselevõtu kohta. Suhtlus sünkroniseerijate vahel toimub eelistatult X-tee kanali kaudu. 2.5. Andmekontrolli mootor Andmekontrolli mootor kontrollib temale läbi REST API-AK liidese saadud andmeid (tänases mõistes XML dokumente) reeglite teegis olevate reeglite põhjal. Lubatav on ka mõni teine liidestus, kuid see tuleb kokku leppida detailprojekteerimise ajal. Koos kontrollitavate andmetega peab saabuma üheselt mõistetav viide reeglile, reeglite komplektile, reeglite komplektidele või kontrolliprotseduurile (mis määrab rakendatavad reeglid ja nende reeglite rakendamise järjekorra), mille alusel andmeid tuleb kontrollida. Üheselt mõistetavus võib järelduda ka andmetest. Kontrolli tulemuseks on esinevate vigade masinmõistetav loend (mis võib olla tühi, kui vigu ei leitud), mis tagastatakse andmete kontrolli saatjale. Vigade loend peab olema interpreteeritav ka inimmõistetavalt. Kõik sisulised (st mitte test) andmekontrollid logitakse analüüside vajaduseks. Hajusa paigalduse korral peab olema võimalus logide saatmiseks kesksüsteemi. Andmekontrollimoodul peab olema suuteline teostama vähemalt lisas 1 nimetatud ulatuses kontrolle. Esitatud loendit tuleb vaadelda indikatiivsena, kui vajaduste loendit. Mõne olemasoleva reeglite formalismi (näiteks XML Schematroni) kasutamisel on funktsionaalne ulatus läbiräägitav. Hanke dokumentide hulka on lisatud kogu tänane Schematronide põhine kontrollide hulk, et anda pakkujale ammendav teadmine tänaste kontrollide ulatusest ja keerukusest. Samuti on lisatud Exceli tabel mille põhiselt kontrolle täna hallatakse. Kontrollitavate dokumentide näidistega saab tutvuda Publitseerimise keskuse leheküljel. Näiteks http://pub.e-tervis.ee/standards2/Standards/8.0, kus tuleb vaadata XML laiendiga faile. Kontrollimise järjekord on järgmine: 1. Kõigepealt kontrollitakse andmete või selle alamosa struktuuri vastavust XSD-le. Andmete all mõeldakse XML dokumenti või sõnumit (CDA, V3 või FHIR). Alamosa suurus on detailprojekteerimise kokkuleppe küsimus. 2. Seejärel tehakse reeglite teegist leitud andmekontrollid. Kui toimus esimese sammus „põrumine“, siis järgmise sammu juurde ei minda. Tagastatakse XSD-de mittevastavuse vead. Siinkohal rõhutab üle, et peab olema võimalik kontrolle adresseerida ühe andmeelemendi (XML taagi) täpsusega. Arvestades CDA-s laialdast taagi siseste parameetrite kasutust, peab olema võimalik adresseerida ka taagi parameetri täpsusega. 2.6. Testrakendus Testimise vajaduseks luuakse rakendus või kohandatakse mõnda olemasolevat, millega saab andmekontrolli mootorile saata andmekirjeid testimiseks masin- ja inmliidese vahendusel. Testrakendus peab võimaldama andmekontrolli mootorile saata andmed ja viite kontrollireeglitele (mis võib sisalduda ka andmetes). Andmekontrolli tulemusena tagastatakse vigade loend, kui vigu leiti, või teade, et andmekontroll läbiti vigu leidmata. Testrakendus luuakse ka veebiliidesena, mida on võimalik adapteerida nii veebirakendustesse kui veebilehtedele. 2.7. Andmete vastuvõtja Selle kesksüsteemi komponendi ülesandeks on läbi X-tee võtta TTO-delt vastu andmeid, saata need läbi REST API andmekontrollimoodulisse ja sõltuvalt vastusest edastada need TIS-i. Andmete saatjale tagastatakse vead või teade, et vigu ei olnud. Andmete vastuvõtja peab olema suuteline jagama saabuvaid andmed olemasoleva valideerimise mooduli ja uude andmekontrollimooduli vahel. Andmete vastuvõtja on olemasolev rakendus, mille nimi on „Seire ja valideerimise moodul“. Selle kohane dokumentatsioon on lisatud hanke materjalide hulka. Läbi selle laekuvad praegu kõik andmed TTO-delt. See komponent tuleb ringi kirjutada peatükis 1.1 toodud olulise märkuse kohaselt. 2.8. Seirerakendus TEHIK-us on seiramiseks kasutusel ELK Stack kasutajaliidesega Kibana. Hankija eeldab sellega arvestamist. Logikirjed peavad olema JSON vormingus. LISA 1: Andmekontrollide sisu määratlus I. Andmeelemendile rakendatavad piirangud: NOT NULL – kontrollitakse, kas väärtus on olemas (viga, kui väärtus puudub). NULL – kontrollitakse, et väärtust ei oleks (viga, kui väärtus olemas); kasutatakse juhtudel, kui antud vormingu kasutamisel selles kohas ei ole see väärtus lubatud. Andmetüüp – Text (vaba (pikk) tekst), Char („lühike“ tekst) Numeric (n/m-n) (komaga arv, millel on n kohta pärast koma (n) või kuni m-n kohta pärast koma (m-n)), Integer (täisarv), Date (kuupäev kujudel yyyy-MM-dd, MM/dd/yyyy või dd.MM.yyyy, kui formaati pole ette antud, muidu vastavalt formaadile), Time (kellaaeg kujul hhhh:mm[:ss]) Pikkus – väärtuse pikkuse piirang, esitatakse kujul n (kuni n tähemärki ja kus n>0) või m-n (m kuni n tähemärki, kus m>=1 ja n>=m) Miinimum väärtus – väärtus, millest väiksem ei saa atribuudi väärtus olla. Maksimaalne väärtus – väärtus, millest suurem ei saa atribuudi väärtus olla. Seotud klassifikaator – klassifikaator, millest valitakse atribuudi väärtus Klassifikaatori seose tugevus (koos eelmisega) – kas klassifikaatori kasutamine on kohustuslik (TRUE), või soovitav (FALSE) Stringi leidumine – etteantud stringi (silbi, sõna või lause leidumine) väljas. Võimalik märkida ka võrdluse täpsust (täpne vastavus, tõstutundete vastavus, tühikuid eirav vastavus, hajus vastavus jt) Formaat – välja sisemise struktuuri määraja; Valik loendist: o E_mail – kontrollitakse, kas atribuudi väärtus vastab e-maili aadressi vastab regulaaravaldisele:  a[{a}][{.a[{a}]}]@ a[{a}][{.a[{a}]}].bb[b] ja kus a on suvaline täht, number või alakriips ja b suvaline täht o Eesnimi – kontrollitakse, kas sisestatud tekst vastab regulaaravaldisele: aa[{a}]{(<tühik>{<tühik>}|{<tühik>}-{<tühik>})aa[{a}]} ja kus a on suvaline täht. o Perekonnanimi – kontrollitakse, kas sisestatud tekst vastab regulaaravaldisele: aa[{a}]{(<tühik>{<tühik>}|-)aa[{a}]} ja kus a on suvaline täht. o Isiku_nimi – kontrollitakse, kas sisestatud tekst vastab regulaaravldisele: <Eesnimi><tühik>[{<tühik>}]<Perekonnanimi> ; kuna eesnimi ja perekonnanimi on sama formaadiga, siis ei ole olouline kummas järjekorras nad selles regulaaravldises on. o EE_Isikukood – kontollitakse atribuudi väärtuse vastavust eesti isikukoodi reeglitele o Telefoninumber – kontrollitakse kas atribuudi väärtus, kui sealt on eemaldatud kõik tühikud, vastab regulkaaravldisele: [+]nnnnn{n} o Aadress – kontrollitakse vastavust ADS standardile o Muster - kontrollitakse vastavust mustri vormingule: Regulaaravaldis, mis kasutab järgmisi märke ja kasutatakse kombinatsioonist Char tüüpi atribuutidega:  [ ] – komkbinatsioon võib esineda või mitte  { } kombinatsioon võib esineda 2 kuni n korda  ( x|y|z|...) – valitakse üks alternatiividest   a – suvaline väike täht  A - suvaline suur täht  b – suvaline täht  x– suvaline sümbol  n – number 0...9  “x[{x}]“ – jutumärkide vahel konkreetne sümbolite kombinatsioon Kuupäeva mustrid - kontrollitakse vastavust mustrile dd.MM.yyyy, yyyy-MM-dd või MM/dd/yyyy ; kasutatakse kombinatsioonis andmetüübiga Date; kasutatakse juhul, kui tahetakse üks konkreetne formaat ära fikseerida, muidu piisab ainult andmetüübi Date määramisest. II. Andmeelementide vaheliste seoste kontroll (andmeploki sees) Kas ühe andeelemendi väärtus on teise andmeelemendi väärtusest:  suurem(või võrdne)  väiksem(või võrdne)  võrdne Kui ühel (määratud) andeelemendil on väärtus olemas, siis peab olemas olema väärtus teisel (määratud) andeelemendil (teistel (määratud) andmeelementidel). Kui ühel (määratud)andeelemendil on väärtus olemas, siis ei tohi teisel (määratud) andeelemendil (teistel (määratud) andmeelementidel) väärtust olla Kui ühel (määratud) andmeelemendil ei ole väärtust olemas, siis peab olemas olema väärtus teisel (määratud) andeelemendil (teistel (määratud) andmeelementidel). Kui ühel (määratud) andmeelemendil ei ole väärtust olemas, siis ei tohi teisel (määratud) andeelemendil (teistel (määratud) andmeelementidel) väärtust olla Märkus: Tingimuse aluseks oleva atribuudi andmete olemasolu võib olla seotud ka atribuudi mingi konkreetse väärtusega. Sellisel juhul võivad ka seotud väljade väärtused olla seotud mingi konkreetse väärtusega või siis väärtuste loenditega. Märkus 2: atribuutide kohustuslikkus võib olla asendatud ka lubatavusega. III. Andmeelementide ja andmeplokkide vaheliste seoste kontroll Kui ühel (määratud) andeelemendil on väärtus olemas, siis peab olemas olema konkreetne määratud andmeplokk (andmeplokid). Kui ühel (määratud) andeelemendil on väärtus olemas, siis ei tohi olemas olla mingit konkreetset (määratud) andmeplokki (andmeplokke). Kui ühel (määratud) andeelemendil ei ole väärtust olemas, siis peab olemas olema konkreetne määratud andmeplokk (andmeplokid). Kui ühel (määratud) andeelemendil ei ole väärtust väärtus olemas, ei tohi olemas olla mingit konkreetset (määratud) andmeplokki (andmeplokke). Märkus 1: Tingimuse aluseks oleva atribuudi andmete olemasolu võib olla seotud ka atribuudi mingi konkreetse väärtusega, mille tulemusena mingid andmepolokid kas on nõutud või mitte. Märkus 2: andmeplokkide kohustuslikkus võib olla asendatud ka lubatavusega. IV. Andmeplokkide vaheliste seoste kontroll Sama mis eelmise plokis aga andmeplokkide kohustuslikkust, keelatavust ja lubatavust tingivad mingi teise andmeploki olemasolu või puudumine