Käesoleval lehel on loetletud e-tervise IT-lahenduste ärilised, koosvõime ja tehnilised põhimõtted, mida e-tervise arhitektuuripaneel (viide töökorraldusele) rakendab lahenduste hindamisel. Lahenduste puhul, mis arhitektuuripaneeli hindamisele ei tule, on loetletud põhimõtted soovituslikud. Esmajoones peavad nendest põhimõtetest lähtuma avaliku sektori asutuste poolt loodavate infosüsteemide arendajad, kuid enamik põhimõtetest on asjakohased kõikidele tervisesüsteemi tarkvara- ja tarkvaratoodete arendajatele.

Tegemist on loeteluga, mis ajapikku täieneb.

Ärilised põhimõtted

  • Kasutajakeskne disain (User Centered Design Thinking)
  • Olemas on protsessianalüüsi dokument (näide), mis on kooskõlastatud huvitatud osapooltega. Avalike infosüsteemidega seotud protsessianalüüsi tulemid tuleb publitseerida
  • ’Once-Only’ printsiibi järgimine. Andmeid, mis on andmekogudesse juba kogutud, ei ole vaja dubleerivalt koguda, vaid tuleb võimaldada andmete taaskasutamine. (AVTS § 431 lõige 3 Andmekogusse andmete kogumisel lähtutakse andmete ühekordse küsimise põhimõttest). Andmekogudega liidestumiseks tuleb prognoosida kasutusmaht ning sõlmida liidestuslepingud
  • Terviseandmete töötlemiseks on vajalik õiguslik alus. Olemas on õiguslikku alust kirjeldav dokument
  • Uued teenused peavad olema koheselt kaetud andmekvaliteedi kontrollidega. Olemas on andmekvaliteedi kontrolli süsteemi kirjeldus. Andmete kvaliteeti tuleb kontrollida võimalikult allika lähedal - võimalusel koheselt andmete sisestamisel
  • Enne lahenduse arendustöödega alustamist leppida kokku mittefunktsionaalsed (MFN) nõuded (näidiseks loetelu TEHIK MFN nõuetest) ning arendustööde käigus tagada nõuete järjepidev kontroll. Märksõnad E-ITS, riskianalüüs, käideldavus, süsteemi autonoomsus
  • Infosüsteemi/rakenduse loomisel peab  tuvastama, kas see peab vastama meditsiiniseadmete direktiivile, mille puhul võib olla arendusprotsessis jälgitavad põhimõtted erinevad, kui siin toodud
  • Juhul, kui kasutajate jaoks eksisteerib samu andmeid töötlevaid lahendusi, tuleb mõelda nendega integratsioonile või andmete migratsioonile uude lahendusse. Kasutajate jaoks tuleb tagada sujuv üleminek uuele lahendusele
  • Igal tarkvara komponendil peab olema selge eesmärk ja kava, kuidas neid saavutatakse
  • Ühine infoväli - kasutaja ei peaks tegema eraldi toiminguid, et teistele andmed kättesaadavaks osutuksid. Tervise infosüsteemi (TIS) puhul on see realiseeritav sündmuspõhise andmevahetuse abil, kus TIS-i saadetakse andmed kohe nende loomise hetkel
  • Dokumenteerida andmete teisese kasutuse protsessid, ligipääsupoliitika ning tehniline lahendus

Koosvõime põhimõtted

  • Avatud rahvusvahelised standardid ja koosvõime. Terviseandmete andmevahetusstandardina primaarselt HL7 FHIR standardi kasutamine. Rakendusel peavad olema dokumenteeritud kasutatavad FHIR ressursid ja/või profiilid. Soovitame kasutada ja toetada HL7 Estonia poolt loodud profiile
  • Primaarselt rahvusvahelistest terminoloogiate kodeerimissüsteemidest (nt SNOMED CT, LOINC, ICD, ATC) lähtumine
  • Riiklike andmekogudega seotud andmevahetuse korral tuleb kasutada X-tee  andmevahetuskihti. Uute teenuste korral soovitame kasutada REST-i
  • Komponentide vahelised liidesed tuleb dokumenteerida. Soovitame uue komponendi arendamisel kasutada “API kõigepealt” (API first) lähenemist, kus enne komponendi arendust dokumenteeritakse selle liides. Soovitame ka enne arendust testide kirjutamist (testdriven development)

Tehnilised põhimõtted

  • Monoliitlahenduste loomise asemel mikroteenuste põhimõtetest (https://microservices.io/) lähtumine 
    • iga teenus keskendub ühele äriprobleemile
    • kõik teenused on väheste omavaheliste sõltuvustega
    • iga teenus on võimalikult sõltumatu, paigaldus valutum
    • iga teenus on sõltumatult uuendatav ja süsteemis rakendatav
    • iga teenus on üksikuna kõrg-käideldav ja lihtsasti testitav
  • Kasutajaliidesed luuakse mikroesitluskihi komponentidena 
    • iga komponent keskendub ühele äriprobleemile
    • iga komponent on sõltumatu, iseseisev
    • Kasutajaliidesed vastavad WCAG nõuetele
    • Kasutada VEERA disainisüsteemi
  • Loodavad lahendused peavad olema pilvekõlbulikud 
    • Pilvekõlbulik lahendus on skaleeruv, vastupidav, jälgitav, automatiseeritud ja turvaline
  • Dokumenteeritud peab olema valitud tehnoloogiate hindamine
    • Soovitame valida töökindlad (eelistatult vabavaralised) tehnoloogiad, mille osas on ka Eestis tagatud suurem arendus- ja halduskompetents (vendor lock-in olukorra vältimiseks)
  • Teenusest peab saama andmeid täies mahus eksportida ning importida. Eksporti peab saama teha ka isikupõhiselt 
  • Koodi kvaliteedi kontrollimisel kasutada automaatseid vahendeid
  • Automatiseeritud testide loomine, mis käivituvad osana CI/CD töövoost
  • Töövoogude koordineerimisel protsessimootori (nt Camunda või Flowable) kasutamine, et tagada protsesside parem läbipaistvus. Eelduseks on, et protsessimootoril on olemas modelleerimisvahend, mis visualiseerib reaalselt käivitatava protsessi ja äripool saab aru ja kooskõlastab modelleerimisvahendis dokumenteeritud protsessid
  • Arendustööde planeerimisel arvestada võimalusega kasutada juba loodud korduvkasutatavaid komponente (nt riigi koodivaramust). Korduvkasutuse potentsiaaliga komponentide loomisel arvestada võimalusega jagada enda loodavat komponenti avalikus koodi repositooriumis, näiteks GitHub-is või riigi koodivaramus. Komponentide funktsionaalsus peab olema selgelt dokumenteeritud
  • Andmetalletuskiht peab olema dokumenteeritud sellisel määral, et andmeid on võimalik töödelda ka selle põhirakendusest erineva tarkvaraga näiteks migratsiooniks, rakenduskihi välja vahetamiseks, andmete sekundaarseks kasutuseks
  • Andmemudelite/andmebaasi struktuuride loomisel arvestada koheselt ka statistika/aruandluse jaoks vajalike andmete olemasoluga
  • Enne uue lahenduse toodangus kasutusele võtmist, tagada lahendusele toimiv ja vastava lahenduse vajadusi arvestav monitooring. Soovitame kasutada OpenTelemetry standardit
  • Lahendusel peab olema muudest logidest eraldatud audit logi, mis annab ülevaate lahenduses tehtud toimingutest (kes, millal, kelle andmetega teatud toimingu tegi). Riigi infosüsteemi kuuluvate lahenduste korral peab audit logi väljastama andmeid andmejälgija liidese kaudu eesti.ee portaalile
  • Süsteemi projekteerimisel tuleb kohe arvestada turvanõuetega
  • Kõik uued teenused tuleb enne toodangusse jõudmist turvatestida välise osapoole poolt ja leitud vead peavad enne toodangusse minekut olema parandatud
  • Kasutajate autentimisel turvaliste autentimisvahendite kasutamine, sh võimalusel ühendada TARAga (esineb võimalus ka oma TARA instants püsti panna)
  • Lahendus peab olema varustatud dokumentatsiooniga (sh arhitektuuridokument, integratsioonide kirjeldus, andmemudel, paigaldusjuhend) ja dokumentatsiooni tuleb kogu aeg ajakohasena hoida
  • Uute teenuste planeerimisel, mille tulemusena hakkavad laekuma terviseandmed tervise infosüsteemi, tuleb koheselt mõelda läbi (sh visandada), kuidas ja millisele loogikale vastavalt saavad olema terviseandmed väljakuvatud riiklikus terviseportaalis (patsiendi vaade) ja tervishoiutöötajate jaoks andmevaaturis (asendub tervisejuhtimise töölauaga)

 

Viimase muutmise aeg: veebruar 2024