sistēma
Elektroniskas VeselÄ«bas Kartes InformÄcijas sistÄma
Elektroniskas VeselÄ«bas Kartes InformÄcijas sistÄma
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Elektroniskas Veselības Kartes Informācijas<br />
<strong>sistēma</strong><br />
Tehniskās arhitektūras apraksts<br />
VEC.EVK.ARCH.01<br />
Versija 1.04<br />
2011
Visas šī dokumenta izmantošanas tiesības tiek noteiktas saskaņā ar Latvijas Republikas<br />
Autortiesību likumu un 22.02.2011 noslēgto līgumu Nr. VEC_2010/2/ERAF.<br />
Neatkarīgi no izmantojamiem līdzekļiem nevienu daļu no šī dokumenta nedrīkst reproducēt<br />
ar jebkādiem mehāniskiem, fotogrāfiskiem vai elektroniskiem līdzekļiem, pārraidīt,<br />
pārrakstīt, uzglabāt elektroniskā izguves sistēmā vai tulkot kādā citā valodā vai arī kopēt<br />
jebkādā citā veidā publiskai vai privātai izmantošanai bez iepriekš saņemtas Nacionālā<br />
veselības dienesta rakstiskas atļaujas.
Saturs<br />
1 IEVADS .............................................................................................................................. 8<br />
1.1 NOLŪKS ...................................................................................................................... 8<br />
1.2 IESAISTĪTĀS PUSES UN ATBILDĪBAS ........................................................................... 8<br />
1.3 DARBĪBAS SFĒRA ........................................................................................................ 8<br />
1.4 DEFINĪCIJAS, APZĪMĒJUMI UN SAĪSINĀJUMI ............................................................. 9<br />
1.6 SAISTĪBA AR CITIEM DOKUMENTIEM ...................................................................... 12<br />
1.7 DOKUMENTA PĀRSKATS .......................................................................................... 13<br />
2 IEINTERESĒTO PERSONU IEGUVUMI UN IETEKME ............................................................. 14<br />
2.1 IEINTERESĒTĀS PERSONAS ...................................................................................... 14<br />
2.2 IEINTERESĒTO PERSONU VAJADZĪBAS ..................................................................... 14<br />
3 SKATU PUNKTI ................................................................................................................. 17<br />
3.1 SISTĒMAS ARHITEKTŪRA ......................................................................................... 17<br />
3.2 LOĢISKĀ ARHITEKTŪRA ........................................................................................... 18<br />
3.3 FIZISKĀ ARHITEKTŪRA ............................................................................................. 19<br />
3.4 PĀRVALDĪBAS ARHITEKTŪRA ................................................................................... 19<br />
4 PROJEKTĒJUMA PAMATPRINCIPI ...................................................................................... 20<br />
4.1 PIEŅĒMUMI UN IEROBEŽOJUMI .............................................................................. 21<br />
5 SISTĒMAS ARHITEKTŪRA ................................................................................................. 22<br />
5.1 SISTĒMAS SADARBĪBA ............................................................................................. 22<br />
5.1.1 Lietotāju autentifikācija un autorizācija .......................................................... 23<br />
5.1.1.1 EVK lietotāju autentifikācija ........................................................................ 23<br />
5.1.1.1 EVK lietotāju autorizācija ............................................................................. 24<br />
5.2 LIETOTĀJU SASKARNES ............................................................................................ 26<br />
5.3 SISTĒMU SASKARNES ............................................................................................... 27<br />
6 LOĢISKĀ ARHITEKTŪRA ................................................................................................... 31<br />
6.1 SISTĒMAS KOMPONENTU GRUPAS ......................................................................... 31<br />
6.1.1 EVK tīmekļa pakalpes ....................................................................................... 31
6.1.2 EVK komponenti .............................................................................................. 32<br />
6.2 LOĢISKAIS DATU MODELIS ...................................................................................... 32<br />
6.2.1 Datu integritāte ............................................................................................... 34<br />
6.2.2 Elektroniskais paraksts .................................................................................... 34<br />
6.3 SISTĒMAS KOMPONENTU SADARBĪBA .................................................................... 35<br />
6.4 SISTĒMAS KOMPONENTI ......................................................................................... 37<br />
6.4.1 Autorizācijas modulis ....................................................................................... 37<br />
6.4.2 Metadatu pārvaldība ....................................................................................... 38<br />
6.4.2.1 Dokumenta veidņu modelēšana .................................................................. 38<br />
6.4.2.1 Validatori ..................................................................................................... 40<br />
6.4.2.2 Prezentācijas katalogs ................................................................................. 41<br />
6.4.3 Pamatdatu un pierakstu pārvaldība ................................................................ 41<br />
6.4.3.1 EVK dokumentu pievienošana ..................................................................... 41<br />
6.4.3.2 EVK dokumentu tālākā apstrāde fona režīmā ............................................. 44<br />
6.4.3.3 EVK dokumentu iegūšana ............................................................................ 46<br />
6.4.4 eDoc pārbaudes serviss ................................................................................... 47<br />
6.4.5 Fona uzdevumi ................................................................................................ 48<br />
6.4.5.1 Personas datu aktualizācija ......................................................................... 50<br />
6.4.5.2 Jaundzimušo datu aktualizācija ................................................................... 51<br />
6.4.5.3 Ģimenes ārstu datu aktualizācija................................................................. 51<br />
6.4.5.4 EVAK datu aktualizācija ............................................................................... 51<br />
6.4.6 Vakcināciju modulis ......................................................................................... 51<br />
6.4.7 Klasifikatoru uzturēšanas modulis ................................................................... 53<br />
6.4.8 Auditācija un <strong>sistēma</strong>s žurnāls ........................................................................ 54<br />
6.4.9 Administrēšanas modulis ................................................................................ 54<br />
6.4.10 IP apziņošanas serviss ...................................................................................... 55<br />
6.4.11 e-Pakalpojumi .................................................................................................. 55
6.4.12 Datu noliktavas integrācijas modulis (nākotnes prasība) ................................ 56<br />
6.4.13 epSOS saskarne (nākotnes prasība) ................................................................. 56<br />
7 FIZISKĀ ARHITEKTŪRA ..................................................................................................... 57<br />
7.1 EVK TĪMEKĻA PAKALPES .......................................................................................... 57<br />
7.2 FONA UZDEVUMI ..................................................................................................... 58<br />
7.3 VALIDATORI ............................................................................................................. 58<br />
7.4 DATU BĀZES ............................................................................................................. 58<br />
7.5 INFRASTRUKTŪRAS SERVERI.................................................................................... 59<br />
8 PĀRVALDĪBAS ARHITEKTŪRA ........................................................................................... 60<br />
8.1 PĀRRAUDZĪBA .......................................................................................................... 60<br />
8.2 ADMINISTRĒŠANAS MEHĀNISMI ............................................................................. 60<br />
8.3 REZERVES KOPĒŠANA UN ATJAUNOŠANA ............................................................... 60<br />
8.4 JAUNINĀJUMU INSTALĒŠANA ................................................................................. 60<br />
9 ARHITEKTŪRAS SKATU NEPRETRUNĪGUMS ....................................................................... 62
Attēlu saraksts<br />
1. attēls. IdentitySelector lappuses piemērs ........................................................................... 23<br />
2. attēls. EVK un tās sadarbība ar lietotājiem un ārējām sistēmām ........................................ 25<br />
3. attēls. EVK komponentu grupas .......................................................................................... 31<br />
4. attēls. EVK loģiskais datu modelis ....................................................................................... 33<br />
5. attēls. Veselības pamatdati ................................................................................................. 34<br />
6. attēls. EVK loģiskie komponenti un to sadarbība ................................................................ 36<br />
7. attēls. No stacionāra izrakstīta pacienta karte MDHT UML modelēšanas rīkā ................... 39<br />
8. attēls. EVK sekciju tipi MDHT UML modelēšanas rīkā ......................................................... 40<br />
9. attēls. Pacienta kartes testa dokumenta izveide ................................................................. 41<br />
10. attēls. EVK dokumentu pievienošana ................................................................................ 42<br />
11. attēls. EVK dokumentu asinhronā apstrāde ...................................................................... 44<br />
12. attēls. EVK dokumentu iegūšana ....................................................................................... 46<br />
13. attēls. eDoc pārbaudes servisa loģiskais plānojums.......................................................... 47<br />
14. attēls. Fona uzdevumi ....................................................................................................... 49<br />
15. attēls. EVK loģisko komponentu izvietojums uz serveriem ............................................... 57
Tabulu saraksts<br />
1.2-1. tabula. Lomas un atbildības ............................................................................................ 8<br />
1.4-1. tabula. Definīcijas un skaidrojumi ................................................................................... 9<br />
1.4-2. tabula. Apzīmējumi un saīsinājumi ................................................................................. 9<br />
2.2-1. tabula. Ieinteresēto personu vajadzības ....................................................................... 14<br />
3.1-1. tabula. Sistēmas konteksta diagrammas elementi ....................................................... 17<br />
3.2-1. tabula. Vadības plūsmas diagrammas elementi............................................................ 18<br />
5.2-1. tabula. Galvenās EVK lietotāju grupas .......................................................................... 26<br />
5.3-1. tabula. EVK saskarnes ar ārējām sistēmām ................................................................... 27
1 Ievads<br />
1.1 Nolūks<br />
Dokumenta mērķis ir aprakstīt galvenos Elektronisko veselības karšu (EVK) informācijas<br />
<strong>sistēma</strong>s izveides principus un risinājuma elementus, tādā veidā definējot risinājuma aprises<br />
un arī nodrošinot, ka viss risinājums tiek veidots pēc vienotiem principiem.<br />
Tehniskās arhitektūras dokuments būs uzskatāms par pabeigtu, kad Pasūtītāja un Izpildītāja<br />
puses piekritīs tā saturam, pieņems to un attiecīgi parakstīs to pēc abpusējas saskaņošanas.<br />
Dokuments izstrādāts balstoties uz līgumu VEC_2010/2/ERAF, kas noslēgts starp Veselības<br />
Ekonomikas Centru, turpmāk Pasūtītājs, un A/S Datorzinību Centrs, turpmāk Izstrādātājs.<br />
Dokuments izstrādāts, izmantojot „IEEE ISO/IEC 1471-2000 Systems and software<br />
engineering - recommended practice for architectural description” standartu.<br />
1.2 Iesaistītās puses un atbildības<br />
Dokumenta izstrādē, saskaņošanā un nodošanā iesaistītās lomas un to atbildības norādītas<br />
tabulā zemāk.<br />
1.2-1. tabula. Lomas un atbildības<br />
Loma Vārds Uzvārds Atbildība<br />
Projekta pārvaldnieks Andrejs Dubrovskis Tiek informēts,<br />
Konsultē, Apstiprina<br />
Projekta vadītājs Izstrādātāja pusē Māris Detlavs Atbildīgais<br />
Projekta vadītājs Pasūtītāja pusē Margreta Baltgalve Konsultē, Apstiprina<br />
Sistēmanalītiķis Gundega Lazdāne Konsultē<br />
Izstrādes vadītājs Edgars Salna Konsultē<br />
Valentīna Ziedone<br />
Ārija Bērziņa<br />
Arnis Puksts<br />
Dzintars Briķis<br />
Konsultē<br />
Konsultē<br />
Konsultē<br />
Konsultē<br />
Arhitekts Raimonds Rudmanis Izpildītājs<br />
Dokumenta izstrādes laikā iesaistīto pušu saraksts un atbildības var mainīties.<br />
1.3 Darbības sfēra<br />
Dokuments apraksta būtiskākās Elektroniskās veselības kartes informācijas <strong>sistēma</strong>s uzbūvi<br />
ietekmējošās prasības un galvenos tehniskos risinājumus, kurus jāievēro, lai nodrošinātu<br />
<strong>sistēma</strong>s atbilstību izvirzītajām prasībām.
Šis dokuments tiks izmantots kā pamats turpmākajiem projekta darbiem: EVK <strong>sistēma</strong>s<br />
projektēšanai, izstrādei un testēšanai.<br />
Dokuments ir saistošs:<br />
• no Pasūtītāja puses projektā iesaistītajām personām;<br />
• EVK <strong>sistēma</strong>s projektētājiem un izstrādātājiem;<br />
• EVK <strong>sistēma</strong>s testētājiem;<br />
• kā arī informatīvs materiāls citiem projektā iesaistītajiem dalībniekiem un projekta<br />
vadītājiem.<br />
1.4 Definīcijas, apzīmējumi un saīsinājumi<br />
1.4-1. tabula. Definīcijas un skaidrojumi<br />
Termins<br />
Darbplūsmas vadības<br />
programma<br />
Elektroniskais paraksts<br />
Medicīniska dokumenta<br />
sekcija<br />
Medicīnisks dokuments<br />
Pacienta karte<br />
Projekts<br />
Sistēma<br />
Tīmekļa pakalpes<br />
Skaidrojums<br />
Programma, kas, izmantojot vairākus resursus, vada noteikta procesa<br />
izpildi, kurš sastāv no savstarpēji saistītiem uzdevumiem.<br />
Drošs elektroniskais paraksts pēc EDL definīcijas.<br />
Medicīniskā dokumenta struktūras daļa, ar noteiktu struktūru un datu<br />
kopu, kas satur gan klasificētas vērtības, gan tekstuālu aprakstu.<br />
EVK kontekstā medicīniskais dokuments ir elektronisks medicīnisks<br />
ieraksts, kas pievienots pacienta kartei.<br />
EVK kontekstā pacienta karte ir elektroniska datu kopa, kas satur pacienta<br />
personas datus, veselības pamatdatus un medicīniskos dokumentus.<br />
Elektroniskās veselības kartes informācijas <strong>sistēma</strong>s izstrādes projekts<br />
saskaņā ar līgumu VEC_2010/2/ERAF, kas noslēgts starp Veselības<br />
Ekonomikas Centru un A/S Datorzinību Centrs.<br />
Elektroniskās veselības kartes informācijas <strong>sistēma</strong>, EVK IS.<br />
Vienots veids, kā sistēmām, kas strādā dažādās platformās, rakstītas<br />
dažādās valodās u.t.t., savstarpēji sazināties. Tīmekļa pakalpes nodrošina<br />
informācijas apmaiņas iespēju, nepārzinot otras puses <strong>sistēma</strong>s un<br />
programmatūru. Tiek izdalīti pakalpes lietotāji un pakalpes sniedzējs.<br />
1.4-2. tabula. Apzīmējumi un saīsinājumi<br />
Apzīmējums,<br />
saīsinājums<br />
ASN.1<br />
DB<br />
Apraksts<br />
No angļu valodas [Abstract Syntax Notation number One] – notācija, kas<br />
tiek lietota komunikāciju protokolu formālajiem aprakstiem<br />
Datu bāze
Apzīmējums,<br />
saīsinājums<br />
CDA<br />
DBVS<br />
EDL<br />
eDoc<br />
epSOS<br />
EVAK<br />
EVK<br />
HL7<br />
HTML<br />
IIS<br />
IP<br />
IR<br />
NLB<br />
OCSP<br />
PDF<br />
PMLP<br />
SOAP<br />
SQL<br />
TDE<br />
Apraksts<br />
No angļu valodas [Clinical Document Architecture] – klīnisko dokumentu<br />
arhitektūra<br />
Datu bāzu vadības <strong>sistēma</strong><br />
Elektronisko dokumentu likums tā spēkā esošajā redakcijā<br />
Parakstīto dokumentu failu formāts, kas satur dokumentu, elektronisko<br />
parakstu un laika zīmogu<br />
No angļu valodas [Smart Open Services for European Patients] - Eiropas<br />
mēroga e-Veselības sadarbības projekts<br />
Eiropas veselības apdrošināšanas karte<br />
Elektroniskā veselības karte<br />
No angļu valodas [Health Level 7] – klīnisko dokumentu elektroniskā veida<br />
standarts<br />
No angļu valodas [Hypertext Markup Language] – valoda, kas, izmantojot<br />
speciālus kodus, nosaka hiperteksta dokumenta atveidojumu displeja<br />
ekrānā gadījumā, ja tiek lietotas tīkla Internet globālā tīmekļa lappuses<br />
No angļu valodas [Internet Information Services] - interneta informācijas<br />
serviss<br />
E-veselības integrācijas platforma<br />
Iedzīvotāju reģistrs<br />
No angļu valodas [Network Load Balancing] – slodzes dalīšanas<br />
tehnoloģija<br />
No angļu valodas [On-Line Certificate Status Protocol] - protokols, kas ļauj<br />
veikt sertifikāta derīguma pārbaudi tiešsaistes režīmā<br />
No angļu valodas [Portable Document Format] – dokumenta formāts<br />
Pilsonības un migrācijas lietu pārvalde<br />
No angļu valodas [Simple Object Access Protocol] - uz XML valodu bāzēts<br />
Web servisu ziņojumu apmaiņas standarts. SOAP definē aploksnes<br />
formātu un virkni noteikumu tā satura aprakstam<br />
No angļu valodas [Structured Query Language] - firmas IBM izstrādāta<br />
valoda, ko lieto datu bāzes pārvaldības sistēmās dažāda tipa datoros<br />
No angļu valodas [Transparent Data Encryption] – pārredzamo datu<br />
šifrēšana
Apzīmējums,<br />
saīsinājums<br />
TSA<br />
Apraksts<br />
No angļu valodas [Time stamping authority] – iestāde, kas izsniedz laika<br />
zīmogus elektroniskiem parakstiem<br />
USPS Valsts akciju sabiedrība "Latvijas Valsts radio un televīzijas centrs" -<br />
uzticams sertifikācijas pakalpojumu sniedzējs<br />
VEC<br />
VNC<br />
VNC VIS<br />
ZIP<br />
Veselības ekonomikas centrs<br />
Veselības norēķinu centrs<br />
Veselības norēķinu centrs Vadības informācijas <strong>sistēma</strong><br />
Failu formāts, kas tiek lietots datu saspiešanai<br />
X.509 Kriptogrāfijas standarts<br />
XAdES<br />
XML<br />
XML Advanced Electronic Signatures (ETSI TS 101 903, version number<br />
1.3.2, 2006-03), elektroniskā paraksta metadatu formāta standarts<br />
No angļu valodas [eXtensible Markup Language] - specifikācija, kas<br />
nodrošina izstrādātājiem iespēju radīt pašiem savas iezīmēšanas valodas,<br />
definējot personiskās birkas (kodus).<br />
Šī valoda ir izstrādāta strukturētu dokumentu apmaiņai starp dažādām<br />
platformām.<br />
XSLT<br />
No angļu valodas [XSL Transformations]<br />
XSL valodas transformācija stila lapas formā, ar labi noformētu XML[XML<br />
1.0] sintaksi, kas atbilst XML nosaukumvietas rekomendācijām<br />
[Namespaces in XML Recomendations].<br />
XSL<br />
WSUS<br />
WS-*<br />
No angļu valodas [Extensible Stylesheet Language] – paplašināmā stila<br />
lapu valoda<br />
No angļu valodas [Windows Server Update Services]<br />
Web pakalpju drošības standartu kopa
1.6 Saistība ar citiem dokumentiem<br />
[1] Programmatūras prasību specifikācija. Elektroniskās veselības kartes informācijas<br />
<strong>sistēma</strong>. Versija 1.0. VEC.EVK.PPS.CR1.1.0. Rīga, 2011<br />
[2] Infrastruktūras prasību dokuments. Elektroniskās veselības kartes informācijas<br />
<strong>sistēma</strong>. Versija 1.01. VEC.EVK.INFRA.01. Rīga, 2011<br />
[3] Programmatūras prasību specifikācija. Elektroniskas veselības kartes vakcināciju<br />
reģistra informācijas <strong>sistēma</strong>. Versija 1.0. VEC.EVK.PPS.VR1.01. Rīga, 2011<br />
[4] Programmatūras prasību specifikācija. Elektroniskas Veselības Kartes Informācijas<br />
<strong>sistēma</strong>. Klasifikatoru modulis. Versija 1.0. VEC.EVK.PPS.KM1.01. Rīga, 2011<br />
[5] Projekta Integrācijas platformas informācijas <strong>sistēma</strong>s izstrāde arhitektūras risinājuma<br />
vīzijas dokuments. Versija 1.0. VEC-132-E_VES_IP-RAVD. Rīga, 2011<br />
[6] Tehniskās arhitektūras apraksts. Veselības aprūpes elektronisko<br />
nosūtījumu/elektronisko pierakstu informāciju <strong>sistēma</strong>s un e-Veselības lietotāju WEB<br />
platformas izstrāde, ieviešana un garantijas uzturēšana. Versija 0.9.<br />
VEC.EBOOK.TAA.0.9. Rīga, 2011<br />
[7] Tehniskā specifikācija. Elektroniskās veselības kartes informācijas <strong>sistēma</strong>s<br />
izstrādāšana. SIA „AA projekts”. Rīga, 2010<br />
[8] Sistēmas arhitektūra un darbības koncepcijas apraksts. Elektroniskās veselības kartes<br />
informācijas <strong>sistēma</strong>. Iepirkuma dokumentācija. Versija 1.3. EVK.PRO.1.TS.2.SDK.1.1.<br />
Rīga, 2010<br />
[9] Robertson, James, and Suzanne Robertson, Complete Systems Analysis, ISBN-10:<br />
0932633501, Dorset House; 2nd edition, 1998<br />
[10] LVRTC eDoc 1.01 dokumenta formāts. Versija 1.0. Rīga, 2010, http://info.e-me.lv/wpcontent/uploads/2009/10/LVRTC_eDoc_Specification_v1.0.pdf
1.7 Dokumenta pārskats<br />
Dokumentā iekļautas šādas nodaļas:<br />
1. nodaļā sniegts ieskats dokumenta saturā un struktūrā.<br />
2. nodaļā aprakstītas projekta veiksmē ieinteresētās personas (stakeholders) un to grupas:<br />
<strong>sistēma</strong>s pasūtītāji, lietotāji, izstrādātāji un uzturētāji, to ieguvumi un ietekme, kā arī to<br />
galvenās vajadzības, kas ir ņemtas vērā, izstrādājot <strong>sistēma</strong>s tehnisko arhitektūru.<br />
3. nodaļā aprakstīti tehniskās arhitektūras aprakstā izmantotie skatu punkti (viewpoints), to<br />
mērķauditorija, dokumentēšanas veids, kā arī sniegts konkrēto skatu punktu izvēles<br />
pamatojums.<br />
4. nodaļā aprakstīti galvenie projektēšanas lēmumi, kas ietekmē visu risinājuma<br />
komponentu izveidi un darbināšanu. Katram aprakstītajam principam (projektējuma<br />
lēmumam) aprakstīti arī alternatīvie risinājumi un sniegts pamatojums, kāpēc izvēlēts tieši<br />
konkrētais projektējuma lēmums nevis kāds no alternatīvajiem.<br />
5. nodaļā aprakstīta <strong>sistēma</strong>s funkcionalitāte un sadarbība ar <strong>sistēma</strong>s lietotājiem un ārējām<br />
sistēmām. Nodaļas mērķis ir noteikt <strong>sistēma</strong>s apjomu (robežas) un precizēt sadarbības<br />
protokolus un pieejas, kuras tiks atbalstītas.<br />
6. nodaļā aprakstīti <strong>sistēma</strong>s iekšējie komponenti, identificēts, kādi no šiem komponentiem<br />
nodrošina ārējo saskarņu funkcionalitāti, noteikti arī <strong>sistēma</strong>s iekšējo komponentu un<br />
moduļu sadarbības scenāriji, nepieciešamās saskarnes, to specifika (autentifikācija,<br />
protokoli).<br />
7. nodaļā sniegts īss apskats par loģisko komponentu izvietošanas variantiem, kurus<br />
nodrošina izmantotie arhitektūras risinājumi.<br />
8. nodaļā sniegta informācija par arhitektūras elementiem, kas izveidoti <strong>sistēma</strong>s<br />
uzturēšanas atvieglošanai.<br />
9. nodaļā aprakstīta arhitektūras skatu nepretrunīguma analīze, kā arī identificētas visas<br />
zināmās arhitektūras skatu neatbilstības.
2 Ieinteresēto personu ieguvumi un ietekme<br />
Šajā nodaļā ir aprakstītas projekta veiksmē ieinteresētās personas (stakeholders) un to<br />
grupas: <strong>sistēma</strong>s pasūtītāji, lietotāji, izstrādātāji un uzturētāji, to ieguvumi un ietekme, kā arī<br />
to galvenās vajadzības, kas ir ņemtas vērā, izstrādājot <strong>sistēma</strong>s tehnisko arhitektūru.<br />
2.1 Ieinteresētās personas<br />
Projekta veiksmē ir ieinteresētas sekojošas galvenās personu grupas:<br />
Sistēmas lietotāji<br />
o<br />
o<br />
o<br />
o<br />
o<br />
Pasūtītāji<br />
Izstrādātāji<br />
Uzturētāji<br />
Pacienti<br />
Ārstniecības personas<br />
Veselības aprūpi kontrolējošās valsts institūcijas<br />
Izglītības, zinātniskās pētniecības un citas organizācijas<br />
Sistēmas administratori<br />
Ieinteresētās personas, kas būs <strong>sistēma</strong>s lietotāji, un to ieguvumi ir aprakstīti dokumenta<br />
„Sistēmas arhitektūra un darbības koncepcijas apraksts” sadaļā „2.4.1 Sistēmas lietotāji”,<br />
skat. [8].<br />
Primārie ieguvēji EVK <strong>sistēma</strong>s izveidošanas gadījumā būs pacients un ārstniecības personas,<br />
kas nepastarpināti sniedz ārstniecības pakalpojumus šim pacientam un kuru rīcībā būs pilna<br />
informācija par pacienta veselības stāvokli, lai pieņemtu pamatotākus lēmumus par<br />
turpmāko ārstēšanas procesu vai profilakses pasākumiem.<br />
2.2 Ieinteresēto personu vajadzības<br />
Ieinteresētās personas ir personas, personu grupas vai organizācijas, kas ir ieinteresētas<br />
projekta veiksmē un kurām ir konkrētas vajadzības un intereses <strong>sistēma</strong>s arhitektūras<br />
kontekstā. Ieinteresēto personu galvenās vajadzības ir uzskaitītas tabulā zemāk.<br />
2.2-1. tabula. Ieinteresēto personu vajadzības<br />
Personu grupas<br />
Pacienti<br />
Vajadzības<br />
Sekot savas veselības aprūpes procesam – uzstādītajai<br />
diagnozei, izmeklējumu rezultātiem un ārstēšanas plānam<br />
Piekļūt saviem medicīniskajiem ierakstiem un kontrolēt<br />
ārstniecības personu darbu<br />
Ērtāk saņemt precīzas instrukcijas par viņu ārstēšanas plāniem<br />
(piemēram, zāļu lietošanu) vai preventīvajiem pasākumiem
Personu grupas<br />
Vajadzības<br />
(piemēram, vakcināciju)<br />
Ārstniecības personas<br />
Efektīvāk sniegt veselības aprūpes pakalpojumus<br />
Saņemt datus par pacientiem, kas ārstējas vai ārstēsies pie<br />
viņiem no citām ārstniecības personām<br />
Veselības aprūpi<br />
kontrolējošās valsts<br />
institūcijas<br />
Efektīvi pārvaldīt veselības aprūpes nozari<br />
Preventīvo veselības aprūpes plānu sastādīšana un izpildes<br />
kontrole<br />
Iegūt juridiskos pierādījumus aprūpes pakalpojumu gadījumu<br />
izmeklēšanas gaitā<br />
Izglītības, zinātniskās<br />
pētniecības un citas<br />
organizācijas<br />
Saņemt EVK datus, piemēram, medikamentu un ārstēšanas<br />
paņēmienu efektivitātes novērtēšanai, kā arī citiem mērķiem<br />
atkarībā no iestādes specifikas un mērķiem<br />
Iegūt statistiskos datus par iedzīvotāju veselību<br />
Administratori<br />
Sistēmas pārraudzība un pārvaldība<br />
Sistēmas pieejamība, elastīgums un mērogojamība<br />
Sistēmas darbības nepārtrauktība un darbības atjaunošanas<br />
spējas<br />
Pasūtītāji<br />
Atbilstība veselības nozares stratēģiskajiem mērķiem<br />
Veikto ieguldījumu atmaksāšanās<br />
Sistēmas ieviešana laikā un plānotajā budžetā<br />
Efektīva resursu izmantošana ieviešanas un darbināšanas laikā<br />
Sistēmas testējamība<br />
Izstrādātāji<br />
Izpratne par <strong>sistēma</strong>s kopējo uzbūvi jeb arhitektūru<br />
Sarežģītāko <strong>sistēma</strong>s elementu detalizētāks uzbūves apraksts<br />
Izmantotā platforma, standarti, programmēšanas valodas,<br />
analīzes, izstrādes un testēšanas rīki<br />
Sistēmas uzturamība<br />
Sistēmas pielāgojamība<br />
Arhitektūras zināšanu saglabāšana<br />
Uzturētāji<br />
Sistēmas dokumentācija
Personu grupas<br />
Vajadzības<br />
Sistēmas pārraudzība un pārvaldība<br />
Sistēmas traucējummeklēšana un atkļūdošana<br />
Produkcijas vides izmaiņu pārvaldība<br />
Arhitektūras zināšanu saglabāšana
3 Skatu punkti<br />
Šajā nodaļā ir aprakstīti tehniskās arhitektūras aprakstā izmantotie skatu punkti (viewpoints),<br />
to mērķauditorija, dokumentēšanas veids, kā arī sniegts konkrēto skatu punktu izvēles<br />
pamatojums.<br />
3.1 Sistēmas arhitektūra<br />
Sistēmas arhitektūras skatu punkts apraksta <strong>sistēma</strong>s funkcionalitāti un tās sadarbību ar<br />
<strong>sistēma</strong>s lietotājiem un ārējām sistēmām. Tās mērķis ir noteikt <strong>sistēma</strong>s apjomu (robežas) un<br />
precizēt sadarbības protokolus un pieejas, kuras tiks atbalstītas.<br />
Sistēmas arhitektūras dokumentēšanai tiek pielietota <strong>sistēma</strong>s konteksta diagramma<br />
(System Context Diagram), kas apraksta augstākā līmeņa <strong>sistēma</strong>s arhitektūru. Sistēmas<br />
konteksta diagrammā izstrādājamā <strong>sistēma</strong> ar nolūku tiek attēlota kā „melnā kaste”,<br />
nenorādot <strong>sistēma</strong>s iekšējo uzbūvi un tās komponentus. Šī diagramma palīdz labāk izprast<br />
svarīgākos <strong>sistēma</strong>s ārējos interfeisa punktus (lietotājus, <strong>sistēma</strong>s, iekārtas u.c.), ar ko<br />
<strong>sistēma</strong>i būs jāsadarbojas.<br />
Sistēmas konteksta diagramma parasti attēlo izstrādājamo sistēmu centrā, neattēlojot tās<br />
iekšējās uzbūves detaļas, kurai pa perimetru tiek uzrādīti lietotāji, <strong>sistēma</strong>s un iekārtas, ar ko<br />
šai <strong>sistēma</strong>i būs jāsadarbojas. Diagrammas mērķis ir fokusēties uz <strong>sistēma</strong>s ārējiem faktoriem<br />
un notikumiem, kas ir jāņem vērā, izstrādājot <strong>sistēma</strong>s arhitektūru. Tā palīdz izprast <strong>sistēma</strong>s<br />
vietu kopējā e-Veselības platformas kontekstā.<br />
Sistēmas konteksta diagramma tiek veidota kā augsta līmeņa datu plūsmas diagramma (Data<br />
Flow Diagram), kas ir izstrādāta atbilstoši strukturētās analīzes principiem, skat. [9].<br />
Sistēmas konteksta diagramma sastāv no sekojošiem grafiskajiem elementiem:<br />
3.1-1. tabula. Sistēmas konteksta diagrammas elementi<br />
Grafiskais elements<br />
Apraksts<br />
Sistēma<br />
Ārējās <strong>sistēma</strong>s vai moduļi<br />
Lietotāji<br />
Datu plūsmas
Sistēmas konteksta diagramma tiek izstrādāta pašā projekta sākumā, lai projekta<br />
dalībniekiem rastos vienāds priekšstats par izstrādājamās <strong>sistēma</strong>s apjomu un robežām. Tā ir<br />
paredzēta pilnīgi visām projektā iesaistītajām pusēm.<br />
3.2 Loģiskā arhitektūra<br />
Loģiskās arhitektūras skatu punkts apraksta <strong>sistēma</strong>s iekšējos komponentus, identificē, kādi<br />
no šiem komponentiem nodrošina ārējo saskarņu funkcionalitāti, kā arī nosaka <strong>sistēma</strong>s<br />
iekšējo komponentu un moduļu sadarbības scenārijus, nepieciešamās saskarnes un to<br />
specifiku, piemēram, izmantotos autentifikācijas mehānismus vai protokolus. Loģiskā<br />
arhitektūra apraksta arī loģisko komponentu funkcionalitāti un to darbināšanai izmantotos<br />
produktus un tehnoloģijas. Tās mērķis ir sadalīt izstrādājamo sistēmu sīkākās vienībās –<br />
komponentos un moduļos, lai sadalītu izstrādes darbus un varētu veikt to plānošanu. Katru<br />
komponentu vai moduli var izstrādāt viens atsevišķs cilvēks vai izstrādātāju grupa.<br />
Loģiskās arhitektūras dokumentēšanai tiek pielietotas vadības plūsmas diagrammas (Control<br />
Flow Diagram), kurās esošās bultas apzīmē moduļu atkarības jeb izsaukumu virzienus, un<br />
plūsmkartes (flowchart). Ar vadības plūsmas diagrammas palīdzību tiek attēlota <strong>sistēma</strong>s<br />
loģisko komponentu karte, kurā ilustrēta komponentu savstarpējā sadarbība un sadarbība ar<br />
ārējām sistēmām. Atsevišķu komponentu uzbūve un to algoritmi tiek attēloti, izmantojot<br />
plūsmkartes diagrammas.<br />
Vadības plūsmas diagrammas sastāv no sekojošiem grafiskajiem elementiem:<br />
3.2-1. tabula. Vadības plūsmas diagrammas elementi<br />
Grafiskais elements<br />
Apraksts<br />
Sistēmas komponenti un moduļi<br />
Sistēmas datu glabātuves<br />
Datu plūsmas<br />
Paskaidrojumi<br />
Izstrādājot loģisko arhitektūru, galvenokārt tiek ņemtas vērā funkcionālās prasības. Tā palīdz<br />
saprast <strong>sistēma</strong>s kopējo uzbūvi jeb arhitektūru, kā arī izmantoto platformu, tehnoloģijas un<br />
standartus. Loģiskā arhitektūra kalpo kā pamats izstrādes darbu plānošanai, izmaksu<br />
vērtēšanai un <strong>sistēma</strong>s prasību sadalīšanai pa komponentiem. Loģiskā arhitektūra satur arī<br />
sarežģītāko <strong>sistēma</strong>s elementu detalizētāku uzbūves aprakstu.
Tā ir paredzēta pilnīgi visām projektā iesaistītajām pusēm, tomēr loģiskās arhitektūras<br />
galvenās mērķauditorijas ir <strong>sistēma</strong>s izstrādātāji un uzturētāji.<br />
3.3 Fiziskā arhitektūra<br />
Fiziskās arhitektūras skatu punkts apraksta loģisko komponentu izvietošanas variantus, kurus<br />
nodrošina izmantotie arhitektūras risinājumi.<br />
Detalizēts infrastruktūras apraksts, nepieciešamie infrastruktūras elementi, datu apjoma,<br />
transakciju skaita un sagaidāmās ātrdarbības novērtējumi, kā arī rekomendētie risinājumi<br />
augstas pieejamības nodrošināšanai ir aprakstīti Infrastruktūras prasību dokumentā, skat.<br />
[2].<br />
Fiziskās arhitektūras galvenās mērķauditorijas ir <strong>sistēma</strong>s pasūtītāji un uzturētāji.<br />
3.4 Pārvaldības arhitektūra<br />
Pārvaldības arhitektūras skatu punkts apraksta arhitektūras elementus, kas ir izveidoti<br />
<strong>sistēma</strong>s uzturēšanas atvieglošanai. Tā mērķis ir definēt, kā <strong>sistēma</strong> tiks kontrolēta,<br />
pārvaldīta un pārraudzīta tās darbināšanas laikā. Pārvaldības arhitektūra apraksta <strong>sistēma</strong>s<br />
administrēšanas mehānismus, kā arī <strong>sistēma</strong>s pārraudzības, rezerves kopēšanas un<br />
jauninājumu instalēšanas stratēģijas.<br />
Tā ir paredzēta pilnīgi visām projektā iesaistītajām pusēm, tomēr pārvaldības arhitektūras<br />
galvenās mērķauditorijas ir <strong>sistēma</strong>s administratori un uzturētāji.
4 Projektējuma pamatprincipi<br />
Šī nodaļa satur galvenos projektēšanas lēmumus, kas ietekmēs visu risinājuma komponentu<br />
izveidi un darbināšanu.<br />
Katrs no projektējuma pamatprincipiem ir aprakstīts savā numurētā paragrāfā, nodrošinot,<br />
ka uz katru no tiem var veikt atsauces šī dokumenta un citu projektējuma dokumentu<br />
ietvaros. Katram aprakstītajam principam (projektējuma lēmumam) aprakstīti arī alternatīvie<br />
risinājumi un sniegts pamatojums, kāpēc izvēlēts tieši konkrētais projektējuma lēmums nevis<br />
kāds no alternatīvajiem.<br />
1) Lai nodrošinātu augstu risinājuma pieejamību un visu pieejamo serveru resursu<br />
izmantošanu, tīmekļa pakalpes tiek darbinātas „active-active” režīmā, kas nozīmē, ka<br />
serveru normālas darbības gadījumā tīmekļa pakalpju izsaukumi tiks sadalīti starp<br />
serveriem. Sesiju un pieprasījumu sadalīšanu starp serveriem veic slodzes dalītāji.<br />
2) EVK <strong>sistēma</strong>s iekšējie moduļi savā starpā sadarbojas „uzticamās apakš<strong>sistēma</strong>s” (no<br />
angļu valodas – trusted subsystem) režīmā – netiek veikta izsaucošā komponenta<br />
autentificēšana un datu plūsmas šifrēšana. Integrācijas platformā eksponēto EVK tīmekļa<br />
pakalpju izsaukumi pilnīgi vienmēr tiek autentificēti un to datu plūsma šifrēta. Jebkuri<br />
turpmākie izsaukumi netiek autentificēti, jo pārējās komponentes uzticas tīmekļa<br />
pakalpēm un atrodas ar tiem vienā drošības zonā.<br />
Šāda pieeja samazina <strong>sistēma</strong>s konfigurēšanas darbu un līdz ar to arī uzturēšanas<br />
apjomu. Ar šo pieeju saistītie drošības riski ir minimāli, jo iekšējā datu centra vide ir<br />
fiziski norobežota un pieejama tikai uzticamiem <strong>sistēma</strong>s administratoriem.<br />
3) Ārējām sistēmām, kuras nevar garantēt pieprasījumu apstrādi mazāk kā 3 sekundēs,<br />
servisu izsaukumi galvenokārt tiek veikti asinhroni.<br />
4) Lai EVK veidotu kā modulāru sistēmu, tās arhitektūrā tiek izmantots tā saucamais<br />
adapteru princips. Tas nodrošina vienotas saskarnes katram adapteru tipam, piemēram,<br />
EVK dokumentu validatoriem, EVK dokumentu pārveidotājiem datorizētās prezentācijas<br />
formātos (HTML, PDF, u.c.), sekciju apstrādes uzdevumiem un fona uzdevumiem. Tā kā<br />
viena tipa adapteriem ir identiskas saskarnes un <strong>sistēma</strong>s konfigurācijā tiek norādīts<br />
saraksts ar konkrētā tipa adapteriem, jauns adapteris var tikt pievienots, izveidojot<br />
adaptera moduli ar atbilstošo saskarni un pievienojot to <strong>sistēma</strong>s konfigurācijā. Tas<br />
nodrošina <strong>sistēma</strong>s papildināšanu ar jauniem dokumentu un to sekciju tipiem, kā arī<br />
jauniem datorizētās prezentācijas formātiem.<br />
5) Lietotāju un sistēmu darbību autorizēšanai tiek izmantota informācija par lietotāju<br />
piederību lomām. IP tiks izveidotas visas EVK nepieciešamās ārstniecības personu lomas<br />
atbilstoši lietotāju darba vajadzībām, kā arī notiks ārstniecības personu autorizācija.<br />
Pacientu autorizācija notiks EVK sistēmā. Tiesību kontrole ir balstīta uz lietotāju<br />
piederību lomām.<br />
6) Regulāri izpildāmie darbi tiek veikti kā atsevišķi veidots process (Windows serviss) fona<br />
darbu veikšanai. Alternatīvais risinājums ir tos veikt kā darba plūsmas, piemēram,<br />
izmantojot Windows Workflow Foundation darbplūsmas vadības programmu (workflow
engine). Darba plūsmas ir vairāk piemērotas biznesa procesu apstrādei, kur katra biznesa<br />
procesa instance rada jaunu darba plūsmu instanci. Darba plūsmas ir grūtāk uzturēt, jo<br />
darba plūsmas definīcijas izmaiņu gadījumā ir jāļauj pabeigties aktīvajām darba plūsmas<br />
instancēm. Gadījumos, kur ir nepieciešama salīdzinoši vienkārša periodiska pakešveida<br />
uzdevumu veikšana fona režīmā, atsevišķi veidots Windows serviss ir vienkāršāk<br />
izveidojams un uzturams.<br />
7) Risinājumā ir izmantota serveru virtualizēšana, lai nodrošinātu vairāku WEB un datu<br />
bāzes serveru darbināšanu un lai izvietotu testa, apmācību un izstrādes vides;<br />
8) Kļūdu un atteices gadījumu ziņojumi tiek ievietoti IP <strong>sistēma</strong>s žurnāla datu bāzēs,<br />
izmantojot IP bibliotēku. Sistēmas administratori tos varēs aplūkot, izmantojot IP<br />
administratīvos rīkus. Ziņojumus, kas ievietoti IP <strong>sistēma</strong>s žurnāla datu bāzēs, varēs<br />
automātiski apstrādāt VEC monitoringa risinājums;<br />
9) Lai pārliecinātos, ka EVK komponenti laika gaitā nav tikuši mainīti un līdz ar to tos var<br />
uzskatīt par autentiskiem un uzticamiem, visi EVK komponenti tiks elektroniski parakstīti.<br />
4.1 Pieņēmumi un ierobežojumi<br />
Šajā nodaļā aprakstīti pieņēmumi un ierobežojumi, uz kuriem balstās galvenie <strong>sistēma</strong>s<br />
projektēšanas lēmumi un kuri jāņem vērā, izstrādājot fizisko <strong>sistēma</strong>s projektējumu un<br />
plānojot risinājuma uzturēšanu:<br />
Tiks izveidotas un ieviestas centralizētās e-Veselības <strong>sistēma</strong>s – Integrācijas<br />
platforma, e-Recepte, e-Pieraksti, e-Nosūtījumi un e-Veselības portāls;<br />
Tiek pieņemts, ka EVK <strong>sistēma</strong>s izstrādes laikā Pasūtītājs būs nodrošinājis sadarbības<br />
iespēju ar ārējo sistēmu uzturētājiem, ar kuriem paredzēti starpsistēmu interfeisi, un<br />
no kuru sistēmām paredzēta sākotnējā datu ielāde;<br />
Tādas koplietošanas funkcijas kā lietotāju tiesību pārvaldība, autentifikācija,<br />
autorizācija, audits un <strong>sistēma</strong>s žurnāls nodrošinās Integrācijas platformas modulis;<br />
EVK projekta ietvaros realizējamie precīzi dokumentu tipi un tiem nepieciešamie<br />
sekciju tipi tiks definēti projektējuma un projekta izstrādes laikā.
5 Sistēmas arhitektūra<br />
Šajā nodaļā ir aprakstīta <strong>sistēma</strong>s funkcionalitāte un sadarbība ar <strong>sistēma</strong>s lietotājiem un<br />
ārējām sistēmām. Nodaļas mērķis ir noteikt <strong>sistēma</strong>s apjomu (robežas), definēt <strong>sistēma</strong>s<br />
vietu vispārējās e-Veselības vides kontekstā un precizēt sadarbības protokolus un pieejas,<br />
kuras tiks atbalstītas.<br />
Pašas <strong>sistēma</strong>s komponenti, kas nodrošina šo sadarbību, ir aprakstīti nodaļā Loģiskā<br />
arhitektūra (skat. 6. nodaļu).<br />
5.1 Sistēmas sadarbība<br />
Sistēma un tās sadarbība ar svarīgākajām veselības nozares sistēmām un galvenajām klientu<br />
grupām ir shematiski parādīta 2. attēlā, lai sniegtu priekšstatu par <strong>sistēma</strong>s darbības vidi un<br />
nepieciešamo integrāciju. Ar raustītu elementa robežu ir attēlotas nākotnē plānotās <strong>sistēma</strong>s<br />
vai moduļi.<br />
Attēlā ir parādītas tikai loģiskās saites starp sistēmām. Sistēmu sadarbība e-Veselības vidē<br />
notiks ar e-Veselības Integrācijas Platformas (IP) starpniecību. Pamata informācijas apmaiņas<br />
protokols būs SOAP (Simple Object Access Protocol), ar kura palīdzību ārējās <strong>sistēma</strong>s Portāls<br />
un e-Pakalpojumi piekļūs publicētajām EVK tīmekļu pakalpēm. Tāpat arī EVK izsauks ārējās<br />
<strong>sistēma</strong>s ar IP starpniecību.<br />
Iedalījums funkcionālajos blokos šajā attēlā veikts atbilstoši <strong>sistēma</strong>s vai <strong>sistēma</strong>s moduļu<br />
tehniskai un funkcionālajai specifikai, izvietošanas pieejai, kā arī sadarbībai ar citām veselības<br />
nozares sistēmām.<br />
Lietotāji izmantos EVK <strong>sistēma</strong>s funkcionalitāti, strādājot ar e-Veselības portālu,<br />
www.latvija.lv e-Pakalpojumiem vai ārstniecības iestādes (ģimenes ārsta prakses) sistēmu,<br />
kura integrēta ar EVK tīmekļa pakalpēm. EVK lietotāju saskarnes komponenti tiks izvietoti<br />
e-Veselības portālā.<br />
Gadījumā, ja būs nepieciešama ziņojumu apmaiņa ar sistēmām, kuru pieejamība netiek<br />
garantēta, ziņojumu uzkrāšanu un piegādi, kad pieslēgums šādām sistēmām būs atjaunots,<br />
nodrošinās IP.<br />
IP <strong>sistēma</strong> nodrošinās pamatfunkcijas drošai sistēmu un lietotāju sadarbībai – ziņojumu<br />
nosūtīšana, autentificēšana, autorizēšana un protokolu transformēšana, ja notiek sadarbība<br />
ar sistēmām, kas neatbalsta SOAP protokolu.
5.1.1 Lietotāju autentifikācija un autorizācija<br />
5.1.1.1 EVK lietotāju autentifikācija<br />
EVK lietotāju autentifikācijai tiks izmantots IP identifikācijas un autentifikācijas serviss, kas<br />
drošā veidā būs integrēts ar trešo pušu identifikācijas un autentifikācijas servisiem:<br />
www.latvija.lv IdentitySelector risinājumu;<br />
PFAS AUTH;<br />
ārstniecības iestāžu IS lietotāju datu bāzēm.<br />
www.latvija.lv IdentitySelector risinājums nodrošina vienotu autentifikācijas un<br />
identifikācijas piegādātāju izvēli ārējiem portāliem un informācijas sistēmām, kas savukārt<br />
būs paplašināms un pārvaldāms centralizēti. Šobrīd IdentitySelector risinājums kā<br />
autentifikācijas avotus piedāvā izmantot:<br />
elektroniskā paraksta viedkarti;<br />
Lattelecom Mobilo ID;<br />
www.latvija.lv portāla lietotājvārdu un paroli;<br />
Latvijas lielāko banku internetbankas portālus (piemēram, Swedbank, SEB banka,<br />
Citadele banka, Norvik banka, Latvijas Krājbanka).<br />
1. attēls. IdentitySelector lappuses piemērs<br />
PFAS AUTH risinājums tiek izmanots VRAA VISS lietotāju autentifikācijai.<br />
Ārstniecības iestāžu IS lietotāju datu bāzes tiks integrētas ar IP identifikācijas un<br />
autentifikācijas servisu, izmantojot iestādes lietotāju LDAP direktoriju, IP autorizācijas<br />
moduļa datu bāzi vai arī iestādes lietotāju datu bāzi. IP identifikācijas un autentifikācijas
servisi ir aprakstīti IP risinājuma arhitektūras vīzijas dokumenta sadaļā „2.3.4. Autentifikācijas<br />
un autorizācijas servisi”, skat. [5].<br />
EVK <strong>sistēma</strong> lietotāju autentifikāciju neveic, bet gan pilnībā uzticas IP identifikācijas un<br />
autentifikācijas servisam, no kura tiks saņemts tā saucamais autentifikācijas apgalvojums -<br />
speciāls drošības talons, kas satur tikai lietotāja autentifikācijas informāciju. Kā universāls<br />
personas identifikators tiks izmantots personas kods.<br />
5.1.1.1 EVK lietotāju autorizācija<br />
EVK lietotāju autorizācijai tiks izmantots IP autorizācijas serviss.<br />
IP autorizācijas servisā tiks uzglabātas ārstniecības personu lomas un tiesības un tas veiks<br />
ārstniecības personu autorizēšanu, izsniedzot ārstniecības personām citās e-Veselības<br />
sistēmās (tai skaitā EVK) derīgus drošības talonus. Par pacientiem IP autorizācijas serviss<br />
papildus autorizācijas informāciju neuzturēs – no IP skatu punkta tie tiks apvienoti vienā<br />
drošības lomā „pacienti”. Papildus drošības atribūtus par pacientiem uzturēs EVK <strong>sistēma</strong>.<br />
IP autorizācija notiek attiecībā uz IP eksponētajiem servisiem, tai skaitā EVK servisiem.<br />
Piemēram, IP autorizācijas serviss var noteikt, ka lietotājs X pieder drošības lomai „pacienti”<br />
un tāpēc tam ir piekļuve EVK servisam, kas ļauj iegūt pacienta karti no EVK <strong>sistēma</strong>s, bet IP<br />
autorizācijas servisam nav pieejama informācija, piemēram, vai lietotājs X drīkst iegūt<br />
konkrēto pacienta Y karti. Objektu, jeb dokumentu līmeņa autorizāciju tālāk jau veic<br />
konkrētā e-Veselības centrālā <strong>sistēma</strong>, piemēram, EVK, izmantojot EVK autorizācijas moduli,<br />
skat. ši dokumenta sadaļu „6.4.1 Autorizācija”.
2. attēls. EVK un tās sadarbība ar lietotājiem un ārējām sistēmām
5.2 Lietotāju saskarnes<br />
Piekļuve EVK <strong>sistēma</strong>s datiem un funkcijām tiks nodrošināta, izmantojot:<br />
e-Veselības portālu<br />
www.latvija.lv e-Pakalpojumus<br />
ārstniecības iestāžu (ģimenes ārsta prakses) <strong>sistēma</strong>s, kuras ir integrētas ar EVK<br />
tīmekļa pakalpēm<br />
Integrācijas platformu, kas nodrošinās piekļuvi <strong>sistēma</strong>s administratora<br />
funkcionalitātei<br />
Galvenās EVK lietotāju grupas ir aprakstītas tabulā zemāk:<br />
5.2-1. tabula. Galvenās EVK lietotāju grupas<br />
Lietotāju grupa<br />
Pacienti<br />
Apraksts<br />
Pacienti izmantos EVK funkcionalitāti, piekļūstot tai www.latvija.lv<br />
vai e-Veselības portālā.<br />
Galvenā šai lietotāju grupai pieejamā funkcionalitāte būs darbs ar<br />
saviem un bērnu vai aizbildniecībā esošo personu ierakstiem EVK.<br />
Šīs lietotāju grupas autentificēšanu www.latvija.lv un tālākā<br />
piekļuve EVK datiem tiks nodrošināta, veicot portāla www.latvija.lv<br />
drošības talona nomaiņu pret derīgu talonu, kuru izsniedz IP<br />
autorizācijas serviss.<br />
Ārstniecības personas<br />
Ārstniecības personas izmantos EVK funkcionalitāti, piekļūstot tai<br />
e-Veselības portālā vai arī savas ārstniecības iestādes informācijas<br />
sistēmā, kas būs integrēta vienotajā e-Veselības sistēmu vidē.<br />
Ārstniecības personām EVK sistēmā būs pieejama funkcionalitāte<br />
EVK pacienta ierakstu apskatei un papildināšanai.<br />
Šīs lietotāju grupas autentificēšanu un autorizāciju nodrošinās IP<br />
lietotāju pārvaldības un autentificēšanas modulis, kurā lietotājus<br />
un to tiesības definēs ārstniecības iestādes administrācijas<br />
darbinieki.<br />
Izmeklētāji<br />
Izmeklētājs var būt gan VEC administrators, gan arī jebkurš ārējs<br />
lietotājs, kuram VEC piešķīris šādas tiesības.<br />
Izmeklētāji veic konkrētu personu EVK izmeklēšanu, lai pārbaudītu<br />
datus, kā arī lai sagatavotu atbildes uz tiesībsargājošo institūciju un<br />
veselības inspekcijas pieprasījumiem.<br />
Administratīvie<br />
lietotāji<br />
Administratīvie lietotāji reģistrē izmeklētāju tiesības, personu<br />
aizgādnību un pilngadību, reģistrē jaunus dokumentu tipus.
Lietotāju grupa<br />
Ārstniecības iestādes<br />
darbinieki<br />
Apraksts<br />
Ārstniecības iestādes darbinieku grupa ietvers plašu lietotāju loku,<br />
sākot ar reģistratoriem un ārstu palīgiem, beidzot ar ārstniecības<br />
iestādes vadību. Ārstniecības iestādes darbiniekiem, kas ir ārstu<br />
palīgi vai reģistratori, tiks nodrošināta daļēja ārstiem pieejamā<br />
funkcionalitāte, lai atvieglotu (atbalstītu) ārstu darbu.<br />
5.3 Sistēmu saskarnes<br />
Integrāciju ar citām sistēmām EVK tiks nodrošināta, izmantojot tīmekļa pakalpes, kas būs<br />
izvietotas e-Veselības integrācijas platformā.<br />
Pacienti e-veselības <strong>sistēma</strong>s lietos vai nu e-Veselības nozares portālā speciāli pacientiem<br />
paredzētā darba vietā, vai arī izmantojot e-pakalpojumus caur portālu www.latvija.lv.<br />
Ārstniecības personas lietos vai nu e-Veselības nozares portālā speciāli pacientiem paredzētā<br />
darba vietā, vai arī izmantojot ārstniecības iestāžu IS.<br />
EVK tiks nodrošinātas saskarnes ar sekojošām ārējām sistēmām:<br />
5.3-1. tabula. EVK saskarnes ar ārējām sistēmām<br />
Ārējās <strong>sistēma</strong>s<br />
e-Veselības portāls,<br />
www.latvija.lv portāls,<br />
ārstniecības iestāžu IS<br />
Apraksts<br />
e-Veselības portāls, www.latvija.lv portāls un ārstniecības iestāžu IS<br />
ir primārās <strong>sistēma</strong>s, kas izmantos EVK funkcionalitāti. Šīs <strong>sistēma</strong>s<br />
izsauks EVK tīmekļa pakalpes, kas būs eksponētas kā IP tīmekļa<br />
pakalpes. Tīmekļa pakalpju izsaukumi paredzēti tikai, izmantojot<br />
integrācijas platformu, kurā tiks nodrošināta lietotāju<br />
autentifikācija, autorizācija un augsta līmeņa tiesību kontrole.<br />
EVK tīmekļa pakalpes, kuras nevarēs garantēt to izpildi mazāk kā 3<br />
sekundēs, tiks veidotas kā asinhronas metodes, piemēram, EVK<br />
dokumentu pievienošana, skat. sadaļu 6.4.3.1.<br />
Visi ziņojumi no šīm sistēmām tiks modelēti kā HL7 ziņojumi, pēc<br />
iespējas izmantojot HL7 standarta ziņojumu veidus. Tikai<br />
gadījumos, ja nebūs iespējams izmantot standarta HL7 ziņojumus,<br />
var tikt veidoti arī modificēti HL7 ziņojumi.<br />
Integrācijas platforma<br />
Integrācijas platforma kalpos kā starpslānis jeb savienotājs starp<br />
dažādām informācijas sistēmām – centrālajām e-veselības<br />
sistēmām, veselības pakalpojumu sniedzēju informācijas sistēmām,<br />
nozares pārvaldības informācijas sistēmām un reģistriem un,<br />
izmantojot VISS, valsts nozīmes reģistriem un apdrošinātājiem.<br />
IP tiks nodrošināta ne tikai ziņojumu apmaiņa starp iesaistītajām<br />
informācijas sistēmām, bet arī dažādi koplietojami un atkārtoti
Ārējās <strong>sistēma</strong>s<br />
Apraksts<br />
izmantojami servisi, kuri ir noderīgi visām iesaistītajām sistēmām.<br />
Šādi servisi, piemēram, ir autentifikācija, autorizācija, personas<br />
datu audita atbalsts, apziņošanas serviss, klasifikatoru reģistrs,<br />
monitorings u.c.<br />
EVK tīmekļa pakalpes tiks eksponētas kā IP tīmekļa pakalpes, skat.<br />
sadaļu 6.1.1.<br />
e-Pieraksti,<br />
e-Nosūtījumi,<br />
e-Recepte<br />
Centrālās e-veselības <strong>sistēma</strong>s: e-Pieraksti, e-Nosūtījumi un<br />
e-Recepte izmantos EVK tīmekļa pakalpes gadījumos, kad tas ir<br />
paredzēts to biznesa procesos, piemēram, e-Nosūtījumi saglabās<br />
EVK sistēmā nosūtījumu rezultātus, bet e-Recepte saglabās<br />
pacientam izrakstītos un izsniegtos medikamentus un ierīces.<br />
Centrālās e-veselības <strong>sistēma</strong>s un EVK atradīsies kopējā IP drošības<br />
zonā, tāpēc to savstarpējai komunikācijai tiks izmantotas nedrošās<br />
tīmekļa pakalpes. Tas nozīmē, ka centrālās e-veselības <strong>sistēma</strong>s<br />
savā starpā uzticēsies un to starpā netiks veikta sistēmu<br />
autorizācija. Lietotāju autorizācijai tiks izmantoti HL7 ziņojuma<br />
metadati, kas saturēs lietotāja identitāti,tā lomas un detalizēto<br />
tiesību komplektu.<br />
Visi ziņojumi no šīm sistēmām tiks modelēti kā HL7 ziņojumi, pēc<br />
iespējas izmantojot HL7 standarta ziņojumu veidus.<br />
VNC VIS<br />
VNC VIS kalpo kā pacientu ģimenes ārstu un EVAK karšu<br />
informācijas datu avots.<br />
Ģimenes ārstu un EVAK informācija tiks iegūta asinhronā režīmā.<br />
Veidojot jaunu pacienta karti EVK sistēmā, tiks izveidoti divi jauni<br />
uzdevumi fona uzdevumu komponenta uzdevumu rindā – pieprasīt<br />
datus par pacienta ģimenes ārstu un EVAK karti.<br />
Tā kā ģimenes ārstu un EVAK informācija laika gaitā var mainīties,<br />
fona uzdevumu komponents veiks periodisku datu aktualizēšanu.<br />
Datu aktualizēšana tiks veikta, periodiski pieprasot no VNC VIS<br />
visas notikušās izmaiņas par noteiktu laika periodu un veicot<br />
attiecīgās izmaiņas pacientu karšu ierakstos.<br />
VNC VIS un EVK atradīsies kopējā IP drošības zonā.<br />
EVK datu apmaiņā ar VNC VIS izmantos HL7 standarta transporta<br />
aploksni, savukārt VNC VIS servisi tiks publicēti IP, izmantojot IP<br />
adapterus.<br />
PMLP Iedzīvotāju<br />
reģistrs<br />
EVK sistēmā veidojot jaunas pacientu kartes, sinhronā režīmā tiks<br />
pieprasīti personu dati PMLP Iedzīvotāju reģistrā. Šī darbība notiks
Ārējās <strong>sistēma</strong>s<br />
Apraksts<br />
sinhronā režīmā, jo pirms izveidot pacienta karti, ir nepieciešams<br />
pārliecināties par personas datu eksistenci un pacienta statusu<br />
Iedzīvotāju reģistrā.<br />
Fona uzdevumu komponents veiks arī periodisku personas datu<br />
aktualizēšanu, pieprasot no PMLP IR visas notikušās izmaiņas par<br />
noteiktu laika periodu un veicot attiecīgās izmaiņas pacientu karšu<br />
ierakstos.<br />
PMLP IR servisi ir publicēti VISS servisu katalogā, kas savukārt tiks<br />
pārpublicēti IP drošo servisu veidā.<br />
EVK datu apmaiņā ar PMLP IR izmantos HL7 standarta transporta<br />
aploksni, savukārt PMLP IR servisi tiks publicēti IP, izmantojot VISS<br />
adapterus.<br />
Jaundzimušo reģistrs<br />
Kamēr jaundzimušajam nav piešķirts personas kods, par<br />
personificēto datu avotu šim pacientam kalpo jaundzimušo<br />
reģistrs. Personas dati jaundzimušo reģistrā tiek identificēti pēc<br />
mātes personas koda un dzimšanas datuma un laika.<br />
EVK sistēmā veidojot jaunas pacientu kartes jaundzimušajam,<br />
sinhronā režīmā tiks pieprasīti jaundzimušā dati Jaundzimušo<br />
reģistrā.<br />
Fona uzdevumu komponents asinhronā režīmā periodiski<br />
pārbaudīs jaundzimušo datus tām personām, kurām EVK IS nav<br />
aizpildīts personas kods. Dati tiks pieprasīti, norādot mātes<br />
personas kodu un bērna dzimšanas datumu un laiku. Ja<br />
Jaundzimušo reģistrā jaundzimušajam būs ievadīts personas kods,<br />
jaundzimušā dati tiks pieprasīti PMLP IR.<br />
EVK datu apmaiņā ar Jaundzimušo reģistru izmantos HL7 standarta<br />
transporta aploksni.<br />
VADC IS, NMP IS<br />
USPS<br />
VADC IS un NMP IS izmantos EVK sistēmu analoģiski kā ārstniecības<br />
iestāžu IS – tās izsauks EVK tīmekļa pakalpes, kas būs eksponētas kā<br />
IP tīmekļa pakalpes, izmantojot HL7 ziņojumus. Pamatā tās<br />
izmantos EVK funkcijas, kas ir paredzētas darbam ar medicīnas<br />
dokumentiem - EVK pacienta ierakstu apskate un papildināšana.<br />
Elektroniski parakstītu medicīnisko dokumentu pārbaudes laikā tiks<br />
izmantots USPS publiski pieejamais OCSP serveris, kas nodrošina<br />
sertifikātu statusu pārbaudi tiešsaistes režīmā atbilstoši RFC 2560<br />
standartam. OCSP servera pieprasījumi tiks veikti sinhroni,<br />
izmantojot HTTPS standarta protokolu. Lai nodrošinātu augstu<br />
veiktspēju, OCSP servisa izsaukumi notiks pa tiešo, apejot
Ārējās <strong>sistēma</strong>s<br />
Apraksts<br />
integrācijas platformas starpslāni. Visi OCSP pieprasījumi tiks<br />
reģistrēti audita žurnālā.<br />
PREDA<br />
Šobrīd ir paredzēts PREDA sistēmu izmantot tikai sākotnējai datu<br />
ielādei. Par tālāko sadarbību starp EVK IS un PREDA tiks lemts<br />
nākamajās EVK kārtās.<br />
No PREDA reģistriem tiks izgūta tikai pamata informācija pacienta<br />
kartes veselības pamatdatiem, medicīnas dokumentu veidošana<br />
nav paredzēta.<br />
Sākotnējo datu ielādes laikā katrs PREDA reģistrs tiks apstrādāts<br />
secīgi, izveidojot pacienta kartes tiem personas kodiem, kuriem<br />
pacienta kartes EVK vēl neeksistē.<br />
VZD AR<br />
EVK analīzes fāzes laikā netika konstatēta nepieciešamība pēc<br />
integrācijas ar VZD AR sistēmu.<br />
Sistēmu sadarbībai ar EVK tiek izmantotas SOAP protokolam atbilstošas tīmekļa pakalpes,<br />
kas klīniskās informācijas apmaiņai izmanto HL7 v3 standarta ziņojumus.<br />
Lietotāju un sistēmu autentificēšana un datu drošība (datu šifrēšana un parakstīšana) tiek<br />
nodrošināta, izmantojot WS-* tīmekļa pakalpju drošības standartus un X.509 digitālos<br />
sertifikātus.<br />
Saskaņā ar HL7 v3 transporta specifikāciju Web Services Profile, Release 2 ziņojumu apmaiņa<br />
notiek, izmantojot SOAP protokolu, kur SOAP aploksnes galvenē atrodas adresācijas un<br />
drošības dati, bet aploksnes ķermeņa HL7 interakcijas ziņojums. SOAP ziņojumi un to<br />
sasaiste ar HL7 v3 un WS-* 1 standartiem detalizētāk ir aprakstīta IP risinājuma arhitektūras<br />
vīzijas dokumentā, skat. [5].<br />
HL7 v3 standarta ziņojumu semantika un saturs nākotnē tiks aprakstīti e-veselības<br />
ziņojumapmaiņā izmantojamo datu struktūru standarta dokumentā.<br />
1 WS-Security v1.0, WS-Security v1.1, WS-Trust v1.2, WS-Trust v1.3, WS-Federation v1.2 un<br />
SAML v1.1, Shibboleth v1.3, SAML v2.0
6 Loģiskā arhitektūra<br />
Šajā nodaļā aprakstīti <strong>sistēma</strong>s iekšējie komponenti, identificēts, kādi no šiem<br />
komponentiem nodrošina ārējo saskarņu funkcionalitāti, noteikti arī <strong>sistēma</strong>s iekšējo<br />
komponentu un moduļu sadarbības scenāriji, nepieciešamās saskarnes, to specifika<br />
(autentifikācija, protokoli).<br />
6.1 Sistēmas komponentu grupas<br />
No drošības viedokļa <strong>sistēma</strong>s komponentus var sadalīt divās grupās:<br />
EVK tīmekļa pakalpes<br />
EVK komponenti<br />
6.1.1 EVK tīmekļa pakalpes<br />
3. attēls. EVK komponentu grupas<br />
Sistēma nodrošina eksponējamas tīmekļa pakalpes, ko izmantos citas ārējas <strong>sistēma</strong>s, lai<br />
nodrošinātu datu izgūšanu un datu ievadu EVK sistēmā.<br />
EVK tīmekļa pakalpju izsaukumi paredzēti tikai, izmantojot integrācijas platformu, kurā tiks<br />
nodrošināta lietotāju autentifikācija, autorizācija un augsta līmeņa tiesību kontrole. Katrs<br />
EVK pakalpes izsaukums saturēs papildus drošības informācijas komplektu, kuru aizpildīs IP<br />
autorizācijas serviss veiksmīgas autorizācijas gadījumā. Drošības informācijas komplekts<br />
saturēs kā minimums sekojošu informāciju:
lietotāja identifikāciju;<br />
ziņojuma laika, avota un mērķa <strong>sistēma</strong>s identifikāciju;<br />
IP audita transakcijas identifikāciju;<br />
lietotāja pilno tiesību komplektu.<br />
Šo informāciju IP nodos EVK tīmekļa pakalpēm drošības talonā vai transporta aploksnē,<br />
atkarībā no IP detalizētā projektējuma. Pieprasījumus, kas neizies IP lietotāju autorizāciju un<br />
tiesību kontroli, integrācijas platforma noraidīs un šādi pieprasījumi līdz EVK <strong>sistēma</strong>i nemaz<br />
nenonāks.<br />
6.1.2 EVK komponenti<br />
Pārējie EVK <strong>sistēma</strong>s komponenti netiek dalīti atsevišķās drošības zonās, jo tiem netiek<br />
nodrošināta piekļuve no ārējām sistēmām pa tiešo. Jebkuri izsaukumi no ārējām sistēmām<br />
notiek, izmantojot EVK tīmekļa pakalpes, kurās notiek papildus autorizācija EVK objektu<br />
līmenī. EVK <strong>sistēma</strong>s komponenti savā starpā veic izsaukumus pa tiešo, neizmantojot tīmekļa<br />
pakalpju līmeni. Komponenti, kas darbojas šajā zonā, viens otram piekļūst, neveicot papildus<br />
autentifikāciju un tiesību pārbaudi.<br />
6.2 Loģiskais datu modelis<br />
Pacientu personificētie dati tiek atdalīti no nepersonificētiem datiem datu bāzes līmenī.<br />
Personificēti un nepersonificētie dati tiek glabāti dažādās datu tabulās, un starp šīm tabulām<br />
tiek nodrošināta šifrēta saite - personas nepersonificēto datu identifikators šifrētā veidā.<br />
Tikai atšifrējot šo identifikatoru, ir iespējams savienot pacienta personificēto un<br />
nepersonificēto informāciju. Tā kā EVK medicīniskie dokumenti satur gan personificēto, gan<br />
nepersonificēto informāciju vienuviet, šie dokumenti tiek šifrēti, izmantojot kriptogrāfiskās<br />
atslēgas.<br />
No drošības viedokļa EVK pamata datus var sadalīt trīs kategorijās:<br />
personificētie dati<br />
nepersonificētie dati<br />
šifrētie dati
4. attēls. EVK loģiskais datu modelis<br />
EVK risinājumā tiek pielietota divu līmeņu datu šifrēšana:<br />
pilnīgi visi EVK dati tiek šifrēti datu bāzes līmenī, izmantojot Microsoft SQL Server<br />
TDE (Transparent Data Encryption) iespējas. TDE nodrošina ātru un izstrādātājiem<br />
vienkāršu datu šifrēšanu datu bāzes failu līmenī. Tādā veidā tiek aizsargāti EVK dati<br />
datu bāzes failu līmenī, kā arī EVK datu rezerves kopijas;<br />
ar citu kriptogrāfisko atslēgu komplektu tiek šifrēti medicīniskie dokumenti un saites<br />
starp personificētajiem un nepersonificētajiem datiem.<br />
Risinājums nodrošina, ka datu bāze pati par sevi nav atšifrējama, jo datu bāze nesatur<br />
atslēgas. Atslēgas, kas nepieciešamas, lai atšifrētu šifrētās saites, tiek glabātas atdalīti no<br />
datu bāzes. Šifrēšanas uzstādījumi ir fiksēti: EVK datubāzē, administratīvajā datu bāzē<br />
(master) un SQL servera instancē. Pasūtītājam ir jānodrošina piekļuve šifrēšanas atslēgām<br />
personām, kurām tai pašā laikā nav piekļuve datu bāzei, lai viena persona nevarētu atšifrēt<br />
datus. Datu šifrēšanai izmantotās atslēgas ir aizsargātas un ir pieejamas tikai drošības<br />
pārvaldniekiem.<br />
Personificētie dati satur pacientu pamatdatus, kā piemēram, vārds, uzvārds, personas kods,<br />
dzimšanas un miršanas datumi, deklarētās adreses personificētā daļa un pacienta<br />
kontaktpersonas. Tie nesatur pacienta klīnisko informāciju. Detalizētāk personificētie dati un<br />
to atribūti ir aprakstīti programmatūras prasību specifikācijas sadaļā „Personificētie dati”,<br />
skat. [1].<br />
Šifrētie dati satur saites starp pacientu personificētajiem un nepersonificētajiem datiem, kā<br />
arī pacientu medicīniskos dokumentus.<br />
Pacienta nepersonificēto datu ieraksts veidojas vienlaicīgi ar personificēto datu ierakstu, tikai<br />
tas satur citu informācijas apjomu. Paredzēts, ka nepersonificētie dati tiks izmantoti<br />
statistikai un pētniecībai. Nepersonificētie dati satur pacientu pamatdatu daļu, kas tiks<br />
izmantoti analītiskām vajadzībām, kā piemēram, dzimumu, pacienta statusu, pilngadības<br />
pazīmi, deklarētās adreses nepersonificēto daļu, ģimenes ārstu, EVAK kartes datus, veselības<br />
pamatdatus, vakcināciju reģistru un medicīnisko dokumentu sekcijas, kas nesatur<br />
personificētus datus. Detalizētāk nepersonificētie dati ir aprakstīti programmatūras prasību<br />
specifikācijas sadaļā „Nepersonificētie dati”, skat. [1].<br />
Veselības pamatdati ir pacienta pamatdatu kopa, kas ir paredzēta kā operatīvi iegūstama<br />
aktuāla pacienta veselības informācija. Tā satur pacienta datus par diagnozēm, medicīnas<br />
ierīcēm un implantiem, alerģijām, medikamentiem un brīdinājumiem. Datu kopa, kas būtu<br />
iekļaujama pacienta pamatdatos, ir noteikta epSOS projekta ietvaros. epSOS ieteikumi tika<br />
ņemti vērā, nosakot arī EVK veselības pamatdatu kopu. Detalizētāk veselības pamatdati ir<br />
aprakstīti programmatūras prasību specifikācijas sadaļā „Veselības pamatdati”, skat. [1].
5. attēls. Veselības pamatdati<br />
EVK dokumentu repozitorijs ir paredzēts medicīnisko dokumentu elektroniskai glabāšanai.<br />
Katram dokumentam, kas tiek reģistrēts repozitorijā, ir jāatbilst noteiktam dokumenta tipam<br />
un dokumenta veidnei, kas ir reģistrēta dokumentu metasistēmā. Medicīniskajam<br />
dokumentam var būt viena vai vairākas sekcijas. Detalizētāk veselības pamatdati ir aprakstīti<br />
programmatūras prasību specifikācijas sadaļā „Medicīniskie dokumenti”, skat. [1].<br />
Vakcināciju modulis nodrošinās ar vakcināciju saistīto medicīnisko dokumentu glabāšanu EVK<br />
dokumentu repozitorijā, līdz ar to vakcināciju reģistra dati būs apakškopa no EVK dokumentu<br />
repozitorija datiem. Detalizētāk vakcinācijas reģistra datu kopas ir aprakstītas vakcināciju<br />
reģistra programmatūras prasību specifikācijas sadaļā „Pamatdati”, skat. [3]. Klasifikatoru<br />
moduļa datu kopas ir aprakstītas klasifikatoru moduļa programmatūras prasību specifikācijas<br />
dokumentā, skat. [4].<br />
6.2.1 Datu integritāte<br />
EVK <strong>sistēma</strong>s datu kvalitāte, integritātes kontrole (ieskaitot biznesa loģikas noteiktos datu<br />
integritātes nosacījumus) un datu pilnīgums tiek nodrošināti SQL datu bāzes līmenī ar SQL<br />
iebūvētajiem līdzekļiem. Datu līmenī tiek realizēta arī pieejas kontrole, ierobežojot pieeju no<br />
biznesa loģikas tikai biznesa funkcijām nepieciešamā apjomā, kā arī audita funkcijas.<br />
EVK medicīnas dokumentu integritāte tiek nodrošināta, izmantojot elektronisko parakstu.<br />
Jebkurš ienākošais medicīniskais dokuments automātiski tiks elektroniski parakstīts,<br />
izmantojot pasūtītāja PKI infrastruktūru vai ārējas organizācijas pakalpojumus. Parakstīšanas<br />
mērķis nav dokumenta autora identificēšana, bet gan tikai dokumentu integritātes<br />
nodrošināšana, tāpēc dokumenti tiks parakstīti ar <strong>sistēma</strong>i izdotu X.509 sertifikātu. Tā kā<br />
sertifikātu derīguma termiņš ir īsāks nekā medicīnas dokumentu uzglabāšanas laiks, EVK<br />
nākotnes funkcionalitātē ir jāparedz dokumentu pār-parakstīšana ar jaunu parakstu.<br />
6.2.2 Elektroniskais paraksts<br />
Medicīniskos dokumentus būs iespējams saglabāt elektroniski parakstītus, izmantojot<br />
uzticama sertifikācijas pakalpojumu sniedzēja (turpmāk tekstā USPS) programmatūras<br />
radītos elektroniskos dokumentus.<br />
USPS programmatūras radītais elektroniskais dokuments (parakstītais fails) tiek veidots kā<br />
Open Packaging Conventions formātam atbilstošs fails. Šī formāta apzīmēšanai USPS izmanto<br />
terminu eDoc. eDoc formāta dokuments sastāv no metadatu, parakstāmo failu un parakstu
sekcijām. Tas ir veidots kā konteiners, kurš var saturēt jebkura formāta failus, tai skaitā<br />
medicīnisko dokumentu, drošo elektronisko parakstu un laika zīmogu.<br />
eDoc formāts plašāk ir aprakstīts eDoc dokumenta formāta specifikācijā, skat. [10].<br />
EVK repozitorijā ir paredzēts saglabāt elektroniski parakstītus dokumentus (eDoc) tādus, kādi<br />
tie ir saņemti no ārējām sistēmām.<br />
6.3 Sistēmas komponentu sadarbība<br />
Šajā nodaļā aprakstīta <strong>sistēma</strong>s loģisko komponentu karte, kurā ilustrēta komponentu<br />
savstarpējā sadarbība un sadarbība ar ārējām sistēmām.<br />
Sistēmas loģisko komponentu karte, kurā ilustrēta komponentu savstarpējā sadarbība un<br />
sadarbība ar ārējām sistēmām, shematiski parādīta 6. attēlā. Ar raustītu elementa robežu ir<br />
attēlotas nākotnē plānotās <strong>sistēma</strong>s vai moduļi.<br />
Attēlā redzams, ka EVK moduļi savu funkcionalitāti nodrošinās citām ārējām sistēmām, no<br />
kurām galvenās ir e-Veselības portāls, ārstniecības iestāžu IS, e-Pakalpojumi, e-Pieraksti,<br />
e-Nosūtījumi un e-Recepte. Lai gan komponentu kartē tas nav parādīts, visi izsaukumi no<br />
ārējām sistēmām uz EVK tiks veikti ar IP starpniecību. Visi izsaukumi, kas nonāks EVK<br />
publicētajās tīmekļa pakalpēs, tiks autentificēti un auditēti, izmantojot autentifikācijas un<br />
auditācijas moduli, kas sadarbojas ar IP auditu.<br />
Praktiski katrs no <strong>sistēma</strong>s moduļiem darbosies ar savu datu krātuvi, kurā tiks glabāta<br />
modulim nepieciešamā informācija.<br />
Attēlā parādītās atbalsta līmeņa komponentes, piemēram, datu noliktavas integrācijas<br />
modulis, fona uzdevumu modulis, klasifikatoru uzturēšanas modulis piekļūst vairāku moduļu<br />
atbilstošajām datu krātuvēm.<br />
IP audita un <strong>sistēma</strong>s žurnāla bibliotēkas izmantos visi pārējie biznesa servisu līmeņa moduļi,<br />
lai veiktu audita un tehnisko notikumu informācijas fiksēšanu IP audita un <strong>sistēma</strong>s žurnāla<br />
datu bāzēs.<br />
Gadījumos, kur EVK moduļi izsauks ārējās <strong>sistēma</strong>s, kuru pieejamību nav iespējams garantēt,<br />
vai, kuras ienākošos ziņojumus varēs apstrādāt tikai noteiktos laika periodos, piemēram,<br />
naktīs, IP vide būs tā, kas nodrošinās ziņojumu uzkrāšanu, lai garantētu ziņojumu piegādi,<br />
kad ārējo sistēmu darbība vai to saskarņu darbība tiks atjaunota.<br />
Darbietilpīgu apstrādes uzdevumu veikšanai, kā arī regulāri veicamo uzdevumus izpildei tiks<br />
izmantota fona uzdevumu komponente.
6. attēls. EVK loģiskie komponenti un to sadarbība
6.4 Sistēmas komponenti<br />
Šajā nodaļā aprakstīti svarīgākie projektējuma elementi, loģisko komponentu funkcionalitāte<br />
un izmantotie produkti un tehnoloģijas. Precizējot klienta prasības un detalizējot EVK<br />
<strong>sistēma</strong>s arhitektūru, analīzes fāzes rezultātā radās nedaudz savādāks EVK sadalījums pa<br />
moduļiem, salīdzinot ar tehnisko piedāvājumu. EVK funkcionālā sadalījuma pa moduļiem<br />
atšķirības ir norādītas šī dokumenta pielikumā „EVK funkcionālais sadalījums pa moduļiem”.<br />
6.4.1 Autorizācijas modulis<br />
Lietotāju autentifikācija un veselības aprūpes iestāžu darbinieku autorizācija tiks nodrošināta<br />
integrācijas platformas modulī. Pacientu autorizāciju nodrošinās EVK autorizācijas modulis.<br />
EVK autorizācijas modelis balstās uz EVK tiesību punktiem, lietotāju lomām, atļaujām un<br />
aizliegumiem. Katrai EVK tīmekļa pakalpei tiks izveidoti fiksēti tiesību punkti.<br />
IP lietotāju administrēšanas modulī administrators veidos veselības aprūpes iestāžu<br />
darbinieku lomas, kombinējot tiesību punktus, un lomas piesaistīs konkrētiem lietotājiem vai<br />
lietotāju grupām.<br />
Savukārt pacienta loma tiek noteikta dinamiski. Atkarībā no personas vecuma grupas,<br />
pilngadības pazīmes un aizgādnības tiek izdalītas 8 pacientu lomas. Detalizētāk pacienta<br />
lomas un to noteikšanas algoritms ir aprakstīti programmatūras prasību specifikācijas sadaļā<br />
„Lietotāju grupas un to raksturiezīmes”, skat. [1]. Paredzamais pacienta lomu un tiesību<br />
attiecību sadalījums pieejams programmatūras prasību specifikācijas pielikumā „Lietotāju<br />
tiesību matrica”, skat. [1].<br />
Papildus lietotāja tiesību pārbaudei tiks izmantotas atļaujas un aizliegumi. Informācija par<br />
pacientu atļaujām, aizliegumiem un pacientu dinamiskajām lomām tiek uzturēta EVK<br />
sistēmā, tāpēc pacientu autorizācijas gadījumā IP pieprasīs no EVK iedzīvotāju autorizācijai<br />
nepieciešamos papildus atribūtus:<br />
vārds, uzvārds<br />
personas kods<br />
e-pasta adrese<br />
pacienta dinamiskā koma:<br />
o<br />
o<br />
o<br />
„Lietotājs ir pacients”<br />
„Lietotājs ir pacienta māte, tēvs vai aizbildnis”<br />
„Lietotājs ir pacienta aizgādnis”<br />
atļaujas, aizliegumi, deleģētās tiesības<br />
lietotāja tiesību vektors – satur atļautās darbības konkrētajā e-Veselības centrālajā<br />
sistēmā, piemēram, iegūt pacienta karti no EVK<br />
Šie papildus atribūti tiks atgriezti izsaucošajai <strong>sistēma</strong>i drošības talona veidā. Precīzāk IP<br />
autorizācijas servisi, to izmantošanas scenāriji un konkrētie drošības talona atribūti ir<br />
aprakstīti IP risinājuma arhitektūras vīzijas dokumentā, skat. [5].
6.4.2 Metadatu pārvaldība<br />
Metadatu pārvaldības komponents ir atbildīgs par EVK dokumentu un to sekciju struktūru.<br />
Tā kā EVK glabātā informācija varēs mainīties laika gaitā un varēs parādīties jauni EVK<br />
ierakstu tipi, metadatu pārvaldības modulis satur informāciju par EVK pieļaujamiem<br />
medicīnisko ierakstu tipiem, to sintaksi un semantiku. Informācija tiek izmantota visu EVK<br />
iesūtīto ierakstu pārbaudei pirms tie tiek akceptēti kā pacienta ieraksta sastāvdaļa.<br />
Dokumentu veidņu administrēšana ir administratīva funkcija, kurai tiek nodrošināta lietotāju<br />
saskarne. Metadatu informācijas pieejamība citām sistēmām tiek nodrošināta caur tīmekļa<br />
pakalpēm.<br />
EVK dokumentu meta <strong>sistēma</strong> apraksta:<br />
dokumentu tipus<br />
sekciju tipus<br />
sekciju apstrādes uzdevumus<br />
Katram dokumentu tipam tiek izveidota arī XSLT transformācija, kas nodrošina HTML<br />
formāta datu ģenerēšanu dokumenta atainošanai cilvēklasāmā formātā.<br />
Sekciju apstrādes uzdevumi ir nepieciešami, lai izgūtu no sekcijām noteiktu datu kopu, kas<br />
attiecas uz EVK pamatdatiem, un iekļautu to atbilstošajās pamatdatu tabulās. Sekciju<br />
apstrādes uzdevumi tiks veidoti, izmantojot XPath un XSLT tehnoloģijas.<br />
6.4.2.1 Dokumenta veidņu modelēšana<br />
e-Veselības medicīnisko dokumentu elektroniskais formāts atbilst HL7 CDA specifikācijai.<br />
Detalizētāk tas ir aprakstīts programmatūras prasību specifikācijas sadaļā „Medicīniskie<br />
dokumenti”, skat. [1].<br />
Pilns dokumentu veidņu modelēšanas process ir aprakstīts programmatūras prasību<br />
specifikācijas sadaļā „Dokumentu veidņu modelēšana” , skat. [1].<br />
Jaunu dokumentu veidņu modelēšana sākas ar jauna dokumenta tipa apraksta izveidi, ko<br />
veic biznesa analītiķis sadarbībā ar nozares ekspertiem.<br />
Modelētājs pēc izveidotā apraksta liek kopā dokumenta veidnes modeli, izmantojot<br />
eksistējošās sekcijas vai pēc nepieciešamības veidojot jaunas sekcijas.<br />
Kā modelēšanas rīks tiek izmantots Model-Driven Health Tools (MDHT), kurš nodrošina CDA<br />
dokumentu modelēšanu, izmantojot UML modelēšanas rīkus. Zemāk 7. attēlā kā piemērs ir<br />
redzama „No stacionāra izrakstīta (miruša) pacienta karte”, jeb veidlapa Nr. 066/u MDHT<br />
modelēšanas rīkā. Piemērā redzams, ka šī veidlapa satur sekojošas sekcijas:<br />
administratīvā sekcija (administrativeSection)<br />
saslimšanas sākums (onsetOfTheDiseaseSection)<br />
slimnieka kustība (patientMovementSection)<br />
operācijas un anestēzijas (operationAndAnesthesiaSection)
citas manipulācijas (otherManipulationsSection)<br />
manipulācijas, kuras veiktas citās ārstniecības iestādēs<br />
(manipulationInOtherHospitalsSection)<br />
7. attēls. No stacionāra izrakstīta pacienta karte MDHT UML modelēšanas rīkā<br />
CDA dokumenti tiek veidoti no sekciju aprakstiem, kas tiek definēti atsevišķā sekciju UML<br />
failā. Arī piemērā izmantotie sekciju tipi ir definēti atsevišķi. Zemāk 8. attēlā kā piemērs ir<br />
redzams sekciju tipu fails, kurš satur, piemēram, manipulāciju (Manipulation) sekcijas tipa<br />
aprakstu. Pacient kartē gan sekcija „Citas manipulācijas”, gan sekcija „Manipulācijas, kuras<br />
veiktas citās ārstniecības iestādēs” abas manto manipulāciju sekciju tipu.
6.4.2.1 Validatori<br />
8. attēls. EVK sekciju tipi MDHT UML modelēšanas rīkā<br />
Kad dokumenta tipa UML modelis ir izstrādāts, tas tiek transformēts komponentēs, kas<br />
nepieciešamas dokumenta veidnes lietošanai. No UML modeļa automātiski tiek uzģenerētas<br />
dokumenta XSD shēma un Java bibiliotēkas. Uzģenerētā Java bibliotēka sastāv no divām<br />
bibliotēkām – viena satur pašu CDA dokumentu aprakstošās klases, bet otra satur EVK<br />
sekciju tipu klases. Katra CDA dokumenta sekcijai atbilst atsevišķa klase, piemēram,<br />
OperationAndAnesthesiaSection. Bibliotēka nodrošina metodes XML formāta faila<br />
nolasīšanai, CDA dokumenta saglabāšanai XML formātā, dokumenta validācijai, dokumenta<br />
sekciju un to elementu apstrādei.<br />
Zemāk 9. attēlā ir redzams koda paraugs, kas izveido neaizpildītu pacienta kartes dokumentu<br />
testēšanas mērķiem.
9. attēls. Pacienta kartes testa dokumenta izveide<br />
Sagatavotās komponentes tiek nodotas EVK IS administratoram, kas tās iekļauj dokumentu<br />
tipu katalogā.<br />
Dokumentu validatorus izmanto metadatu pārvaldības komponents, piemēram, jaunu<br />
dokumnetu pievienošanas laikā, skat. šī dokumenta sadaļu 6.4.3.1.<br />
6.4.2.2 Prezentācijas katalogs<br />
Prezentācijas katalogs ir daļa no EVK metadatiem, kas nodrošinās vienotu un vienādu<br />
medicīnisko ierakstu attēlošanu (transformāciju no EVK saglabātā ieraksta) HTML formātā.<br />
Tas nodrošinās iespēju definēt nepieciešamās transformācijas XSLT formātā, kā arī<br />
gadījumos, kad tas ir nepieciešams, automātiski izpildīt datu priekšapstrādi EVK pirms<br />
atbildes nosūtīšanas pieprasītājam. HTML formāta datu ģenerēšana ir aprakstīta šī<br />
dokumenta sadaļā „EVK dokumentu iegūšana”, skat. šī dokumenta sadaļu 6.4.3.3.<br />
Katram EVK medicīnisko dokumentu tipam prezentāciju katalogā tiks izveidota un saglabāta<br />
XSLT transformācija, kas nodrošinās dokumenta attēlošanu HTML formātā.<br />
6.4.3 Pamatdatu un pierakstu pārvaldība<br />
Modulis nodrošina elektronisko veselības pierakstu informācijas pārvaldību, darbības loģiku<br />
e-Veselības pierakstu uzkrāšanai un pieejamības nodrošināšanai, ņemot vērā noteiktās<br />
pieejas tiesības un pieejas politikas, kā arī nodrošinot nepieciešamo datu aizsardzības līmeni.<br />
6.4.3.1 EVK dokumentu pievienošana<br />
Tā kā jaunu dokumentu saņemšana no ārējām sistēmām un saglabāšana EVK ir pietiekoši<br />
sarežģīts un laikietilpīgs process, dokumentu pievienošana EVK tiek veikta asinhroni.<br />
Dokumentu pievienošanas metode sākotnēji veic tikai tās dokumenta pārbaudes un<br />
apstrādes darbības, kuras pēc iespējas nav atkarīgas no ārējo sistēmu izsaukumiem un kuras<br />
līdz ar to ir iespējams veikt sinhroni. Vienīgais ārējās <strong>sistēma</strong>s izsaukums ir personas datu<br />
iegūšana no PMLP IR. Tas ir nepieciešam, lai nodrošinātu datu integritāti. Savukārt tālākā<br />
pievienoto dokumentu apstrāde, kuras izpildē ir iesaistīti ārējo sistēmu izsaukumi vai<br />
laikietilpīgas darbības, tiek veikta asinhroni ar fona uzdevumu komponentes palīdzību.<br />
Asinhronie pieprasījumu tiek uzkrāti rindā, un apstrādāti sistēmā iepriekš definētā laika<br />
posmā pēc kārtas.<br />
Dokumenta pievienošanas rezultātā klientam tiek atgriezts unikāls EVK dokumenta<br />
identifikators. Lai uzzinātu, vai dokumenta pievienošana bija veiksmīga, klients vēlāk izsauc
speciālu pieprasījumu, kā parametru nododot iepriekš saņemto dokumenta identifikatoru.<br />
Pēc šī identifikatora EVK identificē un atgriež dokumenta pievienošanas statusu.<br />
EVK dokumentu pievienošana shematiski ir parādīta 10. attēlā.<br />
10. attēls. EVK dokumentu pievienošana<br />
Pievienojot jaunu dokumentu EVK, tiek veiktas sekojošas darbības:<br />
1. Tiek pārbaudītas tiesības.<br />
2. Ja dokuments ir elektroniski parakstīts, tiek pārbaudīts tā elektroniskais paraksts,<br />
izmantojot eDoc pārbaudes servisu. Kļūdas gadījumā tiek atgriezts atbilstošais kļūdas<br />
ziņojums.<br />
3. Tiek veikta dokumenta sākotnējā validācija, izmantojot atbilstošā dokumenta tipa<br />
validatoru. Validatori pārbauda tikai tās klasifikatoru vērtības, kuras ir atrodamas EVK<br />
klasifikatoru repliku glabātuvē. Ja dokumenta pārbaudei ir nepieciešams veikt tiešsaistes
pieprasījumus reģistriem, klasifikatoru izplatīšanas modulim vai citām ārējām sistēmām,<br />
šīs darbības tiek veiktas asinhroni kā daļa no fona uzdevumiem.<br />
4. Ja pacienta karte sistēmā neeksistē, tiek veikta personas datu pieprasīšana no<br />
Iedzīvotāju reģistra un izveidota jauna pacienta karte.<br />
5. Veiksmīgas validācijas rezultātā dokuments tiek saglabāts EVK dokumentu repozitorijā<br />
šifrētā veidā.<br />
6. Tiek izveidots jauns dokumentu apstrādes uzdevums un pievienots uzdevumu rindai, ko<br />
vēlāk apstrādās fona uzdevumu komponente.<br />
7. Dokumenta statuss tiek nomainīts uz „Apstrādē”. Kamēr tas atrodas šinī statusā,<br />
dokuments citām komponentēm nav pieejams, izņemot fona uzdevumu komponentu.<br />
8. Izsaucējam tiek atgriezts EVK dokumenta identifikators, izmantojot kuru, vēlāk ir<br />
iespējams uzzināt, vai dokumenta pievienošana bija veiksmīga.<br />
9. Visi dokumenta apstrādes soļi tiek reģistrēti <strong>sistēma</strong>s žurnālā, izmantojot IP <strong>sistēma</strong>s<br />
žurnāla bibliotēku.<br />
10. Kļūdas gadījumā tiek atgriezts atbilstošais kļūdas ziņojums.
6.4.3.2 EVK dokumentu tālākā apstrāde fona režīmā<br />
Fona uzdevumu komponente asinhronā režīmā veic tālāko dokumenta apstrādi, kas ir<br />
shematiski parādīta 11. attēlā.<br />
11. attēls. EVK dokumentu asinhronā apstrāde<br />
Pievienojot jaunu dokumentu EVK, tiek veiktas sekojošas darbības:<br />
1. Fona uzdevumu komponente periodiski pārbauda uzdevumu rindu un saņem jaunus<br />
dokumentu apstrādes uzdevumus.<br />
2. Dokuments tiek nolasīts un atšifrēts.<br />
3. Tiek veikta dokumenta lauku vērtību pārbaude pret reģistriem un klasifikatoriem, kuriem<br />
nav pieejama lokāla replika un ir nepieciešams veikt tiešsaistes izsaukumus.<br />
4. Izmantojot metadatu pārvaldības komponentes, dokuments tiek sadalīts sekcijās.<br />
Izmantojot konkrēto sekciju tipu adapterus, no sekcijām tiek iegūtas datu kopas, kas<br />
attiecas uz EVK pamatdatiem.<br />
5. Dokuments tiek elektroniski parakstīts, izmantojot <strong>sistēma</strong>s X.509 sertifikātu.<br />
6. Ja tas ir nepieciešams, dokuments tiek saspiests, izmantojot ZIP failu formātu.<br />
EVK veiktspējas testu laikā tiks noteikts, vai EVK dokumentus ir nepieciešams saspiest vai<br />
nē. Dokumentu saspiešana ekonomē vietu uz datu nesējiem, bet vienlaicīgi var ietekmēt
arī <strong>sistēma</strong>s ātrdarbību, papildus noslogojot <strong>sistēma</strong>s resursus. EVK medicīnas<br />
dokumenti satur XML formāta datus, kuri saspiestā veidā aizņem vidēji 8% no oriģinālā<br />
dokumenta izmēra. Tādā veidā būtiski tiek ekonomēta vieta uz datu nesējiem, samazinot<br />
EVK risinājuma kopējās izmaksas. Tā kā EVK medicīnas dokumenti tiks saspiesti<br />
asinhronā režīmā un turpmāk tie tiks pieprasīti salīdzinoši reti, EVK kopējo veiktspēju<br />
datu saspiešana būtiski neietekmēs. Tomēr, lai noteiktu reālo dokumentu saspiešanas<br />
ietekmi uz EVK ātrdarbību, vispirms ir nepieciešams veikt <strong>sistēma</strong>s veikspējas testus.<br />
7. Dokuments tiek saglabāts EVK dokumentu repozitorijā šifrētā veidā.<br />
8. Dokumenta veiksmīgas pievienošanas gadījumā dokumenta statuss tiek nomainīts uz<br />
„Aktuāls”. Kļūdas gadījumā dokumenta statuss tiek nomainīts uz „Kļūdains”, papildus<br />
atribūtā saglabājot arī atbilstošo kļūdas ziņojumu. Zinot dokumenta identifikatoru,<br />
dokumenta iesniedzējs vēlāk var noskaidrot, vai dokumenta pievienošana ir bijusi<br />
veiksmīga. Dokuments ar statusu „Kļūdains” sistēmā tiek uzglabāts noteiktu stundu<br />
skaitu, kas ir norādāms <strong>sistēma</strong>s konfigurācijā. Dokumenta iesniedzējam tas ir vai nu<br />
jāanulē vai arī tas tiks anulēts automātiski pēc noteiktā laika perioda beigām, kā<br />
rezultātā dokumenta statuss tiek nomainīts uz „Kļūdains”.<br />
9. Visi dokumenta apstrādes soļi tiek reģistrēti <strong>sistēma</strong>s žurnālā, izmantojot IP <strong>sistēma</strong>s<br />
žurnāla bibliotēku.
6.4.3.3 EVK dokumentu iegūšana<br />
EVK dokumentu iegūšana pieprasītajā formātā shematiski ir parādīta 12. attēlā.<br />
12. attēls. EVK dokumentu iegūšana<br />
Lai iegūtu EVK dokumentu pieprasītajā formātā, tiek veiktas sekojošas darbības:<br />
1. Tiek pārbaudītas tiesības.<br />
2. Ja dokuments ir pieprasīts HL7 formātā, tas tiek atšifrēts, ja nepieciešams, atspiests un<br />
atgriezts metodes izsaucējam. Tiek pārbaudīta arī dokumenta integritāte, pārbaudot tā<br />
elektronisko parakstu.<br />
3. HTML un citu formātu faili tiek ģenerēti tikai pēc vajadzības un uzglabāti kešatmiņā, lai<br />
tos nevajadzētu atkārtoti ģenerēt pie katra dokumenta pieprasījuma. Ja dokuments<br />
pieprasītajā formātā jau eksistē kešatmiņā, tas tiek atgriezts metodes izsaucējam no<br />
kešatmiņas. Ja kešatmiņā vajadzīgais formāts nav pieejams, tas tiek dinamiski<br />
uzģenerēts, izmantojot atbilstošā formāta adapteri, saglabāts kešatmiņā un atgriezts<br />
izsaucējam. Faili datu bāzē tiek uzglabāti šifrētā veidā.
4. Visi dokumenta apstrādes soļi tiek reģistrēti <strong>sistēma</strong>s žurnālā, izmantojot IP <strong>sistēma</strong>s<br />
žurnāla bibliotēku.<br />
5. Kļūdas gadījumā tiek atgriezts atbilstošais kļūdas ziņojums.<br />
6.4.4 eDoc pārbaudes serviss<br />
eDoc faila pārbaudes funkcionalitāte paredz eDoc faila formāta, tā integritātes, elektroniskā<br />
paraksta un izmantotā sertifikāta pārbaudi. Sertifikāta pārbaude notiek tiešsaistē, izmantojot<br />
OCSP klientu.<br />
eDoc pārbaudes serviss nodrošina elektronisko dokumentu iesniegšanu pārbaudei un<br />
pārbaudes rezultātu saņemšanu. Tā kā uzticamais sertifikācijas pakalpojumu sniedzējs<br />
garantē OCSP servisu pieejamību, šis eDoc pārbaudes serviss var tikt veidots kā sinhrons<br />
serviss.<br />
eDoc pārbaudes serviss nodrošinās šādas funkcijas:<br />
pārbaudes pieprasījumu saņemšanu un izpildi;<br />
atbildes sinhronu atgriešanu;<br />
pieprasījumu, atbilžu un ar drošību saistītu darbību reģistrēšanu audita žurnālā.<br />
eDoc pārbaudes servisa loģiskais plānojums shematiski ir parādīts 13. attēlā.<br />
13. attēls. eDoc pārbaudes servisa loģiskais plānojums<br />
eDoc pārbaudes serviss sastāv no vairākām komponentēm:<br />
OCSP klients nodrošina sertifikātu statusu pārbaudi, izmantojot USPS publiski<br />
pieejamo OCSP servisu;<br />
eDoc bibliotēka tiek izmantota, lai pārbaudītu eDoc dokumenta formāta pareizību un<br />
dokumenta integritāti;<br />
Audita žurnāla mērķis ir uzkrāt informāciju par veiksmīgu vai neveiksmīgu pārbaudes<br />
rezultātu un citām svarīgām lietotāju darbībām to vēlākai analīzei.
OCSP protokols nodrošina sertifikātu pārbaudi tiešsaistes režīmā. OCSP atbilžu servera<br />
informācija atspoguļo pašreizējo sertifikāta statusu ar ļoti nelielu nobīdi starp, piemēram,<br />
sertifikāta apturēšanas pieprasījuma saņemšanu un reālo sertifikāta darbības apturēšanu.<br />
OCSP atbildes tiek radītas tieši izmantojot centrālo uzticama sertifikācijas pakalpojumu<br />
sniedzēja sertifikātu datubāzi, neizmantojot CRL sarakstus vai LDAP katalogu kā starpslāņus<br />
informācijas pieejai. Līdz ar to šī ir ieteicamākā no sertifikāta statusa pārbaudes metodēm<br />
programmatūras risinājumos.<br />
Visi USPS izsniegtie sertifikāti ir jebkurā laikā pārbaudāmi ar OCSP atbilžu servera palīdzību,<br />
izmantojot OCSP informācijas apmaiņas protokolu saskaņā ar RFC 2560 standartu.<br />
OCSP pieprasījumi un atbildes tiek kodēti ASN.1 kodējumā, tāpēc bibliotēkai ir jāpiedāvā<br />
funkcijas, kas māk darboties ar ASN.1 kodējumu.<br />
OCSP klienta modulis satur vienu funkciju, kas nodrošina OCSP servera izsaukumu, nododot<br />
tam kā parametru OCSP pieprasījumu un saņemot atbildi, kas satur sertifikātu statusus.<br />
Komunikācija ar OCSP servisu notiek, izmantojot HTTP vai HTTPS protokolu.<br />
eDoc bibliotēka nodrošina visas nepieciešamās pamatdarbības ar eDoc formāta<br />
dokumentiem. Šī bibliotēka nodrošina sekojošas pamatfunkcijas:<br />
eDoc apstrāde – eDoc izveide, saglabāšana un ielāde;<br />
eDoc parakstīšana un paraksta pārbaude, izmantojot OCSP klienta bibliotēku;<br />
veidņu atbalsts – eDoc izveide, izmantojot iepriekš sagatavotu veidni;<br />
eDoc sekciju apstrāde – sekciju izveide un piekļuve to datiem;<br />
metadatu apstrāde – metadatu pievienošana, dzēšana, piekļuve to saturam;<br />
parakstāmo failu apstrāde – faila pievienošana, dzēšana, piekļuve to saturam;<br />
parakstu apstrāde – parakstu pievienošana, dzēšana, piekļuve to saturam.<br />
eDoc bibliotēka izmanto sekojošas papildus bibliotēkas:<br />
ASN.1 bibliotēka – tiek izmantoti OCSP pieprasījumu un atbilžu kodēšanai;<br />
XAdES bibliotēka – elektroniskais paraksts tiek veidots atbilstoši XAdES specifikācijai.<br />
To nodrošina XAdES bibliotēka;<br />
ZIP formāta bibliotēka – eDoc faili tiek iepakoti kā ZIP formāta faili. To nodrošina ZIP<br />
formāta bibliotēka.<br />
6.4.5 Fona uzdevumi<br />
EVK regulāri izpildāmie darbi tiek veikti kā atsevišķi veidots process (Windows serviss) fona<br />
darbu veikšanai. Fona uzdevumu apstrādes komponenti nodrošina pakešveida uzdevumu<br />
veikšanu fona režīmā, piemēram, asinhronu datu apstrādi, informācijas aktualizēšanu vai<br />
regulāru datu nodošanu citām sistēmām.
Fona uzdevumu komponenti shematiski ir parādīti 14. attēlā.<br />
14. attēls. Fona uzdevumi<br />
Fona uzdevumu modulis sastāv no sekojošiem komponentiem:<br />
uzdevumu plānotājs<br />
konfigurācijas komponents<br />
uzdevumu pārvaldība<br />
Fona uzdevumi tiek izpildīti ar iepriekš konfigurējamu regularitāti. Katram uzdevumu tipam<br />
tā izpildes regularitāte tiek uzglabāta komponenta konfigurācijas tabulā, kā arī tam ir<br />
izveidots atsevišķs adapteris, kas izpilda atbilstošo darbību loģiku. Fona uzdevumu modulis<br />
satur sekojošus uzdevumu tipus:<br />
personas datu aktualizācija<br />
jaundzimušo reģistrācija<br />
jaundzimušo datu aktualizācija<br />
ģimenes ārstu datu aktualizācija<br />
EVAK datu aktualizācija
medicīnisko dokumentu apstrāde, skat. 6.4.3 nodaļu<br />
klasifikatoru izmaiņu nolasīšana un publicēšana<br />
nosūtīt pacientiem atgādinājumus par vakcinācijas veikšanu<br />
Uzdevumu plānotājs ir atbildīgs par uzdevumu izpildes plānošanu un kontroli. Uzdevumu<br />
izpilde var tikt uzsākta divos veidos, atkarībā no uzdevumu tipa:<br />
saņemot jaunu uzdevumu rindā, piemēram, <strong>sistēma</strong>i saņemot jaunu medicīnisko<br />
dokumentu, kuram ir nepieciešama asinhrona apstrāde<br />
pēc iepriekš konfigurējamas uzdevuma izpildes regularitātes, piemēram, reizi dienā<br />
ārpus darba stundām sinhronizējot jaundzimušo datus<br />
Uzdevumu plānotājs tiek darbināts kā atsevišķs process. Tas veic sekojošas darbības:<br />
1. Uzdevumu plānotāja startēšanas laikā tas nolasa konfigurācijas informāciju, kas satur<br />
sarakstu ar uzdevumu adapteriem un to izpildes regularitāti, un saglabā šo<br />
informāciju operatīvajā atmiņā. Mainoties fona uzdevumu konfigurācijai, uzdevumu<br />
plānotājs ir jāpārstartē.<br />
2. Periodiski nolasa datus no uzdevumu rindas un uzsāk to apstrādi.<br />
3. Uzsāk jaunus uzdevumus atbilstoši katra uzdevuma tipa izpildes regularitātei.<br />
4. Katram nolasītajam uzdevumam tiek izsaukts atbilstošais uzdevuma adapteris, kā<br />
parametrus tam nododot katram uzdevuma tipam specifiskos papildus datus,<br />
piemēram, medicīniskā dokumenta identifikatoru, kuram ir nepieciešama apstrāde.<br />
5. Visi fona uzdevumu apstrādes soļi tiek reģistrēti <strong>sistēma</strong>s žurnālā, izmantojot IP<br />
<strong>sistēma</strong>s žurnāla bibliotēku.<br />
Konfigurācijas komponents ir atbildīgs par konkrēto uzdevumu adapteru konfigurācijas ielādi<br />
un to pārbaudi.<br />
Uzdevumu pārvaldība satur pašus uzdevumu adapterus, kas atkarībā no uzdevuma tipa<br />
izpilda nepieciešamo darbību secību.<br />
6.4.5.1 Personas datu aktualizācija<br />
Personas datu aktualizācijas moduli izmantos fona uzdevumu modulis periodiskai personas<br />
datu aktualizēšanai. Personas dati tiks ņemti no PMLP IR, izmantojot IP publicētās tīmekļa<br />
saskarnes integrācijai ar PMLP IR. Datu saņemšana tiks veikta, norādot personas kodu, kā<br />
rezultātā tiks aktualizēti personas personificēto un nepersonificēto datu ieraksti.<br />
PMLP IR nodrošina nepieciešamās saskarnes sākotnējo personas datu un vēlāko personas<br />
datu izmaiņu saņemšanai.
6.4.5.2 Jaundzimušo datu aktualizācija<br />
Jaundzimušo datu aktualizācijas moduli izmantos fona uzdevumu modulis personas koda<br />
atjaunošanai pacienta kartē jaundzimušajiem, kuriem EVK nav aizpildīts personas kods.<br />
Jaundzimušo dati tiks ņemti no Jaundzimušo reģistra, izmantojot IP publicētās tīmekļa<br />
saskarnes integrācijai ar Jaundzimušo reģistru. Datu saņemšana tiks veikta, norādot mātes<br />
personas kodu un bērna dzimšanas datumu un laiku.<br />
6.4.5.3 Ģimenes ārstu datu aktualizācija<br />
Ģimenes ārstu datu aktualizācijas moduli izmantos fona uzdevumu modulis periodiskai<br />
ģimenes ārstu datu aktualizēšanai. Dati tiks ņemti no VNC VIS, izmantojot IP publicētās<br />
tīmekļa saskarnes integrācijai ar VNC VIS.<br />
Pacienta kartē tiks aktualizēti sekojoši ģimenes ārsta atribūti:<br />
ģimenes ārsts<br />
specialitāte<br />
ārstniecības iestāde<br />
līguma spēkā no datums<br />
6.4.5.4 EVAK datu aktualizācija<br />
EVAK datu aktualizācijas moduli izmantos fona uzdevumu modulis periodiskai EVAK datu<br />
aktualizēšanai. Dati tiks ņemti no VNC VIS, izmantojot IP publicētās tīmekļa saskarnes<br />
integrācijai ar VNC VIS.<br />
Pacienta kartē tiks aktualizēti sekojoši EVAK atribūti:<br />
EVAK kartes numurs<br />
tips<br />
izdevējiestāde<br />
izsniegšanas datums<br />
spēkā no<br />
spēkā līdz<br />
statuss<br />
6.4.6 Vakcināciju modulis<br />
Vakcināciju modulis nodrošinās ar vakcināciju saistīto medicīnisko dokumentu glabāšanu EVK<br />
dokumentu repozitorijā HL7 CDA dokumentu veidā. Šiem dokumentiem tiks izveidoti jauni<br />
EVK ierakstu tipi, līdz ar to vakcināciju reģistra dati būs apakškopa no EVK dokumentu<br />
repozitorija datiem.<br />
Tiks nodrošināta:
ar EVK kopīgās personas pamatdatu bāzes izmantošana;<br />
pieejas tiesību pārbaude personificētiem datiem;<br />
personificēto datu drošība, to lasīšanas un rakstīšanas audits;<br />
iespēja lasīt nepersonificētus datus pārskatu un analīzes vajadzībām, bez personas<br />
datu pieejas tiesību pārbaudes un audita;<br />
meklēšanas un atlases iespējas datiem.<br />
Personas dati tiks saistīti ar šifrētām abpusējām atslēgām ar vakcināciju reģistra ierakstu.<br />
Tikai atšifrējot atslēgu, pēc tās varēs meklēt personificētu vakcināciju reģistra ierakstus.<br />
Vakcinācijas reģistra datu bāze tiks būvēta kā relāciju datu bāze, kas ļauj datus ātri un<br />
vienkārši meklēt un analizēt. Nākotnē repozitorijā būs iespējams saglabāt elektroniski<br />
parakstītus potēšanas faktu apstiprinošus dokumentus. Pārējiem vakcināciju moduļa<br />
strukturētajiem datiem, kam netiks definēti jauni EVK ierakstu tipi, dati tiks uzglabāti relāciju<br />
datu bāzē.<br />
Tiks nodrošināta iespēja veidot dažādas atskaites gan par paveikto profilakses darbu, gan arī<br />
plānot vakcināciju apjomus nākamajos periodos.<br />
Lietotājiem <strong>sistēma</strong> būs pieejama, izmantojot e-Veselības portālu. Vakcināciju moduļa<br />
funkcionalitāte tiks publicēta EVK tīmekļa saskarņu veidā, kas ārējām sistēmām būs<br />
pieejama, izmantojot integrācijas platformu. Šos servisus varēs izmantot ārstniecības iestāžu<br />
iekšējās informācijas <strong>sistēma</strong>s. Piekļuve klasifikatoru informācijai tiks nodrošināta,<br />
izmantojot klasifikatoru moduļa ārējās saskarnes. Vakcinācijas reģistrs būs lietojams<br />
sekojošām lietotāju grupām:<br />
pacients varēs apskatīt sev veiktās un nākotnē plānotās vakcinācijas;<br />
ārstniecības personāls varēs aplūkot vakcinēšanas faktus, reģistrēt jaunus<br />
vakcinēšanas faktus, kā arī pievienot piezīmes, reģistrēt plānotās vakcinēšanas;<br />
ārstniecības iestādes administrācija varēs iegūt pārskatus par iestādes veiktajiem<br />
vakcinācijas pasākumiem, iegūt pārskatus par plānotajiem vakcinēšanas<br />
pasākumiem (ĢĀ praksē par saviem pacientiem).<br />
Vakcinācijas reģistram tiks uzturēti vairāki klasifikatori, tai skaitā vakcinācijas veidu un<br />
algoritmu klasifikators. Klasifikatorā tiks definēti kritēriji, pēc kuriem personai automātiski<br />
ģenerējamas nepieciešamās plānotās vakcinācijas. Tās tiek noteiktas, izmantojot pacienta<br />
vecumu, dzimumu, ilgumu kopš iepriekšējās vakcinācijas, revakcinācijas reizi u.c.<br />
Izmantojot fona uzdevumu komponenti, pacientiem tiks sūtīti atgādinājumi par vakcinācijas<br />
veikšanu.<br />
Pacientiem tiks sūtīti atgādinājumi par vakcinācijas veikšanu, izmantojot fona uzdevumu<br />
moduli.
6.4.7 Klasifikatoru uzturēšanas modulis<br />
EVK darbam (pārsvarā ievietotās informācijas pārbaudei) nepieciešami klasifikatori no citām<br />
e-Veselības vides informācijas sistēmām. Tāpat EVK nodrošinās savu klasifikatoru informāciju<br />
priekš citām sistēmām.<br />
Klasifikatori ir paredzēti dažādu EVK moduļu, piemēram, vakcināciju reģistra un EVK<br />
pamatdatu vērtību klasifikācijai. Piemēram, klasifikatori var būt: ārsti, ārstniecības iestādes,<br />
specialitātes, līgumi, dokumentu veidi u.c. Klasifikatoru uzturēšanas modulis nodrošinās<br />
klasifikatoru un to versiju uzturēšanu. Klasifikatori tiek glabāti relāciju datu bāzes tabulu<br />
veidā, nodrošinot datu integritātes kontroli.<br />
Klasifikatoru vērtības tiek aizpildītas, tās kopējot vai importējot no IP. Šādu klasifikatoru<br />
ieraksti EVK līmenī nebūs rediģējami. To varēs darīt klasifikatoru turētāju IS, publicējot<br />
jaunas klasifikatoru versijas IP.<br />
Klasifikatoru modulis nodrošinās klasifikatoru validācijas funkcionalitāti (piemēram EVK IS<br />
pirms jauna dokumenta saglabāšanas validēs tā saturu). Klasifikatoru validācijas mehānisms,<br />
pārbaudīs, vai klasifikators tiek uzturēts relāciju veidā, tad validācijai jānotiek klasifikatoru<br />
moduļa līmenī, pretējā gadījumā tiek izmantota IP klasifikatoru validācijas funkcionalitāte.<br />
Klasifikatoru modulis nodrošinās uzturamo klasifikatoru vērtību saņemšanu, savukārt citu –<br />
neuzturamo jeb klasifikatoru, kas netiek izmantoti EVK pamatdatos un vakcināciju reģistrā,<br />
vērtību saņemšana, tiks nodrošināta, izmantojot IP funkcionalitāti.<br />
Klasifikatoru modulis nodrošinās klasifikatoru versiju uzturēšanu, izmantojot klasifikatoru<br />
izmaiņu informāciju no IP izmaiņu apziņošanas servisa.<br />
Klasifikatoru moduļa darbināšanai tiks izmantots klasifikatoru repozitorijs, kas uztur visu<br />
izmantojamo klasifikatoru meta informāciju.<br />
Ar EVK klasifikatoru moduli tiks nodrošinātas šādas pamatfunkcijas:<br />
klasifikatoru importēšana no IP un to glabāšana relāciju veidā;<br />
uzturamo un citu klasifikatoru vērtību saņemšana, izmantojot IP klasifikatoru<br />
izplatīšanas servisu;<br />
uzturamo klasifikatoru vērtību saņemšana klasifikatoru moduļa līmenī;<br />
uzturamo un citu klasifikatoru validācija, izmantojot IP klasifikatoru validācijas<br />
servisu;<br />
uzturamo klasifikatoru validācija klasifikatoru moduļa līmenī;<br />
uzturamo klasifikatoru versiju uzturēšana relāciju veidā.<br />
Klasifikatoru uzturēšanas modulis tiks veidots kā fona uzdevumu moduļa adapteris, skat.<br />
6.4.4 nodaļu.
6.4.8 Auditācija un <strong>sistēma</strong>s žurnāls<br />
Auditācijas mērķis ir uzkrāt informāciju par veiksmīgu vai neveiksmīgu piekļuvi <strong>sistēma</strong>s<br />
objektiem, privilēģiju lietošanu un citām svarīgām lietotāju darbībām tās vēlākai analīzei.<br />
Auditācijas žurnāls ir domāts, piemēram, izmeklētājiem, lai veiktu lietotāju darbību analīzi.<br />
Sistēmas žurnāls ir domāts <strong>sistēma</strong>s administratoriem un izstrādātājiem, lai dotu iespēju<br />
noteikt <strong>sistēma</strong>s kļūdu cēloņus un noteiktu <strong>sistēma</strong>s komponenšu stāvokli.<br />
IP nodrošinās centrālo auditācijas servisu un speciālas bibliotēkas visām E-veselības<br />
centrālajām sistēmām, kas nodrošinās gan <strong>sistēma</strong>s žurnāla, gan auditācijas žurnāla<br />
funkcionalitāti. Auditācijas pierakstu un <strong>sistēma</strong>s žurnāla pierakstu veidošanas process ir<br />
līdzīgs, atšķiras tikai aizpildāmie atribūti un mērķa datu bāze.<br />
Sistēmas žurnāla serviss atbalsta vairākus žurnalēšanas līmeņus, kas nosaka, kāda veida<br />
ziņojumi tiek rakstīti žurnālā. Žurnalēšanas līmenis tiek noteikts <strong>sistēma</strong>s konfigurācijas failā.<br />
Sistēmas izstrādes un atkļūdošanas laikā tiks lietots žurnalēšanas līmenis, kura rezultātā<br />
<strong>sistēma</strong>s žurnālā tiek rakstīts maksimāli daudz informācijas. Normālas <strong>sistēma</strong>s darbības<br />
laikā tiks lietots līmenis, kurš maksimālu atslogotu sistēmu no žurnālu rakstīšanas.<br />
6.4.9 Administrēšanas modulis<br />
Administrēšanas modulis ir programmu komplekts, ar kuru palīdzību administratīvie lietotāji<br />
administrē sistēmu un veic tās uzraudzību. Tas tiek veidots ar mērķi nodrošināt vienotu<br />
administratora darba vietu, kura dos iespēju veikt ar <strong>sistēma</strong>s administrēšanu saistītos<br />
uzdevumus. Administratora darba vietā netiks realizēta funkcionalitāte uzdevumiem, kuru<br />
realizācija tiek nodrošināta ar piegādātās infrastruktūras standarta administrēšanas rīkiem,<br />
vai trešās puses administrēšanas rīkiem, piem., Windows Server 2008 R2 Server Manager<br />
konsoli vai Microsoft SQL 2008 Server Management Studio, piemēram, Windows Server<br />
2008 R2 standarta administrēšanas uzdevumi tiks veikti ar Remote Server Administration<br />
Tools palīdzību.<br />
Infrastruktūras komponentu (DNS, IP adreses, klasteru konfigurēšana) administrēšanai<br />
lietotāji varēs attālināti pieslēgties <strong>sistēma</strong>i, izmantojot Remote Desktop Protocol, un veikt<br />
infrastruktūras izmaiņas, izmantojot Windows Server, SQL Server un citu trešo pušu<br />
komponentu standarta administrēšanas rīkus.<br />
Administratora funkcijām, kuras nav iespējams veikt ar standarta administrēšanas rīkiem,<br />
tiks izstrādāta administratora darba vietas saskarne kā Web lietojums. Piekļuvi <strong>sistēma</strong>s<br />
administratora funkcionalitātei nodrošinās Integrācijas platforma.<br />
EVK administratora darba vieta nodrošinās sekojošas galvenās funkcijas:<br />
klasifikatoru administrēšana;<br />
o<br />
o<br />
o<br />
o<br />
klasifikatoru saraksta attēlošana;<br />
jauna klasifikatora reģistrēšana replicēšanai no IP;<br />
klasifikatora konfigurēšana;<br />
klasifikatora versiju saraksta attēlošana;
atļauju administrēšana;<br />
o<br />
o<br />
o<br />
atļauju saraksta attēlošana;<br />
atļauju pievienošana;<br />
atļauju labošana;<br />
dokumentu veidņu administrēšana;<br />
o<br />
o<br />
dokumentu veidņu saraksta attēlošana;<br />
dokumentu veidņu pievienošana un labošana;<br />
pilngadības pazīmes uzstādīšana;<br />
personas datu aktualizēšana;<br />
vakcinācijas kalendāra administrēšana;<br />
o<br />
o<br />
iegūt vakcinācijas kalendāru;<br />
reģistrēt un labot vakcinācijas kalendāru;<br />
fona uzdevumu administrēšana;<br />
o<br />
o<br />
konfigurēt fona uzdevumu adapterus;<br />
konfigurēt fona uzdevumu adapteru izpildes biežumu un laikus.<br />
Administrēšanas moduļa realizētā funkcionalitāte tiks ierobežota, ņemot vērā lietotājam<br />
piešķirtās tiesības. Administratora moduļa uzbūve dos iespēju ierobežot administrēšanas<br />
Web lietojuma pieejamību no viena vai vairākiem IPv4 vai IPv6 adrešu apgabaliem.<br />
6.4.10 IP apziņošanas serviss<br />
IP nodrošina apziņošanas (jeb notifikāciju) servisu, kurš paredzēts personu un/vai iestāžu<br />
apziņošanai. Sākotnēji IP nodrošinās tikai SMTP apziņošanas metodi. Apziņošanas serviss<br />
eksponē tīmekļa pakalpes ar sekojošām metodēm:<br />
nosūtīt ziņojumu –nosūta ziņojumu, izmantojot norādīto ziņojumu sūtīšanas kanālu.<br />
Ziņojumu veidošana notiek, izmantojot saņemto XML un atbilstošo XSL<br />
transformāciju;<br />
manis sūtītie ziņojumi - atgriež ziņojuma sūtītāja sūtītos ziņojumus, par norādīto<br />
laika periodu un/vai grupas kodu;<br />
man sūtītie ziņojumi –atgriež ziņojuma sūtītāja sūtītos ziņojumus, par norādīto laika<br />
periodu un/vai grupas kodu.<br />
6.4.11 e-Pakalpojumi<br />
e-Veselības portāls ir pacienta primārais piekļuves kanāls e-Veselības e-Pakalpojumiem, tai<br />
skaitā EVK e-Pakalpojumiem.
e-Veselības portāls nodrošinās centralizēti uzturēto e-Veselības vides pakalpojumu<br />
pieejamību plašam lietotāju lokam, izmantojot pēc iespējas visiem plaši pieejamu tīmekļa<br />
pārlūkprogrammās darbināmu lietotāju saskarni. Lielākā daļa EVK e-Pakalpojumu tiks<br />
izvietoti e-Veselības portālā. e-Pakalpojumu saraksts tiks uzturēts arī Latvijas e-Pakalpojumu<br />
vidē www.latvija.lv, kas nodrošinās plašam lietotāju lokam alternatīvu iespēju atrast<br />
vajadzīgo e-Pakalpojumu un uzsākt pakalpojuma izpildi bez atkārtotas autentifikācijas. Pašu<br />
e-Pakalpojumu izpilde tiks nodrošināta Portāla vidē. Daļa no pacientiem paredzētajiem<br />
e-Pakalpojumiem tiks izvietoti primāri www.latvija.lv vidē, izmantojot www.latvija.lv portāla<br />
un VISS komponentus.<br />
e-Veselības portāla darba vietu un e-Pakalpojumu komponenti nodrošina lietotāju interfeisa<br />
prezentācijas līmeni, kur lietotāju funkcionalitāte ir sadalīta pa lietotāju darba vietām. Darba<br />
vietu un e-Pakalpojumu komponenti nodrošina tikai informācijas attēlošanu lietotājiem.<br />
Lietotāju interfeisa loģika un e-Veselības specifiskā funkcionalitāte tiek nodrošināta Portāla<br />
funkcionālajos moduļos un atbilstošajās e-Veselības informācijas sistēmās, piemēram, EVK.<br />
e-Veselības portāla funkcionalitāte ir sagrupēta darba vietās atbilstoši lietotāju grupām,<br />
piemēram, ārsta darba vieta apkopos ārstiem pieejamo EVK funkcionalitāti.<br />
Tie e-Pakalpojumi, kas tiks izvietoti www.latvija.lv pakalpojumu izvietošanas vidē, lietotāju<br />
autentificēšanai, darbību auditēšanai, darba plūsmu nodrošināšanai un sadarbībai ar citām<br />
sistēmām izmanto www.latvija.lv un VISS komponentus.<br />
Detalizētāk e-Veselības portāls un e-Pakalpojumu ir aprakstīti portāla tehniskās arhitektūras<br />
dokumentā, skat. [6].<br />
6.4.12 Datu noliktavas integrācijas modulis (nākotnes prasība)<br />
Datu noliktavas integrācijas modulis nākotnē nodrošinās EVK datu attīrīšanu<br />
(konsolidēšanu), depersonalizēšanu, izmantojot vienotu e-Veselības vidē izmantotu<br />
algoritmu, un depersonalizētās informācijas izlādēšanu nozares datu noliktavas vajadzībām.<br />
6.4.13 epSOS saskarne (nākotnes prasība)<br />
epSOS saskarne nākotnē nodrošinās datu apmaiņu ar epSOS projektā iesaistītajām<br />
e-veselības sistēmām. epSOS arhitektūra ir balstīta uz SOA principiem un paredz epSOS<br />
saskarnei izmantot SOAP tīmekļa pakalpes. epSOS saskarne tiks veidota atbilstoši epSOS<br />
projektā definētajai arhitektūrai un epSOS saskarnes specifikācijai, kas paredz katrai valstij<br />
izveidot īpašus nacionālos adapterus, kas spēs konvertēt konkrētās valsts specifiskos<br />
e-veselības protokolus un datu formātus atbilstoši epSOS specifikācijām. Tiks izveidots īpašs<br />
EVK epSOS adapteris, kurš būs atbildīgs par datu formātu un protokolu konvertēšanu.
7 Fiziskā arhitektūra<br />
Šajā nodaļā sniegts īss apskats par loģisko komponentu izvietošanas variantiem, kurus<br />
nodrošina izmantotie arhitektūras risinājumi.<br />
Detalizēts infrastruktūras apraksts, nepieciešamie infrastruktūras elementi, datu apjoma,<br />
transakciju skaita un sagaidāmās ātrdarbības novērtējumi, kā arī rekomendētie risinājumi<br />
augstas pieejamības nodrošināšanai ir aprakstīti Infrastruktūras prasību dokumentā, skat.<br />
[2].<br />
EVK <strong>sistēma</strong>s loģiskie komponenti tiks izvietoti uz risinājuma infrastruktūras serveriem<br />
atbilstoši 15. attēlā redzamajai shēmai.<br />
15. attēls. EVK loģisko komponentu izvietojums uz serveriem<br />
7.1 EVK tīmekļa pakalpes<br />
EVK tīmekļa pakalpes tiks izvietotas uz <strong>sistēma</strong>s aplikāciju serveriem APP1 un APP2.<br />
Uz šiem serveriem tiks darbināti:<br />
slodzes dalīšanas komponents, kas ir Internet Information Services Application<br />
Request Routing;<br />
EVK tīmekļa pakalpes, kas veidotas, izmantojot Windows Communication<br />
Foundation un tiek darbinātas Windows Server AppFabric aplikāciju serverī.
Sistēmas slodzes dalīšanas nolūkos visi izsaukumi uz Sistēmas tīmekļa pakalpēm tiks nosūtīti<br />
uz vienu no vairākām Sistēmas tīmekļa pakalpju izvietošanas vidēm. EVK slodzi pa vairākiem<br />
fiziskiem resursiem sadala slodzes dalītāji, kuri veidoti, izmantojot Windows Server Internet<br />
Information Services Application Request Routing komponenti.<br />
Sistēmas tīmekļa pakalpes veiks pieprasīto darbību pa tiešo sazinoties ar Sistēmas datu<br />
bāzēm vai arī, izsaucot fona uzdevumu izpildes komponentes.<br />
7.2 Fona uzdevumi<br />
Fona uzdevumu apstrādes komponenti un to adapteri tiks izvietoti uz fona uzdevumu<br />
veikšanas servera FON.<br />
Fona uzdevumu apstrādes komponenti tiks veidoti Microsoft .NET vidē kā Windows servisi.<br />
Fona uzdevumu izpildes komponente koordinēs pakešveida uzdevumu izpildes gaitu, veiks to<br />
ietvaros nepieciešamās darbības un sazināsies ar ārējām sistēmām, izmantojot IP. Lai veiktu<br />
tādus uzdevumus kā <strong>sistēma</strong>s ierakstu auditēšana vai, piemēram, datu sinhronizēšanu ar<br />
Iedzīvotāju reģistru vai klasifikatoru izplatīšanas moduli noteiktos laika brīžos, tiks izmantoti<br />
fona uzdevumu izpildes komponenti, kuri darbosies neatkarīgi no biznesa servisu līmeņa<br />
tīmekļa pakalpju izsaukumiem. Šis komponents piekļūs <strong>sistēma</strong>s datu bāzēm un ārējām<br />
sistēmām. Risinājuma fona apstrādes uzdevumi tiks veidoti, izmantojot Windows servisus,<br />
kuros darbojas speciāli veidota fona uzdevumu apstrādes komponente.<br />
7.3 Validatori<br />
Validatori tiks izvietoti uz validācijas serveriem VAL1 un VAL2. Validatori tiek izdalīti uz<br />
atsevišķiem serveriem, jo tie izmantos Java un GlassFish komponentus, bet uz pārējiem<br />
risinājuma serveriem tiks izmantotas Microsoft .NET tehnoloģijas.<br />
Uz šiem serveriem tiks darbināti:<br />
slodzes dalīšanas komponents, kas ir Internet Information Services Application<br />
Request Routing;<br />
medicīnas dokumentu validācijas rīki, kas validēs EVK dokumentus atbilstoši iepriekš<br />
definētajam datu modelim. Tie tiks veidoti kā GlassFish tīmekļa saskarnes, kas<br />
izmantos medicīnas dokumentu validācijas Java bibliotēkas.<br />
7.4 Datu bāzes<br />
Sistēmas datu bāzes tiks izvietotas uz datu bāzes servera DB. Uz šī servera tiks darbinātas<br />
Microsoft SQL Server DBVS un pārskatu izveides komponenti.<br />
Sistēmas datu bāzes nodrošinās Sistēmas relāciju datu un XML dokumentu uzglabāšanu un<br />
nodrošinās, ka visas datu izmaiņas notiks loģiskā transakcijā.
Lai uzlabotu Sistēmas veiktspēju EVK dati tiks dalīti vairākās loģiskās grupās, kas tiks<br />
uzglabātas uz dažādiem lōgiskajiem sējumiem.<br />
7.5 Infrastruktūras serveri<br />
Uz infrastruktūras serveriem AD1 un AD2 tiks darbināti:<br />
Windows Active Directory Domain Services;<br />
DNS serviss;<br />
RDP serviss, lai nodrošinātu attālinātu pieslēgšanos;<br />
<strong>sistēma</strong>s infrastruktūras administrēšanas standarta komponenti.<br />
Visas Sistēmas komponentes darbosies slodzes dalīšanas režīmā, lai nodrošinātu:<br />
slodzes dalīšanu starp vairākiem fiziskiem resursiem;<br />
<strong>sistēma</strong>s darba turpināšanu gadījumā, ja viens no resursiem nav pieejams;<br />
<strong>sistēma</strong>s versiju izmaiņu veikšanu, neapturot Sistēmas darbu.<br />
EVK lietojumi tiks darbināti Microsoft Windows Server 2008 R2 operētājsistēmā, Internet<br />
Information Services lietojumu serverī. Pašas komponentes veidotas, izmantojot .NET<br />
Framework. EVK datu bāzes tiks darbinātas, izmantojot Microsoft SQL Server DBVS.
8 Pārvaldības arhitektūra<br />
Šajā nodaļā sniegta informācija par arhitektūras elementiem, kas ir izveidoti <strong>sistēma</strong>s<br />
uzturēšanas atvieglošanai.<br />
8.1 Pārraudzība<br />
Ņemot vērā visai lielo risinājumā izmantoto fizisko un programmatūras komponentu skaitu,<br />
efektīvai pārvaldībai ir būtiski, lai problēmu ziņojumi par fiziskiem bojājumiem, resursu<br />
trūkumu vai programmatūras kļūmēm nonāk vienotā administratora centrālē.<br />
Izmantojot IP <strong>sistēma</strong>s žurnāla bibliotēku, visi <strong>sistēma</strong>s komponenti veic kļūdu informācijas<br />
trasēšanu IP <strong>sistēma</strong>s žurnāla datu bāzēs, kas nodrošina centralizētu kļūdu notikumu<br />
monitoringu un apstrādi.<br />
Papildus tam EVK komponentiem tiks izstrādāti veiktspējas rādītāji (performance counters),<br />
kas nodrošina <strong>sistēma</strong>s veikspējas rādītāju monitoringu. Tas ļauj identificēt situācijas, kad<br />
kāda no komponentēm ir pilnībā pārtraukusi darboties vai arī ģenerē nesamērīgi lielu<br />
transakciju skaitu, kas varētu liecināt, piemēram, par nesankcionētas ielaušanās gadījumu.<br />
Veiktspējas rādītāji tiks izstrādāti interfeisiem ar ārējām sistēmām, piemēram, lai mērītu<br />
ienākošo medicīnas dokumentu skaitu, kā arī fona uzdevumu komponentam.<br />
Sistēmas ieviešanas laikā VEC ir ieteicams nokonfigurēt monitoringa sistēmu darbam ar IP<br />
<strong>sistēma</strong>s žurnāla datu bāzi un veiktspējas rādītājiem. Šāda konfigurēšana ir ārpus šī projekta<br />
sfēras.<br />
8.2 Administrēšanas mehānismi<br />
EVK administrēšanas modulis nodrošinās <strong>sistēma</strong>s administrēšanai nepieciešamo<br />
funkcionalitāti. Administrēšanas modulis detalizētāk ir aprakstīts šī dokumenta sadaļā 6.4.9.<br />
8.3 Rezerves kopēšana un atjaunošana<br />
EVK nodrošinās iespēju veikt <strong>sistēma</strong>s rezerves kopēšanu un konsistentas kopijas iegūšanu<br />
bez <strong>sistēma</strong>s darba apturēšanas, jo visi <strong>sistēma</strong>s dati tiks glabāti centralizēti EVK datu bāzē.<br />
Microsoft SQL Server DBVS nodrošina datu rezerves kopiju veikšanu, neapturot <strong>sistēma</strong>s<br />
darbības ar datu bāzi. Rezerves kopēšanas laikā lielākā daļa operāciju, kā piemēram, INSERT,<br />
UPDATE un DELETE, ir atļautas.<br />
Ja <strong>sistēma</strong>s rezerves kopēšanai būs nepieciešama EVK un/vai infrastruktūras komponenšu<br />
darbināšana speciālā režīmā, tad šāda speciāla režīma ieslēgšana/izslēgšana tiks nodrošināta<br />
ar komandrindas interfeisa palīdzību.<br />
Sistēmas rezerves kopēšana ir daļa no EVK administrēšanas iespējām.<br />
8.4 Jauninājumu instalēšana<br />
Pateicoties tam, ka <strong>sistēma</strong>s komponenti darbojas vienlaicīgi uz vairākiem serveriem,<br />
jauninājumu instalēšanu daudzos gadījumos būs iespējams veikt bez <strong>sistēma</strong>s darbības<br />
apturēšanas.<br />
Jauninājumu instalēšanas pieeja būs atkarīga no komponenta tipa:
Komponentiem, kuru vairākas instances strādā vienlaicīgi (slodzes dalītājs, tīmekļa<br />
pakalpes, web saskarnes komponenti, Active Directory), instalēšanas secība ir šāda:<br />
o<br />
o<br />
o<br />
o<br />
no Network Load Balancing (NLB) vai slodzes dalītāja klastera tiek izņemtas<br />
atbilstošās instances (Active Directory tas nav nepieciešams);<br />
tiek instalētas jaunākas versijas;<br />
pēc tam šīs instances tiek pievienotas atpakaļ NLB vai slodzes dalīšanas<br />
klasterim;<br />
pēc tam šī pati darbība tiek veikta ar citām instancēm;<br />
Datu bāžu struktūras izmaiņām pieeja ir tāda, ka strādājošā datu bāzē tiek veiktas<br />
izmaiņas, saglabājot struktūras atpakaļsavietojamību, t.i., darbojas gan komponenti,<br />
kas veidoti iepriekšējai DB versijai, gan jaunie;<br />
Fona komponentu izmaiņas tiek veiktas, apturot fona komponentus, veicot jaunās<br />
versijas instalēšanu un pēc tam palaižot fona komponentus (fona komponentiem<br />
klienti nepiekļūst pa tiešo – tāpēc šinī gadījumā nerodas pieejamības problēmas).<br />
Veicot jauninājumu ieviešanas plānošanu, jāņem vērā, ka gadījumos, kad vienas versijas<br />
komponenti nevar darboties ar otras versijas komponentiem vienlaicīgi (būtisku izmaiņu<br />
gadījumā), tad plānota <strong>sistēma</strong>s darba apturēšana tomēr ir nepieciešama. Visriskantākās<br />
izmaiņas šajā nozīmē ir saistītas ar platformas sistēmu izmaiņām, piemēram, jauna SQL<br />
Server versija vai Windows Server versija.<br />
Jauninājumu ātrākai ieviešanai arī ieteicams ieviest papildu automatizētās jauninājumu<br />
instalēšanas rīkus, piemēram, Windows Server Update Services (WSUS) servisu Windows<br />
serveru jauninājumu instalēšanai. Šādu rīku ieviešana ir ārpus šī projekta sfēras.
9 Arhitektūras skatu nepretrunīgums<br />
Šajā nodaļā aprakstīta arhitektūras skatu nepretrunīguma analīze, kā arī identificētas visas<br />
zināmās arhitektūras skatu neatbilstības.<br />
Arhitektūras skatu nepretrunīgums tiek panākts, arhitektūras izstrādes laikā pieturoties<br />
sekojošiem principiem:<br />
Fokusējoties uz arhitektūras skatu nepretrunīgumu no paša sākuma<br />
Sistēmas arhitektūra tiek izstrādāta pakāpeniski, sākot ar augsta līmeņa<br />
diagrammām un tālāk tās detalizējot, radot jaunas detalizētākas diagrammas. Ja kaut<br />
kas tiek mainīts zemāka līmeņa diagrammās, vienmēr tiek pārbaudītas saistītās<br />
augsta līmeņa diagrammas un veiktas nepieciešamās izmaiņas.<br />
Katram arhitektūras elementam piešķirot precīzu nosaukumu un konsekventi to<br />
izmantojot visā arhitektūras dokumentā<br />
Iekļaujot arhitektūras skatu nepretrunīguma pārbaudi kā formālu dokumenta<br />
caurskates sastāvdaļu
Pielikums. EVK funkcionālais sadalījums pa moduļiem<br />
Tabulā zemāk ir norādītas EVK funkcionālā sadalījuma pa moduļiem atšķirības salīdzinājumā ar tehnisko piedāvājumu.<br />
Atbilstoši tehniskajam piedāvājumam Atbilstoši tehniskās arhitektūras aprakstam Komentāri<br />
1. Pamatdatu un pierakstu pārvaldība 1. Pamatdatu un pierakstu pārvaldība -<br />
2. Pieejas atļauju pārvaldība 2. Autorizācijas modulis Mainīts nosaukums, jo pieejas atļaujas ir tikai viena daļa no autorizācijas<br />
funkcionalitātes<br />
3. Meta datu un prezentācijas pārvaldības<br />
modulis<br />
3. Metadatu pārvaldība Mainīts nosaukums uz īsāku un saprotamāku<br />
4. Administrēšanas modulis 4. Administrēšanas modulis -<br />
5. Personas datu audita modulis 5. Auditācija un <strong>sistēma</strong>s žurnāls Apvienoti, jo no IP viedokļa personas datu audits un funkciju auditācija<br />
6. Funkciju auditācija (žurnalēšana)<br />
neatšķiras.<br />
7. e-Pakalpojumi 6. e-Pakalpojumi Apvienoti, jo no arhitektūras viedokļa ārsta un pacienta darba vieta ir e-<br />
8. Ārsta darba vieta<br />
pakalpojumu apakškopa<br />
9. Pacienta darba vieta<br />
10. Sadarbība ar epSOS 7. epSOS saskarne Mainīts nosaukums, jo pēc būtības tā ir saskarne, ko piedāvājam priekš epSOS<br />
11. Vakcināciju reģistrs 8. Vakcināciju modulis Mainīts nosaukums<br />
12. Autonomo procesu modulis 9. Fona uzdevumi Mainīts nosaukums uz saprotamāku<br />
13. Klasifikatoru un terminoloģijas pārvaldības<br />
10. Klasifikatoru uzturēšanas modulis Mainīts nosaukums uz īsāku un saprotamāku<br />
modulis<br />
11. eDoc pārbaudes serviss Arhitektūras dokuments satur papildus detalizāciju<br />
12. IP apziņošanas serviss Arhitektūras dokuments satur papildus detalizāciju<br />
13. Datu noliktavas integrācijas modulis<br />
Nākotnes prasība<br />
(nākotnes prasība)
Pielikums. Tehniskās prasības<br />
Šajā nodaļā ir aprakstīti tehnisko prasību risinājumi, kas attiecas uz EVK <strong>sistēma</strong>s arhitektūru.<br />
Prasības ID Prasības raksturojums Risinājums<br />
LICS.3<br />
LICS.6<br />
LICS.7<br />
Piegādātais risinājums vai tā komponentes var tikt<br />
izmantotas uz VMware vSphere 4.0 vai jaunākas<br />
virtualizācijas platformas. Fiziskais serveris var būt ar<br />
2,4, vai 8 Intel saimes procesoriem. Pretendentam<br />
piedāvājumā jānorāda vai un kādi licencēšanas<br />
ierobežojumi un/vai papildus izmaksas ir attiecināmas<br />
izmantojot piedāvāto risinājumu zem virtualizācijas<br />
platformas.<br />
Šis punkts nav jāinterpretē kā nepieciešamība iekļaut<br />
piedāvājumā VMware licences.<br />
Piedāvātais risinājums vai tā komponentes var tikt<br />
izmantotas komplektā ar VMware vSphere 4.0 vai<br />
jaunāku Fault Tolerance bojājumu izturīgu risinājumu.<br />
Pretendentam piedāvājumā jānorāda vai un kādi<br />
licencēšanas ierobežojumi un/vai papildus izmaksas ir<br />
attiecināmas izmantojot piedāvāto risinājumu kopā ar<br />
VMware bojājumu izturīgu risinājumu.<br />
Šis punkts nav jāinterpretē kā nepieciešamība iekļaut<br />
piedāvājumā VMware licences.<br />
Piedāvātais risinājums vai tā komponentes var tikt<br />
izmantotas komplektā ar VMware vSphere 4.0 vai<br />
jaunāku High Availability augstas pieejamības<br />
risinājumu. Pretendentam piedāvājumā jānorāda vai un<br />
kādi licencēšanas ierobežojumi un/vai papildus izmaksas<br />
ir attiecināmas izmantojot piedāvāto risinājumu kopā ar<br />
Risinājuma arhitektūra paredz tās darbību, izmantojot virtualizācijas platformu VMware vSphere 4.0 vai<br />
jaunāku. Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2]<br />
Risinājuma arhitektūra paredz tās darbību komplektā ar VMware vSphere 4.0 vai jaunāku Fault<br />
Tolerance bojājumu izturīgu risinājumu. Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību<br />
dokumentā, skat. [2]<br />
Risinājuma arhitektūra paredz tās darbību komplektā ar VMware vSphere 4.0 vai jaunāku High<br />
Availability augstas pieejamības risinājumu. Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras<br />
prasību dokumentā, skat. [2]
INFS.1<br />
INFS.3<br />
INFS.4<br />
VMware augstas pieejamības risinājumu.<br />
Šis punkts nav jāinterpretē kā nepieciešamība iekļaut<br />
piedāvājumā VMware licences.<br />
Piegādājamās IS serveru daļai jābūt spējīgai strādāt uz<br />
kādas no VEC izmantojām serveru platformām:<br />
Windows 2003 R2, Windows Server 2008 vai Linux<br />
saimes operāciju <strong>sistēma</strong>s ar 2.6. sērijas kodolu.<br />
Visām IS darbināšanai nepieciešamajām infrastruktūras<br />
komponentēm (OS, datu bāzes, lietojumu serveri) ir<br />
jāatbalsta 64 bitu adresācijas režīms.<br />
Piegādājamās IS serveru daļai ir jāizmanto OS, kuras to<br />
izstrādātājs (ražotājs) attīsta un kurām Latvijā ir<br />
pieejams serviss (drošības un funkcionalitātes labojumi,<br />
konsultanti (speciālisti)).<br />
Risinājuma arhitektūra paredz EVK darbināšanu, izmantojot VEC izmantoto serveru platformu Windows<br />
Server 2008. Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2]<br />
Visi EVK darbināšanai paredzētie infrastruktūras komponenti – Windows Server 2008, Internet<br />
Information Services lietojumu serveris un .NET framework izpildes vide – atbalsta 64 bitu adresācijas<br />
režīmu un izmanto to, lai nodrošinātu piekļuvi visai infrastruktūras serveros pieejamajai operatīvajai<br />
atmiņai.<br />
Risinājums tiek darbināts, izmantojot Windows Server 2008 operacionālo sistēmu.<br />
Windows Server 2008<br />
Korporācija Microsoft šo produktu turpina attīstīt, tai tiek publicēti drošības un funkcionalitātes labojumi,<br />
un Latvijā ir pieejams gan pamata bezmaksas atbalsts, gan maksas atbalsts Microsoft Premier Support<br />
veidā, gan arī konsultāciju pakalpojumi no Microsoft Enterprise Services speciālistiem un no daudzajiem<br />
Microsoft partneriem Latvijā.<br />
Microsoft Windows Server 2008 produktam nodrošina:<br />
5 (piecu) gadu bāzes atbalstu, kad pieejama tehniskā informācija par produktu mājas lapā, drošības<br />
labojumi, funkcionālie labojumi un iespējams pieprasīt funkcionālās izmaiņas),<br />
vēl 5 (piecu) gadu paplašināto atbalstu, kad tiek nodrošināta informācija par produktu un drošības<br />
labojumi,<br />
papildu atbalstu pēc iepriekš minētajiem 10 (desmit) gadiem, kas pieejams pēc klienta pieprasījuma<br />
un par papildu maksu.<br />
Sīkāk par Microsoft produktu atbalstu skat. http://support.microsoft.com/lifecycle/
INFS.5<br />
INFS.11<br />
INFS.12<br />
INFS.13<br />
Piegādājamās IS serveru daļai jābūt spējīgai strādāt uz<br />
VEC izmantojamās virtualizācijas platformas VMware<br />
vSphere 4.0.<br />
Visām IS serveru daļai nepieciešamajām infrastruktūras<br />
komponentēm ir jāatbalsta IPV4 un IPV6 interneta<br />
sadarbības protokoli.<br />
Piegādātai IS ir jāatbalsta IPV4 un IPV6 interneta<br />
sadarbības protokoli.<br />
Piegādātai IS ir jāatbalsta adresācija izmantojot interneta<br />
domēna vārdu servisu (DNS). Šī prasība attiecināma arī<br />
uz piegādātās IS parametru uzstādīšanu.<br />
Piegādājamā IS serveru daļa ir spējīga strādāt uz VEC izmantojamās virtualizācijas platformas VMware<br />
vSphere 4.0.<br />
Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2], kur attēlots, ka<br />
<strong>sistēma</strong>s operētāj<strong>sistēma</strong>s tiek izvietotas VMware virtualizācijas risinājumā.<br />
EVK serveru daļas nepieciešamās infrastruktūras komponentes atbalsta IPV4 un IPV6 interneta<br />
sadarbības protokolus.<br />
Windows Server atbalsts IPv6 protokolam aprakstīts http://technet.microsoft.com/enus/network/bb530961.aspx<br />
Microsoft .NET Framework programmu darbināšanas vide ne tikai atbalsta jauno IPv6, bet vairākas tā<br />
specifiskās iespējas, piemēram, saziņas nodrošināšana starp divām programmām NAT tīklos, pat ir<br />
atkarīgas no tā – skat. Windows Communications Foundation saziņas platformas Peer-to-peer protokola<br />
aprakstu http://msdn.microsoft.com/en-us/library/cc297274.aspx<br />
EVK atbalsta IPV4 un IPV6 interneta sadarbības protokolus, jo saziņai izmanto platformas elementus<br />
(.NET Framework un tā ietvaros esošo Windows Communication Foundation, kas nodrošina tīmekļa<br />
pakalpju sadarbību, SQL Server), kuri šo atbalstu nodrošina.<br />
EVK komponenti neierobežo viena vai otra protokola lietošanu.<br />
EVK atbalsta tās komponentu adresāciju, izmantojot DNS servisu. Ir iespējams izmantot gan ārēju DNS<br />
servisu, kas translē DNS vārdus uz risinājuma izmantotajām IP adresēm (un otrādi), gan arī risinājumā<br />
paredzēto iekšējo DNS servisu (kas Infrastruktūras prasību dokumentā, skat. [2], esošajā aprakstā ir<br />
izvietots uz AD serveriem).<br />
Papildu tam DNS informācija, kas tiek iekļauta HTTP pieprasījumu galvenēs (header), ir izmantojama,<br />
veicot pieprasījumu maršrutēšanu, izmantojot Internet Information Services iespējas, kurš ir šādā veidā<br />
parametrizējams.<br />
Arī risinājuma komponentu savstarpējās atkarības (ja viens komponents pa tīklu izsauc citu, piemēram,<br />
tīmekļa pakalpe izsauc datu bāzes servisu) tiek definētas, izmantojot DNS nevis IP adreses. Šāda pieeja arī<br />
atvieglo risinājuma pārnešanu no vienas (testa) vides uz citu (produkcijas) vidi, jo katrā no vidēm tām
INFS.14<br />
INFS.15<br />
INFS.17<br />
INFS.31<br />
Piegādātās IS izmantotajiem tīkla protokoliem ir jābūt<br />
pieejamiem demilitarizētajā zonā (DMZ) izvietojamiem<br />
starp-serveriem (proxy servers). Piedāvājumā ir<br />
jānorāda šādu starp serveru piegādātājs, kā arī to<br />
licencēšanas izmaksas (ja tādas ir) un noteikumi.<br />
Ja piegādājamā IS paredz iespēju lietotājam ielādēt<br />
(augšupielādēt) lietotāja sagatavotus failus, ir jāparedz<br />
iespēja piegādāto IS integrēt ar antivīrusu līdzekļiem<br />
izmantojot ICAP[6] protokolu vai analogu mehānismu.<br />
Visām izmantojamām infrastruktūras komponentēm ir<br />
jāatbalsta iespēja nomainīt operāciju <strong>sistēma</strong>s IP adresi<br />
veicot komponentes konfigurāciju bez atkārtotas<br />
instalācijas un datu zudumiem.<br />
Datu integritātes līdzekļi ļauj noteikt un kontrolēt<br />
patvaļīgas sarežģītības datu integritātes noteikumus –<br />
datu integritātes pārbaudes bez standarta SQL<br />
līdzekļiem var tikt aprakstītas ar datu bāzē glabājamu<br />
procedurālu kodu, kuru datu bāzes serveris automātiski<br />
izpilda datu izmaiņu gadījumā;<br />
pašām DNS adresēm var būt piekārtotas citas IP adreses, bet konfigurācijas vērtības nav jāmaina.<br />
EVK sadarbībai ar ārējiem klientiem (sistēmām un lietotājiem), izmanto HTTP un/vai HTTPS protokolus.<br />
Šos protokolus atbalsta daudzi DMZ izvietojamie starp-serveri (reverse proxy).<br />
Piemērs konkrētam reverse-proxy serverim, kas nodrošina risinājuma protokolu publicēšanu DMZ, ir<br />
Microsoft Forefront Threat Management Gateway 2010. Šis proxy serveris arī tiek atbalstīts darbam<br />
virtualizētā vidē. Sīkāk skat. http://www.microsoft.com/forefront/threat-managementgateway/en/us/default.aspx<br />
EVK analīzes fāzes laikā tika konstatēts, ka lietotāju faili EVK netiks augšupielādēti. Tāpēc risinājums<br />
neparedz īpašu vīrusu pārbaudes loģiku. Tomēr uz visiem EVK serveriem tiks uzstādīti antivīrusu<br />
risinājumi, lai nodrošinātu standarta aizsardzību pret vīrusiem.<br />
Kopumā e-Veselības risinājumam HTTP un HTTPS līmenī ir nepieciešama aizsardzība pret ļaunprātīgiem,<br />
piemēram denial-of-service attack, uzbrukumiem, bet tas ir nepieciešams tikai sistēmām, kas ir<br />
eksponētas publiskajā Internet tīklā – portālam un integrācijas platformai. EVK saskarnes tiek izsauktas<br />
tikai un vienīgi caur integrācijas platformas slāni, kuram tad arī tiks nodrošināta aizsardzība pret<br />
ļaunprātīgiem uzbrukumiem HTTP/HTTPS līmenī.<br />
Risinājumā izmantotie infrastruktūras komponenti – Windows Server un Internet Information Services<br />
(kas ir daļa no Windows Server un kurā tiek darbināti <strong>sistēma</strong>s komponenti) – atbalsta IP adrešu<br />
konfigurēšanu, neveicot atbilstošā komponenta atkārtotu instalēšanu.<br />
Papildu tam izmantotais slodzes dalītājs – Internet Information Services Application Request Routing<br />
nodrošina, ka ir iespējams pievienot jaunus serverus, kuri apstrādās pieprasījumus, vai izņemt no<br />
apstrādes serveru klastera esošos serverus, piemēram, apkopes veikšanas nolūkos.<br />
SQL Server 2008 papildu standarta SQL vaicājumiem nodrošina arī vairākus mehānismus patvaļīgas<br />
sarežģītības validācijas mehānismu un pat jaunu datu bāzes datu tipu izveidei, izmantojot datu bāzē<br />
glabājamu procedurālu (vai objektorientētu) kodu, kas rakstīts vai nu SQL Server speciālā valodā<br />
Transact-SQL, kas sintakses ziņā līdzīga SQL, vai arī jebkurā no .NET Framework valodām (C#, VB.NET<br />
u.c.), veidojot SQLCLR programmu moduļus.<br />
Šo procedurālo kodu, kas saglabāts un darbojas datu bāzē, izmantojot trigger mehānismu, var izsaukt
INFS.32<br />
INFS.33<br />
INFS.34<br />
Datu bāzē iebūvēta XML datu apstrāde (glabāšana,<br />
indeksēšana, verifikācija, meklēšana – XPath,<br />
transformēšana - XSLT);<br />
Transakciju mehānisms, tai skaitā, spēja sadarboties ar<br />
trešo pušu transakciju monitoriem (piem. Tuxedo,<br />
Microsoft Transaction service u.c.);<br />
Datu bāze nodrošina iespēju izvietot datu bāzē<br />
pielietojuma loģikas kodu, kas nodrošina vienotu un<br />
standartizētu datu apstrādi;<br />
brīžos, kad notiek datu manipulācijas. To var arī izsaukt neatkarīgi, veicot DB glabāto procedūru<br />
izsaukumus.<br />
Sīkāk par izstrādes iespējām SQL Server 2008 platformā skat.<br />
http://www.microsoft.com/sqlserver/2008/en/us/programmability.aspx<br />
SQL Server 2008 nodrošina XML datu glabāšanu un apstrādi, izmantojot iebūvēto XML datu tipa atbalstu.<br />
Papildu XML apstrādi var veikt, izmantojot DB saglabātu procedurālu loģiku, kas rakstīts vai nu SQL<br />
Server speciālā valodā Transact-SQL, kas sintakses ziņā līdzīga SQL, vai arī jebkurā no .NET Framework<br />
valodām (C#, VB.NET u.c.), veidojot SQLCLR programmu moduļus.<br />
SQL Server 2008 datu konsistences nodrošināšanai viena resursa (datu bāzes) ietvaros tiks nodrošināts<br />
datu bāzes lokālais transakciju mehānisms, t.i., vairākām darbībām ar vienu un to pašu datu bāzi, kurām<br />
jābūt izpildītām kopā vai atceltām kopā, tiks izmantots DBVS transakciju mehānisms.<br />
Ja būs nepieciešams nodrošināt datu konsistenci darbībām, kurās iesaistītas vairākas <strong>sistēma</strong>s datu bāzes<br />
un/vai failu <strong>sistēma</strong>s, vai arī vairākas tīmekļa pakalpes, tad tiks pielietots transakciju mehānisms, kuru<br />
nodrošina Microsoft Distributed Transaction Coordinator (MS DTC) un ar kuru integrējas SQL Server 2008<br />
un NTFS failu <strong>sistēma</strong>s transakciju koordinators.<br />
MS DTC nodrošina dalīto transakciju atbalstu un var sadarboties ar vairākiem Microsoft un citu ražotāju<br />
veidotiem resursu kontrolieriem, piemēram, SQL Server 2008 datu bāzes transakciju integrēšanai,<br />
Windows Server failu <strong>sistēma</strong>s transakciju integrēšanai, Microsoft Message Queuing transakciju<br />
integrēšanai, WS-AtomicTransaction atbalstošiem servisiem tīmekļa pakalpju transakciju nodrošināšanai.<br />
Līdz ar to izmantotā datu bāžu vadības platforma nodrošina gan lokālo transakciju mehānismu, gan arī<br />
integrāciju ar trešo pušu transakciju koordinatoriem.<br />
SQL Server 2008 papildu standarta SQL vaicājumiem nodrošina arī vairākus mehānismus pielietojuma<br />
loģikas koda izveidei un pat jaunu datu bāzes datu tipu izveidei, izmantojot datu bāzē glabājamu<br />
procedurālu (vai objektorientētu) kodu, kas rakstīts vai nu SQL Server speciālā valodā Transact-SQL, kas<br />
sintakses ziņā līdzīga SQL, vai arī jebkurā no .NET Framework valodām (C#, VB.NET u.c.), veidojot SQLCLR<br />
programmu moduļus.<br />
Šo procedurālo kodu, kas saglabāts un darbojas datu bāzē, izmantojot trigger mehānismu, var izsaukt<br />
brīžos, kad notiek datu manipulācijas. To var arī izsaukt neatkarīgi, veicot DB glabāto procedūru
INFS.37<br />
INFS.38<br />
INFS.40<br />
INFS.51<br />
IS izstrādē datu glabāšanai ir jāizmanto kādu no VEC<br />
izmantojamām datu bāzu platformām Microsoft SQL<br />
Server 2008 vai Oracle RDBMS 11G2;<br />
Datu bāzei jānodrošina UTF8 kodējuma datu glabāšana<br />
un apstrāde;<br />
Izmantojamai datu bāzu tehnoloģijai ir jānodrošina<br />
iespēja noteikt izpildes prioritātes dažādām<br />
pieprasījumu grupām – piemēram zemāka prioritāte<br />
fona atskaišu apstrādei.<br />
Transakciju mehānisma atbalsts, ieskaitot spēju<br />
sadarboties ar populāro datu bāzu (Microsoft, Oracle)<br />
transakciju mehānismiem un trešo pušu transakciju<br />
monitoriem (piem. Tuxedo, Microsoft Transaction<br />
service u.c.);<br />
izsaukumus.<br />
Sīkāk par izstrādes iespējām SQL Server 2008 platformā skat.<br />
http://www.microsoft.com/sqlserver/2008/en/us/programmability.aspx<br />
IS izstrādē datu glabāšanai tiks izmantotas VEC izmantotā datu bāžu platforma Microsoft SQL Server<br />
2008.<br />
Microsoft SQL Server 2008 nodrošina UTF8 kodējuma datu glabāšanu un apstrādi, saglabāšanas vai<br />
nolasīšanas brīdī konvertējot datus Unicode (UCS-2) formātā.<br />
Šāda pieeja nodrošina ļoti efektīvu darbu ar datiem .NET vidē, jo gan Windows Server, gan .NET<br />
Framework kā iekšējo datu apstrādes kodējumu izmanto UCS-2.<br />
Šo iespēju Microsoft SQL Server 2008 nodrošina, izmantojot Resource Governor komponentu, ar kura<br />
palīdzību var definēt resursu grupas, resursu izmantotāju (workload) grupas un to prioritātes.<br />
Sīkāk par Resource Governor skat. http://msdn.microsoft.com/en-us/library/bb933866(v=SQL.100).aspx<br />
EVK IS lietojumu servera komponenti tiks veidoti, izmantojot .NET Framework programmu darbināšanas<br />
vidi.<br />
.NET Framework izmanto ADO.NET tehnoloģijas sadarbībai ar relacionālo datu bāžu vadības sistēmām.<br />
ADO.NET adapteri ir pieejami visām populārākajām datu bāžu vadības sistēmām, tai skaitā MS SQL Server<br />
un Oracle.<br />
Microsoft. NET Framework un ADO.NET adapteri atbalsta gan datu bāžu transakciju mehānismu<br />
izmantošanu pa tiešo, nodrošinot, ka darbības ar datu bāzēm tiek apvienotas loģiskās transakcijās, gan<br />
transakciju izmantošanu pastarpināti, ja tiek izmantots .NET Framework abstraktais transakciju<br />
mehānisms System.Transactions, kurš sadarbojas ar ADO.NET datu bāžu transakciju gadījumā, failu<br />
<strong>sistēma</strong>s apstrādes komponentiem failu sistēmu transakciju gadījumā, un MSDTC transakciju<br />
koordinatoru dalīto (distributed) transakciju gadījumā, kad transakcijā iesaistīti vairāki transakcionāli<br />
resursi .<br />
MS DTC, savukārt nodrošina tālāku sadarbību ar WS-AtomicTransaction atbalstošiem servisiem un trešo
INFS.53<br />
INFS.54<br />
PERF.1<br />
Pielietojumu serverim jānodrošina UTF8 kodējuma datu<br />
apstrāde.<br />
Pielietojumu serverim jānodrošina iespēja nomainīt<br />
Informācijas Sistēmas versiju pārtraucot lietotāju pieeju<br />
Informācijas Sistēmai uz laika periodu, kas nepārsniedz 5<br />
minūtes.<br />
Informācijas Sistēmas nomaiņa aplikāciju serverī<br />
neiekļauj datu struktūru izmaiņas un uzkrāto datu<br />
modifikācijas;<br />
Šī prasība attiecināma tikai uz tām Informācijas Sistēmas<br />
komponentēm, kuras tieši ietekmē e-veselība lietotāju<br />
(Ārsti, Pacienti, Farmaceiti utt.) darbu ar Informācijas<br />
Sistēmu.<br />
Lietotāju datu ievadam vai datu pieprasījumam (izziņai)<br />
uz ekrāna ir jāizpildās ne ilgāk kā 3 sekundes (neņemot<br />
vērā tīkla pārsūtīšanas aizturi un pieprasījumu izpildes<br />
laiku ārējās sistēmās). Minētā ātrdarbība jānodrošina<br />
pušu transakciju koordinatoriem.<br />
EVK komponenti tiek veidoti un darbināti, izmantojot .NET Framework.<br />
.NET Framework iekšēji visu informāciju glabā UCS-2 (Unicode) formātā, jo tas ir iekšējais formāts datu<br />
glabāšanai Windows un citos MS infrastruktūras komponentos, nodrošinot efektīvu informācijas iekšējo<br />
apstrādi.<br />
.NET Framework nepieciešamības gadījumā nodrošina datu pārveidošanu UTF-8 un citos kodējumos,<br />
nodrošinot ļoti plašu globalizācijas funkcionalitātes atbalstu.<br />
Piemēram, ASP.NET Web lapu gadījumā, izmainot tikai konfigurācijas iestatījumus Web komponentam, ir<br />
iespējams panākt, ka <strong>sistēma</strong>s attēlotās Web lapas ir kodētas UTF-8; atbilstošie HTTP galvenes lauki arī<br />
norāda, ka dati kodēti UTF-8.<br />
EVK izmantotais pielietojumu serveris Internet Information Services un tā komponentu izpildes vide<br />
ASP.NET nodrošina, ka, instalējot jaunu <strong>sistēma</strong>s komponentu versiju, lietojumu serveris iniciē jaunu<br />
procesu, kurā darbojas jaunās versijas komponenti un visus jaunos pieprasījumus tas nosūta apstrādei uz<br />
šo jauno procesu.<br />
Iepriekš uzsākto pieprasījumu apstrādei tiek saglabāts vecais process līdz brīdim, kad visi vecie aktīvie<br />
pieprasījumi tiek apstrādāti.<br />
Lietojumu servera stāvokļa informācija (aktuāla sesiju glabāšanai) un kešatmiņa (svarīga gan tīmekļa<br />
pakalpēm, gan Web lapām) tiek glabāta dalītā kešatmiņā, kas pieejama visos lietojumu serveros un jauna<br />
procesa palaišana un vecā procesa apturēšana šos datus neietekmē.<br />
Līdz ar to klienti jaunas versijas uzlikšanu vispār nepamana, jo tiek saglabāts gan TCP/IP pieslēgums, gan<br />
sesijas informācija, ja tāda ir (Web lietotāja saskarnes komponentu gadījumā).<br />
Aprakstītā jaunas versijas instalēšana lietojumu serverī neiekļauj datu struktūru izmaiņas un uzkrāto datu<br />
modifikācijas.<br />
Lietotāju datu ievades vai datu pieprasījums (izziņa) uz ekrāna izpildīsies ne ilgāk kā 3 sekundes (neņemot<br />
vērā tīkla pārsūtīšanas aizturi un pieprasījumu izpildes laiku ārējās sistēmās). Minētā ātrdarbība tiks<br />
nodrošināta, ņemot vērā reālu datu bāzes aizpildījumu ražošanas režīmā un veicot datu ielasīšanu<br />
(cached) servera(u) operatīvā atmiņā ne vairāk kā 10% no kopējā pieprasījuma izpildei nepieciešamā,
PERF.11<br />
ņemot vērā reālu datu bāzes aizpildījumu ražošanas<br />
režīmā un nosacījumu, ka servera(-u) operatīvā atmiņā<br />
var tikt ielasīti (cached) ne vairāk kā 10% no kopējā datu<br />
apjoma.<br />
Interaktīvas atskaites sagatavošanai uz ekrāna ir<br />
jāizpildās ne ilgāk kā 15 sekundes (neņemot vērā tīkla<br />
pārsūtīšanas aizturi). Minētā ātrdarbība jānodrošina<br />
ņemot vērā reālu datu bāzes aizpildījumu ražošanas<br />
režīmā un nosacījumu, ka servera operatīvā atmiņā var<br />
tikt ielasīti (cached) ne vairāk kā 10% no kopējā datu<br />
apjoma.<br />
apstrādājamā datu apjoma.<br />
Interaktīvas atskaites sagatavošanai uz ekrāna ir izpildīsies ne ilgāk kā 15 sekundes (neņemot vērā tīkla<br />
pārsūtīšanas aizturi). Minētā ātrdarbība tiks nodrošināta, ņemot vērā reālu datu bāzes aizpildījumu<br />
ražošanas režīmā un nosacījumu, ka servera operatīvā atmiņā var tikt ielasīti (cached) ne vairāk kā 10%<br />
no kopējā datu apjoma.<br />
Atskaitēm, kurām nebūs iespējams nodrošināts šīs prasības izpildi, tiks nodrošināta iespēja veikt to izpildi<br />
fona režīmā (background).<br />
PERF.21 Fona atskaites sagatavošanai ir jāizpildās ne ilgāk kā 10<br />
minūtes, pieņemot ka fona atskaišu izpildes prioritāte<br />
nav samazināta. Minētā ātrdarbība jānodrošina ņemot<br />
vērā reālu datu bāzes aizpildījumu ražošanas režīmā un<br />
nosacījumu, ka servera operatīvā atmiņā var tikt ielasīti<br />
(cached) ne vairāk kā 10% no kopējā datu apjoma.<br />
Fona atskaites sagatavošanas laiks tiks nodrošināts ne ilgāk kā 10 minūtes, pieņemot ka fona atskaišu<br />
izpildes prioritāte nav samazināta. Minētā ātrdarbība tiks nodrošināta, ņemot vērā reālu datu bāzes<br />
aizpildījumu ražošanas režīmā un veicot datu ielasīšanu (cached) servera(u) operatīvā atmiņā ne vairāk<br />
kā 10% no kopējā pieprasījuma izpildei nepieciešamā, apstrādājamā datu apjoma.<br />
PERF.22<br />
PERF.31<br />
Ja, apkopojot lietotāju prasības, tiek konstatēts, ka šī<br />
prasība konkrētai atskaitei ir tehniski neizpildāma,<br />
attiecīgai atskaitei var tikt noteikts cits izpildes laika<br />
robežlielums izmantojot projekta izmaiņu procedūru.<br />
Informācijas <strong>sistēma</strong>i ir jāuzkrāj informācija par fona<br />
atskaišu izpildes laikiem un jānodrošina <strong>sistēma</strong>s<br />
administratoram pieeja pie uzkrātās statistikas.<br />
Sinhrono web servisu pieprasījumu apstrāde nedrīkst<br />
pārsniegt 3 sekundes (netiek ņemts vērā laiks, kas tiek<br />
patērēts ārēju IS web servisu izsaukumiem).<br />
Izmantojot IP audita moduli, EVK uzkrās informāciju par fona atskaišu izpildes laikiem un <strong>sistēma</strong>s<br />
administratoram tiks nodrošināta pieeja pie uzkrātās statistikas.<br />
Sinhrono web servisu pieprasījumu apstrāde tiks veikta ne ilgāk kā 3 sekunžu laikā, neņemot vērā laiku,<br />
kas tiks patērēts ārējo IS web servisu izsaukumiem. Ārējām sistēmām, kuras nevar garantēt pieprasījumu<br />
apstrādi mazāk kā 3 sekundēs, servisu izsaukumi galvenokārt tiek veikti asinhroni, skat. dokumenta<br />
sadaļas 4 apakšpunktu 3).
PERF.32<br />
PERF.41<br />
PERF.42<br />
PERF.43<br />
Asinhrono web servisu pieprasījumu apstrāde nedrīkst<br />
pārsniegt 60 sekundes (laiks tiek mērīts starp<br />
pieprasījuma saņemšanu un atbildes nosūtīšanu<br />
izsaucējam. Netiek ņemts vērā laiks, kas tiek patērēts<br />
ārēju IS web servisu izsaukumiem).<br />
Izmantojamām tehnoloģijām (infrastruktūras<br />
komponentēm) ir jāspēj izmantot apstrādes<br />
paralelizācijai visi sistēmā pieejamie procesori<br />
(procesoru kodoli) vismaz līdz 8 fiziskajiem procesoriem,<br />
32 procesoru kodoliem (32 cores). Ja šāda procesoru<br />
(kodolu) skaita izmantošana tiek ierobežota ar piegādāto<br />
licenci, piedāvājumā ir jānorāda papildus licencēšanas<br />
izmaksas un citi ierobežojumi, kas saistīti ar procesoru<br />
skaita palielināšanu.<br />
Šī prasība nav interpretējama kā nepieciešamība<br />
piegādāt licenci 32 procesu kodoliem, bet gan kā<br />
piedāvātā risinājumu spēja mērogoties.<br />
Izmantojamām tehnoloģijām (infrastruktūras<br />
komponentēm) ir jāspēj izmantot ievada izvada<br />
operāciju apstrādes palielināšanai un apstrādes<br />
paātrināšanai visa sistēmā pieejamā operatīvā atmiņa. Ja<br />
šāda papildus liela mēroga operatīvās atmiņas<br />
izmantošana tiek ierobežota ar piegādāto licenci,<br />
piedāvājumā ir jānorāda papildus licencēšanas izmaksas<br />
un citi ierobežojumi, kas saistīti ar izmantojamās<br />
atmiņas palielināšanu.<br />
Izmantojamām datu bāzu un pielietojumu servera<br />
tehnoloģijām ir jāpieļauj automātiska slodzes dalīšana<br />
starp mezgliem strādājot klasterī (cluster). Ja šāds darbs<br />
prasa papildus licencēšanu, piedāvājumā ir jānorāda<br />
Asinhrono web servisu pieprasījumu apstrāde tiks veikta ne ilgāk kā 60 sekunžu laikā, neņemot vērā<br />
laiku, kas tiks patērēts ārējo IS web servisu izsaukumiem.<br />
Laiks tiek mērīts starp pieprasījuma saņemšanu un atbildes izsūtīšanas brīdi izsaucējam.<br />
Risinājumā izmantotās tehnoloģijas (infrastruktūras komponentēm – serveriem un trešo pušu<br />
programmatūrai) var nodrošināt apstrādes paralelizāciju visiem sistēmā pieejamiem procesoriem<br />
(procesoru kodoliem) vismaz līdz 8 fiziskajiem procesoriem.<br />
EVK fiziskā arhitektūra paredz izmantot 2 fiziskos serverus ar 4 procesoriem (katram 8 kodoli, kopā 32<br />
kodoli). Windows Server 2008 Datacenter Edition un SQL Server 2008 Enterprise spēj nodrošināt<br />
pilnvērtīgu visu servera resursu izmantošanu arī vairāku mezglu (node) gadījumā, ļaujot brīvi mērogot šo<br />
risinājumu.<br />
EVK fiziskā arhitektūra paredz divu SQL Server 2008 Enterprise DBVS serveru darbināšanu katru uz viena<br />
8-kodolu procesora, kas pilnībā nodrošina prasīto veiktspēju.<br />
Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2]<br />
Risinājuma arhitektūrā paredzētās infrastruktūras komponentes nav ierobežotas ar papildus operatīvās<br />
atmiņas izmantošanu.<br />
Risinājuma arhitektūra paredz automātisku slodzes dalīšanu starp mezgliem strādājot klasterī (cluster).<br />
Pieeja automātiskai slodzes dalīšanai starp mezgliem ir aprakstīta Infrastruktūras prasību dokumentā,<br />
skat. [2]
PERF.44<br />
PERF.51<br />
PERF.52<br />
PERF.53<br />
papildus licencēšanas izmaksas un citi ierobežojumi, kas<br />
saistīti ar darbu klāsterī.<br />
Šī prasība nav interpretējama kā nepieciešamība<br />
piegādāt licenci klasterizētam risinājumam, bet gan kā<br />
piedāvātā risinājumu spēja mērogoties.<br />
Izmantojamām datu bāzu un pielietojumu servera<br />
tehnoloģijām ir jāpieļauj klastera re-konfigurēšana<br />
(jauna mezgla pievienošana, mezgla atslēgšana)<br />
neapstādinot <strong>sistēma</strong>s darbu un automātiski nodrošinot<br />
lietotāju pieprasījumu migrēšanu starp klastera<br />
mezgliem.<br />
IS jānodrošina iespēja (administratoram) noteikt<br />
atšķirīgas prioritātes dažādām pieprasījumu grupām –<br />
piemēram fona atskaišu apstrādei;<br />
IS izstrādātājam ir jāņem vērā, ka IS var tikt ekspluatēta<br />
klasterētā un/vai daudzprocesoru vidē un jāizmanto<br />
tādi kritisko resursu bloķēšanas mehānismi, kuri nerada<br />
papildus aiztures sadarbojoties starp vairākiem<br />
procesoriem un klastera mezgliem;<br />
Šī prasība nav interpretējama kā nepieciešamība<br />
piegādāt licenci klasterizētam risinājumam, bet gan kā<br />
piedāvātā risinājumu spēja apstrādāt kļūdu situācijas<br />
klastera slēgumā.<br />
Pretendenta piedāvātajam risinājumam ir jānodrošina<br />
augstas pieejamības īpašības. Risinājumam jāsaglabā<br />
darbaspēja un jānodrošina transakciju integritāte vismaz<br />
šādos scenārijos:<br />
· Sakaru kanāla kļūda vai darba pārtraukums<br />
(transakciju sinhronizācija jāveic automātiski pēc sakaru<br />
SQL Server un Windows Server tehnoloģijas pieļauj klastera re-konfigurēšanu (jauna mezgla<br />
pievienošana, mezgla atslēgšana), neapstādinot <strong>sistēma</strong>s darbu un automātiski nodrošinot lietotāju<br />
pieprasījumu migrēšanu starp klastera mezgliem. EVK risinājuma arhitektūrā ir paredzēts izmantot divus<br />
fiziskus serverus. Sistēmas infrastruktūras risinājumā ir paredzēts, ka viena servera failover gadījumā, tā<br />
funkcijas pārņem otrs serveris. Laika gaitā risinājumu iespējams papildināt ar papildus serveriem,<br />
nemainot kopējo infrastruktūras uzbūvi.<br />
EVK nodrošinās iespēju (administratoram) noteikt atšķirīgas prioritātes dažādām pieprasījumu grupām –<br />
piemēram fona atskaišu apstrādei.<br />
EVK risinājumā ir paredzēts, ka <strong>sistēma</strong> tiks ekspluatēta klasterētā un daudzprocesoru vidē. Līdz ar to<br />
<strong>sistēma</strong>s risinājumā ir izmantoti tādi kritisko resursu bloķēšanas mehānismi, kuri neradīs papildus<br />
aiztures, sadarbojoties starp vairākiem procesoriem un klastera mezgliem.<br />
EVK risinājums nodrošinās iespēju apstrādāt kļūdu situācijas klastera slēgumā.<br />
EVK risinājums nodrošinās augstas pieejamības īpašības. Risinājums saglabās darbaspējas un nodrošinās<br />
transakciju integritāti vismaz šādos scenārijos:<br />
Sakaru kanāla kļūda vai darba pārtraukums (transakciju sinhronizācija tiks veikta automātiski pēc<br />
sakaru kanāla atjaunošanas);<br />
Operāciju <strong>sistēma</strong>s vai tehniska kļūda kādā (vienā) no serveriem; Risinājumam ir jāveic korekta
PERF.54<br />
PERF.55<br />
kanāla atjaunošanas);<br />
· Operāciju <strong>sistēma</strong>s vai tehniska kļūda kādā (vienā)<br />
no serveriem; Risinājumam ir jāveic korekta situācijas<br />
apstrāde, kad servera darbs tiek atjaunots;<br />
· Datubāzes servera, pielietojumu servera jeb paša<br />
pielietojuma programmatūras kļūda;<br />
Precīzi darbības turpināšanas scenāriji dažādām<br />
situācijām ir jādokumentē informācijas <strong>sistēma</strong>s analīzes<br />
fāzes laikā.<br />
IS ir jāatpazīst un jāspēj korekti apstrādāt<br />
infrastruktūras elementu ziņojumi par ārkārtas<br />
situācijām (sesijas pārtraukšana, piespiedu sesijas<br />
pārslēgšanu un tml.).<br />
Izmantojamām tehnoloģijām (infrastruktūras<br />
komponentēm) ir jāspēj automātiski atjaunot darbību<br />
bez datu zudumiem vai bojājumiem, ja tiek bojāts viens<br />
no vairākiem alternatīviem pieslēgumiem disku atmiņai<br />
(storage).<br />
situācijas apstrāde, kad servera darbs tiek atjaunots;<br />
Datubāzes servera, pielietojumu servera jeb paša pielietojuma programmatūras kļūda.<br />
Risinājuma augstas pieejamības un mērogošanas pieeja ir aprakstīta Infrastruktūras prasību dokumentā,<br />
skat. [2].<br />
EVK tiks nodrošināts, ka tiek atpazīti un korekti apstrādāti infrastruktūras elementu ziņojumi par ārkārtas<br />
situācijām (sesijas pārtraukšana, piespiedu sesijas pārslēgšanu un tml.). Sistēmas uzbūve tiks veidota<br />
tādā veidā, lai infrastruktūras elementu ziņojumi ārkārtas situācijām tiktu identificēti, apstrādāti,<br />
ierakstīti <strong>sistēma</strong>s funkciju žurnālā, un nepieciešamības gadījumā tiks veidota papildus <strong>sistēma</strong>s reakcija<br />
uz identificēto ārkārtas situāciju. Sistēmas izstrādes posmā tiks veikta iespējamo ārkārtas situāciju<br />
identifikācija un tiks izstrādāti <strong>sistēma</strong>s darbības scenāriji šo identificēto ārkārtas situāciju apstrādei.<br />
Risinājuma augstas pieejamības un mērogošanas pieeja ir aprakstīta Infrastruktūras prasību dokumentā,<br />
skat. [2].<br />
EVK IS infrastruktūras risinājums nodrošinās iespēju automātiski atjaunot darbību bez datu zudumiem vai<br />
bojājumiem, ja tiek bojāts viens no vairākiem alternatīviem pieslēgumiem disku atmiņai (storage),vai<br />
gadījumiem, kad disks, uz kura atradīsies datu bāze, pārtrauks savu darbību. Izmantotais EVK<br />
infrastruktūras risinājums nodrošinās <strong>sistēma</strong>s darbību bez pārtraukumiem, un bez datu zudumiem, vai<br />
bojājumiem.<br />
EVK infrastruktūras līmeņa risinājums:<br />
tiks izmantoti RAID 10 konfigurācijas diski (tiek dublēti diski);<br />
tiks izmantoti vairāki slēdži (switch) uz disku masīvu (storage) (tiek dublēts fiziskais pieslēgums);<br />
tiks izmantoti vairāki porti datoros, kuri ar to strādā (tehniskā arhitektūrā tiks paredzēti 2 HBA<br />
adapteri katrā datorā – dublēts pieslēgums no katra datora);<br />
tiks izmantoti 2 disku masīva kontrolieri disku masīvam (izsargājoties pret gadījumu, kad iziet no
PERF.56<br />
PERF.57<br />
SECR.1<br />
SECR.2<br />
Izmantojamām datu bāzu un pielietojumu servera<br />
tehnoloģijām ir jāveic automātiska klastera rekonfigurēšana<br />
(mezgla atslēgšana) gadījumā, ja klastera<br />
mezgls ir bojāts (tehnisks defekts, programmu<br />
nodrošinājuma kļūda, pielietojuma kļūda), neapstādinot<br />
<strong>sistēma</strong>s darbu un automātiski nodrošinot lietotāju<br />
sesiju migrēšanu starp klastera mezgliem. Sesijas<br />
migrēšanas laikā ir pieļaujams pēdējās lietotāja<br />
nepabeigtās darbības (transakcijas) pārtraukšana.<br />
Šī prasība nav interpretējama kā nepieciešamība<br />
piegādāt licenci klasterizētam risinājumam, bet gan kā<br />
piedāvātā risinājumu spēja apstrādāt kļūdu situācijas<br />
klastera slēgumā.<br />
Pretendentam piedāvājumā jānorāda optimālā<br />
infrastruktūras konfigurācija ņemot vērā paredzamos<br />
datu apjomus, lietotāju skaitu, ātrdarbības un<br />
pieejamības prasības.<br />
Sistēmā visas lietotāju un administratoru veiktās<br />
darbības tiek identificētas (zināms kurš konkrēti izpilda<br />
minēto darbību). Šī prasība neattiecas uz funkcionalitāti,<br />
kas speciāli norādīta kā publiski pieejama;<br />
Ārēju pieprasījumu (WEB servisu) iniciējošie lietotāji ir<br />
identificējami tieši vai izmantojot e-veselības<br />
ierindas viss disku masīva kontrolieris);<br />
datu krātuves (storage) kontrolieris (draiveriem) VMWare jāatbalsta MultiPath IO (lai<br />
operētāj<strong>sistēma</strong> (OS) var izmantot abus HBA).<br />
Risinājums nodrošinās alternatīvo datu kanālu un tā izmantošanu infrastruktūras līmenī.<br />
Izmantojamām datu bāzu un pielietojumu servera tehnoloģijām tiek nodrošināta automātisku klastera<br />
re-konfigurēšana (mezgla atslēgšana) gadījumā, ja klastera mezgls ir bojāts (tehnisks defekts, programmu<br />
nodrošinājuma kļūda, pielietojuma kļūda), neapstādinot <strong>sistēma</strong>s darbu, automātiski nodrošinot lietotāju<br />
sesiju migrēšanu starp klastera mezgliem. Sesijas migrēšanas laikā var tikt veikta pēdējās lietotāja<br />
nepabeigtās darbības (transakcijas) pārtraukšana.<br />
Optimālā infrastruktūras konfigurācija, ņemot vērā paredzamos datu apjomus, lietotāju skaitu,<br />
ātrdarbības un pieejamības prasības ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2]<br />
Sistēmā lietotāju un administratoru veiktās darbības tiek identificētas (zināms kurš konkrēti izpilda<br />
minēto darbību).<br />
Katrs EVK pakalpes izsaukums saturēs papildus drošības informācijas komplektu, kuru aizpildīs IP<br />
autorizācijas serviss veiksmīgas autorizācijas gadījumā. Drošības informācijas komplekts saturēs lietotāja<br />
identifikāciju.<br />
Ārēju pieprasījumu (WEB servisu) iniciējošie lietotāji tiks identificēti, izmantojot e-veselības autorizācijas
SECR.3<br />
SECR.4<br />
SECR.5<br />
SECR.6<br />
SECR.7<br />
SECR.10<br />
SECR.11<br />
autorizācijas moduli integrācijas platformā.<br />
Visām darbībām tiek pārbaudīta autorizācija darbības<br />
izpildei. Pārbaudei jānotiek katra pieprasījumu līmenī;<br />
Jebkurš nesekmīgs autorizācijās vai autentifikācijas<br />
mēģinājums tiek reģistrēts <strong>sistēma</strong>s žurnālā;<br />
Lietotāju autorizācijas tiesību informācija tiek glabāta<br />
atmiņas apgabalā, kas aparātiski nodalīts no lietotāja<br />
pieprasījuma izpildei izmantotās atmiņas. Ar nodalītu<br />
tiek saprasts nodalījums izmantojot lietotājam<br />
neapejamus infrastruktūras elementu līdzekļus.<br />
Tiek realizēts autorizācijas princips, ka viss kas nav tiešā<br />
veidā atļauts ir aizliegts.<br />
IS izstrādē jāievēro OWASP rekomendētie sistēmu<br />
izstrādes principi:<br />
http://www.owasp.org/index.php/Category:Principle.<br />
Izstrādē un IS ekspluatācijā nedrīkst izmantot<br />
komponentes, kuras ražotājs pozicionē kā „Beta”, „Prerelease”,<br />
„Release candidate”„obsolete” vai arī kādā<br />
citā veidā nerekomendē izmantošanai ražošanas<br />
sistēmās.<br />
IS Izstrādē nedrīkst izmantot komponentes, kurām<br />
ražotājs nepiegādā vai tuvāko 2 gadu laikā no izstrādes<br />
uzsākšanas brīža plāno pārtraukt izstrādi un/vai piegādāt<br />
moduli integrācijas platformā.<br />
EVK visas darbības tiks nodrošināta tikai pēc veiksmīgas autorizācijas. Pārbaude tiks nodrošināta katra<br />
pieprasījuma līmenī.<br />
Katrs EVK pakalpes izsaukums saturēs papildus drošības informācijas komplektu, kuru aizpildīs IP<br />
autorizācijas serviss veiksmīgas autorizācijas gadījumā. Drošības informācijas komplekts saturēs lietotāja<br />
pilno tiesību komplektu.<br />
Nesekmīgie autorizācijās vai autentifikācijas mēģinājumi tiek reģistrēti <strong>sistēma</strong>s žurnālā, izmantojot IP<br />
audita bibliotēku.<br />
Lietotāju autorizācija tiks izdalīta atsevišķā procesā, kas dos iespēju tam izdalīt atsevišķu atmiņas<br />
apgabalu, tādējādi to aparātiski nošķirot no lietotāja pieprasījuma izpildei izmantotās atmiņas.<br />
Tiks realizēts autorizācijas princips, ka viss, kas nav tiešā veidā atļauts, ir aizliegts.<br />
EVK IS izstrādē tiks ņemti vērā OWASP rekomendētie sistēmu izstrādes principi:<br />
http://www.owasp.org/index.php/Category:Principle.<br />
Precīzas rekomendācijas un to ievērošanas veids tiks saskaņots projekta projektēšanas fāzē.<br />
EVK <strong>sistēma</strong>s arhitektūra paredz izmantot tikai attiecīgo ražotāju ražošanas sistēmās rekomendētas<br />
komponentes. Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2]<br />
Risinājuma arhitektūrā netiek izmantotas komponentes, kurām ražotājs nepiegādā vai tuvāko 2 (divu)<br />
gadu laikā no izstrādes uzsākšanas brīža plāno pārtraukt izstrādi un/vai piegādāt drošības labojumus.
SECR.12<br />
SECR.13<br />
SECR.14<br />
SECR.15<br />
SECR.31<br />
SECR.32<br />
AUDT.1<br />
drošības labojumus.<br />
WEB pielietojumiem sesiju pārvaldība jāorganizē pēc<br />
OWASP rekomendētajiem principiem:<br />
http://www.owasp.org/index.php/Session_Managemen<br />
t<br />
Administratoru pieeja <strong>sistēma</strong>i jāspēj ierobežot ar vienu<br />
vai vairākiem IP apgabaliem. Ar IP apgabalu šeit tiek<br />
saprasts IPV4 vai IPV6 adrešu intervāls.<br />
WEB pielietojumiem jāņem vērā OWASP rekomendācijas<br />
AJAX tehnoloģiju izmantošanai<br />
http://www.owasp.org/index.php/Ajax_and_Other_%22<br />
Rich%22_Interface_Technologies<br />
Jāpielieto ražotāju un nozares ekspertu ieteiktās labās<br />
prakses drošu informācijas sistēmu izstrādē.<br />
IS autentifikācija ir jāveic izmantojot E-veselības<br />
Integrācijas Platformas autentifikācijas servisu.<br />
IS autorizācija ir izmantojot E-veselības Integrācijas<br />
Platformas autorizācijas servisu (E-veselības<br />
autorizācijas servisu)<br />
Visām IS ekspluatācijā izmantotajām infrastruktūras<br />
komponentēm ir jānodrošina SNMP v2 vai v3 sistēmu<br />
uzraudzības interfeiss. Komponentēm, kuras<br />
nenodrošina SNMP interfeisu jāpiegādā nepieciešamie<br />
risinājumi uzraudzības interfeisa pārveidošanai<br />
atbilstoši SNMP v2 vai v3 prasībām;<br />
WEB pielietojumiem sesiju pārvaldība tiks veidota atbilstoši OWASP rekomendētajiem principiem:<br />
http://www.owasp.org/index.php/Session_Management.<br />
Precīzas rekomendācijas un to ievērošanas veids tiks saskaņots projekta projektēšanas fāzē.<br />
Sistēmu administratoriem pieeja <strong>sistēma</strong>i tiks nodrošināta, izmantojot Remote Desktop Protocol (RDP)<br />
pieeju, kurai tiek nodrošināta iespēja ierobežot konkrētu IP adrešu apgabalu.<br />
WEB pielietojumiem tiks ņemtas vērā OWASP rekomendācijas AJAX tehnoloģiju izmantošanā atbilstoši<br />
http://www.owasp.org/index.php/Ajax_and_Other_%22Rich%22_Interface_Technologies.<br />
Precīzas rekomendācijas un to ievērošanas veids tiks saskaņots projekta projektēšanas fāzē.<br />
Tiks pielietotas ražotāju un nozares ekspertu ieteiktās labās prakses drošu informācijas sistēmu izstrādē.<br />
Lietotāju un ārēju IS autentifikācija tiks veikta, izmantojot IP autentifikācijas servisu.<br />
Lietotāju un ārēju IS autorizācija tiks veikta, izmantojot IP autorizācijas servisu.<br />
Tiks nodrošināta iespēja attālināti uzraudzīt <strong>sistēma</strong>s veiktspēju un citus <strong>sistēma</strong>s kvalitātes rādītājus,<br />
iestrādājot sistēmā SNMP (Simple Network Management Protocol) atbalstu. Sistēmas uzraudzības<br />
mehānisms nodrošinās iespēju izmantot pieejamos šo standartu atbalstošos monitoringa rīkus.<br />
Pretendenta izstrādātajām komponentēm SNMP (v2c; detalizētu informāciju skat.<br />
http://msdn.microsoft.com/en-us/library/aa379141(v=VS.85).aspx)) atbalsts IS komponentēs tiks<br />
nodrošināts, izmantojot Windows SNMP Service (detalizētu informāciju skat.
AUDT.2<br />
AUDT.3<br />
AUDT.5<br />
AUDT.6<br />
AUDIT.7<br />
AUDIT.8<br />
AUDT.11<br />
ADMN.31<br />
Visām IS ekspluatācijā izmantotajām infrastruktūras<br />
komponentēm jānodrošina automātiska iespēja sūtīt<br />
SNMP ziņojumus (SNMP trap) situācijās, kurās<br />
nepieciešama cilvēka (administratora) iejaukšanās<br />
<strong>sistēma</strong>s darbā;<br />
Visu infrastruktūras komponenšu SNMP interfeisiem ir<br />
jābūt brīvi pieejamām vai jātiek piegādātām SNMP MIB<br />
definīcijām;<br />
Informācijas Sistēmai jānodrošina SNMP v2 vai v3<br />
interfeiss IS darba uzraudzībai (tikai lasīšana). Konkrētos<br />
rādītājus jāprecizē Informācijas Sistēmas projektēšanas<br />
laikā.<br />
IS jānodrošina programmatūras kļūdu un izņēmumu<br />
situāciju (exceptions) paziņošana uzraudzības serverim<br />
izmantojot SNMP ziņojumus (SNMP trap).<br />
IS jānodrošina programmatūras kļūdu un izņēmuma<br />
situāciju (exceptions) paziņošana izmantojot e-pastu.<br />
SNMP ziņojumu (SNMP trap) saturam ir jātiek dublētam<br />
<strong>sistēma</strong>s LOG-failos.<br />
IS jāsniedz informācija Personas datu uzraudzības<br />
servisam par visiem ar personas datiem saistītiem<br />
notikumiem ņemot vērā Fizisko personu datu<br />
aizsardzības likuma[2] prasības.<br />
Sistēmai jānodrošina iespēja uzstādīt funkcionālos un<br />
drošības labojumus. Ja šādu labojumu uzstādīšanai tas ir<br />
nepieciešams, IS administratīvajā interfeisā ir<br />
jānodrošina iespējas:<br />
http://msdn.microsoft.com/en-us/library/aa379100(VS.85).aspx).<br />
SNMP Service tiek nodrošināta divus programmatūras sadarbībai ar ārējām aplikācijām WinSNMP API<br />
v2.0 un SNMP Extension Agent API (detalizētu informāciju skat. http://msdn.microsoft.com/enus/library/aa379207(v=VS.85).aspx).<br />
Optimālākā SNMP standarta implementācija tiks izraudzīta <strong>sistēma</strong>s<br />
projektēšanas fāzē.<br />
Sistēmas infrastruktūrā tiks izmantoti ražotāja Microsoft standarta programmatūras produkti, kuriem ir<br />
nodrošināts IPv6 atbalsts. Windows SNMP Service tiek nodrošināts, sākot ar Windows Server 2008<br />
versiju (detalizētu informāciju skat. http://msdn.microsoft.com/en-us/library/aa377981(v=VS.85).aspx).<br />
Microsoft SQL Server un Microsoft IIS veiktspējas pārraudzībai tiks izmantots jau tajos iebūvētais SNMP<br />
pārraudzības atbalsts. Programmatūras ražotājs (Microsoft) publicētos SNMP objektus (MIB) piegādā<br />
kopā ar attiecīgo produktu instalācijām:<br />
Microsoft SQL Server (detalizētu informāciju skat. http://technet.microsoft.com/enus/library/dd316347.aspx#ECAA);<br />
Microsoft IIS (detalizētu informāciju skat. http://technet.microsoft.com/enus/library/bb726987.aspx#EAAA).<br />
EVK tiks nodrošināta programmatūras kļūdu un izņēmuma situāciju (exceptions) paziņošana, izmantojot<br />
e-pastu. Tas tiks nodrošināts, izmantojot centralizētu VEC monitoringa rīku.<br />
SNMP ziņojumu (SNMP trap) saturs tiks dublēts <strong>sistēma</strong>s LOG-failos.<br />
EVK IS nodrošinās informācijas sniegšanu Personas datu uzraudzības servisam par visiem ar personas<br />
datiem saistītiem notikumiem, ņemot vērā Fizisko personu datu aizsardzības likuma prasības.<br />
EVK tiks nodrošināta iespēja uzstādīt funkcionālos un drošības labojumus.<br />
EVK administratīvajā interfeisā tiks nodrošinātas iespējas nepieciešamības gadījumā:
ADMN.41<br />
ADMN.42<br />
ARCH.1<br />
· Apturēt/Atsākt jaunu lietotāju pieslēgumu<br />
veidošanu;<br />
· Pārtraukt esošās lietotāju sesijas (visas vai tikai<br />
norādītās) saglabājot atsevišķo lietotāju veikto operāciju<br />
integritāti;<br />
· Apturēt/Atjaunot datu apmaiņu caur interfeisiem;<br />
· Apturēt/Atjaunot fona procesu un uzdevumu<br />
izpildi;<br />
Informācijas <strong>sistēma</strong>i jānodrošina iespēja veikt <strong>sistēma</strong>s<br />
rezerves kopēšanu un konsistentas kopijas iegūšanu bez<br />
<strong>sistēma</strong>s darba apturēšanas. Ja <strong>sistēma</strong>s rezerves<br />
kopēšanai nepieciešama IS un/vai infrastruktūras<br />
komponenšu darbināšana speciālā režīmā, tad šāda<br />
speciāla režīma ieslēgšana/izslēgšana jānodrošina ar<br />
komandrindas interfeisa palīdzību.<br />
Izmantojamām infrastruktūras komponentēm (datu<br />
bāzei, pielietojumu serverim) ir jānodrošina iespēja<br />
veidot rezervēšanas politiku pamatojoties uz IS turētāja<br />
noteikto atjaunošanas laiku (piemēram, atjaunošana ne<br />
ilgāka kā 2h).<br />
Informācijas Sistēmu arhitektūra ir jāveido kā<br />
daudzlīmeņu arhitektūra ar uzskaitītajiem loģiski<br />
nodalītiem funkcionalitātes līmeņiem:<br />
· Datu līmenis – nodrošina datu uzglabāšanu un datu<br />
integritātes kontroli (ieskaitot biznesa loģikas noteiktos<br />
datu integritātes nosacījumus). Datu līmenis jārealizē<br />
datu bāzes vadības sistēmā. Datu līmenī tiek realizēta<br />
pieejas kontrole limitējot pieeju no biznesa loģikas tikai<br />
biznesa funkcijām nepieciešamā apjomā, kā arī audita<br />
funkcijas.<br />
Apturēt/Atsākt jaunu lietotāju pieslēgumu veidošanu;<br />
Pārtraukt esošās lietotāju sesijas (visas vai tikai norādītās), saglabājot atsevišķo lietotāju veikto<br />
operāciju integritāti;<br />
Apturēt/Atjaunot datu apmaiņu caur interfeisiem;<br />
Apturēt/Atjaunot fona procesu un uzdevumu izpildi.<br />
EVK nodrošinās iespēju veikt <strong>sistēma</strong>s rezerves kopēšanu un konsistentas kopijas iegūšanu bez <strong>sistēma</strong>s<br />
darba apturēšanas.<br />
Ja <strong>sistēma</strong>s rezerves kopēšanai būs nepieciešama EVK un/vai infrastruktūras komponenšu darbināšana<br />
speciālā režīmā, tad šāda speciāla režīma ieslēgšana/izslēgšana tiks nodrošināta ar komandrindas<br />
interfeisa palīdzību.<br />
Izmantojamām infrastruktūras komponentēm (datu bāzei, pielietojumu serverim) tiks nodrošināta<br />
iespēja veidot rezervēšanas politiku, pamatojoties uz IS turētāja noteikto atjaunošanas laiku (piemēram,<br />
atjaunošana ne ilgāka kā 2h).<br />
EVK loģiskā arhitektūra ir aprakstīta 3.2 Loģiskā arhitektūra sadaļā, bet tās realizācija fiziskajā līmenī -<br />
Infrastruktūras prasību dokumentā, skat. [2].
ARCH.2<br />
ARCH.3<br />
ARCH.4<br />
· Biznesa loģikas līmenis nodrošina lietotāju<br />
funkcionālo pieprasījumu pārvēršanu datu apstrādes<br />
pieprasījumos. Šajā līmenī tiek veikta pieejas kontrole,<br />
kā arī nodrošināta datu apstrādes loģika. Biznesa loģikas<br />
līmeni ieteicams realizēt datu bāzes vadības sistēmā.<br />
· Integrācijas līmenis nodrošina biznesa loģikas<br />
funkciju publicēšanu WEB pakalpojumu (WEB servisu)<br />
veidā, kā arī ārēju WEB pakalpojumu pieejamību biznesa<br />
loģikas līmenim. Integrācijas līmeni ieteicams realizēt<br />
pielietojumu serverī.<br />
· Lietotāju Interfeisa loģikas līmenis nodrošina<br />
biznesa loģikas līmeņa funkcionalitātes prezentāciju<br />
atbilstoši lietotāju vajadzībām, lietotājiem ērtā un<br />
saprotamā veidā. Interfeisa loģikas līmeni ieteicams<br />
realizēt pielietojumu serverī.<br />
· Lietotāju interfeisa prezentācijas līmenis nodrošina<br />
informācijas attēlošanu lietotājam<br />
Līmeņu sadarbība jāorganizē definētu un dokumentētu<br />
interfeisu veidā. Līmeņu un to sadarbības tehniskais<br />
apraksts jāpiegādā kā daļa no Sistēmas arhitektūras<br />
dokumenta.<br />
Izstrādājot <strong>sistēma</strong>s arhitektūru ir jāparedz papildus<br />
funkcionalitāte, kas nepieciešama efektīvai sistēmu<br />
testēšanai un diagnostikai. Iespēju robežās <strong>sistēma</strong>i ir<br />
jāveic pašdiagnostika, nodrošinot izsaukumu parametru<br />
vērtību un pieejas tiesību kontroli starp dažādiem<br />
arhitektūras līmeņiem.<br />
Arhitektūra veidojama minimizējot nepieciešamo<br />
infrastruktūras komponenšu un programmu bibliotēku<br />
skaitu un sarežģītību.<br />
Komponentu savstarpējā sadarbība un sadarbība ar ārējām sistēmām ir aprakstīta 6.3 Sistēmas<br />
komponentu sadarbība sadaļā. Loģisko komponentu izvietošanas varianti ir aprakstīti 7 Fiziskā<br />
arhitektūra sadaļā.<br />
EVK pārvaldības arhitektūra ir aprakstīta 8 Pārvaldības arhitektūra sadaļā.<br />
EVK arhitektūra paredz izmantot nelielu skaitu infrastruktūras komponenšu un programmu bibliotēku.<br />
Detalizēts nepieciešamo komponenšu apraksts atrodams 6.4 Sistēmas komponenti sadaļā.
ARCH.5<br />
ARCH.7<br />
ARCH.21<br />
ARCH.25<br />
Arhitektūra veidojama minimizējot nepieciešamo<br />
tehnoloģiju (programmēšanas valodu, bibliotēku,<br />
izstrādes tehnoloģiju u.c.) skaitu.<br />
Visas <strong>sistēma</strong>s arhitektūra veidojama ņemot vērā<br />
iespējamos informācijas <strong>sistēma</strong>s datu plūsmas<br />
pārrāvumus:<br />
· Visas lietotāju darbības sistēmā jāaizsargā ar<br />
transakciju mehānismiem;<br />
· Datu apmaiņa starp sistēmām ir jāaizsargā ar<br />
transakciju mehānismu, vai jānodrošina iespēja<br />
automātiski atjaunot/atkārtot apmaiņu pēc pārrāvuma<br />
saglabājot pilnu datu integritāti;<br />
Datu apmaiņa starp sistēmām realizējama vienā no<br />
šādiem ` veidiem:<br />
· Sinhronu un/vai Asinhronu WEB servisu izsaukumi;<br />
· XML standarta formāta failu apmaiņa;<br />
· Teksta formāta failu apmaiņa;<br />
Atsevišķos gadījumos, kad nav iespējams ietekmēt<br />
pieejamā interfeisa tehnoloģiju, var tikt izmantotas citas<br />
sadarbības tehnoloģijas. Konkrēts datu apmaiņas<br />
mehānisms tiks precizēts Informācijas Sistēmas izstrādes<br />
analīzes fāzes laikā.<br />
Iespēja simulēt ārējo interfeisu darbu situācijās, kad<br />
ārējas <strong>sistēma</strong>s nav pieejamas. Simulācija veicama<br />
limitētam datu apjomam, pietiekošam <strong>sistēma</strong>s<br />
testēšanas veikšanai.<br />
Interfeisi, kuri izmantos E-veselība Integrācijas platformu<br />
(IP) šīs prasības nodrošināšanai, var izmantot IP<br />
funkcionalitāti.<br />
EVK arhitektūra paredz izmantot nelielu skaitu izmantojamo tehnoloģiju. Detalizēts izmantojamo<br />
tehnoloģiju apraksts atrodams 6.4 Sistēmas komponenti sadaļā.<br />
Datu plūsmas starp EVK komponentēm tiks nodrošināta izmantojot transakciju mehānismu.<br />
Datu apmaiņai starp sistēmām tiks izmantoti sinhronu un asinhronu Web servisu izsaukumi. Ārējām<br />
sistēmām, kuras nevar garantēt pieprasījumu apstrādi mazāk kā 3 sekundēs, servisu izsaukumi<br />
galvenokārt tiek veikti asinhroni.<br />
Testēšanas nolūkiem Sistēmas interfeisiem tiks izveidota funkcionalitāte to simulētam izsaukumam, kuri<br />
atgriezīs testēšanas piemēros definētus rezultātus.
ARCH.27<br />
ARCH.41<br />
Jānodrošina iespēja kontrolēt ārējām sistēmām nosūtīto<br />
pieprasījumu izpildes ilgumu un apstrādāt situācijas, kad<br />
tiek pārsniegts pieļaujamais atbildes gaidīšanas laiks;<br />
Informācijas Sistēmai jānodrošina ārējo klasifikatoru<br />
saņemšana un ielāde no Integrācijas platformas (eveselība<br />
klasifikatori) un citiem avotiem, ja klasifikators<br />
nav pieejams integrācijas platformā.<br />
Sistēmas pielietojumu serverī tiks nodrošināta iespēja kontrolēt ārējām sistēmām nosūtīto pieprasījumu<br />
izpildes ilgumu un apstrādāt situācijas, kad tiek pārsniegts pieļaujamais atbildes gaidīšanas laiks. Sistēmas<br />
žurnālos tiks reģistrēti ziņojumi par pārsniegtiem pieprasījumu izpildes laikiem ārējās sistēmās.<br />
Prasību nodrošinās Klasifikatoru uzturēšanas modulis, kas aprakstīts 6.4.7 Klasifikatoru uzturēšanas<br />
modulis sadaļā.
Change language