Hankeleping nr 3-9/2264-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 8, 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 „TIS andmeedastusstandardite loomise keskkond“ (projekti
number 2014-2020.12.03.19-0608) 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 183815 ) 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. Teabekeskuse testimine OWASP ASVS v4.0 Level 1 testimise metoodika alusel vastavalt
punktis 8.1 toodud tingimustele.
4. Töötundide maht 105 tundi.
5. Tööde teostamise tähtaeg 29.01.2021, töödega alustatakse pärast lepingu allkirjastamist.
6. Tööde maksumus on 12 075 eurot, millele lisandub käibemaks.
7. Vajadusel muud tingimused:
7.1 Infosüsteemidele ligipääsemiseks tuleb suhelda Tellija kontaktisikuga, kelleks on testijuht Bret
Rand (e-posti aadress:
[email protected] ).
8. Lepingule on allkirjastamisel lisatud:
8.1. Täitja pakkumus failis TT_55-Teabekeskus_ASVS-L1.docx.
8.2. Lisa 1 Teabekeskuse standardite haldamise arhitektuur ver211.docx.
8.3. Lisa 2 Teisel infopäeval näidatud prototüübi ekraanipildid.docx.
8.4. Re Teabekeskuse turvatestimine.msg.
Tellija: Täitja:
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Saatja: Mehis Hakkaja <
[email protected]>
Saaja: Bret Rand
Teema: Re: Teabekeskuse turvatestimine
Tere Bret,
Vastavalt viimastele soovidele nüüd täidetult ning allkirjastatult uuesti manuses.
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 Fri, Feb 28, 2020 at 2:47 PM Bret Rand <
[email protected] <mailto:
[email protected]> > wrote:
Tere!
Vaatasime projektijuhiga peale ja meile sobiks kui turvatestimine ja logide turvatestimine on testitud OWASP ASVS Level 1 tasemel. Et mahtuda planeeritud eelarvesse loobume esmasest testimisest. Kõik muus osas on pakkumus sobiv, aga loobume esmasest testimisest ja logide turvatestimine peaks olema OWASP ASVS Level 1 tasemel.
Täiendasin turvatestimise taotlust, et palun esitada uus pakkumus.
Bret
From: Bret Rand
Sent: Friday, February 28, 2020 14:01
To: 'Mehis Hakkaja' <
[email protected] <mailto:
[email protected]> >
Subject: RE: Teabekeskuse turvatestimine
Selge. Ma siis teavitan projektijuhti ja arutame, mida saaks veel koomale võtta, et mahtud planeeritud eelarvesse.
Bret
From: Mehis Hakkaja <
[email protected] <mailto:
[email protected]> >
Sent: Friday, February 28, 2020 13:50
To: Bret Rand <
[email protected] <mailto:
[email protected]> >
Subject: Re: Teabekeskuse turvatestimine
Logidega jauramine on pigem selline aeganõudev, et kui teha, siis põhjalikult. Aga kui tahate seal mahtu kokku tõmmata pinnapealsemaks, siis võime selle logide osa 16h peale tõmmata 24h asemel.
Parimat,
Mehis
On Fri, 28 Feb 2020, 13:13 Bret Rand, <
[email protected] <mailto:
[email protected]> > wrote:
Tere!
Kas logide testimine on siis arvestatud OWASP ASVS Level 2 alusel või OWASP ASVS Level 1 alusel? Uurisin täna OWASP ASVS skoopi ja vaatasin erinev maht logide teemal on tasemel OWASP ASVS Level 2 ja OWASP ASVS Level 1.
Bret
From: Mehis Hakkaja <
[email protected] <mailto:
[email protected]> >
Sent: Friday, February 28, 2020 13:01
To: Bret Rand <
[email protected] <mailto:
[email protected]> >
Subject: Re: Teabekeskuse turvatestimine
Tere Bret,
Saadan täidetult ja allkirjastatult TT_55.
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 Thu, Feb 27, 2020 at 1:50 PM Bret Rand <
[email protected] <mailto:
[email protected]> > wrote:
Tere!
Vaatasime pakkumuse üle ja hindasime, kas saab taset madalamaks panna. Otsustasime, et taseme saab madalamaks panna OWASP ASVS level 1 kuid soovime, et turvatestimise sisse jääks ikka ka logid.
Täiendasin turvatestimise taotlust selles osas.
Bret
From: Bret Rand
Sent: Thursday, February 20, 2020 13:27
To: Mehis Hakkaja <
[email protected] <mailto:
[email protected]> >
Subject: Teabekeskuse turvatestimine
Tere!
Uus CEF projekti Teabekeskus on plaan varsti hakata arendama. Nüüd on vaja tellida sellele turvatestimine.
Lisan manusesse kõik vajalikud dokumendid ning lisaks kui soovite prototüüpi näha, siis võib kokkuleppida koosoleku ja meie inimesed saavad Teile tutvustada seda.
Pakkumust ootame uue turvatestimise raamlepingu 3-9/1607-1 pealt.
Bret
Teabekeskuse standardite haldamise arhitektuur
Versioon 2.1
Dokumendi kohta
Käesolev dokument kirjeldab Teabekeskuse standardite haldamise lahenduse visiooni, mis on laiem
kui riigihanke „Tervise Infosüsteemi andmeedastusstandardite loomise keskkond“ skoop. Hankest
välja jäävad osad on tekstis kuvatud hallis kaldkirjas. Tervikliku ülevaate huvides on need teksti sisse
jäetud, kuid neid ei tuleks lugeda hanke skoopi kuuluvaks.
Sissejuhatus
Tänane tööprotsess ja töövahendite võimalused dokumendi- ja sõnumistandardite loomeks,
haldamiseks ja avaldamiseks on mitterahuldavad. Peamisteks puudusteks on:
Kohmakus avaldamisel – keerukas või peaaegu võimatu on avaldada standarditest uusi
versioone iseseisvalt. Avaldamine toimub kogumiku põhiselt. Vajadus on avaldamine muuta
standardite või standardite gruppide põhiseks ning võimaldada esialgset avaldamist.
Avaldatud materjal võib ka kehtivust kaotada.
Mudeli ja näidiste lahusus – mallimudelite ja XML näidiste sünkroonis hoidmine on käsitöö.
Puuduvad võimalused vastavuste automatiseeritud kontrolliks. Vajadus on luua mudelite,
näidiste ja stiililehtede täpseid vastavusi tagavad töövahendid.
Halb leitavus – kogu avaldatud materjal (standardid, näidised jt) on ühes ~500 failiga
kataloogis. Liigendus on minimaalne. Leidmist ja mõistmist abistavad tekstid ja võimalused
puuduvad. Vajadus on luua üldotsing, erinevad ankurleheküljed ja liigendused standardite ja
nende osade leidmiseks. Tähtsamad sõlmed varustada selgitustega.
Halb loetavus – mallimudel, mis peaks olema nö standardi tüvitekst, on raskelt loetav.
Peamiseks info allikateks on kujunenud näidis XML-id. Põhjuseks on mallimudeli halb loetavus.
Mallimudel peaks sisaldama ammendava teadmise standardite kohta. Näidised peaksid
ilmestama konkreetsete andmekoosseisudega mallimudelisse kätketud üldisi teadmisi.
Tööprotsessi aeglus – uute standardite loome ja olemasolevate muutmise tööprotsessid on
liiga aeglased. Uue standardi loomisel on tüüpiline tsükkel 1 aasta. Avaldamise tegevus on väga
kohmakas, võtab palju aeg (kuni 10 tundi) ja nõuab mitmete töötajate (sh.
süsteemiadministraatori) samaaegset kohalolu. Avaldamise tarkvara, mis ei olnud
projekteeritud nii mahukate materjalide avaldamiseks, pahatihti lõpetab tõrkega ja kogu
tegevust on vaja alustada otsast peale. Vajadus on võimaldada standardite loomes kasutada
ka iteratiivset ja eri osapooli kaasavat tööprotsessi. Standardi loome alates idee sünnist kuni
avaldamiseni peaks olema tehtav ka mõne kuuga. Avaldamise vahetu tegevus peaks olema
tehtav ühe inimese poolt peale mõnede valikute ja kinnituste andmist inimaja kasutuse mõttes
mõnede minutite kuni veerand tunni jooksul. Ülejäänud avaldamisega (publitseerimisega)
seotud tegevused peavad toimuma tarkvara poolt inimosalemist vajamata.
Visioon
Ületamaks sissejuhatuses toodud puudusi on vajalik luua uus töövahend (uued töövahendid), mis
võimaldaks ellu rakendada senisest efektiivsemaid ja paremat kvaliteeti tagavat tööprotsesse.
Tööprotsessi efektiivsuse mõõduks on kiirus ja tööjõu vajadus. Kiiruse all on mõeldud aega
tööpäevades mis kulub tervikuna standardi loomele, muudatuste teostusele või reageerimisele
avastatud veale, kuni standardi avaldamiseni. Tööjõu vajaduse all on peamine vajadus vähendada
välise partneri koormust ja süsteemiadministraatorite kohalolust avaldamisel.
Uue töövahend visioonilised eesmärgid:
1. Suurem sidusus
a. Uute standardite väljatöötamisel tuleb arvestada rohkem olemasolevatega, st.
vältida liialt sarnase tähendusega mallide teket.
b. Määrustesse minevad andmekoosseisud peaks saama võtta mallimudelitest, st.
loobuda tänasest eraldis seisvast käsitööst.
c. Näidis XML-id tuleb genereerida mallimudelitest. Näidiste käsitsi koostamine
peaks olema vaid erandlik.
d. Klassifikaatorid, OIDid ja andmekontrollid tuleb hoida ühes kohas, st. sama
element/mõiste oleks kasutusel mallimudelis ja haldusliideses ning samad
andmed ilmuksid välja sirvimisel ja otsimisel sõltumata sirvimise või otsimise
lähtekohast.
2. Laiemad tööprofiilid ja ühiskasutatav keskkond
a. Tuleb vähendada erinevust sisulise ja tehnilise standardimise vahel. Sisu eest
vastutajad peavad rohkem valdama tehnilist poolt ja vastupidi.
b. Vajalik on ühiskasutatav standardimise töökeskkond, kus eri ülesannetega isikud
saaksid oma pädevuse piires tulemite valmimisse oma panuse anda.
Töökeskkonnale tagada ligipääs ka välistele partneritele.
3. Standardite eskiis- ja tööversioonid – vajalik on luua võimalus koostada standardite ja
mallimudelitest eskiis- ja tööversioone. Eesmärk oleks loobuda STRK dokumentidest.
Standardimise varajase järgu jaoks tuleks luua spetsialiseerunud kasutajaliidesed.
4. Standardite, mallide jt. mõiste vabam kommenteerimine – võimalused salvestada
standardimise tööprotsessi ajal kogunenud kaasnevat teavet, valikute põhjusi ja infot
toimunud oluliste arutluste kohta. Täiendavat infot peaks saama lisada standardite, mallide,
klassifikaatorite, OID-de jt. mõistete juurde.
5. Muudatuste ajaloo säilitamine – võimalus tagant järgi jälgida toimunud muudatusi sisu, aja ja
teostaja täpsusega.
6. Avaldamise lihtsus – standardite, klassifikaatorite, OIDide, andmekontrollid ja juhendite
(dokumentide) vahetu avaldamine peab olema võimalik teostada ühe pädeva isiku poolt kuni
15-ne minuti jooksul.
Visioon standardimise tööprotsesside sammudest
Standardite loome uues töövahendis peaks olema avatud, kaasav, iteratiivne ja lame. Avatuse all
mõeldakse veebipõhist ligipääsu töös olevatele standarditele. Kaasamise all võimalust kaugtööna
standardeid muuta ja täiendada. Iteratiivsus tähendab võimalust standarditest avaldada ka esialgseid
versioone ja avaldamiseni on teostuslikult võimalikult lihtne. Lame tähendab üleliigsete tööprotsessi
sammude vältimist. Suures plaanis on standardi versiooni elutsüklis 2 seisundit – loomisel ja avaldatud.
Lähemal vaatlemisel on otstarbekas loomise seisundis eristada eskiisilist käsitlust ülejäänust.
Uue standardi loome. Eelduseks on sellekohase projekti käivitumine ja uue standardi kavandi
olemasolu.
1. Esmalt luuakse standardi juurelement ja mallimudelist otsitakse välja esmased kandidaadid ja
need kopeeritakse standardi käsitluse eskiisile. Puuduvad osad luuakse juurde pööramata
esialgu tähelepanu üksikasjade korrektsusele. Kõik eskiisile kopeeritud ja juurde loodud read,
mallid, klassifikaatorid, OIDid jt. elemendid on esialgses tähenduses. Sama standardi eskiisist
on võimalik ülal hoida mitut iseseisvat koopiat.
2. Eelnevalt nimetatud eskiise saab sirvida ja pea kõiki tegevusi saab teostada tabeli sarnastel
kuvadel. Nendelt kuvadelt on võimalik eksportida sisu Exceli, rtf või mõnesse teise formaati
eesmärgiga saata need asjast huvitatud osapooltele läbivaatuseks, kooskõlastamiseks ja
tagasiside andmiseks. Eskiisilisest standardist on võimalik andmeid eksportida ka osade kaupa.
3. Kooskõlastustelt saadud tagasiside sisestatakse uue standardi peamisele eskiisile. Tehakse
uued väljavõtted ja saadetakse uuele kooskõlastuse ringile. Andmekoosseise on võimalik välja
võtta seadusloome jaoks sobival kujul. Soovijatele saab eskiisilistele vaadetele anda ligipääsu
lugemise või ka kirjutamise õigustes.
7. Punkte 2 ja 3 korratakse kuni kogu andmestruktuur, klassifikaatorid jt materjalid on saanud
kõikidelt osapooltelt peamise kooskõlastuse ja rohkem olulisi täiendamise või muutmise
vajadust selles ei nähta. Kooskõlastuse andmine käib väljaspool rakendust. Iga standardi loome
juures on vähemalt üks vastutav isik kellel peab olema piisav ülevaade ja pädevus standardi
loomet hallata ja olulisi otsuseid langetada. Nagu näiteks eskiisi ridade seisundite muutmine
või üleminek tööprotsessi järgmisse sammu.
8. Samal ajal eelnevaga aga hiljemalt peale viimaste kooskõlastuste saamist asutakse loodud ja
muudetud malle siduma HL7 struktuuridega. Selle tarvis eskiisiline käsitlus jäetakse järkjärgult
maha. Puhtandandmed kopeeritakse standardi struktuuri loome ja halduse töölehele. Koos
HL7 struktuuri sidumisega toimub ka näidisandmete sisestamine. Peab olema võimalik lisada
sama standardi kohta erinevaid näidisandmete komplekte.
9. Kooskõlastamine osapooltega võib haldamise töölehtedelt tehtud väljavõtete abil jätkuda.
Lisandub võimalus väljavõte teha XML kujul. Samuti on vastavat kompetentsi ja pädevust
omavatel isikutel võimalik kaugtööna osaleda standardi tehnilises viimistlemises.
10. Mallimudelid viimistletakse näidis XML-de genereeritavale tasemele. See eeldab XML-i
koostamiseks vajalike kõikide üksikasjade paika panemist.
11. Peale piisava kaetuse ja kvaliteedi veendumuse tekkimist toimub standardi avaldamine.
Avaldada on võimalik ka esialgset versiooni. Sellisel juhul peaks versiooni number algama
nulliga. Alates versioonist 1 loetakse standard jõustunuks. Kõik avaldatud versioonid on
kättesaadavad ja on võimalik automaatselt leida nende vahelisi erinevusi.
Olemasoleva standardi muutmine
1. Muutmise minevast standardist tehakse töökoopia. Standardi viimase avaldatud versiooni
juurde ilmub märge „muutmisel“.
2. Muudatusi teostatakse haldamise töölehel. Eskiisilist käsitlust muutmise juures on
ebasoovitav, sest standardi muudatused ei tohi kujuneda niivõrd mahukaks, mis vajaksid
eskiisilise käsitlusele omast vabadust. Samas peab haldusrakendus võimaldama standardit viia
muutmise kohasesse eskiisilisse käsitlusse, sest praktikas tuleb ette olukordi, kus ikkagi
versioonide vahelised erinevused on väga suured.
a. Võimalik on teha väljavõtteid Excelisse ja saata need kooskõlastamisele huvitatud
osapooltele. Samuti on huvitatud osapooltel võimalik töös olevaid materjale sirvida ja
töös osaleda.
3. Laekunud ettepanekud viiakse sisse standardi töökoopiasse, kus on võimalik luua uusi malle,
mallidele uusi atribuute, luua uusi seoseid, olemasolevaid muuta ja eemaldada. Uute
klassifikaatorite või nende versioonide ja OIDide loome toimub eraldi ekraanikuvadel. Samuti
on andmekontrollide loome eraldi kuvadel. Uusi ja olemasolevaid on võimalik siduda
mallidega.
4. Standardist uue versiooni avaldamine toimub halduri baasist, millest saadakse kõik vajalik, sh.
standardi struktuur, näidisandmed, selgitused ja juhendid või viited nendele.
5. Avaldada on võimalik ka esialgselt. Sellisel juhul on avaldatud versiooni juures märge
„esialgne“.
Standardi seisundid (võib vaadelda ka elutsüklina):
olematus
Uue standardi algatamine uuena.
UUS / loomisel
Standardiga on töö lõppenud.
See on avaldamiseks valmis.
Standard võetakse muutmisele,
uue versiooni loomise huvides.
Uue standardi kustutamine.
Võimalik vaid tingimusel, kui Valmis MUUTMISEL
see standad pole avaldatud.
Standardist salvestatakse
maha uus versioon või
loobutakse uue versiooni
loomises.
Standardi kustutamine
Olematus
Uue joonise kommentaarid:
1. Standardi olekumudel on teadlikult valitud võimalikult lihtne. See juhib vaid rakenduse
funktsionaalsuse kättesaadavust aga ei pretendeeri standardi elutsükli kõikide sammude
kajastamisele.
2. Olekumudelis puuduvad olekud nagu näiteks „Avaldatud“ või „Avaldatud esialgselt“, sest
see kajastab vaid töökoopias olevate standardite olekuid. Avaldatud on need standardid,
mis on kopeeritud avalikku baasi. Standardi kui tervik (st. kõikide oma versioonidega) saab
olla korraga avaldatud ja muutmisel.
Vee olulisi nõudeid
1. HL7 struktuure (XSD faile) või teisi alusstruktuure peab olema võimalik importida
haldusrakendusse, et neid saaks kasutada mallide loomes.
2. HL7 alusstruktuuride XSD-d peavad olema samuti avaldatud Teabekeskuses ja neile peab
saama osundada fikseeritud URL-ga.
3. Stiililehti (XSL faile) peab olema võimalik standardite juurde laadida, neid hallata ja neile peab
olema võimalik osundada näidis XML-dest. Näidis XML-id peavad olema vaadeldavad koos
stiililehtedega.
4. Standardite, mallide, näidiste jt. mõistete eri versioonide vaheliste erinevuste kiire leitavus.
Erinevused peavad olema leitavad inimtööd kaasamata.
5. Alustruktuurid ja näidised peavad olema osundatavad fikseeritud URL-ga. Tänase pub.keskuse
hea omadus. Samuti peavad olema URL-iga osundatavad standardi ja mallid.
6. Standardid ja sellega seotud mõisted (mallid, HL7 klassid, OIDid, klassifikaatorid) ning nendega
soetud tekstid peavad olema üldotsinguga otsitavad avalikust liidesest.
7. OIDid, klassifikaatorid, XML näidised, XSD, standardid jt. materjalid peavad olema leitavad
Google otsinguga. Tänase pub.keskuse hea omadus.
8. Tänased XML näidised ja dokumendid on täis fikseeritud viiteid ja URL-e. Täiesti iseseisvaid
dokumente peaaegu ei ole. URL-ide osas töötab tänane pub.keksuse hästi. Olemasolevate
materjalide viited ja URL-id (sh. viited stiililehtedele) ei tohi Teabekeskuses avaldatuna
muutuda mittetoimivateks.
9. Tuleb leida lahendus rahvusvaheliste klassifikaatorite (nt SNOMED, LOINC, ATC jt), siseriiklike
registrite (nt ATC, Tervishoiutöötajad jt) ja OIDide mugavaks kaasamiseks standardite ja
nendega seotud näidiste loomeks. Iga klassifikaatori ja registri sidumine haldusrakendusega
vajab eraldi otsustamist.
10. Säilitada tuleb tänane standardite ja mallide võrkstruktuursus. Eelkõige tähendab see seda, et
mallide ühiskasutus eri standardites peab olema võimalik ka edaspidi. Lisaks mallidele on
ühiskasutuses ka OID-d ja klassifikaatorid, st. konkreetse OID-i või klassifikaatori poolt
vaadates peavad olema leitavad seotud mallid ja läbi ahelpäringu ka standardid.
Funktsioon
Peatükis tuleb juttu Teabekeskuse standardite haldamise ja avaldamise rakenduse funktsionaalsest
jaotusest. Suures plaanis on ette näha kogu funktsionaalsuse jagunemist kahe rakenduse vahel –
Haldusrakendus ja Avalik rakendus. Ajutiseks kasutamiseks on vajalik luua ka andmete migratsiooni
toetav rakendus. Haldusrakendus on mõeldud eelkõige maja siseseks ja seotud partneritele
kasutamiseks kogu vajaliku loome ja haldamisega seotud tegevuste jaoks. Avalik rakendus keskendub
eelkõige anonüümse inimkliendi ja masinkliendi teenindamisele.
Lisamärkusena olgu öeldud, et lühendi HL7 all mõeldakse baasstandardeid CDA, V3 ja FHIR. FHIRi
profiilide kirjeldamise ressurssi „StructureDefinition“ (..hl7.org/fhir/structuredefinition.html) kohaste
väljundite saamise funktsioonide valmistamine võetakse töösse mõnes järgnevas Teabekeskuse
arenduse etapis.
Funktsionaalne jaotus arvestab järgnevaid üldisi põhimõtteid:
1. Standardite loome ja muutmine toimub haldusrakenduses. EA rakendus leiab kasutamist vaid
ajalooliste andmete vaatamiseks. Täiesti uute standardite loome algab uues rakenduses.
2. Peale uue rakenduse valmimist tuleb minna selle rakenduse poolt toetatud standardimise
tööprotsessi kasutamisele.
3. Avaldatud standardeid ja muid materjale (klassifikaatorid, OIDid jt) saab otse muuta vaid
kirjavigade parandamise huvides. Uue versiooni loome otsustab parandaja.
4. Avaldamine toimub kasutaja algatusel töökoopia baasi andmete pealt.
a. EA baasis hoitakse vaid ajaloolisi andmeid. Nende kopeerimine uude baasi toimub
järk-järgult.
b. Kõik standarditega seotud andmed (standardite juurelemendid, mallid, mallide
atribuudid, seosed, kitsendused, atribuutide seosed HL7-ga, OID-id, klassifikaatorid,
kitsenduse, näidisandmed, juhendid jne.) hoitakse töökoopia baasis. Samuti ka OIDid,
klassifikaatorid või vähemalt nende esindajad, kui nende tegelik haldus toimub mujal.
5. Töökoopia ja EA baasi vahel toimub EA baasis hoitavate andmete järk-järguline üle toomine
töökoopia baasi kasutaja algatusel.
Haldusrakenduse funktsionaalne jaotus
Haldusrakenduse funktsionaalse jaotus käib vaid standardite loome ja avaldamise kohta. Ülejäänud
(OIDid, klassifikaatorid, andmekontrollid jt) on kirjeldamata. Nende kirjeldus tuleb hiljem või võetakse
üle mõne olemasoleva haldusrakenduse funktsionaalsus.
Esimese astme jaotuse all on mõeldud peamenüüd (Üldotsing, Standardid, jne). Teine tase väljendab
alammenüüd või vormi olulisemaid osi. Alates kolmandast tasemest on jaotus funktsioonide,
alamfunktsioonide või oluliste omanduste lõikes. Funktsioonile vastab rakenduses reeglina nupp või
tegevuslink/ikoon.
1. Üldotsing – võimaldab otsida täpse sõna või mitme sõna või silpide järgi standardite, mallide,
atribuutide, selgituste, klassifikaatorite, OIDide ja andmekontrollide hulgast. Seda juhul kui
otsingule on nimetatud andmeallikad kättesaadavad. Allikate kättesaadavus võib olla
raskendatud väliste haldussüsteemide korral.
a. Üldotsingu otsinguvorm – üks lahter, mille funktsionaalsus on sarnane Google
üldotsinguga.
b. Vastusloend – vastusloend on sarnande või samane avaliku osa üldotsinguga.
i. Vastusloendilt siirdumine seotud mõiste detailvormile – võimaldab liikuda ühe
klõpsaga seotud mõiste detailvormile. Näiteks leides klassifikaatori elemendi
on võimalik liikuda kogu klassifikaatori detailvormile. Leidsid malli, saad
liikuda malli detailvormile.
2. Standardid
a. Töös olevad standardid – standardite töökoopiad. Töökoopiasse tekib standard kas
läbi uue loomise või olemasoleva kopeerimise EA baasist. Kord töökoopiasse jõudnud
standard jääb sinna tähtjatult püsima (va. kustutamine eemaldab jäädavalt). Muutub
vaid tema seisund (vt. seisundigraafi).
i. Otsing – otsinguvorm töös olevate standardite hulgast otsitava leidmiseks.
Selle vormi vajalikkus võib-olla vähetähtis, sest tüüpiliselt ei tohiks palju
standardeid korraga töös olla. Tähendust omab filtreerimine seisundi järgi.
ii. Töös olevate standardite loend. Loendi veerud vastavalt prototüübile. Reale
klõpsates saab liikuda standardi detailvormile.
iii. Uue standardi algatamine – vorm uue standardi põhiandmete sisestamiseks ja
salvestamiseks. Vastav nupp peaks asuma loendivormi päises.
iv. Standardi kopeerimine ühisbaasist – võimaldab EA baasist kopeerida
standardi andmed töökoopiasse. Seda läheb iga standardi kohta vaja üks kord.
Standard saab seisundi MUUTMISEL.
v. Standardi gruppide haldus – standardite grupid on võrreldes olemasolevaga
uus võimalus muuta standardid kasutaja jaoks paremini leitavaks ja tõsta
teadlikust standardite vahelistest seostest. Näiteks päring ja vastus.
1. Uue grupi lisamine juurena või olemasoleva grupi alla.
2. Grupi nime ja teiste andmete muutmine.
3. Grupi kustutamine (võimalik peale kõikide standardite grupist
eemaldamist)
4. Gruppi standardi lisamine
5. Grupist standardi eemaldamine.
vi. Standardi detailvorm – keerukas kompleksvorm kõikide standardiga tehtavate
tegevuste ja andmete kuvamisega seotud funktsioonide jaoks. Vorm koosneb
alamosadest / taabidest.
1. Standard eskiisina – eraldi taab standardi eskiisiliseks käsitlemiseks.
Siin on suuremad vabadused võrreldes standardi struktuurse käsitluse
vormidel. Eskiisiline käsitlus on mõeldud uue standardi loomeks, kuid
võib leida kasutamist ka olemasoleva standardi muutmisel
a. Uue rea lisamine – reaks saab olla vahepealkiri, malli päis või
malli atribuut, sõltuvalt lisamise kohast. Rea tähendust saab
hiljem ka muuta.
b. Olemasoleva rea muutmine – võimaldab muuta reas
sisalduvaid andmeid, sh. muuta rea asukohta hierarhias.
c. Rea ja/või sellega seotud alamridade (malli) nihutamine
hierarhia sama taseme piires üles. Jõudes nihutamisel
esimesele kohale, siis vastav tegevusnupp muutub
mitteaktiivseks.
d. Rea ja/või sellega seotud alamridade (malli) nihutamine alla –
analoogne tegevus eelnevaga aga teises suunas.
e. Ridade ühe kaupa nihutamisele täiendavaks võimaluseks
peaks olema ridade hiirega lohistamine üle mitmete ridade.
Lohistamise korral võib lubada ka samaaegselt hierarhia
taseme muutmist.
f. Rea ja/või sellega seotud alamridade (malli) nihutamine
hierarhias üles – muudab rea asukohta hierarhias. Näiteks
malli atribuudist saab malli päis. Alammallist saab ülemmall
või ploki pealkiri.
g. Rea ja/või sellega seotud alamridade (malli) nihutamine
hierarhias alla – analoogne tegevus eelnevaga aga
vastupidises suunas.
h. Rea taustvärvi muutmine – võimaldab tabeli ilmestamise
huvides muuta rea värvi. Värvide valik peaks olema suurusjärk
64-ja värvi vahel.
i. Rea oleku muutmine – rea olek sõltuvalt tema valmiduse
järgust. Olekud täpsustuvad hiljem. Olekud on vajalikud
eristamaks rea valmiduse astet.
j. Malli andmete kopeerimine eskiisi – võimaldab ühisbaasi
mallimudelist välja valida ühe malli ja selle andmed päis,
atribuudid, seotud OIDid ja klassifikaatorid ning selgitused
kopeerida eskiisi.
k. Eskiisist malli loomine. Standardi eskiisiline ja
mallistruktuurne käsitlus on lahus. Nende vahel on võimalik
soovitud andmeid / struktuuri osi kopeerida.
i. Täiesti uuene – luuakse eskiisi andmete põhjal
struktuursele taabile uus mall. Mall saab seisundiks
uus ja peale esimest sünki ühisbaasi ilmub see ka
sinna.
ii. Muutes olemasolevat – analoogselt eelnevaga liigub
mall struktuursele taabile. Erinevused originaaliga
jäävad nähtavaks. Esimese sünkimise ajal ühisbaasi
tuleb otsustada kas erinevused kirjutavad ühisbaasis
olemasolevad andmed üle või luuakse tingimuslaused
malli sisu sõltuvuse näitamiseks standardist.
iii. Jäädes vana juurde – eskiisis tehtud muudatusi ei
arvestata. Mall jääb töökoopias originaalsel kujul.
l. Rea kustutamine – eskiisist rea kustutamine. Rida kustub
jäädavalt.
m. Andmete eksportimine Excelisse – võimaldab alla laadida
Exceli faili kas kogu eskiisist või märgitud ridadega eskiisist.
Iga eskiisi koopiat on võimalik eraldi eksportida.
n. Ridade selekteerimine ja neile alljärgnevate operatsioonide
võimaldamine. Vajalik omadus samatähenduslike
operatsioonide teostamiseks väiksema töövaevaga.
i. Kustutamine – massiline kustutamine.
ii. Muutmisele avamine – võimaldab avalda
selekteeritud read Exceli tabeli sarnaseks
muudetavaks tabeliks
iii. Eskiisist malli loomine töökoopiasse.
iv. Oleku muutmine.
v. Taustvärvi muutmine.
vi. Andmete eksportimine Excelisse.
o. Olemasoleva alusel eskiisist uue koopia loomine – võimaldab
luua eskiisist eraldi koopia ja sellega jätkata tööd eelnevaga
rööbiti. Vajalik omadus alternatiivlahenduse vormistamiseks.
p. Olemasoleva koopia täielik kustutamine – vajalik omadus kui
koopia loomine osutus ekslikuks või sellega töö jätkamine ei
oma enam mõtteksust.
2. Standard struktuurina (töökoopia)
a. Struktuuris puu sõlmede avamine ja sulgemine. Viimane
avatuse / suletuse seis jääb üle sessiooni meelde, st. tulles
hiljem samale leheküljele tagasi on sama seis olemas.
b. Mallile atribuudi lisamine (piiratud võimalused) – võimalik
lisada malli atribuuti vaid selle nime, andmetüübi, kordsuse ja
selgituse andmetes. OIDde, klassifikaatoreid, näidisandmeid
ja seotus HL7 baasstruktuuriga tuleb teostada malli
detailvormil.
c. Uue malli päise lisamine (piiratud võimalused) – võimalik
lisada uut malli vaid selle nime ja selgituse andmetega.
Ülejäänud andmed ja seotused tuleb teostada malli
detailvormil.
d. Malli sees atribuudi liigutamine üles või alla – malli sisese
atribuudi järjekorra muutmine vastavalt baasstandardi
võimalusele. Teatavasti HL7 osaliselt dikteerib järjekorda.
e. Malli või atribuudi oleku muutmine. Analoogne omadus
eskiisiga.
f. Standardi struktuuri eksportimine Excelisse – võimalik
eksportida Excelisse ka struktuuri osaliselt.
g. Standardist näidis XML-i genereerimine ja selle allalaadimine.
Näidise lisamine standardiga seotud failide loendisse.
h. Olemasolevast näidisandmete komplektist uue koopia
loomine. Vajalik kergendamaks näidisest uue variatsiooni
loomist.
i. Olemasoleva näidisandmete komplekti eemaldamine
(kustutamine). Eelkõige vajalik ekslikult tehtud koopia
kustutamiseks. Kas on vaja eristada ka eemaldamist või
märkimist kehtetuks jäägu otsustamiseks edaspidiselt.
j. Malli kohta tema kõikide seoste küsimine. Tegevus algatub
malli nime juures olevast tööriistaribalt. Tulemus kuvatakse
tabelina kas eraldi avanevasse hüpikaknasse või
suurendatakse malli all olevat ekraani pinda vajalike seoste
kuvamiseks. Seoste kohta tuleb kuvada seose tüüp, seose peal
olev tekst ja olulised andmed seose otspunkti kohta nagu
näiteks nimi, tüüp ja ehk ka mingi osa selgitusest. Lisaks peab
olema võimalik saada nimekirja kõikidest standarditest, kus
fookuses olev mall on kasutusel. Kuvatud seosed on võimalik
sulgeda, st. taastada ekraanipinnal varasem seis.
3. Standardi struktuur selgitustega – eelnevaga samad võimalused
millele lisandub:
a. Reas selgituse muutmine <-- otstarbekas on taabist
„Standardi struktuur selgitustega“ loobuda ja selituse lahter
panna täiendavaks veeruks eelmise taabi tabelisse.
4. Standardi struktuur näidisandmetega – üle eelnevaga samad
võimalused millele lisandub:
a. Näidisandmete vaatamine koos malli põhiliste andmetega.
Näidisandmete muutmine toimub malli detailvormil.
b. Olemasoleva XML näidise import – vajalik omadus
olemasolevate standardite ja näidiste sidumiseks.
i. Impordiga seotud probleemide ja otsustuskohtade
lahendamine. Teatavasti on XML näidised keeruka
struktuuriga. Nende vastavus mallimudeliga on
tagatud vaid hoolsa käsitööga. Mittevastavuste
leidumine on paratamatu. Nendest üle saamiseks on
vajalik kasutajale välja kuvada importimisel tekkinud
probleemide loend. Kasutajal peab olema võimalik
importi korrata olles eelnevalt näidises vajalikud
muudatused mõne teise töövahendiga ära teinud.
c. Tehnilise võimekuse korral luua ka võimalus näidisandmeid
vaadata koos stiililehega.
5. Töös olevad mallid
a. Töös olevate mallide loend. Vajalik omadus, kui standard on
võetud muutmisele. Suurematesse standarditesse võib-olla
kaasatud kuni 100 malli. Tänuväärne on muutmisest
puudutatud malle näha eraldi loendina.
b. Uue malli lisamine – lisatakse vaid malli põhilised andmed
(nimi, kirjeldus).
c. Olemasoleva kustutamine – Malli jäädav kustutamine. Kaob
ära kõikidest standarditest ja kõik seosed katkevad. Enne selle
operatsiooni teostus näidatakse kasutajale ära kõik seotud
mallid ja malliga olevad teised seosed (OIDid, klassifikaatorid
jt). See funktsioon on vajalik eelkõige ekslikult sisestatud malli
kustutamiseks.
d. Olemasoleva eemaldamine standardist – malli kasutus selles
standardis lõpetatakse. Teiste standardite jaoks jääb
kasutusse.
e. Olemasoleva märkimine kehtetuks – malli kasutus kõikides
seotud standardites lõppeb. Enne selle operatsiooni teostus
näidatakse kasutajale ära kõik seotud mallid ja malliga olevad
teised seosed (OIDid, klassifikaatorid jt). Erinevus
kustutamisega on selles, et mall jääb alles aga ta on seisundis
kehtetu.
6. Seotud failid – standardiga seotud failide loend. Siia laetakse ka
standardi kohased stiililehed (XSL failid).
a. Seotud failide loend
b. Faili allalaadimine
c. Faili lisamine
d. Faili eemaldamine
e. Lisaks failile peab saama lisada ja eemaldada URL viiteid. URL
viited on osundamised failidele.
7. Standardi üldandmed
a. Üldandmete muutmine, sh. standardi määramine või
eemaldamine grupist.
b. Standardi seisundi muutmine toimub läbi tegevuste.
Detailvormil seisundit otse muuta ei saa.
c. Standardi avalikustamine (publitseerimine) – avalikustamise
juures tuleb nimetada versiooni number, avalikustamise
kuupäev ja vajadusel lisada selgitav tekst. Avalikustamine
peab olema viimasesse versiooni korratav. Vajalik omadus kui
avalikustamisel või avalikustatud materjali kontrollimisel
leitakse vigu. Versiooni numbri positsioonide tähendused:
i. Esimene positsioon – standardi struktuuride
järjepidevus ei ole tagatud. Eemaldatud on malle /
atribuute, nende tähendusi on muudetud ja/või
lisatud on rohkelt uusi malle / atribuute. Eelmine
versioon kehtib tähtajaliselt.
ii. Teine positsioon -- standardi struktuuri järjepidevus
on mõistlikus ulatuses tagatud või tagatud täielikult.
Eelmine versioon kehtib tähtajatult.
iii. Kolmas positsioon – standardi struktuuri järjepidevus
on tagatud. Midagi ei ole eemaldatud, millegi
tähendus ei ole muutunud. Võimalikud on tekstilised
ja/või näidisandmete parandused või vähemolulised
lisandumised.
d. Standardi avalikustamisega seotud vigade nimekiri. Vigade
käsitlus vajab täiendavat analüüsi.
8. Malli detailvorm – kompleksvorm malliga seotud kõikide
operatsioonide ja andmete vaatamise võimaluste teostamiseks. Vorm
sisaldab alamosi või taabe.
a. Malli atribuudid
i. Atribuudi lisamine.
ii. Atribuudi põhiandmete muutmine.
iii. Kitsenduse lisamine.
iv. Kitsenduse kustutamine.
v. Atribuudi kustutamine. Atribuut kaob ära kõikide
standardite jaoks.
vi. Atribuudi eemaldamine antud standardi jaoks. Teiste
jaoks jääb alles.
vii. Klassifikaatori lisamine.
viii. Klassifikaatori eemaldamine.
ix. OIDi lisamine.
x. OIDi eemaldamine.
xi. Andmekontrolli lisamine.
xii. Andmekontrolli eemaldamine.
b. Atribuutide seosed HL7-ga
i. Atribuudi sidumine HL7 atribuudiga / elemendiga.
Sisaldab ka seose muutmist.
ii. Seose kustutamine. Kui atribuut jääb teiste
standardite jaoks kasutusele, siis toimub kustutamine
ainult selle standardi tähenduses.
c. Näidisandmed
i. Näidisandmete lisamine. Peab võimaldama lisada
taagi parameeterid (neid saab olla mitu) ja taagi
vahelisi andmeid. Samuti XML plokkide parameetreid.
Rakendus peaks võimaldama lisada ainult lubatud
parameeterid.
ii. Olemasolevate muutmine. Peab olema võimalik
muuta taagide vahelisi, siseseid ja plokkide andmeid.
iii. Eemaldamine, sisaldab ka grupi eemaldamist.
iv. Näidisandmete komplektist koopia loomine, mille
alusel andmetest teise variandi tegemine.
v. Komplekti kustutamine.
vi. Malli kohase näidis XML-i genereerimine (võimalus
genereerida koos alammallidega või ilma).
Genereerimine võib toimuda ka automaatselt, st.
kasutajale on mallist XML vorming alati kättesaadav.
vii. Mallide korduv (dubleeriv) kasutus näidisandmete
käsitlemisel. Näiteks mall „Analüüs“ võib näidises olla
mitmekordses koopias.
d. Seotud mallid
i. Mallile seose lisamine teise malliga antud standardi
piires või läbivalt kõikidele standarditele.
ii. Seose eemaldamine antud standardist.
iii. Seose kustutamine kõikidest standarditest.
iv. Malli kohta kõikide seoste pärimine ja vastuse
saamine nimekirjana. Nimekirja peavad olema
ülemmallid, alammallid, seotud HL7 klassid koos
otspunti atribuudi nimega, seotud OID-id ja
klassifikaatorid. Lisaks peab olema võimalik saada
nimekirja kõikidest standarditest, kus fookuses olev
mall on kasutusel.
e. Üldandmed
i. Malli üldandmete muutmine.
ii. Malli seisundi muutmine.
iii. Malli eemaldamine antud standardist (mall jääb
muidu alles).
iv. Malli kustutamine kõikidest standarditest.
v. Mallide liitmine. Liituvad mallide atribuudid. Teine
mall jääb alles.
f. Malli kohase võrkstruktuuri visuaali automaatne
genereerimine (edaspidi joonis). Ideaalis peaks saama iga
malli kohta vaadata analoogset joonist tänases EA baasis
olevate joonistega. Genereeritav joonis peab vastama
järgnevatele tingimustele:
i. Peab olema võimalik joonisel kujutatavaid elemente
sisse ja välja lülitada. Näiteks teha joonist ainult
mallidest, mallid koos OID-ide ja klassifikaatoritega
või mallid koos XSD-ga.
ii. Peab olema võimalik valida alammallide tasemete
sügavust. Joonisele kuvatakse alammallid, nende
alamad jne. vastavalt valitud sügavuse astmele.
iii. Fookuses olev mall joonise keskel
iv. Ülemmallid üleval. Üks tase üles ülemmalle.
v. Alammallid all.
vi. Seotud HL7 XSD klassid vasakul
vii. Seotud OID-id ja klassifikaatorid paremal.
viii. Seosed ei tohi üksteisega ristuda ega lõikuda ning
seosed ei tohi minna üle joonise elementide.
ix. Seostel olevad tekstid tuleb kuvada vasakult
paremale horisontaalis.
x. Mallidest ja HL7 klassidest tuleb kuvada kõik
atribuudid.
xi. Seosed HL7 atribuudi ja malli atribuutide vahel
peavad olema osundatud täpselt atribuudi teksti
juurde.
xii. Kui malli atribuutidest on seosed mitme HL7 klassiga,
siis tuleb vasakul kuvada ka kõik need klassid ja ka
nende klasside vahele jäävad klassid omavaheliste
seostega.
b. Avaldatud standardid
i. Otsing – otsinguvorm avaldatud (publitseeritud) standardite hulgast otsitava
leidmiseks.
ii. Avalikustatud standardite loend – vaikimisi on loendis standardite viimased
versioonid.
1. Avalikustatud standardi loendi rida – reas on võimalik klõpsata lahti
alamloend standardi varasemate versioonide vaatamiseks. Iga
versioon on eraldi klõpsatav ja sellele klõpsamine avab selle versiooni
kohase detailvormi.
2. Avalikustatud standardi detailvorm – funktsionaalne jaotus samane
avaliku rakenduse funktsioonidega, va. järgnev punkt:
a. Võimalik on nimetusi, selgitusi ja muid inimlugemiseks
mõeldud tekste (vajab täpsustamist) võtta muutmisele
kirjavigade parandamise huvides. Muudatuse tegeliku sisu
eest vastutab muudatuse tegija. Kõik tegevused logitakse
kasutaja ja tehtud muudatuse sisu täpsusega.
3. Baasstruktuurid – HL7 XSD baasstruktuuride sirvimine ja import (CDA, V3 ja FHIR)
a. Puustruktuurne sirvimine analoogselt tänase EA rakendusega, mis võimaldaks kõige
põhilisemal tasemel aru saada, kas XSD struktuuride import on toimunud korrektselt.
Vajalik on kasutajale välja näidata XSD klasside vahelisi seoseid, nimetusi,
andmetüüpe, atribuutide nimetusi, nende andmetüüpe, kordsusi ja selgitusi (FHIR-i
XSD sisaldavad rikkalikult selgitusi). Tuleb arvestada, et korraga võib olla imporditud
baasstandardi eri versioonide XSD-st, sh. suured erisused nagu näiteks CDA, V3 või
FHIR.
i. Detailandmete vaatamine. Sisu vajab täpsustamist.
b. Seotud mallide nimekirja kuvamine ja mallile liikumine. Võimaldab XSD klassi
(elemendi) pealt saada nimekirja seotud mallidest koos seospunkti atribuudiga.
Seotud mõisted kuvada ka eraldi hüpikaknasse või ekraanipinda juurde võttes XSD
klassi (elemendi) alla. Võimalik liikude seotud malli detailvormile või seote loend
sulgeda.
c. Baasstandardi XSD-de import. Funktsioon peab võimaldama failina või terve
kataloogina osundatud XSD faili või failide importi haldusrakenduse baasi. Impordi
eesmärk on võimaldada XSD klasside atribuute siduda mallide atribuutidega näiteks
alapunktis „Atribuutide seosed HL7-ga“ kirjeldatud viisil.
i. Importimise funktsioon peab olema korratav. Impordil esinevatest
probleemidest tuleb teavitada vastava loendiga.
ii. Kasutajal peab olema võimalik imporditud komplektile anda oma nimi ja
selgitus. Importimise aeg ja seda teinud kasutajanimi peab olema nähtav.
4. Klassifikaatorid – ei ole hetkel dokumendi skoobis. Visioon prototüübina olemas.
5. OIDid – ei ole hetkel dokumendi skoobis. Visioon prototüübina olemas.
6. Andmekontrollid – ei ole hetkel dokumendi skoobis. Visioon prototüübina olemas.
7. Dokumendid – ei ole hetkel dokumendi skoobis.
8. Admin tegevused -- ei ole hetkel dokumendi skoobis. Siin peaks olema kasutajate haldamine,
logide vaatamine, veel teadmata häälestusparameetrite muutmine jt.
Avaliku rakenduse funktsionaalne jaotus
Avalik rakendus on loob võimalusi soovitud informatsioonini jõuda erinevaid sisendpunkte kasutades.
Alustasin klassifikaatorist ja jõudsin välja malliga seotud andmekontrollini. Alustasin standardist ja
jõudsin välja konkreetse HL7 atribuudini jne. Teadsin märksõna ja leidsin kõik sellega seotud mõisted
ning on võimalik liikuda mõiste detailkuvale. Olulist tähelepanu pööratakse ka versioonide vahelisele
võrdlemisele, kasutaja mugavusele ja informatsiooni esitamisele arusaadaval viisil.
Alljärgneva funktsionaalse jaotuse kohta on olemas ka prototüüp.
1. Üldotsing – võimaldab otsida täpse sõna või mitme sõna või silpide järgi standardite, mallide,
atribuutide, klassifikaatorite, klassifikaatori elementide, OIDide, andmekontrollide ja juhendite
hulgast.
a. Üldotsingu otsinguvorm, eelnevalt nimetatud otsingukriteeriumite sisestamiseks.
b. Vastusloend – vastusloendi read on sorteeritavad allika, nimetuse / koodi ja täiendava
selgituse järgi.
i. Vastusloendilt siirdumine seotud mõiste detailvormile – klassifikaatori, OIDi,
standardi või malli detailvormile. Siia kuuluvad ka andmekontrollid,
dokumendid jt.
2. Klassifikaatorid
a. Otsinguvorm – võimalus otsida klassifikaatorit või selle elementi täpse nime või selle
osade järgi. Samuti otsingu tulemust kitsendada viimase muutmise järgi.
b. Vastusloend – vastusloendi read on sorteeritavad nime, seotud OIDi, kirjelduse ja
viimase muutmise järgi.
i. Vastusloendi rida – reale klõpsamine avab detailvormi. Rea juures on võimalus
kogu klassifikaator alla laadida Exceli, CVS ja XML vormingutes. Lisaks on rea
juures link juhendile.
c. Klassifikaatori detailvorm – loendivorm klassifikaatori elementide ja varasemate
versioonide vaatamiseks. Lisaks kirjeldus, seotud juhend(id) ja võimalus avada seoste
vorm.
i. Klassifikaatori seoste vorm – väikeloend klassifikaatori seoste vaatamiseks ja
seosega viidatud detailvormile liikumiseks.
ii. Versioonide vahelised erinevused – klassifikaatori versioonide erinevusi kuvav
vorm, kus on ilmekalt näha lisandumises, eemaldumised, liitumised,
jagunemised ja muutused.
3. OID keskus
a. Hierarhiline vaade – OID hierarhia vaatamine klõpsates sõlmi lahti ja kokku. Vaikimisi
on avatud kõige olulisemad harud.
b. OIDi detailvorm – klõpsates OIDil on võimalik avada OIDi detailvorm kus on näha OIDi
kõik andmed ja seosed klassifikaatorite, mallide, standardite ja andmekontrollidega.
Klõpsates vastaval real saab liikuda seotud mõiste detailvormile.
c. Otsing – võimaldab OIDi otsida täpse või osalise koodi või nime järgi. Otsing ja
vastusloend on hierarhilisele vaatele alternatiivne võimalus.
d. Vastusloend – vastusloendi reale klõpsamine avab OIDi detailvormi.
4. Standardid – avaldatuna standardite põhiselt. Kogumiku põhisus on täielikult kasutaja eest
varjul.
a. Standardite grupid – loend standardi gruppidest, kus on näha ka gruppi kohta käivad
selgitused. Grupi real klõpsamine siirdub sellesse gruppi kuuluvate standardite
loendile.
b. Kõikide standardite loend – kõik avaldatud standardid viimaste versioonidena on ühe
või kahe tulbalises loendis kuvatud. Standardite koguhulk on suurusjärk 150, mis
võimaldab soovi korral kõik korraga ekraanile kuvada. Loend on sorteeriva standardi
nimi, tüübi ja avaldatud kuupäeva järgi. Alternatiiviks on teha otsing ja vastusloendi
põhine standardi leidmine.
c. Loendi rida – kui standardist on varasemaid versioone või esialgselt avaldatud
(mitteametlike) versioonise, siis on võimalik need real klõpsates alamridadena
ekraanile tuua. Põhirida ja iga alamrida on klõpsatav ja see viib standardi detailvormile.
d. Standardi detailvorm – keerukas kompleksvorm standardiga seotud kõikide andmete
ja seoste kuvamiseks. Vormi päises on viited juhenditele.
i. Standard tabelina – kuvatakse kogu standard hierarhilise tabelina, kus ridades
on näha kogu oluline informatsioon (kood, nimi, selgitus, OID(id),
klassifikaator(id) ja seotus HL7 elementidega).
1. Malli esindav tabeli rida on klõpsatav ja selle peale avaneb mallid
detailvorm.
2. Võib kaaluda klõpsatavaks muuta ka seotud OIDid, klassifikaatorid ja
HL7 elemendid, mis viivad kasutaja vastavale detailvormile.
3. Versiooni võrdlus tabelina
a. Päringuvorm – võimaldab märkida millist liiki muudatusi
soovitakse näha. Valikuteks on lisandumised, muutumised ja
kadumine. Võimalik valida ka lähteversioon, mis saab olla vaid
jooksvast versioonist väiksem.
b. Võrdlusvorm – esitab erinevused puustruktuurselt ja
liigendatult, kus on näiteks taustvärviga eristuvalt näha
lisandumised, muutused ja eemaldumised. Prototüübis on
toodud üks ilmekas näide.
ii. Standardiga seotud tekst – standardi kohta käiva tekstilise info kuvamine. Kui
see on pikk, siis osa sellest. Kogu teksti nägemine toimuks täiendava klõpsuga.
1. Versioonide võrdlus. Kasutaja märgib ära võrreldava versiooni ja
rakendus kuvab erinevused näiteks analoogselt Wordi vastava
omadusega.
iii. Andmekontrollid – standardiga seotud kõikide andmekontrollide kuvamine
ühe loendina. Loendi real klõpsamine viib andmekontrolli detailvormile.
1. Versioonide võrdluse funktsioon vajab täpsustamist.
iv. Näidisfailid – standardiga seotud XML näidised loendina. Faile on võimalik alla
laadida.
1. Versioonide võrdlus.
a. Päringuvorm – võimaldab lisaks muudatuse iseloomule
(lisandumine, muutmine ja kadumine), lähteversioon valida
ka näidise komplektide vahel.
b. Võrdlusvorm -- esitab erinevused kas näiteks analogselt
XMLSpy rakendusega või prototüübis toodud viisil.
2. Näidise vaatamine koos stiililehega (XSL failiga). Peaks arvestama ka
võimalusega näidist vaadata erinevate stiililehtedega.
v. Õigusloome – standardile vastav õigusloome tekst.
1. Versioonide võrdlus sarnane võrdlus tabelina.
vi. Klassifikaatorid – standardiga seotud kõik klassifikaatorid ühtse loendina.
Reale klõpsamine viib klassifikaatori detailvormile.
1. Versioonide võrdluses võimalik vaadata eemaldunud ja lisandunud
klassifikaatoreid.
vii. OIDid – standardiga seotud kõik OIDid ühtse loendina. Reale klõpsamine viib
OIDi detailvormile.
1. Versioonide võrdlus sarnane klassifikaatorite osaga.
e. Malli detailvorm – kompleksvorm malli detailandmete ja seotud mõistete
vaatamiseks. Sisaldab alamosi või taabe.
i. Mall tabelina – tabelina on kujutatud malli ja sellega seotud alammallid
samaselt standardi tabelina.
1. Versiooni võrdlus tabelina on samase funktsionaalsusega kogu
standardi kohasega.
ii. Mallile vastav lõik näidis XML-st.
1. Versiooni võrdlus näidises on samase funktsionaalsusega kogu
standardi kohasega.
iii. Malliga seotud klassifikaatorid – klõps real viib klassifikaatori detailvormile.
1. Versiooni võrdlus klassifikaatorite osas esitab erinevused jooksva ja
järgneva versiooni osas. Erinevusteks saavad olla seose lisandumine ja
eemaldumine.
iv. Malliga seotud OIDid – klõps real viib OIDi detailvormile.
1. Versiooni võrdlus OIDide osas esitab erinevused analoogselt
klassifikaatoritega.
5. Andmekontrollid
a. Andmekontrollide otsinguvorm.
b. Andmekontrollide loend, mis on sorteeritav erinevate veergude järgi.
c. Andmekontrolli realt on võimalik avada seotud mallide ja atribuutide loendid. Loendi
realt on võimalik siirduda vastavale detailvormile.
6. Juhendid
a. Juhendite otsinguvorm.
b. Juhendite loend, kus kui on juhendist versioone, siis real klõpsamine avab selle alla
loendi varasematest versioonidest.
c. Rea lõpus on lingid dokumendi alla laadimiseks.
d. Rea lõpus on olemas või võimalik avada loend seostega standarditele. Klõpsamine
loendi real siirdub vastavale detailvormile.
Kasutajarollid
Teabekeskus ei käsitle tundlike isikuandmeid ega riigisaladuse mõttes piiratud ligipääsuga andmeid.
Vajadus keerukama rollide ja ligipääsuõiguste mehhanismi järgi puudub. Allnimetatud rollid on valitud
kooskõlas tulevase töökorraldusega.
Avalik kasutaja – ei vaja autentimist. Pääseb ligi kogu avalikustatud sisule. Piiratud
sihtrühmale avalikustatavat sisu ei paista tekkivat. Avalik kasutaja pääseb kasutama kogu
avaliku rakenduse funktsionaalsust, va. admin tegevused.
Standardite üldhaldur – pääseb tegema kõiki tegevuse standarditega, sh. uute standardite
avaldamine ja väikeparanduste tegemine avalikustatud sisus. Lisaks olemasoleva standardi
kustutamine ja XSD-de haldamine (laadimine, korrektuurid).
Sisuline standardimine – pääseb tegema kõiki tegevusi, mida kujutatud prototüübi
lehekülgedel „Standard eskiisina“ ja „Standardi struktuur“ ehk kogu tegevustik standardi
sisulise (ettevalmistava) tööga ja standardi mallistruktuuri esmase paika panekuga. Lisaks
õigus luua uus standard. Prototüübis nupp „Algata uus standard“. Samuti kõik tegevused
standarditega seotud juhendmaterjalidega. Võib kaaluda ligipääsu piiramist konkreetse
standardiga. See võib osutuda vajalikuks, kui korraga on töös mitu standardit ja nendega
tegelevad eri isikud.
Tehiniline standardimine – tegevused taabil „Standardi struktuur“ ja ülejäänud tegevused
standardiga, va. selle avaldamine (publitseerimine) ja väikeparanduste tegemine
avalikustatud sisus. Osaliselt kattuv sisulise standardimisega. Rolli ülesanne on luua
korrektne mallistruktuur, standard siduda baasstruktuuriga (HL7) ja lisada näidisandmed
ning saada valiidsed näidis XML-id. Sarnaselt eelneva rolliga võib kaaluda piirata ligipääsu
standardi põhiselt.
Tehnilise standardimise rolli on mõeldud võimalusena anda sarnaselt tänasega mallistruktuuri
loomine, HL7-ga sidumine ja näidiste koostamine koostööpartnerile.
Neile isikutele kes teeksid standardi nullis lõpuni antakse sisulise ja tehnilise standardimise rollid.
OID-ide üldhaldur – pääseb tegema Teabekeskuse kõikide OIDidega seotud kõiki tegevusi.
o OIDide haru haldur – pääseb tegema kõiki tegevusi konkreetse OIDi alampuu piires.
Vajalik roll, kui OIDi puust tuleks anda mõni haru haldamiseks mõnele teisele
organisatsioonile.
Klassifikaatorite üldhaldur – pääseb tegema Teabekeskuse kõikide klassifikaatoritega kõiki
tegevusi.
o Konkreetsete klassifikaatorite või nende gruppide haldur – analoogselt OIDide haru
halduriga pääseb tegelema piiratud hulga klassifikaatoritega.
Andmekontrollide haldur – pääseb tegelema kõiki tegevusi kõikide standardite kõikide
andmekontrollidega.
Rakenduse admin – tegeleb rollide haldamise ja rakenduste (ametkondlik ja avalik) üldiste
halduse tegevustega. Ei oma eelnevate rollide õigusi.
Vorm
Peatükis on kirjeldatud kavandatava süsteemi rakendus- ja andmebaasi kihtide esmast jaotust.
Andmebaasi struktuuri kohta on olemas ka detailsed joonised ja kirjeldused. Põhjalikumalt on
käsitletud migratsiooni, mille kohta on ka olemas detailsem dokument.
Teabekeskuse arhitektuuri kandvateks ideedeks on:
1. Andmebaasid
a. Andmebaasi mootoriks on Postgre.
b. . Tänane Enterprise Arhitecti andmebaas jääb kasutusse vaid ajalooliste andmete
vaatamiseks ja olemasolevate standardite importimise allikana.
c. Standardite loome ja haldamise huvides luua uus andmeskeem. Kui klassifikaatorite,
OIDide, andmekontrollide ja seotud dokumentide (juhendite) halduse jääb ka loodava
rakenduse funktsionaalsuseks, siis ka need andmed paikenvad täiendavas
andmeskeemis.
d. Avalikule osale luua eraldi andmebaas või andmeskeem, mis arvestaks avaldamise,
andmete kiire leidmise ja võrdlemise vajadusi.
2. Rakendused
a. Rakendusserveri tarkvaraks on Tomcat.
b. Analoogselt andmebaasidega on halduri ja avaliku poole rakendused eraldi serveritel.
See võimaldab süsteeme eraldi arendada ja ülal hoida.
i. Standardite haldamise poolel on täna vaid 3 – 5 kasutajat ja tulevikus ei ole
ette näha kasutajate hulga kasvu üle 10-ne. Mõnekümneni võib kasvada OIDe
ja klassifikaatoreid haldavate isikute arv, kui otsustatakse haldamise
vastutused laiali jaotada. Avaliku poole kasutajate arv võib küünida 100-ni.
Samas, igapäevane sisuline kasutus on madal. Peamist koormust tekitavad
otsingumoorotid ja juhukülalised. Masinliidesele (klassifikaatorite teema)
langev koormus on kokkulepete küsimus tarbivate poolega. Tõenäoliselt
tihedam intervalli kui 1 või 2 korda nädalas uuendusi küsimas käia pole
otstarbekas.
c. Mõlemas rakenduses (halduri ja avalik) tuleb selgelt ülejäänud rakendusest eristada
kasutajaliidese kihti/loogikaid, kuni võimaluseni need eraldi paigaldatavaks muuta.
i. Kasutajaliidese kiht tuleb luua raamistikus Angular (https://angular.io/).
ii. Tuleb kasutada EMTA stiiliraamatut (kasutusel ka projektis SKAIS2), mida
vajadusel kohandada Teabekeskuse vajadustega. See puudutab eelkõige
puustruktuurseid kuvasid.
d. Võimaldamaks teistel süsteemidel andmeid automaatselt uuendada on vajalik luua
masinloetavad veebiteenused REST (JSON, XML) API. Veebiteenuste sisuks saaksid olla:
i. Klassifikaatori väärtuste allalaadimine.
ii. Klassifikaatori väärtuste uuendamine.
3. Arhitektuursed üldnõuded
a. ISKE soovitav tase on K1T1S0. K1 – käideldavus vahemikus 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 tuvastatavad. 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 tervikluse nõuetega).
b. Rakenduse loomisel tuleb arvestad TEHIKu IT-profiilis välja toodud nõuetega
https://wiki.sm.ee/display/AV/IT-Profiil
c. Kasutajate autentimise lahenduse esimeseks valikuks on protokoll Kerberos ja teenus
MS Active Directory. TEHIKu IT profiilis nimetatud teine valik SSO KeyCloak ja TARA on
samuti aktsepteeritavad.
Ülevaatlik arhitektuurne joonis, kus nooled näitavad andmete peamist liikumise suunda. Halduse
poolel andmete lugemine ja kirjutamine. Avalikus osas toimub vaid andmete lugemine. Avaliku
andmebaasi täitmine toimub masstegevusena Halduri rakenduse poolt.
cmp Veel uuem versioon ver2
Haldur Tehikus Haldur, väline partner
Avalik kasutaja
Haldusliides Teabekeskuse avalik liides
http://sise.tehik.ee/ http://teave.tehik...
Teabeksekue halduri rakendusserver Teabeksekuse rakendusserver
Halduri rakenduse kasutajaliides Avaliku rakenduse kasutajaliides
Halduri rakenduse (REST) teenuskiht Avaliku rakenduse (REST) teenuskiht
Teabekeskuse Postgre andmebaas haldamiseks Teabekeskuse Postgre andmebaas
avalikele andmetele
Kõik standardimisega seotud EA andmeskeem
andmed. Teabekeskuse avalike
andmete skeem
Halduri baas
Avalik baas
Enterprise Architect
Ajalooliste
andmete sirvimine
Haldur (EA rakendus)
Dokumendi koostamise ajaks ei olnud selget arusaama, et milliseid valmis või pooltootelisi vahendeid
saaks kasutada näiteks OIDide, klassifikaatorite aga miks ka mitte juhendite (dokumentide)
haldamiseks. Sellest tulenevalt ei ole loodud skemaatilisi jooniseid ühendusteks teiste süsteemidega.
Järgnevas on kujutatud andmeskeemide vahel andmete liikumise põhilised suunad. Töökoopiate baasi
tulevad varasemad andmed EA baasist ja uued andmed inimkasutajalt. Nooltel on nimetatud
olulisemad liigid. Avaliku baasi liiguvad andmed EA baasist ja töökoopiate baasist.
analysis Andmete peamine liikumissuund
Standardite ja nendega seotud andmete avaldamine.
Töökoopia jaoks
standardi ja mallide
Uued standardid ja
andmete import.
mallid, muudatused,
näidisandmed, OIDid, Teabekeskuse avalike
Kõik standardimisega seotud
klassifikaatorid, EA andmeskeem andmete skeem
andmed.
Haldur andmekontrollid ja
dokumendid.
Avadatud standardid (sh mallid),
Standardite ja mallide töökoopiad, OIDid, klassifikaatorid,
Standardid ja mallid ning XSD-d andmekontrollid ning nende
näidisandmed, OIDid, klassifikaatorid,
andmekontrollid, dokumendid jt. versioonid.
Andmebaasi struktuuridest
Alljärgnevas on baasi skeemide ülevaatlikud joonised. Detailsed joonised on saadaval EA failina.
Halduri skeemi ehk töökoopia põhimõttelise struktuuri joonis.
cmp Anmebaasi jäme struktuur
Standardi grupid
0..*
1..*
0..* 0..*
0..*
Eskiisid Standardid ja mallid 0 XML näidisandmed
0..*
0..*
0..* 0..* 1..*
Mallide vahelised Mallide atribuudid
seosed
0..*
0..* 0..*
0..* 0..* 0..*
OIDid Klassifikaatorid Andmekontrollid
Joonist täiendavad seletused:
1. Eskiisid on lahus ülejäänud mõistetest. Eskiise saab olla ühe standardi kohta mitu ja eskiis on
hierarhilise struktuuriga. Eskiiside ja standardite vahel andmeid kopeeritakse. Tabelite
vahelised seosed puuduvad tagamaks loomingulist vabadust.
2. Standardid on töökoopias hierarhilise struktuuriga aga samas tuleb säilitada analoogselt EA
baasiga mallimudeli võrkstruktuursus. Andmebaasis tuleb võrkstruktuursed seosed väljendada
mitu-mitmele seose kaudu. Töökoopias on standardite käsitlus täisfunktsionaalne. Sisu
dikteerib HL7 ja mallimudel.
3. OIDid, klassifikaatorid ja andmekontrollid asuvad eraldi tabelites või mõnes teises baasis.
Seosed on mitu-mitmele malli atribuutidega. Kui teises baasis, siis tuleb lahendada andmete
topelt sisestamise vältimise ja tiheda kasutuse / linkimise küsimused.
4. Näidisandmed saavad olla seotud mallide ja atribuutidega. Näidisandmete struktuur on
joonisel väljendatust keerukam.
EA skeemi/baasi tegeliku struktuuri joonis. Välja on toodud EA baasi ~100 tabelist standardimise jaoks
kasutust leidvad.
dm Kompaktne üldjoonis
t_package t_diagram
t_diagramobjects
t_object
t_objectproperties t_connector
t_diagramlinks
0..2
t_connectorconstraint t_taggedvalue
t_attribute
t_connectortag
t_attributeconstraints
Joonist täiendavad seletused:
1. Rohelise värviga ristkülikud on tuumobjektid, millede analoogid on sama värvi ka töökoopia
baasis.
2. EA baasis on kõik põhimõisted (standardid, mallid, klassifikaatorid, OIDid, XSD klassid)
t_object-id.
3. Ülejäänud tabelid (halli taustaga) sisaldavad andmeid jooniste ja täiendavate kirjelduste kohta.
Avalike andmete skeemi kavandatava struktuuri joonis.
dm Ülevaade
a_standard_grupp
a_standard_kuuluvus
a_standard
a_dokument
a_standard_dokument
a_mall a_standard_xml
a_mall_xml
a_atribuut
a_atribuut_andmekontroll a_atribuut_oid a_atribuut_klassifikaator
a_andmekontroll a_oid a_klassifikaator
a_klassifikaator_element
Joonist täiendavad seletused:
1. Keskne mõiste on standard ja tema mitmene kuuluvus gruppi. Standardi versioonid on
välisvõtmega seotud.
2. Standard (ja selle versioon) saab olla seotud mitme dokumendiga / juhendiga.
3. Standard (ja selle versioon) saab olla seotud mitme näidis XML-ga.
4. Standardi alla kuuluvad mallid, mis on omavahel hierarhilises seoses.
5. Iga malli juures on seda ja tema alammalle esindav näidis XML.
6. Andmekontrollid, OIDid ja klassifikaatorid on eraldi tabelites ja need on mitmussuhtes
atribuudiga.
7. Seos HL7-ga on väljendatud tabelis a_atribuut XML rajaga (xpath).
Andmete migreerimisest Publitseerimise keskusest Teabekeskusesse
Olemasolev Publitseerimise keskuse andmebaas sisaldab kahte peamist teemat: standardid ja OIDid.
Kusjuures standardite all mõeldakse lisaks standarditele, teatistele ja toimingutele ka klassifikaatoreid,
juhendeid ja teisi materjale. Standardite teema on üles ehitatud kolme tasemelise hierarhiana, mille
astmeteks on standard, versioon ja fail. Sellele vastavad tabelid „standards“, „versions“ ja „files“.
OIDide teema on käsitletud detailselt tabelites eesliitega OID. Publitseerimiskeskuse avaleht
http://pub.e-tervis.ee/ on staatiline (st. ei tule andmebaasist) ja seetõttu jätab mulje neljandast
tasemest.
Teabekeskuse andmebaas on projekteeritud oluliste teemade iseloomu ja nende halduse vajadusi
paremini arvestavalt, sh. on eraldatud on käsitletavate andmete haldamine ja avalikustamine.
Andmete haldamise poolel on oluliseks omaduseks koostöö Enterprise Architect-ga (EA), mis tähendab,
et halduri baasi osaks on ka kogu EA skeem, mis on säilitatud muutumatul kujul. Ülejäänud tabelid on
projekteeritud EA skeemi juurde ja kõrvale arvestades kasutajaliidese vajadusi. Osadest tabelitest on
välisvõtme viited EA skeemi tabelitele, et tagada andmete vahel üheselt mõistetav sidusus. EA skeemis
asuvateks andmeteks on standardite (sh. toimingute ja teatiste) päised, mallid, OIDid ja
klassifikaatorite päised ning nimetatud andmete vahelised seosed. Kusjuures standardite päised ja
mallid on alaliselt EA skeemis. Halduri baasi teistesse tabelitesse ilmuvad nad ainult nende halduse
(lisamise, muutmise või eemaldamise) ajaks, et tagada nende haldamiseks loodud funktsioonide toime.
OIDid ja klassifikaatorite päised on kahepaiksed selles ulatuses, milles on vaja hoida ülal seoseid
standardite ja mallide vahel. Standarditesse ja mallidesse mitte puutuvaid OIDe ja klassifikaatorite
päised ei ole vaja hoida EA skeemis.
Andmete liikumine avalikku baasi toimub läbi halduri baasi. Seega olemasoleva pub.keskuse andmed
tuleb esmalt migreerida halduri baasi. Peale selle õnnestumist tuleb teostada esmane avalikustamine.
Eri versioonide väljapanekuks avalikus baasis tuleb migreerimist lähtekohast halduri baasi korrata
vajalik arv kordi. See puudutab eelkõige EA baasi eri versioonidest andmete lugemist. Olemasolevate
andmete liikumine läbi halduri baasi tagab hilisema võimaluse avalikustatud versioonidesse
paranduste publitseerimise.
Migreerimise sammud
Publitseerimise keskuse avaliku osa andmebaas koosneb 15-nest tabelist, millest 7 on OIDide
käsitluseks ja 3 jäävad maha. Ülejäänud 5 sisaldava ülejäänud andmeid. Avaliku osa andmete
migreerimine tuleks jaotada järgnevateks osadeks:
OIDide ülekanne
o Kasutajate ja organisatsioonide ülekanne
Klassifikaatorite ülekanne
Juhendite ülekanne
Standardite ülekanne
Andmete migreerimise detailid on kirjeldatud eraldi dokumendis. Kui OIDide, klassifikaatorite ja
juhendite ülekanne on suhteliselt lihtne, siis standardite ülekanne nõuab selleks otstarbeks ajutise
rakenduse loomist, sest lisaks avalikule osale tuleb andmeid võtta ka EA baasist. Samuti on ülekande
protsess keerukas ja mitme etapiline. Ajaliselt võib see aega võtta mitu kuud kuni 1 aasta. Täielik ja
kogu standardite versioonide ajalugu kajastav üleminek polegi võimalik või selle saavutamine muutub
ebamõistlikult töömahukaks. Tõenäoliselt tuleb leppida kompromissiga, kus standardite kõiki
vanemaid või teatud versioonist vanemaid andmeid tuleb lugeda tööle jäätavast Publitseerimise
keskusest.
Standardite ülekande keerukuse põhjusteks on:
Standarditega seotud materjalide avaldamise loogika põhimõtteline muutus. Kui varem
avaldati kõik standardid ja nendega seotud näidised jt. dokumendid kogumiku põhiselt ühe
pika failide loendina (nt. kogumik 6.0 sisaldab 567 faili), siis Teabekeskuses hakkab avaldamine
olema standardi (teatise, toimingu) põhine.
Standardi esitamine Teabekeskuses saab olema standardi kohases mallide hierarhilise puuna.
Varasemalt on avaldatud mallide graafi tervikuna või osade kaupa. Kui näidis XML-id välja
jätta, siis standardeid ammendavalt kirjeldavaid dokumente polegi.
Eesmärk loobuda näidisdokumentide loomisel käistööst ning neid genereerida mallimudelist.
Vajadus saavutada standardite ja juhendite parem sidusus. Publitseerimiskeskuses on kokku
ligi 4000 faili. Ainsaks võimaluseks jaotuste tegemiseks standardite ja muude liigituste vahel
on otsuseid teha failinimede põhjal. Standardi nime ja failinime vahel täpne vastavus
praktiliselt puudub. Samas, mõningast mittevastavust lubades on võimalik suur osa faile
standarditega seostada. Mingi osa jääb paratamatult käsitööks.
Publitseerimise keskusest ei kanta üle andmeid tabelitest:
„acr“, sest ei sisalda kasuliku infot standardite ja organisatsioonide seoste kohta.
„news“, sest tabel sisaldab vaid 5 rida ja kõigu uuem uudis on 2008 mai.
„sessions“, sest olemasoleva rakenduse sessioonide info ei oma uues rakenduses väärtust.
Prototüübi ekraanipildid
Alljärgnevas on prototüübi ekraanikuvade valikulised tõmmised, mis olid näitamisel ka teisel
infopäeval. Lisatud on viited arhitektuuri dokumendile.
Pilt ilmestab funktsionaalses jaotuses punkti 2.a.vi.2 ehk „Standard struktuurina (töökoopia)“.
Pilt ilmestab funktsionaalses jaotuses punkti 2.a.vi.5 ehk „Töös olevad mallid“.
Pilt ilmestab funktsionaalses jaotuses punkti 2.a.vi.8.a ehk „Malli atribuudid“.
Pilt ilmestab funktsionaalses jaotuses punkti 2.a.vi.8.b ehk „Atribuutide seosed HL7-ga“.
Pilt ilmestab funktsionaalses jaotuses punkti 2.a.vi.8.b.i ehk „Atribuudi sidumine HL7 atribuudiga“.
Pilt ilmestab funktsionaalses jaotuses punkti 2.a.vi.8.c ehk „Näidisandmed“.
Pilt ilmestab avaliku rakenduse funktsionaalses jaotuses punkti 4.d.i.3 ehk „Versiooni võrdlus
tabelina“.
Pilt ilmestab avaliku rakenduse funktsionaalses jaotuses punkti 4.d.iv.1 ehk „Versioonide võrdlus“.
Testimistaotlus Tervise ja Heaolu
Teabekeskus
Infosüsteemide Keskus
Testmistaotluse nr.: TT_55 Algatamise 02.01.2021
kuupäev:
Seotud Projekti number:
muudatusettepanekud:
Tähtsus: Oluline
Algataja nimi: Bret Rand Tähtaeg: 29.01.2021
Ametikoht/roll: Testimise juht Organisatsioon: Tervise ja Heaolu
Infosüsteemide Keskus
Sisukord
1 Projekti sisu...........................................................................................................................................................2
1.1 Testitava teenuse kirjeldus ...........................................................................................................................2
1.1.1 Eesmärgid .............................................................................................................................................2
1.1.2 Tehniline arhitektuur kokkuvõtlikult ....................................................................................................3
1.1.3 Lisad ......................................................................................................................................................5
1.1 Projekti mõjud teistele projektidele/muudatustele .....................................................................................5
1.2 Projekti- ja tooteriskid ..................................................................................................................................5
2 Testimise kirjeldus ................................................................................................................................................5
2.1 Testimise eesmärk ja ulatus .........................................................................................................................5
2.2 Testimise edukriteerium ...............................................................................................................................6
2.3 Testimise osapooled ja osamäär ..................................................................................................................6
3 Testimistööde teostamine ....................................................................................................................................6
3.1 Testkeskkonna andmed ................................................................................................................................6
3.2 Testimise ajakava..........................................................................................................................................6
3.3 Testimisel osalejad........................................................................................................................................7
3.4 Testimise töömaht ja maksumus (pakkumus) ..............................................................................................7
1
Testimistaotlus Tervise ja Heaolu
Teabekeskus
Infosüsteemide Keskus
1 Projekti sisu
1.1 Testitava teenuse kirjeldus
Tervise Infosüsteemis (digilugu.ee) masintöödeldavate XML dokumentide struktuuride ehk standardite
kirjeldamise töökorralduse ja töövahendite valikud pärinevad aastast 2008. Toona alustati mõne standardiga,
perspektiiviga kirjeldada mõnekümne dokumendi struktuur.
Sellest ajast on palju muutunud:
kirjeldatutud standardite ehk masinloetavate dokumentide hulk on kasvanud 140’ni, koos versioonidega
on neid üle 400. Tulenevalt keerukuse ja mahu kasvust on avalik liides http://pub.e-tervis.ee/standards2
muutunud väga ebaefektiivselt kasutatavaks.
2008 valitud töövahendid on muutunud tööprotsessid kohmakaks ja kulukaks, mis ohustab tulemite
kvaliteeti ning tekitab põhjendamata ülekulu tervishoiuasutustele IT süsteemide arenduses.
standardimise tegevusvaldkond ise on pikemas perspektiivis võtnud uue suuna masintöödeldavate
dokumendistruktuuride loomelt andmevormindamise ning andmevormingu rakendusjuhendite
avaldamise suunas.
1.1.1 Eesmärgid
Teabekeskuse standardite haldamise ja avalikustamise rakenduse väljatöötamise peamine eesmärk on tagada
jätkusuutlik tehnoloogiline ja protseduuriline lahendus masintöödeldavate meditsiinidokumentide struktuuride
ehk standardite edaspidiseks säilitamiseks, haldamiseks ja avalikustamiseks. Kaasnevateks eesmärkideks on tõsta
kirjelduse kvaliteeti, loomeprotsesside efektiivsust ja oluliselt paremaks muuta avaliku loetavust. Täiendavaks
kaasnevaks eesmärgiks on jooksvate kulude kokkuhoid.
Arenduse hanke eesmärkide täpsustused.
1. Eesmärgid tööprotsessile:
A. Suurem sidusus:
a. Uute standardite väljatöötamisel hakatakse arvestama rohkem olemasolevatega.
b. Määrustesse minevad andmekoosseisud hakkavad tulema andmemudelitest.
c. Näidis XML’d genereeritakse mallimudelitest.
d. Klassifikaatorid, OIDid ja andmekontrollid tulevad ühes kohast, st. nendest ei hoita ülal
mitut originaalkoopiat.
B. Laiemad tööprofiilid ja ühiskasutatav keskkond:
a. Väheneb erisus sisulise ja tehnilise standardimise vahel.
b. Kättesaadavaks muutub ühiskasutatav standardimise töökeskkond.
c. Võimalus standardeid ja malle haldurite poolt kommenteerida.
C. Muudatuste ajaloo säilitamine – võimalus tagant järgi jälgida toimunud muudatuse sisu, aja ja
teostaja täpsusega.
D. Avaldamise lihtsus – standardite vahetu avaldamine peab olema võimalik teostada ühe pädeva
isiku poolt kuni 15 minuti jooksul.
E. Võimalus koostada FHIR’i (https://www.hl7.org/fhir/) põhiseid standardeid.
2. Avalike kasutajate rahuloluga seotud eesmärgid/tunnused:
A. Hästi toimiv otsingumootor, võimalus otsida läbivalt märksõna järgi.
2
Testimistaotlus Tervise ja Heaolu
Teabekeskus
Infosüsteemide Keskus
B. Võimalik ainult standardite muudatusi pärida.
C. Võimalus vaadata standardi versiooni tervikliku dokumendina, sh. näidis, skeemid ja kontrollid.
1.1.2 Tehniline arhitektuur kokkuvõtlikult
Järgnevalt ülevaatlik arhitektuurne joonis, kus nooled näitavad andmete peamisi liikumise suundi. Halduse poolel
on andmete lugemine ja kirjutamine. Avalikus osas toimub vaid andmete lugemine. Avaliku andmebaasi täitmine
toimub masstegevusena Halduri rakenduse poolt.
cmp Veel uuem versioon ver2
Haldur Tehikus Haldur, väline partner
Avalik kasutaja
Haldusliides Teabekeskuse avalik liides
http://sise.tehik.ee/ http://teave.tehik...
Teabeksekue halduri rakendusserver Teabeksekuse rakendusserver
Halduri rakenduse kasutajaliides Avaliku rakenduse kasutajaliides
Halduri rakenduse (REST) teenuskiht Avaliku rakenduse (REST) teenuskiht
Teabekeskuse Postgre andmebaas haldamiseks Teabekeskuse Postgre andmebaas
avalikele andmetele
Kõik standardimisega seotud EA andmeskeem
andmed. Teabekeskuse avalike
andmete skeem
Halduri baas
Avalik baas
Enterprise Architect
Ajalooliste
andmete sirvimine
Haldur (EA rakendus)
Joonis 1. Teabekeskuse arhitektuuri joonis
Teabekeskuse arhitektuuri kandvateks ideedeks on:
1. Arhitektuursed üldnõuded:
A. ISKE soovitav tase on K1T1S0.
K1 – käideldavuse vahemik 90% - 99% ja maksimaalne lubatud ühekordse katkestuse pikkus
teenuse töö ajal kuni 24 tundi.
3
Testimistaotlus Tervise ja Heaolu
Teabekeskus
Infosüsteemide Keskus
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).
B. Tehnoloogiate ja raamistike valikul rakenduse loomiseks tuleb lähtuda TEHIK’u IT-profiilis
https://wiki.sm.ee/display/AV/IT-Profiil nimetatud tehnoloogilistest eelistustest. Valik
kooskõlastatakse hankijaga enne projekti algust.
2. Andmebaasid:
A. Andmebaasi mootoriks peab olema Postgre.
B. Tänane Enterprise Arhitecti skeem jääb kasutusse vaid ajalooliste andmete vaatamiseks ja
olemasolevate standardite importimise allikana.
C. Standardite loomiseks ja haldamiseks luua uus andmeskeem, mis peab sisaldama ka seotud
dokumentide (juhendite) andmeid.
D. Avalikule osale luua eraldi andmebaas või andmeskeem, mis arvestaks avaldamise, andmete kiire
leidmise ja võrdlemise vajadusi.
3. Rakendused:
A. Rakendusserveri tarkvaraks on Tomcat embedded versioon.
B. Rakendus peab töötama konteineris (Docker).
C. Analoogselt andmebaasidega on halduri ja avaliku poole rakendused eraldi serveritel. See
võimaldab süsteem eraldi arendada ja ülal hoida.
D. Standardite haldamise poolel on täna vaid 3-5 kasutajat ja tulevikus ei ole ette näha kasutajate
hulga kasvu üle 10’ne. Mõnekümneni võib kasvada OID’e ja klassifikaatoreid haldavate isikute arv,
kui otsustatakse haldamise vastutused laiali jaotada. Avaliku poole kasutajate arv võib küündida
100’ni. Samas, igapäevane sisuline kasutus on madal. Peamist koormust tekitavad
otsingumootorid ja juhukülalised.
E. Mõlemas rakenduses (halduri ja avalik) tuleb selgelt ülejäänud rakendusest eristada
kasutajaliidese kihti/loogikaid.
F. Kasutajaliidese üldises kujunduses tuleks lähtuda Maksu- ja Tolliameti Iseteeninduskeskkonna
stiiliraamatust, mida vajadusel (nt. puustruktuuride kuvamine) võib laiendada vastavalt
Teabekeskuse konkreetsele vajadustele.
Teabekeskuse laiem visioon ning täpsemad kirjeldused käesoleva arenduse hanke skoopi kuuluvatest
komponentidest on kirjeldatud dokumendis Lisa 1 Teabekeskuse standardite haldamise arhitektuur ver211.docx,
mis on lisatud turvatestimise taotluse dokumendile.
Võimalik on tutvuda mitmete komponentide prototüüpidega, nagu nt. idee näidisandmete käsitlusest,
versioonide võrdlemisest, hierarhiline kuvamine, redigeerimise ja loendivormid jt, mis on lisatud turvatestimise
taotluse dokumendile. Prototüübiga tutvumine vajab tellijapoolset ettenäitamist, sest teema on keerukas ja pole
olnud võimalik luua iseennast seletavat / ladusalt intuitiivset prototüüpi.
1.1.3 Lisad
1. Lisa 1 Teabekeskuse standardite haldamise arhitektuur ver211.docx
2. Lisa 2 Teisel infopäeval näidatud prototüübi ekraanipildid.docx
4
Testimistaotlus Tervise ja Heaolu
Teabekeskus
Infosüsteemide Keskus
1.2 Projekti mõjud teistele projektidele/muudatustele
Projekt/Muudatus Sõltuvuse iseloom Märkused
(ressurss/tulemid/ajakava)
1.3 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
Teabekeskuse toote keskmine suur Turvatestimisel leitud vead
rakenduste parandatakse.
kasutajaliidese kaudu
rikutakse andmete
terviklikust.
2 Testimise kirjeldus
2.1 Testimise eesmärk ja ulatus
Punkti 1.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.
2. Kontrollitakse, et testitava rakenduse võimalike haavatavauste kaudu ei oleks võimalik juurde pääseda
andmetele, mis asuvad väljaspool testitava rakenduse funktsionaalsust.
3. Turvatestimine peab olema tehtud OWASP ASVS level 1 testimise metoodika alusel.
4. Turvatestimine logide kohta peab olema tehtud OWASP ASVS level 1 testimise metoodika alusel.
5. Testimise lõppedes esitletakse tulemusi tellijale ja tellija poolt kaasatud arendajale.
2.2 Testimise edukriteerium
Testitavad objektid Edukriteeriumid/Meetrika
Rakendus koos kasutajaliidesega Rakenduse veebiliideses ei ole üldtuntud turvaauke, mis võimaldaksid
välisel ründajal rakendusse sisse murda ja teha selles mingeid äriloogika
vastaseid tegevusi.
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
jäävate osapooltega, siis tuleb ka nende osalus ära märkida.
R – vastutav teostaja/juht
A – vastutav vastuvõtja/tellija/omanik
5
Testimistaotlus Tervise ja Heaolu
Teabekeskus
Infosüsteemide Keskus
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
Teabekeskus asub TEHIKu testkeskkonnas.
Testimisel olevad aadressid (hetkel ei ole teada konkreetseid aadresse, kui selgub, siis teavitame):
1. halduri rakendus;
2. avalik rakendus;
3. halduri rakenduse andmebaas;
4. avaliku rakenduse andmebaas;
5. logid;
6. lähtekood.
Ligipääsude haldamine käib vastavalt kehtivale ligipääsude haldamise korrale.
3.2 Testimise ajakava
Tarne Tähtaeg Koosseis
Rakenduse ja logide turvatestimine ASVSv4.0 (või 3 ... 4 töönädalat al. testide algusest Jaanuaris vt. 3.3
uuema) Tase 1 alusel 2021
Veaparanduste test sõltuvalt tulemitest ja kõikide 2 ... 4 tööpäeva ületestide algusest vt. 3.3
paranduste tarnest
3.3 Testimisel osalejad
Organisatsioon Koosseis Roll
Clarified Security OÜ Mehis Hakkaja Turvatestimise meeskonna ja projekti juht, raportite
üle vaataja
Clarified Security OÜ Anti Räis, Turvatestija vastutavas rollis (vähemalt 1 vastutav
turvatestija, kes omab OSWE/GWAPT/CWAPT
Silvia Väli,
sertifikaati) ja vastavas rollis testimise kogemust
Elar Lang,
Andres Liiver
6
Testimistaotlus Tervise ja Heaolu
Teabekeskus
Infosüsteemide Keskus
Clarified Security OÜ Mihkel Raba, Turvatestija (kaasatakse vastavalt vajadusele ja
sobilikkusele)
Liis Jaks,
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-ta Töö maksumus km-ga
ühik (h) (EUR) (EUR)
Turvatestimine ASVS Tase 1 alusel (al. Jaanuar 74 8510 10212
2021); 2 liidest (haldur + avalik)
Logide turvatestimine ASVS Tase 1 alusel 16 1840 2208
Veaparanduste test sõltuvalt tulemitest 15 1725 2070
Kokku (ASVS Tase 1 + logid): 105 12075 14490
7