HealthSense (De)Serialiseerija
tehniline kirjeldus
Eesmärk
Eesmärk on arendada valmis terviklik ELT (extract - load - transform) ahel (pool-
)struktureeritud andmete laadimiseks relatsioonilisse andmebaasi, mida oleks võimalik
rakendada Eesti terviseandmete CDA dokumentide laadimiseks andmelattu
dünaamiliselt. Dünaamiline laadimine tähendab, et andmebaasi skeem ei ole ette
defineeritud, vaid tuletatakse andmete laadimise käigus.
Andmebaasis olevad andmed peavad olema päritavad teades nende andmete
paiknemist algses mudelis (dokumendis või sõnumis).
Hanke tulemusena arendatav deserialiseerija rakendus peab võimaldama andmelao
relatsioonilisse andmebaasi laadida (pool-)struktureeritud, tihti dokumendi või
sõnumivormingus olevaid andmeid. Deserialiseerijat soovib TEHIK rakendada eelkõige
terviseandmete laadimiseks andmelattu, kuid rakendus peaks olema piisava
abstraktsustasemega, et võimaldab töödelda ja laadida mistahes XML ja JSON
vormingus andmeid.
Deserialiseerimise mõiste all peetakse silmas serialiseeritud objektide nagu XML
dokumendid või JSON sõnumid viimine andmebaasi kujule, mis võimaldab andmeid
relatsioonilises baasis taaskasutada.
Taustainfo
Tervise infosüsteemis ja selle andmebaasides talletatakse Health Level 7 (HL7) Clinical
Document Architecture (CDA) põhinevaid XML dokumente ning HL7 FHIR standardil
põhinevaid JSON sõnumeid.
HL7 CDA tervisedokumendid tuginevad kohalikele dokumendivormingutele, lähtuvalt
dokumendi tüüpidest ja nende aja jooksul täienenud versioonidest. Standardikogumik on
avaldatud TEHIKu publitseerimiskeskuses aadressil: https://pub.e-
tervis.ee/standards2/Standards näidisdokumentide ja juhendite kujul.
HL7 FHIR sõnumistandard on välja töötamisel ning avaldatakse TEHIKu teabekeskuse
keskkonnas.
Rohkem taustainfot terviseandmete andmevormingutest, standarditest ja
rakendatavatest klassifikaatoritest leiab: https://www.tehik.ee/teabekeskus
Projekti eeltööna on TEHIK teinud koostööd Tartu Ülikooli teadusrühmaga, uurides
võimalikke lahendusi terviseandmete deserialiseerimiseks. Välja töötatud meetodid on
käesoleva hanke sisendiks.
Tartu Ülikooliga arendatud meetodid
Andmete relatsioonilisse baasi laadimise jaoks on koostöös Tartu Ülikooliga
prototüübitud kahte erinevat lähenemist. Esimene neist vaatab CDA XMLi struktuuri ja
andmetesse sisse, ja selle põhjal deklareerib eelnevalt, et mis on esmajärgus oluline ja
eraldab selle. Teine lähenemine lähtub CDA XMLi struktuurist ja eraldab kõik info
automaatselt. Järgnevas on nende kohta toodud detailsem kirjeldus.
Semantiline baas
Semantilise baasi loomise idee aluseks on mingis lähenduses “mõistlik” sisend-CDA faili
tükeldus relatsioonilise baasi tabeliteks nii, et osa olulist infot on koheselt päritav ja muu,
nö “lahti harutamata” info on väiksemate tükkidena kirjetega kaasas (praegu algse faili
XML-i osadena, või edaspidi ka nt JSON-ina). Selline lähenemine annab võimaluse pärida
peamine info kiirelt, tutvuda alampuudena sälitatud infoga ja seda vajadusel eraldi lahti
parsida või otse pärida (XPath, XQuery või muu taolise formaadile vastava päringu-keele
abil).
Meetod tekitab tabelid cda_documents, cda_meta, cda_sections, cda_subsections,
cda_entries, cda_subentries ja eraldi tabeli logide jaoks. Iga tabeli korral on eraldi välja
toodud teatud võtme-väärtused, nt section korral <code code="AMBS"
codeSystem="1.3.6.1.4.1.28284.6.2.2.11.2" codeSystemName="Sektsiooni kodeering"
displayName="Ambulatoorne haigusjuht"/> elemendi atribuutide väärtused, cda_entries
korral ka effectiveTime elemendi value atribuudi väärtus jne.
Põhjalik kirjeldus tabelite kohta on toodud vastava koodibaasi README.md failis.
Viide koodibaasile: fail semantic-db.zip
Automaat-struktuuriga baas
Erinevalt semantilise baasi lähenemisest parsib automaat-struktuuriga baasi parser kogu
XML-struktuuri andmetabeliteks laiali. Rangelt XMLi struktuuri parsides eraldatakse
tabelid stiilis section.component, section.entry, observation.entryRelationship vmt. Tabelil
entryRelationship võivad omakorda olla veerud "@typeCode", "observation.@classCode",
"observation.code.@code" jne. Üksteisega seotud tabelite tekitamise vajadus lähtub üks-
mitmele seostest, nt representedOrganization elemendi all võib olla mitu telecom
elementi, igal sisuline atribuut value; antud näite korral tekitame tabeli
ClinicalDocument.author.assignedAuthor.representedOrganization.telecom
veeruga ”@value“ ja hoiame meeles elementide järgnevuse veeru _seq_no abil.
Struktuuri jälgitavuse mõttes saab tuua tabeli nimes esile tema taseme, nt
level4_observation.entryRelationship; kui tabeli taset esile ei tooda, siis hallatakse eri
tasemete infot ühes tabelis koos (nt level4_observation.entryRelationship ja
level5_observation.entryRelationship asemel observation.entryRelationship).
Automaatse struktuuriga baasi korral on hea see, et info on koheselt päritav (ei pea
midagi lisaks parsima või eraldama). Samas tabelite ja veergude nimed võivad olla väga
pikad (isegi nii pikad, et ei sobi “AS IS” kujul relatsioonilisse baasi tabeli või veeru nimeks -
pikkuse piirangud tulevad ette).
Kirjeldus programmi kohta on toodud vastava koodibaasi README.md failis.
Viide koodibaasile: fail hesedese.zip
Taotletav meetod (tervise-)andmete deserialiseerimiseks
Taotletav meetod on varem prototüübitud meetodite edasiarendus, kus säilivad mõlema
meetodi nn “head omadused”:
● Kõik info jõuab CDA XML dokumentidest andmebaasi ühel või teisel moel, midagi
ei lähe kaduma, s.t:
○ andmebaasi struktuur peegeldab laias laastus (täpsemalt sõltub
seadistusest) algsete CDA XML dokumentide struktuuri - võimaldab teha
päringuid ilma, et oleks vaja olulisel määral lisateadmisi
○ kui mingi info baasi ei jõua, siis see on teadlik disaini-otsus
○ arvestatakse andmebaasi piirangutega (nt rel. baasi tabeli ja veeru nime
maksimaalse pikkuse piirang ei saa takistuseks)
○ andmebaasi veeru tüüp on piisavalt suur, et kogu tekstiline info vastu võtta
● Info CDA XML failidest on vajalikul määral koheselt lahti parsitud, aga mitte liiga
palju (täpne määr sõltub seadistusest);
○ nt üldjuhul ei soovita HTML tabeleid eraldi tr ja td tabeliteks lahti võtta,
sest tabeli päis on eri tabelitel erinev ja korrektseks interpretatsiooniks
tuleks tabel uuesti kokku panna ja sealne info relatsioonilises baasis
semantilisemal viisil esitada
● Meetod võimaldab anda täiendava, intuitiivsema nimetuse tabelile või veerule
(täiendav semantika)
Meetodiga seotud detailid
Toome järgnevas välja mõningad detailid, mis on nii prototüübi kui üldise meetodi
edasiarendusega otseselt seotud.
● Midagi ei lähe kaduma. Siin on oluline tähele panna, et prototüüpide korral on
tehtud teadlikud lihtsustatud valikud, mida produktsiooni-lahenduse korral võib
olla vaja täiendada:
○ Semantilise baasi tekitamise korral ignoreeritakse XML nimeruume
(namespace) ja nimeruumi prefikseid. See annab automaatselt
ühetaolisemad XML-d ja nö “puhtamad” säilitatavad alampuud. Ei ole
selge/verifitseeritud, et kas võivad tekkida konfliktsed olukorrad (kas
mingis kahes või enamas eri nimeruumis on identsed
elemendid/atribuudid).
○ XML märgenduste korral nn mixed-mode content olukorrad võivad
JSONiks pöörates infot kaotada, sh segi pöörata algse järjekorra (JSONiks
pööratakse sisu sellepärast, et TEHIK tehnilise lahenduse siht-baas on
Vertica, mis oskab JSONiga opereerida). Võib olla vajalik säilitada algne
info blob-ina (algne XML-i alampuu või konverdituna nt JsonML formaati
vmt) vastava kirje juures, et täielik info oleks olemas.
○ Prototüüp ei oma erikäitlust XML-i CDATA sektsioonide korral; võimalik, et
see on vaja lisada.
● Koheselt lahti parsitud, aga mitte liiga palju. Piirangud lahti parsimise osas peab
saama ette anda konfiguratsiooniga (XPath-id elementideni, mida säilitada blob-
ina/alampuuna terviklikult).
● Lisa-semantika haldus. Tekitatavate tabelite ja veergude nimetuste puhul peab
olema konfiguratsiooniga määratav deterministlik ümber nimetamise loogika, et
tulla toime siht-baasi nimetuste pikkuse piiranguga ja/või lisada täiendavat
semantikat kohe, esmasel andmelao tekitamisel.
○ Ümbernimetamise korral on algne nimetus säilitatav ka andmebaasi tabeli
või veeru kommentaarina. See on mugav lisa-info sellele, kes tunneb
algset CDA formaati hästi.
Tehniline kirjeldus
Tehniline eesmärk
Arhitektuurikavandi eesmärk on loodav lahendus kavandada nõnda, et komponendid
oleksid taaskasutatavad ning rakendatavad andmelaadimise ökosüsteemis - see
tähendab, et deserialiseerimist oleks võimalik rakendada ka teistele andmelaadimistele,
kus andmeallika väljundiks on keerulisema struktuuriga objektid, mis sisaldavad
alamobjekte ja massiive.
Tehnoloogiad
Andmeallikad - Oracle, PostgreSQL, S3
Tervise infosüsteemi andmebaasis Oracle 19c paikenvad CDA XML dokumendid
vastavas tabelis XMLType elemendis, tabeli veerud sisaldavad täiendavat
metaandmestikku andmete laekumise kohta.
Tervise infosüsteemi mikroteenuste andmebaasid PostgreSQL sisaldavad CDA XML
dokumente ning HL7 FHIR JSON sõnumeid.
Tervise infosüsteemi mikroteenuste S3 storage (Minio) sisaldab HL7 FHIR JSON
sõnumeid.
Andmelaadimise lahendus - Meltano
Alusplatvormiks Meltano EL andmelaadimise open-source tarkvara -
https://meltano.com/ (python)
Meltano võimaldab mistahes (toetatud) allikast nagu andmebaasid, REST APId või enda
arendatud extractor connector komponentide abil laadida andmeid mistahes (toetatud)
sihtmärki nagu andmebaasid, failid jne. Erinevate allikate ja sihtmärkide kombineerimine
on võimalik tänu nende vahel rakendatavale singer.io standardile, kus extractori
väljastatav (STDOUT) striim singer.io standardi vormingus on tarbitav vastava loader
(target) komponendi (STDIN) sisendina - https://hub.meltano.com/singer/spec/ .
Meltano võimaldab andmelaadimise (extract ja load) vahel rakendada täiendavaid
andmetöötlusi mapper komponentide abil. Täiendav dokumentatsioon leitav siit:
● https://docs.meltano.com/guide/mappers/
● https://sdk.meltano.com/en/latest/stream_maps.html
Andmelaadimise sihtmärk
Vertica andmelao andmebaas, versioon 23.4 või uuem, sh. Vertica FLEX
tabelistruktuurid- https://docs.vertica.com/23.4.x/en/flex-tables/understanding-flex-
tables/
Vertica FLEX tabelid annavad paindlikkuse hoida andmebaasis keerulisemaid nested
struktuure ning neid vajadusepõhiselt materialiseerida. Täiendavalt on FLEX tabelite
litsentseerimistingimused soodsamad ning seetõttu on eelistatud flex tabelite
kasutamine.
Täiendavalt peaks rakendus töötama Meltano ökosüsteemis target-postgres ehk
PostgreSQL andmebaasiga.
Andmete materialiseerimine andmelao andmebaasis
Vertica FLEX tabelite definitsioonides tuleb kasutatavad veerud materialiseerida
veergude default väärtuste määramisega vastavale flex json pathile. Täpsem
dokumentatsioon leitav siit: https://docs.vertica.com/23.4.x/en/flex-
tables/materializing-flex-tables/
Transformatsioonide rakendamine andmetele andmelaos - dbt
Täiendavate transformatsioonide rakendamiseks tuleb kasutada dbt ehk Data Build Tool
open-source tarkvara, täpsem teave: https://www.getdbt.com/product/what-is-dbt .
Andmelaadimiste orkestreerimine
Andmelaadimised ehitatakse valmis Docker konteineritena, mis järgivad stateless
printsiipi ning orkestreeritakse Kubernetes klastrites. Andmelaadimisi käivitab TEHIKu
poolne dag tüüpi orkestraator, mis ajastab laadimised vastavalt konfiguratsioonile.
Docker konteinerite käivitusel järgitakse short-lived printsiipi - st. laadimise käivitamiseks
pannakse konteiner tööle ning selle töö lõppemisel ressurss vabastatakse ning
konteineri instants läheb kinni.
Andmekataloog - DataHub
Andmekataloogina rakendatakse DataHub open-source tarkvara, mis võimaldab ära
kaardistada andmete kohta käivad metaandmed erinevates andmete elukaare etappides
- st. andmeallika, andmelaadimise, andmelao ja seal toimuvate transformatsioonide
lõikes. Samuti joonistub andmekataloogist välja andmete pärinemine (Data Lineage).
Täpsem teave: https://datahubproject.io/
Pseudonüümimine - TEHIKu komponent
Andmelaadimise käigus andmete pseodonüümimise jaoks tuleb arendada integratsioon
TEHIKu pseudonüümija komponendiga - tegemist on Javas arendatud teenusega, mida
on võimalik tarbida üle (X-tee) REST API, Java SDK või Java CLI rakenduse abil. Rohkem
infot:
https://koodivaramu.eesti.ee/tehik/pseudoengine
https://koodivaramu.eesti.ee/tehik/pseudoengine/Docs
Arhitektuurikavandi joonis
Toodud joonisel on näidisvoogude abil kirjeldatud komponente koostöös töötamas,
vastavalt andmeallikast lähtuvatele vajadustele. Täpsemalt on komponentide töö
kirjeldatud alljärgnevalt.
Kavandatav lahendus ja arendustööd
Rakendades Meltano ökosüsteemi andmelaadimiste alusplatvormina saab
deserialiseerija põhilised komponendid arendada kui Meltano mapper’id.
Kavandatavas arhitektuuris võib muudatusi teha kokkuleppel tellijaga.
Funktsionaalsuse tagamiseks on vaja arendada või täiendada peatükis kirjeldatud
komponente.
Üldised nõuded
Tarkvarakomponentide ja teekide kasutus
Lähtuma peab TEHIKu IT profiilist ja ristfunktsionaalsetest nõuetest.
Kasutada võib levinud ning arendustoega tarkvaralisi komponente, mis on avatud
lähtekoodiga. Komponentidel ei tohi olla lahendamata CVE’sid ehk turvahaavatavusi.
Kõrvalekaldeid võib teha TEHIKu arhitekti nõusolekul.
Lahenduste konteineriseeritavus
Arendatavad rakendused peavad töötama konteineriseeritavalt - st. eraldiseisvates
Docker konteinerites, v.a. juhul, kus on otstarbekas hoida komponente ühe loogilise
tükina.
Konteinerid peavad olema olekuvabad, st. konteineri olek (state) kirjutatakse väljapoole
konteinerit (Kubernetes PvC, S3 teenus, väline andmebaas oleku hoidmiseks).
Metaandmete genereerimine
Andmelaadimise ja deserialiseerimise käigus tekib uusi andmestruktuure, mis tekitab
andmestikku uusi seoseid. Andmelaadimise käigus tekib täiendavat metaandmestikku
(seosed, laadimisaeg, allikas, andmete pärinemine), mis tuleb sihtmärkandmebaasi
(andmelattu) talletada.
Monitooring
Arendatavad komponendid peavad toetama standardseid monitoorimisliideseid, millega
on võimalik veenduda nende töös.
Logimine
Logimine toimub rakenduse konteinerite puhul STDOUT kaudu, kus rakendatakse
Kubernetes platvormil Prometehus logide kogumist ning Elasticut logikaeveks.
Andmelaadimistel peab olema täiendav logimine, kus on võimalik tuvastada erinevaid
laadimisetappe, laadimistsükleid siduda laetud andmetega.
Idempotentsus
Andmelaadimised peavad olema idempotentsed, st. korratavad samade
sisendparameetrite alusel.
Laadimiste paralleliseeritavus
Üheaegselt peab olema võimalik mitmel andmelaadimisel töötamine, sellest lähtuvalt ei
tohiks andmelaadimiste töövood minna konflikti - nt. kui kasutatakse ajutist olekut, siis
see olek ei tohi olla üle kirjutatud teise paralleelse laadimisprotsessi poolt.
Automatiseeritus
Andmete laadimine peab olema automatiseeritud, seejuures ei tohiks uute
andmestruktuuride tekkimine nõuda täiendavat arendus- või seadistustööd.
Tõrkekindlus
Kõik komponendid peavad olema arendatud koos veahaldusega ja toime tulema ka
vigase sisendiga. Vigase sisendi puhul peab olema ettemääratud tegutsemisviis ning see
ei tohi ahela toimimist takistada järgmiste dokumentide või sõnumite töötlemisel.
Andmete ühekordne pärimine
Alliksüsteemide minimaalseks koormamiseks ei tohi samu andmeid uuesti küsida ning
järgida inkrementaalse laadimise printsiipi.
Duplikaatkirjete vältimine
Andmelaadimine ei tohiks tekitada duplikaatkirjeid - st. identseid kirjeid samas
kontekstis.
Nimeskeemide rakendamine
Läbivalt tuleb kasutada nimekonvensiooni.
Seadistatavus
Komponentide seadistus ei tohi olla jäigalt koodi kirjutatud vaid peab olema välise
konfiguratsiooni kaudu juhitav.
Koodi taaskasutatavus ja avaldamine
Loodavate rakenduste lähtekood avalikustatakse Koodivaramu või GitHub
repositooriumites. Meltano ökosüsteemi loodud komponente soovime avalikustada
Meltano Hub’is, et ka teised asutused saaksid loodud lahendusi oma ökosüsteemis
kasutada. Sellest lähtuvalt peab Meltano komponendid järgima Meltano arendus ja
dokumenteerimisnõudeid.
Lähtekoodi kirjutamisel kasutatakse inglise keelt.
Andmelaadimisallikate toe laiendamine - arendatavad või
täiendatavad komponendid
Allikast andmete laadimine peab olema realiseeritud inkrementaalsena, st. samu
andmeid päritakse ühe korra - muudatusi on võimalik tuvastada change_time tüüpi
atribuudi abil allikast.
tap-oracle - võimalik kohandamine
https://hub.meltano.com/extractors/tap-oracle/
Andmete väljavõtt tervise infosüsteemi Oracle andmebaasist peab võimaldama
XMLType struktuuride kaasamist andmelaadimise käigus.
tap-postgresql - võimalik kohandamine
https://hub.meltano.com/extractors/tap-postgres
Andmete väljavõtt tervise infosüsteemi mikroteenuste andmebaasidest peab
võimaldama XML ja JSON struktuuride kaasamist andmelaadimiste käigus.
tap-s3 / tap-json - arendus
https://hub.meltano.com/extractors/tap-singer-jsonl
https://hub.meltano.com/extractors/tap-s3
Andmete väljavõtt uue põlvkonna tervise infosüsteemi S3 Minio pinnalt JSON failidest.
Võimalik, et vaja arendada uus laadimiskomponent võttes aluseks viidatud
komponendid.
Andmevormingu teisendamise komponendid (mapper) - arendatavad
komponendid
Mapper komponentide abil on võimalik allika väljundstriimis teha andmevormingu,
struktuuri, schema jms. vajalikke muudatusi. Mapper komponentide tulemusena muutub
striimi esialgne struktuur - tekib juurde schema definitsioone - st. objekte (tabeleid), tekib
juurde ka ridu.
mapper-xml-2-json - XML struktuuride asendamine JSON struktuuridega
Arvestades seda, et sihtmärkandmebaasides ei ole võimalik XML andmestruktuuridega
andmetöötlust teha, siis tuleb XML vormingus andmed konverteerida JSON
vormingusse. Siinkohal on arenduse sisendi eeskujuks Tartu Ülikooli arendatud
lahendus, mis kasutab Benedict Pythoni teeki:
https://github.com/fabiocaccamo/python-benedict
HTML elemendid XMLi sees tuleb säilitada originaalkujul
XML teisendamises JSON struktuuri tekib probleem HTML elementidega (eriti HTML
tabelitega), seetõttu antud faasis tuleb XML JSONisse teisendamise käigus jätta
teisendamata HTML elementide struktuurid ning säilitada need (ülem)struktuuris kui
vabatekst.
mapper-html-table-2-json - HTML tabelite normaliseerimine
Arvestades seda, et HTML tabelid jäid eelnevas etapis deserialiseerimata, siis antud
mapperi eesmärk on ekstraheerida vabatekstilistest veergudest HTML tabelid ning need
eraldiseisvalt deserialiseerida. Seejuures peab HTML tabelite deserialiseerimise
lahendus arvestama THEAD, TH elementidega ning tulema toime colspan ning rowspan
atribuutide kasutamisega, et HTML tabel oleks teisendatud JSON struktuuri, mis oleks
hiljem andmelao andmebaasis kasutatav kui tavaline 2 dimensiooniline tabel.
mapper-dese - massiivide ja keeruliste andmestruktuuride deserialiseerimine
Keerulised JSON struktuurid võivad sisaldada endas nested objekte (parent-child
hierarhiaid) ning massiive. Vastavate andmestruktuuride käsitlemiseks andmelaos tuleb
need struktuurid normaliseerida - samatüübilisi objekte sisaldavad massiivid eraldada
eraldi tabelitesse ning tuvastada rekursiivsed hierarhiad, kus samatüübiline objekt
kajastub alamobjekti sees.
Eeskujuks on Tartu Ülikooli arendatud lahendus.
mapper-schema-on-read
Target objekti andmete laadimiseks on vajalik tuvastada andmestruktuur (schema)
laekunud andmetest. Siinkohal peab aga arvestama, et andmestruktuurid võivad
dokumentide lõikes varieeruda - tulem schema peab toetama schema evolutionit ehk
andmestruktuuri muutust.
Schema on read mapperi väljund on singer.io striimi täiendamine schema kirjelduse
osas, mis võimaldab deserialiseeritud andmestruktuure sihtmärgis sobilikesse
tabelitesse kirjutada.
mapper-object-identifier - objektinimede pikkuse piirangu lahendamine
Vertica andmebaasi piirangu tõttu ei tohi objekti nimi (so. skeemi, tabeli, vaate või veeru
nimetus) olla pikem kui 128 tähemärki. Täiendavad piirangud on esitatud
dokumentatsioonis: https://docs.vertica.com/23.4.x/en/sql-reference/language-
elements/identifiers
Taustainfoks: Tartu Ülikooli arendatud prototüübis saab kasutada replacements.csv faili -
asendada pikemad nimetused lühematega. Ühtlasi võimaldab see siis objektinimede
pikkusi lühendada (aga ei garanteeri suvalise andmestiku korral mingi pikkuse sisse
mahtumist, st vajadusel tuleb asenduste faili probleem-kohtade (jätkuvalt liiga pikkade
nimede korral) korduvalt täiendada). Prototüübis saab kasutada replacements.csv faili.
Asendused on rekursiivsed (kui esmalt on asendus ‘AABBCC’ => ‘aabbcc’, ja peale seda on
kirjeldatud ka asendus ‘aabbcc’ => ‘abc’, siis tulemuseks on ‘abc’).
Antud komponendi (mapper) ülesanne on liialt pikad objektinimed asendada
lühematega, mis sobituksid Vertica andmebaasist lähtuvate piirangutega.
Kasutada räsimisalgoritme, kus osa objekti nimest asendatakse räsiga.
Kasutada ka tekstilist asendust, kus eelkonfigureeritud loendi alusel asendatakse teatud
sõned objekti nimes lühemaga.
Rakendus peab hoidma asenduste kohta olekut (andmebaasis), mille abil on võimalik
tuvastada, mis oli objekti nime väärtus originaalis.
Algse objekti nimi tuleks kirjutada täiendavalt ka andmebaasi objekti kommentaari.
Asendusfunktsioon peab tagama, et erinevad objekti nimed ei saaks asendusel sama
väärtust.
mapper-pseodoengine
Konfiguratsiooniga juhitav komponent, mille eesmärk on määratud andmestruktuurides
asendada delikaatsed isikuandmed pseudonüümiga. Integratsioon peab toimuma
TEHIKus arendatud Pseudonüümija teenuse vastu.
Andmelaadimise sihtmärki kirjutamine
Vertica andmebaasi andmete kirjutamiseks on Meltano ökosüsteemis olemas target-
vertica komponent https://hub.meltano.com/loaders/target-vertica/ , kuid see on
arendatud varasema platvormi Singer.io komponendina, mitte Meltano SDK põhjal.
Antud komponent tuleks konverteerida Meltano SDK peale.
target-vertica komponenti tuleb täiendada võimalusega kirjutada andmeid Vertica FLEX
tabelitesse, TEHIKus on selle kohta näidiskood olemas, kuid see tuleb
toodangukõlblikuks kirjutada.
target-vertica komponenti tuleks täiendada, et oleks võimalik anda andmebaasis
objektidele kommentaare vastavalt schema definitsioonile.
Andmete transformatsioon ja integratsioonikiht andmelaos
Eelnevates etappides toodi andmed andmelattu, ehitati valmis allika andmemudelile
lähedased sihtstruktuurid, kuid andmelaos on vaja andmed baastasemel integreerida.
Üks näide integreerimisprobleemist on järgnevad XML struktuurid, kus XML struktuuris
võib ühekordne element mahtuda ära tavapärasesse tabelisse aga massiivi korral
andmed eraldatakse eraldi tabelisse.
Praktikas aga on sellistes kohtades vaja andmed integreerida, selle näidis on toodud
allpool.
Näidis Lineaarne struktuur Massiivi sisaldav struktuur
XML <element> <element>
sisend <atribuut>Väärtus</atribuut> <atribuut>Väärtus</atribuut>
<alamad> <alamad>
<alam> <alam>
<attribuut>v1</attribuut> <attribuut>v1</attribuut>
</alam> </alam>
</alamad> <alam>
</element> <attribuut>v2</attribuut>
</alam>
</alamad>
</element>
JSON { {
"element": { "element": {
"atribuut": "Väärtus", "atribuut": "Väärtus",
"alamad": { "alamad": {
"alam": { "alam": [
"attribuut": "v1" {
} "attribuut": "v1"
} },
} {
} "attribuut": "v2"
}
]
}
}
}
“Deserialis { {
eeritud” "element.atribuut": "Väärtus", "element.atribuut": "Väärtus",
flat JSON "element.alamad.alam.attribuut": "v1" "element.alamad.alam.#table":
triviaalne
} "element.alamad.alam"
näidis
}
# "element.alamad.alam"
{
"attribuut": "v1"
},
{
"attribuut": "v2"
}
Tabel(id) Tabel: dokument Tabel: dokument
Veerud: Veerud:
● element.atribuut ● element.atribuut
● element.alamad.alam.attribuut ● element.alamad.alam.#table
Tabel: element.alamad.alam
Veerud:
● attribuut
Integatsio create view "element.alamad.alam" as
oni vaade select "element.alamad.alam.attribuut" as "attribuut"
from dokument
union all select "attribuut" as "attribuut"
from "element.alamad.alam"
Andmete integratsioonid tuleb realiseerida genereeritud dbt skriptide abil.
Andmelaadimiste orkestreerimine
Andmelaadimine peab kirjeldama ära oma pipeline ehk töövoo vajalikud etapid, mida siis
välise orkestreerimiskomponendiga (nt. Apache AirFlow või sarnane) abil käivitatakse.
Integratsioon andmekataloogiga
Andmekataloogi DataHubiga peavad andmelaadimise etapid olema integreeritud,
seejuures kirjeldades ära andmete elukaare (Data Lineage), metaandmed
andmestruktuuride kohta ja seosed erinevate laadimisetappide vahel.
Mudeli statistika kogumise võimekus
Mudeli statistika kogumise võimekus võimaldab andmeanalüütikul ja -arendajal
tuvastada andmestruktuure, nende esinemise tihedust ja andmekaevet
andmestruktuuride kohta.
Realisatsioon peaks olema mapper-schema-on-read tasandil, kus tekib täiendav
metaandmestik, mis tuleb eraldi andmebaasitabeli(te)sse kirjutada.
Hinnangulised mahud
Tervise infosüsteemis on talletatud ligikaudu 30 TB (terabaiti) XML dokumente.
Iga-aastane andmete juurdekasv on ligikaudu mahus 5 TB.
Arvestama peaks igapäevase arvestusliku dokumentide pealekasvuga 100 000
dokumenti.
Kitsendused ja ennetatavad probleemid
Teadaolevad nüansid ja probleemid, mida tuleb arenduse käigus lahendada:
Kodeeringu probleemide lahtiseletus
CDA dokumentide andmekvaliteet, st.:
● XML dokumentides võib esineda varieeruvat kodeeringut (encoding), kus
dokumendi väline keha ning atribuutide väärtused on erinevas kodeeringus
● mudeli erinevus
● kuigi dokumendid on kõik CDA XML formaadis, on nad siseselt ikkagi teatud
määral erineva struktuuriga sõltuvalt kasutatavast mallist (statsionaarsed
epikriisid, saatekirja vastused, …). Lisaks on ka nende mallide osas ajalooliselt
esinenud erinevaid versioone. Sarnasel viisil võidakse edasi arendada malle ka
tulevikus. Seega lahendus peab olema robustne, mis saaks hakkama ka tuleviku
mallidega.
● dokumendi mall ei pruugi vastata kirjeldatud malli versioonile
● dokumendi struktuur ei pruugi olla valiidne XML
● dokument ei pruugi valideeruda CDA XSD schema vastu
● mõned dokumendid võivad olla teistega võrreldes suured (teadaolevalt ca 50MB)
● dokumentidel võib olla kordusi (täielikud duplikaadid)
● teatud sisu (nt HTML tabelid esitatuna XMLina) tuleb jätta alles algsel kujul, nn
HTML sisu peaks jääma muutumatuna vabatekstina - ei võeta XMLi (või sellest
tuletatud JSONi) lahti
● XML sees esineb kommentaare, need ei ole olulised säilitada
● Enamike XML => JSON konverterite korral ei säili mixed-mode content; kogu info
säilitamiseks tuleb eraldi vaeva näha (nt hoida alles vastav XMLi alampuu või
konvertida JsonML formaati).
● XMLi nimeruumide ja nimeruumi prefiksite kasutus üle dokumentide on väga
erinev, otse konvertimisel jääb sisse ebavajalik “müra”; samas ei ole kindel, et
millises mahus on olnud algne nimeruumide kasutus hädavajalik (kui suur on
kadu, kui neid täielikult ignoreerida).
● Vertica kui siht-andmebaasi korral peab silmas pidama, et puudub üldine TEXT
tüüp (nagu on olemas nt PostgreSQLi või SQLite korral); samas on üldise,
struktuurist lähtuva andmelao tekitamise korral raske andmetüüpi kuidagi
spetsiifiliselt kitsendada (vaikimisi VARCHAR või LONG VARCHAR jäävad tihti
lühikeseks ja põhjustavad seeläbi kas dokumendi laadimise katkemise või osalise
(ära lõigatud) pikkusega sisu.
Dokumenteerimisnõuded
Projekti dokumentatsiooniks luuakse TEHIKu Confluence WiKi keskkonda pesa.
Dokumentatsioon peab kirjeldama lahenduse arhitektuuri, toimeprintsiipe, langetatud
tehnilisi otsuseid ja valikuid. Dokumentatsioon peab töötama ka juurutusjuhendina,
kuidas
Arendusprojekti käigus valmivate tehniliste komponentide kirjeldused peavad olema
täiendavalt dokumenteeritud koodirepositooriumis Markdown failides nii eesti kui inglise
keeles.
Kasutatavad vahendid ja andmestikud
Arenduspartner arendab tarkvara oma taristut kasutades, algoritmide ja lahenduste
testimiseks antakse arenduspartneri arendajale VPN ligipääs TEHIKu test võrku, kus
avatakse ligipääsud järgnevatele süsteemidele:
● tervise infosüsteemi testkeskkonna Oracle andmebaasile ning teistele vajalike
andmeallikatele
● andmelao platvormi Vertica klastri testkeskkonnale
● Kubernetes (Rancher) test klastrile
● GitLab
Arenduses kasutatavad andmestikud:
● tervise infosüsteemi testkeskkond testandmetega
● anonümiseeritud live andmete alamhulk, näidisena olemas 10 000 erinevat CDA
XML dokumenti
Vajadusel ja kokkuleppel TEHIKuga on võimalik täiendavate näidiste genereerimine.
Rakendusete töö valideerimine live keskkonna andmestikul toimub ainult TEHIKu poolt.
Pakkujal on õigus saada ligipääs Tartu Ülikooli teadusrühma poolt arendatud
deserialiseerija kontseptsiooni lähtekoodile.
Hea tulevane koostööpartner!
Tervise ja Heaolu Infosüsteemide Keskus (TEHIK) on läbi viimas Health-Sense projekti,
mille käigus kuulutab TEHIK lähiajal välja riigihanke (De)serialiseerimise toodangutarkvara
loomiseks. Rohkem informatsiooni projekti kohta on lisatud manusena.
Hanke eeldatav maksumus kuni 200 000 EUR
Planeeritud ajaraam 01.01.2024-31.03.2024
Hange sisaldab proovitööd.
Vajadusel anname ligipääsu:
• Proof of Concept (PoC) rakenduse koodile
• Näidisdokumentidele üle kõigi versioonide
• Näidisvalm sisendfailidest, et anda parem ettekujutus milliseid struktuure esineb.
Selleks, et projekti ettevalmistamine oleks edukas, kutsume Teid osalema turu-uuringul,
leidmaks parim lahendus. Selles palume vastata järgmistele küsimustele:
1. Kas tehniline kirjeldus sisaldab pakkumuse esitamise jaoks piisavalt infot ning
skoop on arusaadav? Kui ei ole, siis palume tagasisidet, millises osas vajaks dokument
täiendusi.
2. Kas eeldatav maksumus on projekti kvaliteetseks teostamiseks piisav?
3. Milliseid kompetentse oleks vaja töid teostaval meeskonnal teie hinnangul?
4. Muud soovitused hanke paremaks läbiviimiseks on samuti oodatud.
Turu-uuringu läbiviimise ajaks on 13.12.2023, kell 15:00. Selleks ajaks ootame Teie mõtteid
aadressile
[email protected]. Lisaküsimuste korral võta ühendust samuti aadressil
[email protected].
Lugupidamisega
TEHIK