Elektroniskas Veselības Kartes Informācijas sistēma - Nacionālais ...

IEGULDĪJUMS TAVĀ NĀKOTNĒElektroniskas Veselības Kartes InformācijassistēmaTehniskās arhitektūras aprakstsNVD.EVK.ARCH.3Versija 3.0.062013

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Elektroniskas Veselības Kartes InformācijassistēmaTehniskās arhitektūras aprakstsNVD.EVK.ARCH.3Versija 3.0.06ApstiprinātsApstiprināts_________________Māris TaubeNacionālais veselības dienests,Direktors2013. gada __________________________________ Andris ĶikānsA/S "Datorzinību centrs",Valdes priekšsēdētājs2013. gada _________________________________ Linda FreimaneNacionālais veselības dienests,E-veselības un starptautiskās sadarbībasdepartamentsE-veselības un standartu nodaļaProjekta vadītāja2013. gada __________________________________ Andrejs DubrovskisA/S "Datorzinību centrs",Projekta vadītājs2013. gada _________________Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 2 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Visas šī dokumenta izmantošanas tiesības tiek noteiktas saskaņā ar Latvijas RepublikasAutortiesību likumu un 22.02.2011 noslēgto līgumu Nr. VEC_2010/2/ERAF.Neatkarīgi no izmantojamiem līdzekļiem nevienu daļu no šī dokumenta nedrīkst reproducētar jebkādiem mehāniskiem, fotogrāfiskiem vai elektroniskiem līdzekļiem, pārraidīt,pārrakstīt, uzglabāt elektroniskā izguves sistēmā vai tulkot kādā citā valodā vai arī kopētjebkādā citā veidā publiskai vai privātai izmantošanai bez iepriekš saņemtas Nacionālāveselības dienesta rakstiskas atļaujas.© Nacionālais veselības dienests, 2013. Visas tiesības aizsargātas.© Datorzinību centrs, 2013. Visas tiesības aizsargātas.Nacionālais veselības dienestsCēsu iela 31 k-3, Rīga LV – 1012Tālrunis: +371 67501590Fakss: +371 67501591E-pasts: info@vmnvd.gov.lvA/S „Datorzinību centrs”Lāčplēša iela 41, Rīga, Latvija, LV-1011Tālrunis: +371 67338366Fakss: +371 67332146E-pasts: dzc@dzc.lvNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 3 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Izmaiņu vēstureNr. Izmaiņu raksturojums Datums Autors Versija Pamatojums1. Dokumenta izveidošana 09.05.2011 R.Rudmanis 0.1 Dokumentasākotnējāversija2. Redakcionālas izmaiņas visādokumentā06.06.2011 R.Rudmanis 0.2 Dokumentamelnraksts3. Sagatavots dokumenta tīrraksts 01.07.2011 R.Rudmanis 1.0 Dokumentatīrraksts4. Redakcionālas izmaiņas visādokumentā5. Redakcionālas izmaiņas visādokumentā6. Papildināts pielikums „Tehniskāsprasības”.7. Papildinātas nodaļas 6.4, 6.4.3.2,6.4.5.3, 6.4.5.4, prasība INFS.15,pielikums „EVK funkcionālaissadalījums pa moduļiem”.01.09.2011 R.Rudmanis 1.01 Caurskatesrezultāti08.09.2011 R.Rudmanis 1.02 Otrreizējāscaurskatesrezultāti16.09.2011 R.Rudmanis 1.03 Caurskatesrezultāti05.10.2011 R.Rudmanis 1.04 Dokumentagala versija8. Aktualizēts dokumenta saturs 26.09.2012 R.Rudmanis 2.0 Izstrāde9. Redakcionālas izmaiņas visādokumentā10. HL7 CDA dokumentu arhitektūrassadaļas papildināšana unaktualizācija11. Redakcionālas izmaiņas visādokumentā12. Papildinājumi pēc pasūtītājakomentāriem, visa dokumentā.20.12.2012 R.Rudmanis 2.03 Caurskatesrezultāti15.04.2013 A.Dubrovskis 3.0.04 Dokumentaaktualizācija06.06.2013 R.Rudmanis 3.0.05 Caurskatesrezultāti01.08.2013 A.Dubrovskis 3.0.06 CaurskatesrezultātiDokumenta vēstureIzmaiņasApstiprinājumiDatums Versija Autors Apraksts Datums Apstiprināja(Vārds, Amats)Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 4 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 5 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Saturs1 IEVADS ............................................................................................................................ 121.1 NOLŪKS .................................................................................................................... 121.2 DARBĪBAS SFĒRA ...................................................................................................... 121.3 DEFINĪCIJAS, APZĪMĒJUMI UN SAĪSINĀJUMI ........................................................... 131.4 SAISTĪBA AR CITIEM DOKUMENTIEM ...................................................................... 181.5 DOKUMENTA PĀRSKATS .......................................................................................... 192 IEINTERESĒTO PERSONU IEGUVUMI UN IETEKME ............................................................. 202.1 IEINTERESĒTĀS PERSONAS ...................................................................................... 202.2 IEINTERESĒTO PERSONU VAJADZĪBAS ..................................................................... 213 SKATU PUNKTI ................................................................................................................. 233.1 SISTĒMAS ARHITEKTŪRA ......................................................................................... 233.2 LOĢISKĀ ARHITEKTŪRA ........................................................................................... 243.3 FIZISKĀ ARHITEKTŪRA ............................................................................................. 253.4 PĀRVALDĪBAS ARHITEKTŪRA ................................................................................... 254 PROJEKTĒJUMA PAMATPRINCIPI ...................................................................................... 264.1 PIEŅĒMUMI UN IEROBEŽOJUMI .............................................................................. 275 SISTĒMAS ARHITEKTŪRA ................................................................................................. 285.1 SISTĒMAS SADARBĪBA ............................................................................................. 285.1.1 Lietotāju autentifikācija un autorizācija .......................................................... 295.2 LIETOTĀJU SASKARNES ............................................................................................ 325.3 SISTĒMU SASKARNES ............................................................................................... 335.4 MEDICĪNAS DOKUMENTU ARHITEKTŪRA................................................................ 375.4.1 CDA vispārīgs apraksts ..................................................................................... 375.4.2 CDA struktūra .................................................................................................. 42Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 6 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.065.4.3 CDA galvene ..................................................................................................... 445.4.4 CDA ķermenis. Sekcija ..................................................................................... 465.4.5 CDA ķermenis. Ieraksts (Entry) ........................................................................ 485.4.6 Pieeja dokumentu modeļu veidošanai un dokumentu dzīves cikls ................. 515.4.7 Dokumentu glabāšana un izmantošana e-veselības sistēmas ietvaros ........... 525.4.8 CDA dokumentu pieņēmumi un ierobežojumi ................................................ 536 LOĢISKĀ ARHITEKTŪRA ................................................................................................... 546.1 SISTĒMAS KOMPONENTU GRUPAS ......................................................................... 546.1.1 EVK tīmekļa pakalpes ....................................................................................... 546.1.2 EVK komponenti .............................................................................................. 556.2 LOĢISKAIS DATU MODELIS ...................................................................................... 556.2.1 Šifrēšanas atslēgu glabāšanas politika ............................................................. 576.2.2 Datu integritāte ............................................................................................... 596.2.3 Elektroniskais paraksts .................................................................................... 596.3 SISTĒMAS KOMPONENTU SADARBĪBA .................................................................... 606.4 SISTĒMAS KOMPONENTI ......................................................................................... 636.4.1 Autorizācijas modulis ....................................................................................... 636.4.2 Metadatu pārvaldība ....................................................................................... 646.4.3 Pamatdatu un pierakstu pārvaldība ................................................................ 696.4.4 eDoc pārbaudes serviss ................................................................................... 826.4.5 Fona uzdevumi ................................................................................................ 856.4.6 Vakcināciju modulis ......................................................................................... 896.4.7 Klasifikatoru modulis ....................................................................................... 916.4.8 IP audita un sistēmas žurnāla bibliotēkas........................................................ 936.4.9 Administrēšanas modulis ................................................................................ 936.4.10 IP apziņošanas serviss ...................................................................................... 96Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 7 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.066.4.11 e-Pakalpojumi .................................................................................................. 966.4.12 Datu noliktavas integrācijas modulis (nākotnes prasība) ................................ 976.4.13 epSOS saskarne (nākotnes prasība) ................................................................. 987 FIZISKĀ ARHITEKTŪRA ..................................................................................................... 997.1 EVK TĪMEKĻA PAKALPES .......................................................................................... 997.2 FONA UZDEVUMI ................................................................................................... 1007.3 DOKUMENTU VALIDĀCIJAS MODULIS ................................................................... 1007.4 DATU BĀZES ........................................................................................................... 1017.5 INFRASTRUKTŪRAS SERVERI.................................................................................. 1018 PĀRVALDĪBAS ARHITEKTŪRA ......................................................................................... 1028.1 PĀRRAUDZĪBA ........................................................................................................ 1028.1.1 Administrēšanas mehānismi.......................................................................... 1028.2 REZERVES KOPĒŠANA, ATJAUNOŠANA NO REZERVES KOPIJĀM ........................... 1028.2.1 Rezerves datu kopēšana ................................................................................ 1028.2.2 Datu atjaunošana no rezerves kopijām ......................................................... 1038.3 JAUNINĀJUMU INSTALĒŠANA ............................................................................... 1049 ARHITEKTŪRAS SKATU NEPRETRUNĪGUMS ..................................................................... 105Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 8 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Attēlu saraksts1. attēls. IdentitySelector lappuses piemērs ........................................................................... 292. attēls. EVK un tās sadarbība ar lietotājiem un ārējām sistēmām ........................................ 313. attēls. CDA dokumenta piemērs .......................................................................................... 424. attēls. CDA dokumenta struktūra ........................................................................................ 435. attēls. CDA dokumenta galvenes xsd shēmas fragments .................................................... 446. attēls. CDA dokumenta galvenes fragmenta piemērs ......................................................... 467. attēls. CDA dokumenta sekcijas struktūra ........................................................................... 468. attēls. CDA dokumenta sekcijas xsd shēma ........................................................................ 47Otraja līmeņa CDA dokumentiem sekcijas nesatur strukturētu datu laukus: ......................... 489. attēls. CDA dokumenta sekcijas aizpildīšanas piemērs ....................................................... 4810. attēls. CDA dokumenta ieraksta struktūra ........................................................................ 4811. attēls. Organizer (grupējums) elementa piemērs ............................................................. 4912. attēls. Observation (novērojums) elementa struktūra ...................................................... 5013. attēls. Observation (novērojums) elementa izmantošanas piemērs ................................ 5114. attēls. Dokumenta veidošanas un izmantošanas dzīves cikls............................................ 5115. attēls. EVK komponentu grupas ........................................................................................ 5416. attēls. EVK loģiskais datu modelis ..................................................................................... 5617. attēls. Personificētie dati ................................................................................................... 5618. attēls. Veselības pamatdati ............................................................................................... 5719. attēls. Šifrēšanas atslēgu hierarhija ................................................................................... 5820. attēls. EVK loģiskie komponenti un to sadarbība .............................................................. 6221. attēls. No stacionāra izrakstīta pacienta karte MDHT UML modelēšanas rīkā ................. 6622. attēls. EVK sekciju tipi MDHT UML modelēšanas rīkā ....................................................... 6723. attēls. Pacienta kartes testa dokumenta izveide ............................................................... 6824. attēls. Pacienta kartes stāvokļi .......................................................................................... 71Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 9 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0625. attēls. Pacienta karšu izveide ............................................................................................ 7226. attēls. Pacienta kartes asinhronā apstrāde ....................................................................... 7327. attēls. EVK dokumenta stāvokļi ......................................................................................... 7528. attēls. SOAP aploksnes saturs ............................................................................................ 7628. attēls. EVK dokumentu pievienošana ................................................................................ 7729. attēls. EVK dokumentu asinhronā apstrāde ...................................................................... 7930. attēls. EVK dokumentu iegūšana ....................................................................................... 8131. attēls. eDoc pārbaudes servisa loģiskais plānojums.......................................................... 8232. attēls. Fona uzdevumi ....................................................................................................... 8633. attēls. e-Pakalpojumu arhitektūra ..................................................................................... 9734. attēls. EVK loģisko komponentu izvietojums uz serveriem ............................................... 99Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 10 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Tabulu saraksts1. tabula. Definīcijas un skaidrojumi ....................................................................................... 132. tabula. Apzīmējumi un saīsinājumi ...................................................................................... 143. tabula. Ieinteresēto personu vajadzības ............................................................................. 214. tabula. Sistēmas konteksta diagrammas elementi .............................................................. 235. tabula. Vadības plūsmas diagrammas elementi .................................................................. 246. tabula. Galvenās EVK lietotāju grupas ................................................................................. 327. tabula. EVK saskarnes ar ārējām sistēmām ......................................................................... 33Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 11 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.061 Ievads1.1 NolūksElektroniskās Veselības Kartes informācijas sistēmas (EVK IS) programmatūras tehniskāsarhitektūras apraksta mērķis ir aprakstīt galvenos EVK IS izveides principus un risinājumaelementus, tādā veidā definējot risinājuma aprises un arī nodrošinot, ka viss risinājums tiekveidots pēc vienotiem principiem.Dokuments ir saistošs:• no Pasūtītāja puses projektā iesaistītajām personām,• EVK IS izstrādātājiem,• EVK IS testētājiem,• kā arī informatīvs materiāls citiem projektā iesaistītajiem dalībniekiem un projektavadītājiem.Dokuments izstrādāts balstoties uz līgumu VEC_2010/2/ERAF, kas noslēgts starp VeselībasEkonomikas Centru un A/S Datorzinību Centrs, turpmāk Izstrādātājs.Saskaņā ar MK rīkojumu Nr. 436 „Par Veselības norēķinu centra un Veselības ekonomikascentra reorganizāciju”, kopš 01.11.2011. Nacionālais veselības dienests, turpmāk Pasūtītājs,ir VEC funkciju, pārvaldes uzdevumu, tiesību, saistību, finanšu līdzekļu, mantas un lietvedībaspārņēmējs.Dokuments būs uzskatāms par pabeigtu, kad Pasūtītāja un Izpildītāja puses piekritīs tāsaturam, pieņems to un attiecīgi parakstīs to pēc abpusējas saskaņošanas.Dokuments izstrādāts, izmantojot „IEEE ISO/IEC 1471-2000 Systems and softwareengineering - recommended practice for architectural description” standartu.1.2 Darbības sfēraDokuments apraksta būtiskākās Elektroniskās veselības kartes informācijas sistēmas uzbūviietekmējošās prasības un galvenos tehniskos risinājumus, kurus jāievēro, lai nodrošinātusistēmas atbilstību izvirzītajām prasībām.Šis dokuments tiks izmantots kā pamats turpmākajiem projekta darbiem: EVK sistēmasprojektēšanai, izstrādei un testēšanai.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 12 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.061.3 Definīcijas, apzīmējumi un saīsinājumi1. tabula. Definīcijas un skaidrojumiTerminsAbstrakcijaAtribūtsDarbplūsmasprogrammavadībasSkaidrojumsBūtisko aspektu izdalīšana un mazsvarīgu aspektu ignorēšana.Klases objekta informatīvs elements, kas apzīmē kādu īpašību.Programma, kas, izmantojot vairākus resursus, vada noteikta procesaizpildi, kurš sastāv no savstarpēji saistītiem uzdevumiem.Elektroniskais parakstsKlaseMedicīniska dokumentasekcijaMedicīnisks dokumentsObjektsPacienta kartePārvaldības darbībaProjektsSistēmaTīmekļa pakalpesZiņojumsDrošs elektroniskais paraksts pēc EDL definīcijas.Objektu kopa, kam ir kopīgi atribūti un pārvaldības darbības.Medicīniskā dokumenta struktūras daļa, ar noteiktu struktūru un datukopu, kas satur gan klasificētas vērtības, gan tekstuālu aprakstu.EVK kontekstā medicīniskais dokuments ir elektronisks medicīnisksieraksts, kas pievienots pacienta kartei.Objektorientētā programmēšanā - vienība, kas satur informāciju unpārvaldības darbības.EVK kontekstā pacienta karte ir elektroniska datu kopa, kas satur pacientapersonas datus, veselības pamatdatus un medicīniskos dokumentus.Darbība vai transformācija, ko piemēro klases objektam vai ko izpilda patsobjekts.Elektroniskās veselības kartes informācijas sistēmas izstrādes projektssaskaņā ar līgumu VEC_2010/2/ERAF, kas noslēgts starp VeselībasEkonomikas Centru un A/S Datorzinību Centrs.Elektroniskās veselības kartes informācijas sistēma, EVK IS.Vienots veids, kā sistēmām, kas strādā dažādās platformās, rakstītasdažādās valodās u.t.t., savstarpēji sazināties. Tīmekļa pakalpes nodrošinainformācijas apmaiņas iespēju, nepārzinot otras puses sistēmas unprogrammatūru. Tiek izdalīti pakalpes lietotāji un pakalpes sniedzējs.Objektu saziņas līdzeklis.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 13 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.062. tabula. Apzīmējumi un saīsinājumiApzīmējums,saīsinājumsASN.1DBCCDCDCDADBVSDMKEDEDLeDocepSOSEVAKEVKHL7HTMLIISIPIRAprakstsNo angļu valodas [Abstract Syntax Notation number One] – notācija, kastiek lietota komunikāciju protokolu formālajiem aprakstiemDatu bāzeNo angļu valodas [Continuity of Care Document] – dokuments aprūpesnepārtrauktībaiHL7 kodēto (klasificēto) datu tipsNo angļu valodas [Clinical Document Architecture] – klīnisko dokumentuarhitektūraDatu bāzu vadības sistēmaNo angļu valodas [Database Master Key] – DMK ir SQL servera ģenerētasimetriskā kriptogrāfijas atslēga, kas tiek izmantota citu atslēgu šifrēšanaiHL7 datu tips, kas nodrošina nestrukturēto (tekstveidā) datu glabāšanu,nodrošina arī iespēju papildus glabāt bināro datu fragmentus.Elektronisko dokumentu likums tā spēkā esošajā redakcijāParakstīto dokumentu failu formāts, kas satur dokumentu, elektroniskoparakstu un laika zīmoguNo angļu valodas [Smart Open Services for European Patients] - Eiropasmēroga e-Veselības sadarbības projektsEiropas veselības apdrošināšanas karteElektroniskā veselības karteNo angļu valodas [Health Level 7] – klīnisko dokumentu elektroniskā veidastandartsNo angļu valodas [Hypertext Markup Language] – valoda, kas, izmantojotspeciālus kodus, nosaka hiperteksta dokumenta atveidojumu displejaekrānā gadījumā, ja tiek lietotas tīkla Internet globālā tīmekļa lappusesNo angļu valodas [Internet Information Services] - interneta informācijasservissE-veselības integrācijas platformaIedzīvotāju reģistrsNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 14 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Apzīmējums,saīsinājumsIVL_TSKMMDHTNLBNMPDNVDNVD VISOCSPOIDPDFPMLPPREDASBSSMKSOAPSQLSSKSMTPTDEAprakstsHL7 datu tips, kas nodrošina laiku vai laika intervālu glabāšanuKlasifikatoru modulisNo angļu valodas [Model-Driven Health Tools] – CDA dokumentumodelēšanas rīksNo angļu valodas [Network Load Balancing] – slodzes dalīšanastehnoloģijaNeatliekamās medicīniskās palīdzības dienestsNacionālais veselības dienestsNacionālā Veselības Dienesta Vadības informācijas sistēmaNo angļu valodas [On-Line Certificate Status Protocol] - protokols, kas ļaujveikt sertifikāta derīguma pārbaudi tiešsaistes režīmāNo angļu valodas [Object Identifier Definition] – objekta identifikatoradefinīcijaNo angļu valodas [Portable Document Format] – dokumenta formātsPilsonības un migrācijas lietu pārvaldeAr noteiktām slimībām slimojošo pacientu reģistrsNo angļu valodas [SQL Service Broker Services] – Microsoft SQL serverakomponente, kas nodrošina asinhronu ziņojumu sūtīšanu un saņemšanustarp apakšsistēmāmNo angļu valodas [Service Master Key] - SMK ir SQL servera augstākālīmeņa kriptogrāfijas atslēga, kas tiek izmantota, lai aizsargātu serveralīmeņa konfidenciālos datusNo angļu valodas [Simple Object Access Protocol] - uz XML valodu bāzētsWeb servisu ziņojumu apmaiņas standarts. SOAP definē aploksnesformātu un virkni noteikumu tā satura aprakstamNo angļu valodas [Structured Query Language] - firmas IBM izstrādātavaloda, ko lieto datu bāzes pārvaldības sistēmās dažāda tipa datorosStarptautisks slimību katalogsNo angļu valodas [Simple Mail Transfer Protocol] – elektroniskā pastapārsūtīšanas standartsNo angļu valodas [Transparent Data Encryption] – datu pārredzamāNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 15 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Apzīmējums,saīsinājumsAprakstsšifrēšana, kas notiek reālā laikāTSTSTSAUMLTehniskā specifikācijaHL7 datu tips, kas nodrošina datuma/laika glabāšanuNo angļu valodas [Time stamping authority] – iestāde, kas izsniedz laikazīmogus elektroniskiem parakstiemNo angļu valodas [Unified Modeling Language] – grafisko valodu kopa, kasļauj modelēt visdažādākos biznesa un programmatūras izstrādesaspektus. Tā ir uz metamodelēšanu balstīta valoda, kura orientēta uzsistēmas arhitektūru un projektēšanu.USPS Valsts akciju sabiedrība "Latvijas Valsts radio un televīzijas centrs" -uzticams sertifikācijas pakalpojumu sniedzējsVRZIPVakcinācijas reģistrsFailu formāts, kas tiek lietots datu arhivēšanaiX.509 Kriptogrāfijas standartsXAdESXMIXMLXML Advanced Electronic Signatures (ETSI TS 101 903, version number1.3.2, 2006-03), elektroniskā paraksta metadatu formāta standartsNo angļu valodas [XML Metadata Interchange] – specifikācija, kasnodrošina izstrādātājiem iespēju apmainīties ar datu modeļiem, kas irizstrādāti ar dažādiem rīkiem un dažādās valodās, piemēram, UnifiedModeling Language (UML).No angļu valodas [eXtensible Markup Language] - specifikācija, kasnodrošina izstrādātājiem iespēju radīt pašiem savas iezīmēšanas valodas,definējot personiskās birkas (kodus).Šī valoda ir izstrādāta strukturētu dokumentu apmaiņai starp dažādāmplatformām.XSLTNo angļu valodas [XSL Transformations]XSL valodas transformācija stila lapas formā, ar labi noformētu XML[XML1.0] sintaksi, kas atbilst XML nosaukumvietas rekomendācijām[Namespaces in XML Recomendations].XSLWCFNo angļu valodas [Extensible Stylesheet Language] – paplašināmā stilalapu valodaNo angļu valodas [Windows Communication Foundation] – apakšsistēmusavstarpējās saziņas programmatūras bibliotēkaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 16 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Apzīmējums,saīsinājumsWSUSWS-*AprakstsNo angļu valodas [Windows Server Update Services] – komponente, kasnodrošina sistēmas atjauninājumu automātisku izplatīšanu datortīklāWeb pakalpju drošības standartu kopaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 17 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.061.4 Saistība ar citiem dokumentiem[1] Programmatūras prasību specifikācija. Elektroniskās veselības kartes informācijassistēma. Versija 1.0. VEC.EVK.PPS.CR1.1.0. Rīga, 2011[2] Infrastruktūras prasību dokuments. Elektroniskās veselības kartes informācijassistēma. Versija 1.01. VEC.EVK.INFRA.01. Rīga, 2011[3] Programmatūras prasību specifikācija. Elektroniskas veselības kartes vakcinācijureģistra informācijas sistēma. Versija 1.0. VEC.EVK.PPS.VR1.01. Rīga, 2011[4] Programmatūras prasību specifikācija. Elektroniskas Veselības Kartes Informācijassistēma. Klasifikatoru modulis. Versija 1.0. VEC.EVK.PPS.KM1.01. Rīga, 2011[5] Projekta Integrācijas platformas informācijas sistēmas izstrāde arhitektūras risinājumavīzijas dokuments. Versija 1.0. VEC-132-E_VES_IP-RAVD. Rīga, 2011[6] Tehniskās arhitektūras apraksts. Veselības aprūpes elektroniskonosūtījumu/elektronisko pierakstu informāciju sistēmas un e-Veselības lietotāju WEBplatformas izstrāde, ieviešana un garantijas uzturēšana. Versija 0.9.VEC.EBOOK.TAA.0.9. Rīga, 2011[7] VEC e-veselības projektu arhitektūras vadlīnijas. VEC.EHG.ARCH.1.0. Rīga, 2010[8] Tehniskā specifikācija. Elektroniskās veselības kartes informācijas sistēmasizstrādāšana. SIA „AA projekts”. 1.sējums, 2.sējums. Rīga, 2010[9] Tehniskā specifikācija. Elektroniskās veselības kartes informācijas sistēmasizstrādāšana. SIA „AA projekts”. 3.sējums. VEC.STD.ISREQ.1.0. Rīga, 2010[10] Sistēmas arhitektūra un darbības koncepcijas apraksts. Elektroniskās veselības kartesinformācijas sistēma. Iepirkuma dokumentācija. Versija 1.3. EVK.PRO.1.TS.2.SDK.1.1.Rīga, 2010[11] Robertson, James, and Suzanne Robertson, Complete Systems Analysis, ISBN-10:0932633501, Dorset House; 2nd edition, 1998[12] 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[13] Terminoloģijas vārdnīca. Elektroniskās Veselības Kartes Informācijas sistēma.VEC.EVK.Glossary.1.0, Rīga, 2011[14] Programmatūras prasību specifikācija. 2.izstrādes kārta. Elektroniskās veselības kartesinformācijas sistēma. NVD.EVK.PPS.CR2.1.0. Rīga, 2012[15] Interfeisu specifikācijas dokuments. Elektroniskās Veselības Kartes Informācijassistēma. VEC.EVK.INT.CR1.0.2.[16] Interfeisu izmantošanas rokasgrāmata. Integrācijas Platformas Informācijas Sistēmasizstrāde. Klasifikatoru Reģistrs. NVD.IP.ADM.IIR.KLR.1.00.[17] Veselības aprūpes elektronisko nosūtījumu/elektronisko pierakstu informācijusistēmas un e-Veselības lietotāju WEB platformas izstrāde, ieviešana un garantijasuzturēšana. Tehniskās arhitektūras apraksts. VEC.EBOOK.TAA.1.0. Rīga, 2011[18] E-veselības ziņojumapmaiņā izmantojamo datu struktūras. VEC.STD.HL7.1.00. Rīga,2012.[19] Elektroniskās Veselības Kartes Informācijas sistēma, Saskarņu izmantošanasrokasgrāmata, NVD.EVK.INTHB.CR3.1.3, Versija 1.3, 2013Izmantotie dokumenti pieejami projekta dokumentu bibliotēkā darbalapas.dzc.lv.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 18 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.061.5 Dokumenta pārskatsDokumentā iekļautas šādas nodaļas:1. nodaļā sniegts ieskats dokumenta saturā un struktūrā.2. nodaļā aprakstītas projekta veiksmē ieinteresētās personas (stakeholders) un to grupas:sistēmas pasūtītājs, lietotāji, izstrādātāji un uzturētāji, to ieguvumi un ietekme, kā arī togalvenās vajadzības, kas ir ņemtas vērā, izstrādājot sistēmas tehnisko arhitektūru.3. nodaļā aprakstīti tehniskās arhitektūras aprakstā izmantotie skatu punkti (viewpoints), tomērķauditorija, dokumentēšanas veids, kā arī sniegts konkrēto skatu punktu izvēlespamatojums.4. nodaļā aprakstīti galvenie projektēšanas lēmumi, kas ietekmē visu risinājumakomponentu izveidi un darbināšanu. Katram aprakstītajam principam (projektējumalēmumam) aprakstīti arī alternatīvie risinājumi un sniegts pamatojums, kāpēc izvēlēts tiešikonkrētais projektējuma lēmums nevis kāds no alternatīvajiem.5. nodaļā aprakstīta sistēmas funkcionalitāte un sadarbība ar sistēmas lietotājiem un ārējāmsistēmām. Nodaļas mērķis ir noteikt sistēmas apjomu (robežas) un precizēt sadarbībasprotokolus un pieejas, kuras tiks atbalstītas.6. nodaļā aprakstīti sistēmas iekšējie komponenti, identificēts, kādi no šiem komponentiemnodrošina ārējo saskarņu funkcionalitāti, noteikti arī sistēmas iekšējo komponentu unmoduļu sadarbības scenāriji, nepieciešamās saskarnes, to specifika (autentifikācija,protokoli).7. nodaļā sniegts īss apskats par loģisko komponentu izvietošanas variantiem, kurusnodrošina izmantotie arhitektūras risinājumi.8. nodaļā sniegta informācija par arhitektūras elementiem, kas izveidoti sistēmasuzturēšanas atvieglošanai.9. nodaļā aprakstīta arhitektūras skatu nepretrunīguma analīze, kā arī identificētas visaszināmās arhitektūras skatu neatbilstības.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 19 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.062 Ieinteresēto personu ieguvumi un ietekmeŠajā nodaļā ir aprakstītas projekta veiksmē ieinteresētās personas (stakeholders) un togrupas: sistēmas pasūtītājs, lietotāji, izstrādātāji un uzturētāji, to ieguvumi un ietekme, kā arīto galvenās vajadzības, kas ir ņemtas vērā, izstrādājot sistēmas tehnisko arhitektūru.2.1 Ieinteresētās personasProjekta veiksmē ir ieinteresētas šādas galvenās personu grupas:Sistēmas lietotājio Pacientio Ārstniecības personaso Ārstniecības iestāžu vadītājio Administratīvais personālso Veselības aprūpi kontrolējošās valsts institūcijaso Izglītības, zinātniskās pētniecības un citas organizācijaso Sistēmas administratoriPasūtītājiIzstrādātājiUzturētājiIeinteresētās personas, kas būs sistēmas lietotāji, un to ieguvumi ir aprakstīti dokumenta„Sistēmas arhitektūra un darbības koncepcijas apraksts” sadaļā „2.4.1 Sistēmas lietotāji”,skat. [9].Primārie ieguvēji EVK sistēmas izveidošanas gadījumā būs pacients un ārstniecības personas,kas nepastarpināti sniedz ārstniecības pakalpojumus šim pacientam un kuru rīcībā būs pilnainformācija par pacienta veselības stāvokli, lai pieņemtu pamatotākus lēmumus parturpmāko ārstēšanas procesu vai profilakses pasākumiem.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 20 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.062.2 Ieinteresēto personu vajadzībasIeinteresētās personas ir personas, personu grupas vai organizācijas, kas ir ieinteresētasprojekta veiksmē un kurām ir konkrētas vajadzības un intereses sistēmas arhitektūraskontekstā. Ieinteresēto personu galvenās vajadzības ir uzskaitītas tabulā zemāk.3. tabula. Ieinteresēto personu vajadzībasPersonu grupasVajadzībasPacienti Sekot savas veselības aprūpes procesam – uzstādītajaidiagnozei, izmeklējumu rezultātiem un ārstēšanas plānamPiekļūt saviem medicīniskajiem ierakstiem un kontrolētārstniecības personu darbuĒrtāk saņemt precīzas instrukcijas par viņu ārstēšanas plāniem(piemēram, zāļu lietošanu) vai preventīvajiem pasākumiem(piemēram, vakcināciju)Ārstniecības personas Efektīvāk sniegt veselības aprūpes pakalpojumusSaņemt datus par pacientiem, kas ārstējas vai ārstēsies pieviņiem no citām ārstniecības personāmVeselībaskontrolējošāsinstitūcijasaprūpivalstsEfektīvi pārvaldīt veselības aprūpes nozariPreventīvo veselības aprūpes plānu sastādīšana un izpildeskontroleIegūt juridiskos pierādījumus aprūpes pakalpojumu gadījumuizmeklēšanas gaitāIzglītības, zinātniskāspētniecības un citasorganizācijasSaņemt EVK datus, piemēram, medikamentu un ārstēšanaspaņēmienu efektivitātes novērtēšanai, kā arī citiem mērķiematkarībā no iestādes specifikas un mērķiemIegūt statistiskos datus par iedzīvotāju veselībuAdministratori Sistēmas pārraudzība un pārvaldībaSistēmas pieejamība, elastīgums un mērogojamībaSistēmas darbības nepārtrauktība un darbības atjaunošanasspējasPasūtītāji Atbilstība veselības nozares stratēģiskajiem mērķiemVeikto ieguldījumu atmaksāšanāsSistēmas ieviešana laikā un plānotajā budžetāNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 21 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Personu grupasVajadzībasEfektīva resursu izmantošana ieviešanas un darbināšanas laikāSistēmas testējamībaIzstrādātāji Izpratne par sistēmas kopējo uzbūvi jeb arhitektūruSarežģītāko sistēmas elementu detalizētāks uzbūves aprakstsIzmantotā platforma, standarti, programmēšanas valodas,analīzes, izstrādes un testēšanas rīkiSistēmas uzturamībaSistēmas pielāgojamībaArhitektūras zināšanu saglabāšanaUzturētāji Sistēmas dokumentācijaSistēmas pārraudzība un pārvaldībaSistēmas traucējummeklēšana un atkļūdošanaProdukcijas vides izmaiņu pārvaldībaArhitektūras zināšanu saglabāšanaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 22 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.063 Skatu punktiŠajā nodaļā ir aprakstīti tehniskās arhitektūras aprakstā izmantotie skatu punkti (viewpoints),to mērķauditorija, dokumentēšanas veids, kā arī sniegts konkrēto skatu punktu izvēlespamatojums.3.1 Sistēmas arhitektūraSistēmas arhitektūras skatu punkts apraksta sistēmas funkcionalitāti un tās sadarbību arsistēmas lietotājiem un ārējām sistēmām. Tās mērķis ir noteikt sistēmas apjomu (robežas) unprecizēt sadarbības protokolus un pieejas, kuras tiks atbalstītas.Sistēmas arhitektūras dokumentēšanai tiek pielietota sistēmas konteksta diagramma(System Context Diagram), kas apraksta augstākā līmeņa sistēmas arhitektūru. Sistēmaskonteksta diagrammā izstrādājamā sistēma ar nolūku tiek attēlota kā „melnā kaste”,nenorādot sistēmas iekšējo uzbūvi un tās komponentus. Šī diagramma palīdz labāk izprastsvarīgākos sistēmas ārējos interfeisa punktus (lietotājus, sistēmas, iekārtas u.c.), ar kosistēmai būs jāsadarbojas.Sistēmas konteksta diagramma parasti attēlo izstrādājamo sistēmu centrā, neattēlojot tāsiekšējās uzbūves detaļas, kurai pa perimetru tiek uzrādīti lietotāji, sistēmas un iekārtas, ar košai sistēmai būs jāsadarbojas. Diagrammas mērķis ir fokusēties uz sistēmas ārējiem faktoriemun notikumiem, kas ir jāņem vērā, izstrādājot sistēmas arhitektūru. Tā palīdz izprast sistēmasvietu kopējā e-Veselības platformas kontekstā.Sistēmas konteksta diagramma tiek veidota kā augsta līmeņa datu plūsmas diagramma (DataFlow Diagram), kas ir izstrādāta atbilstoši strukturētās analīzes principiem, skat. [11].Sistēmas konteksta diagramma sastāv no šādiem grafiskajiem elementiem:4. tabula. Sistēmas konteksta diagrammas elementiGrafiskais elementsAprakstsSistēmaĀrējās sistēmas vai moduļiLietotājiDatu plūsmasNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 23 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Sistēmas konteksta diagramma tiek izstrādāta pašā projekta sākumā, lai projektadalībniekiem rastos vienāds priekšstats par izstrādājamās sistēmas apjomu un robežām. Tā irparedzēta pilnīgi visām projektā iesaistītajām pusēm.3.2 Loģiskā arhitektūraLoģiskās arhitektūras skatu punkts apraksta sistēmas iekšējos komponentus, identificē, kādino šiem komponentiem nodrošina ārējo saskarņu funkcionalitāti, kā arī nosaka sistēmasiekšējo komponentu un moduļu sadarbības scenārijus, nepieciešamās saskarnes un tospecifiku, piemēram, izmantotos autentifikācijas mehānismus vai protokolus. Loģiskāarhitektūra apraksta arī loģisko komponentu funkcionalitāti un to darbināšanai izmantotosproduktus un tehnoloģijas. Tās mērķis ir sadalīt izstrādājamo sistēmu sīkākās vienībās –komponentos un moduļos, lai sadalītu izstrādes darbus un varētu veikt to plānošanu. Katrukomponentu vai moduli var izstrādāt viens atsevišķs cilvēks vai izstrādātāju grupa.Loģiskās arhitektūras dokumentēšanai tiek pielietotas vadības plūsmas diagrammas (ControlFlow Diagram), kurās esošās bultas apzīmē moduļu atkarības jeb izsaukumu virzienus, unplūsmkartes (flowchart). Ar vadības plūsmas diagrammas palīdzību tiek attēlota sistēmasloģisko komponentu karte, kurā ilustrēta komponentu savstarpējā sadarbība un sadarbība arārējām sistēmām. Atsevišķu komponentu uzbūve un to algoritmi tiek attēloti, izmantojotplūsmkartes diagrammas.Vadības plūsmas diagrammas sastāv no šādiem grafiskajiem elementiem:5. tabula. Vadības plūsmas diagrammas elementiGrafiskais elementsAprakstsSistēmas komponenti un moduļiSistēmas datu glabātuvesDatu plūsmasPaskaidrojumiIzstrādājot loģisko arhitektūru, galvenokārt tiek ņemtas vērā funkcionālās prasības. Tā palīdzsaprast sistēmas kopējo uzbūvi jeb arhitektūru, kā arī izmantoto platformu, tehnoloģijas unstandartus. Loģiskā arhitektūra kalpo kā pamats izstrādes darbu plānošanai, izmaksuNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 24 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06vērtēšanai un sistēmas prasību sadalīšanai pa komponentiem. Loģiskā arhitektūra satur arīsarežģītāko sistēmas 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ūrasgalvenās mērķauditorijas ir sistēmas izstrādātāji un uzturētāji.3.3 Fiziskā arhitektūraFiziskās arhitektūras skatu punkts apraksta loģisko komponentu izvietošanas variantus, kurusnodrošina izmantotie arhitektūras risinājumi.Detalizēts infrastruktūras apraksts, nepieciešamie infrastruktūras elementi, datu apjoma,transakciju skaita un sagaidāmās ātrdarbības novērtējumi, kā arī rekomendētie risinājumiaugstas pieejamības nodrošināšanai ir aprakstīti Infrastruktūras prasību dokumentā, skat.[2].Fiziskās arhitektūras galvenās mērķauditorijas ir sistēmas pasūtītājs un uzturētāji.3.4 Pārvaldības arhitektūraPārvaldības arhitektūras skatu punkts apraksta arhitektūras elementus, kas ir izveidotisistēmas uzturēšanas atvieglošanai. Tā mērķis ir definēt, kā sistēma tiks kontrolēta,pārvaldīta un pārraudzīta tās darbināšanas laikā. Pārvaldības arhitektūra apraksta sistēmasadministrēšanas mehānismus, kā arī sistēmas pārraudzības, rezerves kopēšanas unjauninājumu instalēšanas stratēģijas.Tā ir paredzēta pilnīgi visām projektā iesaistītajām pusēm, tomēr pārvaldības arhitektūrasgalvenās mērķauditorijas ir sistēmas administratori un uzturētāji.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 25 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.064 Projektējuma pamatprincipiŠī nodaļa satur galvenos projektēšanas lēmumus, kas ietekmēs visu risinājuma komponentuizveidi un darbināšanu.Katrs no projektējuma pamatprincipiem ir aprakstīts savā numurētā paragrāfā, nodrošinot,ka uz katru no tiem var veikt atsauces šī dokumenta un citu projektējuma dokumentuietvaros. Katram aprakstītajam principam (projektējuma lēmumam) sniegts pamatojums,kāpēc izvēlēts tieši konkrētais projektējuma lēmums.1) Lai nodrošinātu augstu risinājuma pieejamību un visu pieejamo serveru resursuizmantošanu, tīmekļa pakalpes tiek darbinātas „active-active” režīmā, kas nozīmē, kaserveru normālas darbības gadījumā tīmekļa pakalpju izsaukumi tiks sadalīti starpserveriem. Sesiju un pieprasījumu sadalīšanu starp serveriem veic slodzes dalītāji.2) EVK sistēmas iekšējie moduļi savā starpā sadarbojas „uzticamās apakšsistēmas” (noangļu valodas – trusted subsystem) režīmā – netiek veikta izsaucošā komponentaautentificēšana un datu plūsmas šifrēšana. Integrācijas platformā eksponēto EVK tīmekļapakalpju izsaukumi pilnīgi vienmēr tiek autentificēti un to datu plūsma šifrēta. Jebkuriturpmākie izsaukumi netiek autentificēti, jo pārējās komponentes uzticas tīmekļapakalpēm un atrodas ar tiem vienā drošības zonā.Šāda pieeja samazina sistēmas konfigurēšanas darbu un līdz ar to arī uzturēšanasapjomu. Ar šo pieeju saistītie drošības riski ir minimāli, jo iekšējā datu centra vide irfiziski norobežota un pieejama tikai uzticamiem sistēmas administratoriem.3) Integrācija ar citām sistēmām EVK tiek nodrošināta, izmantojot tīmekļa pakalpes, kas irizvietotas e-Veselības Integrācijas Platformā (IP).4) Ārējām sistēmām, kuras nevar garantēt pieprasījumu apstrādi mazāk kā 3 sekundēs,servisu izsaukumi galvenokārt tiek veikti asinhroni.5) Lai EVK veidotu kā modulāru sistēmu, tās arhitektūrā tiek izmantots tā saucamaisadapteru princips. Tas nodrošina vienotas saskarnes katram adapteru tipam, piemēram,EVK dokumentu validatoriem, EVK dokumentu pārveidotājiem datorizētās prezentācijasformātos (HTML, PDF, u.c.), sekciju apstrādes uzdevumiem un fona uzdevumiem. Tā kāviena tipa adapteriem ir identiskas saskarnes un sistēmas konfigurācijā tiek norādītssaraksts ar konkrētā tipa adapteriem, jauns adapteris var tikt pievienots, izveidojotadaptera moduli ar atbilstošo saskarni un pievienojot to sistēmas konfigurācijā. Tasnodrošina sistēmas papildināšanu ar jauniem dokumentu un to sekciju tipiem, kā arījauniem datorizētās prezentācijas formātiem.6) Lietotāju un sistēmu darbību autorizēšanai tiek izmantota informācija par lietotājupiederību lomām. IP tiks izveidotas visas EVK nepieciešamās ārstniecības personu lomasatbilstoši lietotāju darba vajadzībām, kā arī notiks ārstniecības personu autorizācija.Pacientu autorizācija notiks EVK sistēmā. Tiesību kontrole ir balstīta uz lietotājupiederību lomām.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 26 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.067) Regulāri izpildāmie darbi tiek veikti kā atsevišķi veidots process (Windows serviss) fonadarbu veikšanai. Alternatīvais risinājums ir tos veikt kā darba plūsmas, piemēram,izmantojot Windows Workflow Foundation darbplūsmas vadības programmu (workflowengine). Darba plūsmas ir vairāk piemērotas biznesa procesu apstrādei, kur katra biznesaprocesa instance rada jaunu darba plūsmu instanci. Darba plūsmas ir grūtāk uzturēt, jodarba plūsmas definīcijas izmaiņu gadījumā ir jāļauj pabeigties aktīvajām darba plūsmasinstancēm. Gadījumos, kur ir nepieciešama salīdzinoši vienkārša periodiska pakešveidauzdevumu veikšana fona režīmā, atsevišķi veidots Windows serviss ir vienkāršākizveidojams un uzturams.8) Risinājumā ir izmantota serveru virtualizēšana, lai nodrošinātu vairāku WEB un datubāzes serveru darbināšanu un lai izvietotu testa, apmācību un izstrādes vides;9) Kļūdu un atteices gadījumu ziņojumi tiek ievietoti IP sistēmas žurnāla datu bāzēs,izmantojot IP bibliotēku. Sistēmas administratori tos varēs aplūkot, izmantojot IPadministratīvos rīkus. Ziņojumus, kas ievietoti IP sistēmas žurnāla datu bāzēs, varēsautomātiski apstrādāt NVD monitoringa risinājums;10) Lai pārliecinātos, ka EVK komponenti laika gaitā nav tikuši mainīti un līdz ar to tos varuzskatīt par autentiskiem un uzticamiem, visi EVK komponenti tiks elektroniski parakstīti.4.1 Pieņēmumi un ierobežojumiŠajā nodaļā aprakstīti pieņēmumi un ierobežojumi, uz kuriem balstās galvenie sistēmasprojektēšanas lēmumi un kuri jāņem vērā, izstrādājot fizisko sistēmas projektējumu unplānojot risinājuma uzturēšanu:Tiks izveidotas un ieviestas centralizētās e-Veselības sistēmas – Integrācijasplatforma, e-Recepte, e-Pieraksti, e-Nosūtījumi un e-Veselības portāls;Tiek pieņemts, ka EVK sistēmas izstrādes laikā Pasūtītājs būs nodrošinājis sadarbībasiespēju ar ārējo sistēmu uzturētājiem, ar kuriem paredzēti starpsistēmu interfeisi, unno kuru sistēmām paredzēta sākotnējā datu ielāde;Tādas koplietošanas funkcijas kā lietotāju tiesību pārvaldība, autentifikācija,autorizācija, audits un sistēmas žurnāls nodrošinās Integrācijas platformas modulis;EVK projekta ietvaros realizējamie precīzi dokumentu tipi un tiem nepieciešamiesekciju tipi tiks definēti projektējuma un projekta izstrādes laikā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 27 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.065 Sistēmas arhitektūraŠajā nodaļā ir aprakstīta sistēmas funkcionalitāte un sadarbība ar sistēmas lietotājiem unārējām sistēmām. Nodaļas mērķis ir noteikt sistēmas apjomu (robežas), definēt sistēmasvietu vispārējās e-Veselības vides kontekstā un precizēt sadarbības protokolus un pieejas,kuras tiks atbalstītas.Pašas sistēmas komponenti, kas nodrošina šo sadarbību, ir aprakstīti nodaļā Loģiskāarhitektūra (skat. 6. nodaļu).5.1 Sistēmas sadarbībaSistēma un tās sadarbība ar svarīgākajām veselības nozares sistēmām un galvenajām klientugrupām ir shematiski parādīta 2. attēlā, lai sniegtu priekšstatu par sistēmas darbības vidi unnepieciešamo integrāciju. Ar raustītu elementa robežu ir attēlotas nākotnē plānotās sistēmasvai moduļi.Attēlā ir parādītas tikai loģiskās saites starp sistēmām. Sistēmu sadarbība e-Veselības vidēnotiks ar e-Veselības Integrācijas Platformas (IP) starpniecību. Pamata informācijas apmaiņasprotokols būs SOAP (Simple Object Access Protocol), ar kura palīdzību ārējās sistēmas piekļūspublicētajām EVK tīmekļu pakalpēm. Tāpat arī EVK izsauks ārējās sistēmas ar IP starpniecību.Iedalījums funkcionālajos blokos šajā attēlā veikts atbilstoši sistēmas vai sistēmas moduļutehniskai un funkcionālajai specifikai, izvietošanas pieejai, kā arī sadarbībai ar citām veselībasnozares sistēmām.Lietotāji izmantos EVK sistēmas funkcionalitāti, strādājot ar e-Veselības portālu,www.latvija.lv e-Pakalpojumiem vai ārstniecības iestādes (ģimenes ārsta prakses) sistēmu,kura integrēta ar EVK tīmekļa pakalpēm. EVK lietotāju saskarnes komponenti tiks izvietotie-Veselības portālā.Gadījumā, ja būs nepieciešama ziņojumu apmaiņa ar sistēmām, kuru pieejamība netiekgarantēta, ziņojumu uzkrāšanu un piegādi, kad pieslēgums šādām sistēmām būs atjaunots,nodrošinās IP.IP sistēma nodrošinās pamatfunkcijas drošai sistēmu un lietotāju sadarbībai – ziņojumunosūtīšana, autentificēšana, autorizēšana un protokolu transformēšana, ja notiek sadarbībaar sistēmām, kas neatbalsta SOAP protokolu.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 28 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.065.1.1 Lietotāju autentifikācija un autorizācijaEVK lietotāju autentifikācijaEVK lietotāju autentifikācijai tiks izmantots IP identifikācijas un autentifikācijas serviss, kasdrošā veidā būs integrēts ar trešo pušu identifikācijas un autentifikācijas servisiem:www.latvija.lv IdentitySelector risinājumu;PFAS AUTH;ārstniecības iestāžu IS lietotāju datu bāzēm.www.latvija.lv IdentitySelector risinājums nodrošina vienotu autentifikācijas unidentifikācijas piegādātāju izvēli ārējiem portāliem un informācijas sistēmām, kas savukārtbūs paplašināms un pārvaldāms centralizēti. Šobrīd IdentitySelector risinājums kāautentifikācijas avotus piedāvā izmantot:elektroniskā paraksta viedkarti;Lattelecom Mobilo ID;www.latvija.lv portāla lietotājvārdu un paroli;Latvijas lielāko banku internetbankas portālus (piemēram, Swedbank, SEB banka,Citadele banka, Norvik banka, Latvijas Krājbanka).1. attēls. IdentitySelector lappuses piemērsPFAS AUTH risinājums tiek izmanots VRAA VISS lietotāju autentifikācijai.Ārstniecības iestāžu IS lietotāju datu bāzes tiks integrētas ar IP identifikācijas unautentifikācijas servisu, izmantojot iestādes lietotāju LDAP direktoriju, IP autorizācijasmoduļa datu bāzi vai arī iestādes lietotāju datu bāzi. IP identifikācijas un autentifikācijasNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 29 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06servisi ir aprakstīti IP risinājuma arhitektūras vīzijas dokumenta sadaļā „2.3.4. Autentifikācijasun autorizācijas servisi”, skat. [5].EVK sistēma lietotāju autentifikāciju neveic, bet gan pilnībā uzticas IP identifikācijas unautentifikācijas servisam, no kura tiks saņemts tā saucamais autentifikācijas apgalvojums -speciāls drošības talons, kas satur tikai lietotāja autentifikācijas informāciju. Kā universālspersonas identifikators tiks izmantots personas kods.EVK lietotāju autorizācijaEVK lietotāju autorizācijai tiks izmantots IP autorizācijas serviss.IP autorizācijas servisā tiks uzglabātas ārstniecības personu lomas un tiesības un tas veiksārstniecības personu autorizēšanu, izsniedzot ārstniecības personām citās e-Veselībassistēmās (tai skaitā EVK) derīgus drošības talonus. Par pacientiem IP autorizācijas servisspapildus autorizācijas informāciju neuzturēs – no IP skatu punkta tie tiks apvienoti vienādrošības lomā „pacienti”. Papildus drošības atribūtus par pacientiem uzturēs EVK sistēma.IP autorizācija notiek attiecībā uz IP eksponētajiem servisiem, tai skaitā EVK servisiem.Piemēram, IP autorizācijas serviss var noteikt, ka lietotājs X pieder drošības lomai „pacienti”un tāpēc tam ir piekļuve EVK servisam, kas ļauj iegūt pacienta karti no EVK sistēmas, bet IPautorizācijas servisam nav pieejama informācija, piemēram, vai lietotājs X drīkst iegūtkonkrēto pacienta Y karti. Objektu, jeb dokumentu līmeņa autorizāciju tālāk jau veickonkrētā e-Veselības centrālā sistēma, piemēram, EVK, izmantojot EVK autorizācijas moduli,skat. šī dokumenta sadaļu „6.4.1 Autorizācija”.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 30 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.062. attēls. EVK un tās sadarbība ar lietotājiem un ārējām sistēmāmNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 31 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.065.2 Lietotāju saskarnesPiekļuve EVK sistēmas datiem un funkcijām tiks nodrošināta, izmantojot:e-Veselības portāluwww.latvija.lv e-Pakalpojumusārstniecības iestāžu (ģimenes ārsta prakses) sistēmas, kuras ir integrētas ar EVKtīmekļa pakalpēm Integrācijas platformu, kas nodrošinās piekļuvi sistēmas administratorafunkcionalitāteiVienota un vienāda medicīnisko ierakstu attēlošana tiks nodrošināta, izmantojotprezentācijas katalogu, kas ir daļa no EVK metadatiem. Prezentācijas katalogs nodrošināsmedicīnisko ierakstu transformāciju no EVK saglabātajiem ierakstiem HTML un PDFformātos. Katram EVK medicīnisko dokumentu tipam prezentāciju katalogā tiks izveidota unsaglabāta atbilstošā XSLT transformācija skat. šī dokumenta sadaļu „6.4.2 Metadatupārvaldība”. Katram dokumenta tipam būs pieejams arī tehniskais dokumenta modelis XMIformātā un dokumenta validācijas komponente, kas ļaus izveidot dokumenta ievades formue-Veselības portālā un citās ārstniecības iestāžu informācijas sistēmās, izvietojot lietotājasaskarnes elementus atbilstoši XMI dokumenta definīcijai.Galvenās EVK lietotāju grupas ir aprakstītas tabulā zemāk:6. tabula. Galvenās EVK lietotāju grupasLietotāju grupaPacientiAprakstsPacienti izmantos EVK funkcionalitāti, piekļūstot tai www.latvija.lvvai e-Veselības portālā.Galvenā šai lietotāju grupai pieejamā funkcionalitāte būs darbs arsaviem un bērnu vai aizbildniecībā esošo personu ierakstiem EVK.Šīs lietotāju grupas autentificēšanu www.latvija.lv un tālākāpiekļuve EVK datiem tiks nodrošināta, veicot portāla www.latvija.lvdrošības talona nomaiņu pret derīgu talonu, kuru izsniedz IPautorizācijas serviss.Ārstniecības personasĀrstniecības personas izmantos EVK funkcionalitāti, piekļūstot taie-Veselības portālā vai arī savas ārstniecības iestādes informācijassistēmā, kas būs integrēta vienotajā e-Veselības sistēmu vidē.Ārstniecības personām EVK sistēmā būs pieejama funkcionalitāteEVK pacienta ierakstu apskatei un papildināšanai.Šīs lietotāju grupas autentificēšanu un autorizāciju nodrošinās IPlietotāju pārvaldības un autentificēšanas modulis, kurā lietotājusNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 32 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Lietotāju grupaAprakstsun to tiesības definēs ārstniecības iestādes administrācijasdarbinieki.IzmeklētājiIzmeklētājs var būt gan NVD administrators, gan arī jebkurš ārējslietotājs, kuram NVD piešķīris šādas tiesības.Izmeklētāji veic konkrētu personu EVK izmeklēšanu, lai pārbaudītudatus, kā arī lai sagatavotu atbildes uz tiesībsargājošo institūciju unveselības inspekcijas pieprasījumiem.AdministratīvielietotājiAdministratīvie lietotāji reģistrē izmeklētāju tiesības, personuaizgādnību un pilngadību, reģistrē jaunus dokumentu tipus.ĀrstniecībasdarbiniekiiestādesĀrstniecības iestādes darbinieku grupa ietvers plašu lietotāju loku,sākot ar reģistratoriem un ārstu palīgiem, beidzot ar ārstniecībasiestādes vadību. Ārstniecības iestādes darbiniekiem, kas ir ārstupalīgi vai reģistratori, tiks nodrošināta daļēja ārstiem pieejamāfunkcionalitāte, lai atvieglotu (atbalstītu) ārstu darbu.5.3 Sistēmu saskarnesIntegrācija ar citām sistēmām EVK tiks nodrošināta, izmantojot tīmekļa pakalpes, kas būsizvietotas e-Veselības integrācijas platformā.Pacienti e-Veselības sistēmas lietos vai nu izmantojot e-Veselības nozares portālā pacientiemparedzēto darba vietu, vai arī izmantojot e-pakalpojumus caur portālu www.latvija.lv.Ārstniecības personas lietos vai nu izmantojot e-Veselības nozares portālā ārstiem,ārstniecības iestādēm un reģistratoriem paredzētās darba vietas, vai arī izmantojotārstniecības iestāžu IS.EVK tiks nodrošinātas saskarnes ar šādām ārējām sistēmām:7. tabula. EVK saskarnes ar ārējām sistēmāmĀrējās sistēmase-Veselības portāls,www.latvija.lvportāls, ārstniecībasiestāžu ISAprakstse-Veselības portāls, "http://www.latvija.lv" portāls un ārstniecībasiestāžu IS ir primārās sistēmas, kas izmantos EVK funkcionalitāti. Šīssistēmas izsauks EVK tīmekļa pakalpes, kas būs eksponētas kā IPtīmekļa pakalpes. Tīmekļa pakalpju izsaukumi paredzēti tikai,izmantojot integrācijas platformu, kurā tiks nodrošināta lietotājuautentifikācija, autorizācija un augsta līmeņa tiesību kontrole.EVK tīmekļa pakalpes, kuras nevarēs garantēt to izpildi mazāk kā 3sekundēs, tiks veidotas kā asinhronas metodes, piemēram, EVKNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 33 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Ārējās sistēmasAprakstsdokumentu pievienošana, skat. sadaļu 6.4.3.Visi ziņojumi no šīm sistēmām tiks modelēti kā HL7 ziņojumi, pēciespējas izmantojot HL7 standarta ziņojumu veidus. Tikai gadījumos,ja nebūs iespējams izmantot standarta HL7 ziņojumus, var tikt veidotiarī modificēti HL7 ziņojumi.IntegrācijasplatformaIntegrācijas platforma kalpos kā starpslānis jeb savienotājs starpdažādām informācijas sistēmām – centrālajām e-veselības sistēmām,veselības pakalpojumu sniedzēju informācijas sistēmām, nozarespārvaldības informācijas sistēmām un reģistriem un, izmantojot VISS,valsts nozīmes reģistriem un apdrošinātājiem.IP tiks nodrošināta ne tikai ziņojumu apmaiņa starp iesaistītajāminformācijas sistēmām, bet arī visām iesaistītajām sistēmāmkoplietojami un atkārtoti izmantojami servisi . Šādi servisi, piemēram,ir autentifikācija, autorizācija, personas datu audita atbalsts,apziņošanas serviss, klasifikatoru reģistrs, monitorings u.c.EVK tīmekļa pakalpes tiks eksponētas kā IP tīmekļa pakalpes, skat.sadaļu 6.1.1.e-Pieraksti,e-Nosūtījumi,e-RecepteCentrālās e-veselības sistēmas: e-Pieraksti, e-Nosūtījumi une-Recepte izmantos EVK tīmekļa pakalpes gadījumos, kad tas irparedzēts to biznesa procesos, piemēram, e-Nosūtījumi saglabās EVKsistēmā nosūtījumu rezultātus, bet e-Recepte saglabās pacientamizrakstītos un izsniegtos medikamentus un ierīces.Centrālās e-veselības sistēmas un EVK atradīsies kopējā IP drošībaszonā, tāpēc to savstarpējai komunikācijai tiks izmantotas nedrošāstīmekļa pakalpes. Tas nozīmē, ka centrālās e-veselības sistēmas savāstarpā uzticēsies un to starpā netiks veikta sistēmu autorizācija.Lietotāju autorizācijai tiks izmantoti HL7 ziņojuma metadati, kassaturēs lietotāja identitāti, tā lomas un detalizēto tiesību komplektu.Visi ziņojumi no šīm sistēmām tiks modelēti kā HL7 ziņojumi, pēciespējas izmantojot HL7 standarta ziņojumu veidus.NVD VISNVD VIS kalpo kā pacientu ģimenes ārstu un EVAK karšu informācijasdatu avots.Tā kā ģimenes ārstu un EVAK informācija laika gaitā var mainīties,NVD VIC veiks periodisku EVK datu aktualizēšanu. Datu aktualizēšanatiks veikta, no NVD VIS periodiski izsaucot EVK servisus un veicotattiecīgās izmaiņas pacientu karšu ierakstos.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 34 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Ārējās sistēmasAprakstsPMLPreģistrsIedzīvotājuNVD VIS un EVK atradīsies kopējā IP drošības zonā.EVK datu apmaiņā ar NVD VIS izmantos HL7 standarta transportaaploksni, savukārt NVD VIS servisi tiks publicēti IP, izmantojot IPadapterus.EVK sistēmā veidojot jaunas pacientu kartes, tiks pieprasīti personudati PMLP Iedzīvotāju reģistrā. Šī darbība notiks sinhronā režīmā, jopirms izveidot pacienta karti, ir nepieciešams pārliecināties parpersonas datu eksistenci un pacienta statusu Iedzīvotāju reģistrā.Fona uzdevumu komponents veiks arī periodisku personas datuaktualizēšanu, pieprasot no PMLP IR visas notikušās izmaiņas parnoteiktu laika periodu un veicot attiecīgās izmaiņas pacientu karšuierakstos.PMLP IR servisi ir publicēti VISS servisu katalogā, kas savukārt tikspārpublicēti IP drošo servisu veidā.EVK datu apmaiņā ar PMLP IR izmantos HL7 standarta transportaaploksni, savukārt PMLP IR servisi tiks publicēti IP, izmantojot VISSadapterus.Jaundzimušo reģistrs Kamēr jaundzimušajam nav piešķirts personas kods, parpersonificēto datu avotu šim pacientam kalpo jaundzimušo reģistrs.Personas dati jaundzimušo reģistrā tiek identificēti pēc mātespersonas koda un dzimšanas datuma un laika.EVK sistēmā veidojot jaunas pacientu kartes jaundzimušajam,sinhronā režīmā tiks pieprasīti jaundzimušā dati Jaundzimušoreģistrā.Fona uzdevumu komponents asinhronā režīmā periodiski pārbaudīsjaundzimušo datus tām personām, kurām EVK IS nav aizpildītspersonas kods. Dati tiks pieprasīti, norādot mātes personas kodu unbērna dzimšanas datumu un laiku. Ja Jaundzimušo reģistrājaundzimušajam būs ievadīts personas kods, jaundzimušā dati tikspieprasīti PMLP IR.EVK datu apmaiņā ar Jaundzimušo reģistru izmantos HL7 standartatransporta aploksni.VADC IS, NMP ISVADC IS un NMP IS izmantos EVK sistēmu analoģiski kā ārstniecībasiestāžu IS – tās izsauks EVK tīmekļa pakalpes, kas būs eksponētas kāIP tīmekļa pakalpes, izmantojot HL7 ziņojumus. Pamatā tās izmantosEVK funkcijas, kas ir paredzētas darbam ar medicīnas dokumentiem -Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 35 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Ārējās sistēmasAprakstsEVK pacienta ierakstu apskate un papildināšana.USPSPREDAElektroniski parakstītu medicīnisko dokumentu pārbaudes laikā tiksizmantots USPS publiski pieejamais OCSP serveris, kas nodrošinasertifikātu statusu pārbaudi tiešsaistes režīmā atbilstoši RFC 2560standartam. OCSP servera pieprasījumi tiks veikti sinhroni,izmantojot HTTPS standarta protokolu. Lai nodrošinātu augstuveiktspēju, OCSP servisa izsaukumi notiks pa tiešo, apejot integrācijasplatformas starpslāni. Visi OCSP pieprasījumi tiks reģistrēti auditažurnālā.Šobrīd ir paredzēts PREDA sistēmu izmantot tikai sākotnējai datuielādei. Par tālāko sadarbību starp EVK IS un PREDA tiks lemtsnākamajās EVK kārtās.No PREDA reģistriem tiks izgūta tikai pamata informācija pacientakartes veselības pamatdatiem, medicīnas dokumentu veidošana navparedzēta.Sākotnējo datu ielādes laikā katrs PREDA reģistrs tiks apstrādātssecīgi, izveidojot pacienta kartes tiem personas kodiem, kuriempacienta kartes EVK vēl neeksistē.VZD AREVK analīzes fāzes laikā tika pieņemts lēmums izmantot PMLP adrešureģistru.Sistēmu sadarbībai ar EVK tiek izmantotas SOAP protokolam atbilstošas tīmekļa pakalpes,kas klīniskās informācijas apmaiņai izmanto HL7 v3 standarta ziņojumus.Lietotāju un sistēmu autentificēšana un datu drošība (datu šifrēšana un parakstīšana) tieknodrošināta, izmantojot WS-* tīmekļa pakalpju drošības standartus un X.509 digitālossertifikātus.Saskaņā ar HL7 v3 transporta specifikāciju Web Services Profile, Release 2 ziņojumu apmaiņanotiek, izmantojot SOAP protokolu, kur SOAP aploksnes galvenē atrodas adresācijas undrošības dati, bet aploksnes ķermeņa HL7 interakcijas ziņojums. SOAP ziņojumi un tosasaiste ar HL7 v3 un WS-* 1 standartiem detalizētāk ir aprakstīta IP risinājuma arhitektūrasvīzijas dokumentā, skat. [5].1 WS-Security v1.0, WS-Security v1.1, WS-Trust v1.2, WS-Trust v1.3, WS-Federation v1.2 unSAML v1.1, Shibboleth v1.3, SAML v2.0Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 36 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Galveno e-veselības nozarē izmantojamo medicīnas dokumentu semantika un saturs iraprakstīti e-veselības ziņojumapmaiņā izmantojamo datu struktūru standarta dokumentā.5.4 Medicīnas dokumentu arhitektūraSistēmas pamata mērķis ir medicīnas dokumentu glabāšana un apstrāde. Medicīnasdokumentu glabāšanai tiek izmantota HL7 standarta sadaļa – CDA (Clinical DocumentArchitecture). Šinī dokumenta sadaļā tiek aprakstīta EVK sistēmas pieeja HL7 dokumentuapstrādei, glabāšanai un to standartizācijai.5.4.1 CDA vispārīgs aprakstsCDA nodrošina dokumentu organizācijas standartu to glabāšanai vai apmaiņai starporganizācijām vai sistēmām.CDA dokuments ir pabeigta informācijas vienība, kas var eksistēt neatkarīgi no ziņojuma, arkura palīdzību tā tika piegādāta. Principā, CDA dokuments var saturēt ne tikai tekstuāloinformāciju, bet arī multimēdijus (ieskaitot bildes, skaņu vai cita veida specifiskoinformāciju). CDA pamatā ir trīs līmeņu arhitektūra, kur 2. un 3. līmenis nodrošina vairākierobežojumu dokumentiem, nodrošinot striktāku pieeju CDA datu saturam.Izmantojot XML, HL7 v3 un klasifikatorus, CDA atļauj ārstniecības sistēmām apmainīties ardokumentiem, kas ir gan mašīnlasāmi, gan arī nodrošina cilvēklasāmības iespēju (jāsaprot, kašī iespēja ir lielā mērā teorētiska un prasa cilvēkam speciālo apmācību – līdz ar to grūtipielietojama praksē). Parasti, cilvēklasāma forma CDA dokumentiem tiek veidota ar XSLTtransformāciju palīdzību. EVK projekta ietvaros visiem dokumentu veidiem tiek nodrošinātastransformācijas HTML dokumenta reprezentācijas iegūšanai.CDA dokumentiem piemīt šādas īpašības:Noturība – Klīniskais dokuments eksistē nemainīgs visu tā normatīvajos dokumentosparedzēto glabāšanas laiku (dokuments satur visu nepieciešamo informāciju, lai tasvar būt atspoguļots un apstrādāts, neskatoties uz iespējamām izmaiņāmklasifikatoros vai normatīvajā bāzē);Pārvaldība – Klīniskajam dokumentam ir precīzi norādīta organizācija un persona, kasir atbildīgi par tā veidošanu un pārvaldību;Juridiska spēka potenciāls – Klīniskais dokuments tiek veidots ar nodomu tiktparakstītam atbilstoši likumdošanai;Pilnīgums – Klīniskā dokumenta parakstīšanai ir jēga tikai tādā gadījumā, ja tā tiekpiemērota dokumentam kopumā, nevis tikai tā daļām.CDA dokumentu piemēri:Izraksts – epikrīze;Ambulatora pakalpojuma rezultāts;Izmeklējuma rezultāts;Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 37 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Pacienta medicīnas pamatdatu kopsavilkums.CDA dokumentu veidu skaits, kas var tikt pievienoti EVK sistēmai, nav ierobežots un irpaplašināms atbilstoši vajadzībai un normatīvās bāzes izmaiņām.CDA dokumentu detalizēta struktūra ir iedota tālāk dokumentā, bet ilustrācijai šeit irievietots pilns CDA dokumenta piemērs.Skrīningmamogrāfijas rezultātsPIEMĒRA IELA10A33RĪGARĪGAS NOVADSLATVIJALV1010MADARAAUGSTKALNELATVIJAZiedonisBriedisMedicīnas iestādeMEDICĪNAS IESTĀDES IELA11Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 38 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06RĪGARĪGAS NOVADSLATVIJALV1050Skrīninga dokumentu kopīgā informācija8272819Skrīningmamogrāfijas rezultāta informācijaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 39 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Skrīningmamogrāfijas rezultātiSkrīningmammogrāfijas rezultāta aprakstsKonstatēts labdabīgs krūts audzējslabajā krūtī.LATVIJAParauga ĀrstsRīgas 5.medicīnas skolaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 40 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06MEDICĪNAS IESTĀDESIELA11RĪGARĪGAS NOVADSLATVIJALV1050Skrīningmamogrāfijas slēdziena aprakstsAudzējs ir labdabīgs unoperējams.LATVIJAParauga ĀrstsRīgas 5.medicīnas skolaMEDICĪNAS IESTĀDESIELA11RĪGARĪGAS NOVADSLATVIJANacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 41 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06LV10503. attēls. CDA dokumenta piemērs5.4.2 CDA struktūraKlīniskajam dokumentam ir jāsatur galvene, kas glabā informāciju par pacientu, autoru,dokumenta veidošanas datumu, organizāciju utml.Dokuments var saturēt arī sadaļu ar brīvo tekstu, kura var būt vai nebūt tālāk sadalīta pasekcijām. Papildus teksta sekcijām CDA var saturēt arī strukturētu (uz HL7 v3 XML tipiembāzētu) informāciju.Tiek definēti trīs CDA atbilstības līmeņi. Dokumenta formalitāte un informācijas glabāšanasstriktums palielinās no 1. līdz 3. līmenim.CDA dokumenta struktūras shēma ir parādīta 3. attēlā zemāk.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 42 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06CDA galveneDokumenta un veidnes identifikācijaPacienta identifikācijaOrganizācijas identifikācijaĀrstnieciskās personas identifikācijaCDA ķermenis1 līmenis 2 līmenis 3 līmenisNeinterpretētibinārie datiSekcijaTeksta vaibinārie datiSekcijaTeksta vaibinārie datiSekcijaStrukturētieapakšelementiKlasificētasvērtībasSekcijaStrukturētieapakšelementiTeksta vaibinārie dati4. attēls. CDA dokumenta struktūraCDA dokumentu līmeņu apraksts:Pirmais līmenis atbilst dokumentiem, kuri tiek veidoti CDA formātā, lai nodrošinātuto glabāšanas iespēju kādā no CDA apstrādes sistēmām (piemēram EVK). Šāda veidadokumenti izmanto CDA struktūru tikai dokumenta, ārstniecības iestādes unārstnieciskās personas identifikācijai. Dokumenta satura atšifrēšana paliek datunolasīšanas sistēmas pārziņā. Šāda veida dokumentus nav paredzēts glabāt EVKsistēmā.Otrais līmenis atbilst dokumentiem, kuri satur formalizētu iekšējo struktūru.Dokumentiem pastāv dalījums pa sekcijām – norādot sekciju obligātumu, secību,veidu un skaitu. Šāda veida dokuments neļauj to apstrādāt pilnīgi (informācijasekcijās joprojām ir nestrukturēta), bet ļauj nodrošināt vienotu dokumenta izskatuārējās sistēmās, kā arī vienotu visu veidu dokumentu apstrādes algoritmu. Otrālīmeņa CDA dokumentus ir paredzēts izmantot EVK sistēmā pārejas periodā, jo šādudokumentu veidošana ir vienkāršāka datu avotu organizācijām.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 43 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Trešais līmenis atbilst dokumentiem, kuru struktūra ir pilnīgi formalizēta. Trešālīmeņa CDA dokumenti satur tikai klasificētas vērtības, un sekciju struktūra ir sadalītapa elementiem, no kuriem katrs ir pilnīgi specificēts un atbilst likumdošanānoteiktajam medicīnas dokumenta fragmentam (specificējot arī izmantojamosklasifikatorus). Paredzēts, ka lielākā daļa no EVK dokumentiem būs trešā līmeņa CDAdokumenti.5.4.3 CDA galveneVisiem CDA līmeņiem ir kopīga dokumenta galvene, kas satur informāciju par ārstnieciskopersonu, pacientu, dokumenta veidošanas laiku un tipu, dokumenta autoru utml.CDA dokumenta galvenes xsd shēmas fragments ir parādīts 4. attēlā zemāk.5. attēls. CDA dokumenta galvenes xsd shēmas fragmentsObligātie vai EVK procesu ietvaros aizpildāmie lauki, kas iekļauti šinī struktūrā, aprakstašādas datu vienības:Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 44 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06typeId – Dokumenta identifikācija (fiksēta vērtība);templateId – Dokumenta veidne (tips);id – Dokumenta unikāls identifikators (ārstniecības iestādes ir atbildīgas par šīidentifikatora aizpildīšanu un unikalitāti iestādes ietvaros);code – Dokumenta veidnes nosaukums un pilns klasifikatora ieraksts;title – Lietotājam redzams dokumenta nosaukums (tiks izmantots lietotājamredzamas dokumenta reprezentācijas veidošanā);effectiveTime – Dokumenta veidošanas datums;recordTarget – Pacienta identifikācijas struktūra;author – Ārstnieciskās personas identifikācijas struktūra;custodian – Organizācijas identifikācijas struktūra;component – Konteinera elements, kas satur visu dokumenta struktūru.CDA dokumenta galvenes fragmenta piemērs ir parādīts 5. attēlā zemāk.Rentgenmamogrāfijas kartePreiļu novads, Preiļi, Pils iela 15 - 1,LV5301JānisOzoliņšLatvijaZiedonisNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 45 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06BriedisTesta IestādeRīgas raj., Rīga, Gintermuižas iela 4,LV10156. attēls. CDA dokumenta galvenes fragmenta piemērs5.4.4 CDA ķermenis. SekcijaCDA ķermenis ir dokumenta daļa, kura tiek saglabāta XML elementā.3. līmeņa CDA dokumentiem ķermenis sastāv no sekcijām, sekcijas elementiem unapakšsekcijām, kuru struktūra pārsvarā definē CDA dokumenta kopējo izskatu uninformācijas aizpildījumu.CDA dokumenta sekcijas struktūra ir parādīta 6. attēlā zemāk.SekcijaSekcijas identifikācijaSekcijas cilvēklasāms nosaukums un satura cilvēklasāmainterpretācijaSekcijas elementi (ieraksti)Apakšsekcijas7. attēls. CDA dokumenta sekcijas struktūraKatra sekcija satur sekcijas identifikācijas sadaļu (ar tās palīdzību sekcijas tiek apstrādātas unvalidētas, saņemot dokumentu EVK sistēmā).Sekcijas var saturēt cilvēklasāmo nosaukumu un sekcijas satura apkopojumu cilvēklasāmāformā. Gadījumā, ja dokuments tiek veidots atbilstoši otrajam CDA līmenim, dokumentaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 46 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06sekcijas nesatur vairāk nekādu papildus informāciju. Vairumā gadījumu EVK dokumentiemarī sekcijas saturs būs strukturēts – tas saturēs sekcijas elementus un/vai apakšsekcijas.Ir paredzēts, ka EVK dokumenti nesaturēs lielus cilvēklasāmus teksta blokus. Tas irpamatojams ar to, ka šiem blokiem ir jānodrošina ekvivalenta strukturētu un klasificētumedicīnas datu glabāšana. EVK sistēma nevar garantēt, ka teksta laukos un strukturētajādaļā esošā informācija atbilst viena otrai. Līdz ar to – cilvēklasāma CDA dokumenta formatiks veidota, izmantojot transformācijas, kas tiks izveidotas katram EVK reģistrēta CDAdokumenta veidam. Šādi tiks panākta iespēja nākotnē pārtulkot dokumentus citās valodās(nodrošinot atbilstošo klasifikatoru tulkošanu) un izvairīties no iekšēji nekonsistentadokumenta veidošanas riska (kad tekstā ierakstītā informācija var atšķirties no klasificētāsinformācijas dokumenta ierakstos).CDA dokumenta sekcijas xsd shēma ir parādīta 7. attēlā zemāk.8. attēls. CDA dokumenta sekcijas xsd shēmaDokumenta sekcija sastāv no šādiem aizpildāmiem laukiem:templateId – sekcijas identifikācija (atbilstoši CDA modeļa specifikācijai);code – sekcijas kods un nosaukums;title – sekcijas cilvēklasāms nosaukums;text – sekcijas cilvēklasāms apraksts (netiek aizpildīts 3. līmeņa dokumentiem);entry – konkrēts medicīnas datu iekrasts (atbilstoši dokumenta modelim).Pārējie sekciju lauki tiek aizpildīti tikai speciālos gadījumos, kas var būt aprakstīti konkrētadokumenta modeļa specifikācijā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 47 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06CDA dokumenta sekcijas aizpildīšanas piemērs ir parādīts attēlā zemāk:Rentgenmamogrāfijas anamnēze.........Otraja līmeņa CDA dokumentiem sekcijas nesatur strukturētu datu laukus:Rentgenmamogrāfijas anamnēze9. attēls. CDA dokumenta sekcijas aizpildīšanas piemērs5.4.5 CDA ķermenis. Ieraksts (Entry)CDA dokumentos sekcijas apkopo datus atbilstoši kādam konkrētam priekšmeta apgabalam(piemēram diagnoze, anamnēze, operācijas apraksts). Tomēr pašu medicīnas datuglabāšanai tiek izmantota dziļāka līmeņa struktūra – ieraksti (entry). Šādās struktūrās tiekglabāti elementārie dati (viena mērījuma rezultāts, diagnozes kods atbilstoši SSK-10,NOMESCO operācijas kods, ārsta teksta rehabilitācijas rekomendācija vai citi).Ieraksti tiek glabāti CDA dokumentā, kā sekcijas (vai citu ierakstu) apakšelementi. Ierakstuglabāšanas augsta līmeņa struktūra ir parādīta 9. attēlā zemāk:Entry (Ieraksts)Ieraksta identifikācijaDatu konteinersObservation (novērojums)Organizer (grupējums)10. attēls. CDA dokumenta ieraksta struktūraNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 48 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06CDA specifikācija paredz arī citu ieraksta komponenšu lietošanu (act, encounter,observationMedia, procedure, regionOfInterest, substanceAdministration, supply), tomērEVK dokumentu modeļos tiek izmantoti tikai observation (novērojums) un organizer(grupējums) komponentes. Organizer tiek izmantots, kad ir nepieciešams apvienot vairākusdatu elementus vienā loģiskā grupā.Organizer (grupējums) elementa piemērs, kas apvieno ārsta vārdu un profesiju, ir parādīts10. attēlā zemāk.Edgars Briedis11. attēls. Organizer (grupējums) elementa piemērsVisiem pārējiem medicīnas datu elementiem dokumentos tiek izmantota observation(novērojums) datu struktūra. Observation (novērojums) elementa struktūra ir parādīta 11.attēlā zemāk.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 49 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0612. attēls. Observation (novērojums) elementa struktūraEVK dokumentos observation (novērojums) struktūrās kā obligāti tiek izmantoti šādi lauki:templateId – Novērojuma tipa identifikācija;id – var tikt izmantots dokumenta satura elementu identifikācijai (atkarīgs nodokumenta modeļa);code – Novērojuma nosaukums un tā veida identifikācija;effectiveTime – Novērojuma datums/laiks (ja pielietojams – atkarīgs no dokumentamodeļa);value – Novērojuma vērtība. Novērojuma vērtība var pieņemt jebkuru HL7 atļautotipu (izmantojot xsi:type atribūtu tipa norādei). Visbiežāk EVK dokumentu modeļostiek lietoti tipi CD, TS vai IVL_TS, ED, bet potenciāli var būt arī cits datu tips;entryRelationship – Novērojuma sasaiste ar citiem novērojumiem. Tiek izmantotsnovērojumu hierarhijas veidošanai.Observation (novērojums) elementa izmantošanas piemērs ir parādīts 12. attēlā zemāk.Ārsts, kas nosūtījis pacienti EDNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 50 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Ārstniecības personas tālruņa nr. ED13. attēls. Observation (novērojums) elementa izmantošanas piemērs5.4.6 Pieeja dokumentu modeļu veidošanai un dokumentu dzīves ciklsDokumentu modeļu veidošanas process EVK ietvaros ir parādīts zemāk redzamā 13. attēlā:14. attēls. Dokumenta veidošanas un izmantošanas dzīves ciklsJaunā dokumenta modeļa veidošana sākas ar normatīvās bāzes izpēti un, potenciāli,labošanas piedāvājumiem. Šis darbs tiek veikts, nozares ekspertam piesaistot IT profesionāli.Tiek izpētīta normatīvā bāze, kas attiecas uz konkrēto dokumentu, un citi ar šo dokumentusaistītie informācijas avoti (MK noteikumi, izmaiņu piedāvājumi, reālajā praksē pielietotodokumentu piemēri). Visa iegūtā informācija tiek apkopota dokumenta abstraktajā modelī.Šinī etapā tiek specificētas iestādes, kuras izmantos izveidojamo elektronisko dokumentu, cikun kādi lauki būs dokumentā, kuri no tiem ir obligāti, kā lauki tiek apvienoti grupās, kuroslaukos ir jāizmanto VVIS sistēmā pieejamie klasifikatori, vai ir nepieciešams saņemt no VVISpamatdatus, lai varētu izveidot CDA dokumentu. Papildus tiek noteikta dokumentaiesūtīšanas struktūra un ielikta pazīme vai dokumentu ir jāparaksta ar elektronisko parakstuvai ar iestādes elektronisko zīmogu.CDA dokumenti tiek veidoti no sekciju aprakstiem, kas tiek definēti atsevišķā sekciju UMLfailā. Modelētājs pēc izveidotā apraksta liek kopā dokumenta veidnes modeli, izmantojoteksistējošās sekcijas vai pēc nepieciešamības veidojot jaunas sekcijas. Tādā veidā tiekNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 51 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06nodrošināta sekciju atkalizmantošana. Sekciju tipu fails, piemēram, satur manipulāciju(Manipulation) sekcijas tipa aprakstu, savukārt pacienta kartē dažāda veida manipulācijusekcijas visas manto šo manipulāciju sekciju tipu, kas ir definēts atsevišķi, skat. piemērusadaļas 6.4.2 apakšsadaļā “Dokumenta veidņu modelēšana”.Pirms dokumenta apstiprināšanas atbildīgā iestāde veic dokumenta saskaņošanu aratbilstošās nozares asiocācijām 2 .Pēc specifikācijas apstiprināšanas, ko veic nozares neatkarīgie eksperti, tiek uzsākta tehniskāmodeļa izstrāde.Modelēšanai tiek piesaistīts tehniskais eksperts (programmētājs) ar HL7 CDA dokumentaformāta un modelēšanas rīka (MDHT) zināšanām, un rezultātā tiek iegūts tehniskaisdokumenta modelis XMI formātā (uz šī modeļa bāzes var izveidot dokumenta ievades formu)un dokumenta validācijas komponente (*.jar formāta fails, kas satur nepieciešamo loģiku, laivalidētu XML failus uz atbilstošo modeli).5.4.7 Dokumentu glabāšana un izmantošana e-veselības sistēmas ietvarosCDA dokumenti tiek glabāti EVK kā viens vesels, saglabājot precīzu dokumentu saturu tādāversijā, kā tie tika iesūtīti no ārstniecības iestādēm. Dokumentiem ir pieejama XSLTtransformācija, kas ļauj no XML dokumenta formas iegūt HTML un PDF cilvēklasāmusvariantus.Dokumentu saņemšana un apstrāde detalizētāk ir aprakstīta sadaļās 6.4.2 (Metadatupārvaldība) un 6.4.3 (Pamatdatu un pierakstu pārvaldība).2 Elektroniskā dokumenta saskaņošanas process ir atbildīgās iestādes atbildība. Atbildīgāiestāde pirms saskaņošanas uzsākšanas izveido aktivitāšu sarakstu, apzina iesaistītās pusesun atbilstoši aktivitātšu sarakstam veic dokumenta saskaņošanu.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 52 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.065.4.8 CDA dokumentu pieņēmumi un ierobežojumiApstrādājot CDA dokumentus EVK sistēmā, tiek pieņemts:Netiks apstrādāti dokumenti, kas neizies validāciju attiecībā pret CDA shēmu;Netiks apstrādāti dokumenti, kas neizies validāciju attiecībā pret modeli (ar EVKvalidatora palīdzību);Netiks apstrādāti dokumenti, kas saturēs vērtības, kas neatbilst e-veselībasklasifikatoru reģistrā saglabātiem klasifikatoriem, ņemot vērā klasifikatoru versijasun laika rāmi, kurā klasifikators derīgs.Netiks apstrādāti dokumenti, kuriem dokumentu numurs sakrīt ar sistēmā jauesošiem dokumentiem. Šajā gadījumā tiek prasīts dokumentam ievadīt versijasnumurs.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 53 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.066 Loģiskā arhitektūraŠajā nodaļā aprakstīti sistēmas iekšējie komponenti, identificēts, kādi no šiemkomponentiem nodrošina ārējo saskarņu funkcionalitāti, noteikti arī sistēmas iekšējokomponentu un moduļu sadarbības scenāriji, nepieciešamās saskarnes, to specifika(autentifikācija, protokoli).6.1 Sistēmas komponentu grupasNo drošības viedokļa sistēmas komponentus var sadalīt divās grupās:EVK tīmekļa pakalpesEVK komponenti15. attēls. EVK komponentu grupas6.1.1 EVK tīmekļa pakalpesSistēma nodrošina eksponējamas tīmekļa pakalpes, ko izmantos citas ārējas sistēmas, lainodrošinātu datu izgūšanu un datu ievadu EVK sistēmā.EVK tīmekļa pakalpju izsaukumi paredzēti tikai, izmantojot integrācijas platformu, kurā tiksnodrošināta lietotāju autentifikācija, autorizācija un augsta līmeņa tiesību kontrole. KatrsEVK pakalpes izsaukums saturēs papildus drošības informācijas komplektu, kuru aizpildīs IPautorizācijas serviss veiksmīgas autorizācijas gadījumā. Drošības informācijas komplektssaturēs vismaz šādu informāciju:Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 54 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06lietotāja identifikāciju;ziņojuma laika, avota un mērķa sistēmas identifikāciju;IP audita transakcijas identifikāciju;lietotāja pilno tiesību komplektu.Šo informāciju IP nodos EVK tīmekļa pakalpēm drošības talonā vai transporta aploksnē,atkarībā no IP detalizētā projektējuma. Pieprasījumus, kas neizies IP lietotāju autorizāciju untiesību kontroli, integrācijas platforma noraidīs un šādi pieprasījumi līdz EVK sistēmai nemaznenonāks.6.1.2 EVK komponentiPārējie EVK sistēmas komponenti netiek dalīti atsevišķās drošības zonās, jo tiem netieknodrošināta tieša piekļuve no ārējām sistēmām. Jebkuri izsaukumi no ārējām sistēmāmnotiek, izmantojot EVK tīmekļa pakalpes, kurās notiek papildus autorizācija EVK objektulīmenī. EVK sistēmas komponenti savā starpā veic tiešus izsaukumus, neizmantojot tīmekļapakalpju līmeni. Komponenti, kas darbojas šajā zonā, viens otram piekļūst, neveicot papildusautentifikāciju un tiesību pārbaudi.6.2 Loģiskais datu modelisPacientu personificētie dati tiek atdalīti no nepersonificētiem datiem datu bāzes līmenī.Personificēti un nepersonificētie dati tiek glabāti dažādās datu tabulās, un starp šīm tabulāmtiek nodrošināta šifrēta saite - personas nepersonificēto datu identifikators šifrētā veidā.Tikai atšifrējot šo identifikatoru, ir iespējams savienot pacienta personificēto unnepersonificēto informāciju. Tā kā EVK medicīniskie dokumenti XML un HTML formātos saturgan personificēto, gan nepersonificēto informāciju vienuviet, šie dokumenti tiek šifrēti,izmantojot kriptogrāfiskās atslēgas.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 55 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06EVK ir izdalīti divi datu apgabali, lai datu līmenī atdalītu personificētos datus:personificētie datinepersonificētie dati, veselības pamatdati un medicīniskie dokumenti16. attēls. EVK loģiskais datu modelisEVK risinājumā tiek pielietota divu līmeņu datu šifrēšana:pilnīgi visi EVK dati tiek šifrēti datu bāzes līmenī, izmantojot Microsoft SQL ServerTDE (Transparent Data Encryption) iespējas. TDE nodrošina ātru un izstrādātājiemvienkāršu datu šifrēšanu datu bāzes failu līmenī. Tādā veidā tiek aizsargāti EVK datidatu bāzes failu līmenī, kā arī EVK datu rezerves kopijas;ar citu kriptogrāfisko atslēgu komplektu tiek šifrēti medicīniskie dokumenti un saitesstarp personificētajiem un nepersonificētajiem datiem.Personificētie dati satur pacientu pamatdatus, kā piemēram, vārds, uzvārds, personas kods,dzimšanas un miršanas datumi, deklarētās adreses personificētā daļa un pacientakontaktpersonas. Tie nesatur pacienta klīnisko informāciju. Detalizētāk personificētie dati unto atribūti ir aprakstīti programmatūras prasību specifikācijas sadaļā „Personificētie dati”,skat. [1].17. attēls. Personificētie datiŠifrētie dati satur saites starp pacientu personificētajiem un nepersonificētajiem datiem, kāarī pacientu medicīniskos dokumentus.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 56 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Pacienta nepersonificēto datu ieraksts veidojas vienlaicīgi ar personificēto datu ierakstu, tikaitas satur citu informācijas apjomu. Paredzēts, ka nepersonificētie dati tiks izmantotistatistikai un pētniecībai. Nepersonificētie dati satur pacientu pamatdatu daļu, kas tiksizmantoti analītiskām vajadzībām, kā piemēram, dzimumu, dzimšanas un miršanas gadu,pacienta statusu, pilngadības pazīmi, deklarētās adreses nepersonificēto daļu, ģimenes ārstu,EVAK kartes datus, veselības pamatdatus, vakcināciju reģistru un medicīnisko dokumentusekcijas, kas nesatur personificētus datus. Detalizētāk nepersonificētie dati ir aprakstītiprogrammatūras prasību specifikācijas sadaļā „Nepersonificētie dati”, skat. [1].Veselības pamatdati ir pacienta pamatdatu kopa, kas ir paredzēta kā operatīvi iegūstamaaktuāla pacienta veselības informācija. Tā satur pacienta datus par diagnozēm, medicīnasierīcēm un implantiem, alerģijām, medikamentiem un brīdinājumiem. Datu kopa, kas būtuiekļaujama pacienta pamatdatos, ir noteikta epSOS projekta ietvaros. epSOS ieteikumi tikaņemti vērā, nosakot arī EVK veselības pamatdatu kopu. Detalizētāk veselības pamatdati iraprakstīti programmatūras prasību specifikācijas sadaļā „Veselības pamatdati”, skat. [1].18. attēls. Veselības pamatdatiEVK dokumentu repozitorijs ir paredzēts medicīnisko dokumentu elektroniskai glabāšanai.Katram dokumentam, kas tiek reģistrēts repozitorijā, ir jāatbilst noteiktam dokumenta tipamun dokumenta veidnei, kas ir reģistrēta dokumentu metasistēmā. Medicīniskajamdokumentam var būt viena vai vairākas sekcijas. Detalizētāk veselības pamatdati ir aprakstītiprogrammatūras prasību specifikācijas sadaļā „Medicīniskie dokumenti”, skat. [1].Vakcināciju modulis nodrošinās ar vakcināciju saistīto medicīnisko dokumentu glabāšanu EVKdokumentu repozitorijā, līdz ar to vakcināciju reģistra dati būs apakškopa no EVK dokumenturepozitorija datiem. Detalizētāk vakcinācijas reģistra datu kopas ir aprakstītas vakcinācijureģistra programmatūras prasību specifikācijas sadaļā „Pamatdati”, skat. [3]. Savukārtklasifikatoru moduļa datu kopas ir aprakstītas klasifikatoru moduļa programmatūras prasībuspecifikācijas dokumentā, skat. [4].6.2.1 Šifrēšanas atslēgu glabāšanas politikaRisinājums nodrošina, ka datu bāze pati par sevi nav atšifrējama, jo datu bāze nesaturatslēgas. Atslēgas, kas nepieciešamas, lai atšifrētu šifrētās saites, tiek glabātas atdalīti nodatu bāzes. EVK datu šifrēšanas atslēgu hierarhija ir parādīta zemāk redzamā 19. attēlā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 57 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0619. attēls. Šifrēšanas atslēgu hierarhijaEVK datu šifrēšanai tiek izmantotas datu bāzes simetriskās atslēgas. Savukārt simetriskāsatslēgas tiek šifrētas, izmantojot DMK (Database Master Key) atslēgu.DMK ir SQL servera ģenerēta simetriskā atslēga. Tā tiek glabāta šifrētā veidā. ĢenerējotDMK, tā tiek glabāta divās kopijās:viena kopija ir šifrēta, izmantojot SMK (Service Master Key) atslēguotra kopija ir šifrēta, izmantojot lietotāja norādīto paroliVeidojot DMK, lietotājam obligāti ir jānorāda parole. DMK atslēgas šifrēšanai tiek izmantotsTriple DES algoritms. DMK ir datu bāzes līmeņa atslēga, ko var ērti izmantot citu atslēgušifrēšanai. Pārvietojot datu bāzi uz citu serveri, visa ar DMK šifrētā informācija būs pieejamatikai, izmantojot lietotāja iepriekš norādīto paroli. Savukārt SMK (otra atslēga, kas pēcnoklusējuma šifrē DMK) tiek glabāta servera, nevis datu bāzes līmenī.DMK atslēgas lietošana citu atslēgu šifrēšanai notiek automātiski - datu bāzes lietotājs, kamir tiesības izmantot kādu simetrisko atslēgu datu šifrēšanai vai atšifrēšanai, nemaz nezin, kapati atslēga arī tiek šifrēta ar DMK atslēgu.DMK atslēga ir aizsargāta un tiek šifrēta, izmantojot SMK atslēgu un paroli, kas norādītauzstādot EVK datu bāzi.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 58 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06SMK ir SQL servera paša augstākā līmeņa atslēga, kas tiek izmantota, lai aizsargātu serveralīmeņa konfidenciālos datus. SMK atslēga tiek ģenerēta automātiski, tiklīdz pirmo reizi pēctās rodas nepieciešamība.SMK atslēga tiek aizsargāta divos veidos – izmantojot SQL servisa lietotāja autorizācijas datus(lietotāja vārds un parole) komplektā ar Windows Data Protection API bibliotēku, kā arīizmantojot datora, uz kā SQL serveris darbojas, konta atslēgu. Tas nozīmē, ka gadījumā, janomainīsies lietotāja vārds, zem kura strādā SQL serveris, tad SMK joprojām būs lietojama -atslēga tiks atšifrēta, izmantojot datora kontu un tā tiks no jaunu šifrēta, izmantojot jaunoservisa kontu.Pasūtītājam ir jānodrošina piekļuve šifrēšanas atslēgām personām, kurām tai pašā laikā navpiekļuve datu bāzei, lai viena persona nevarētu atšifrēt datus. Datu šifrēšanai izmantotāsatslēgas ir aizsargātas un ir pieejamas tikai drošības pārvaldniekiem.SQL servera lietotājiem ir tiesības piekļūt tikai nepersonificētajai datu bāzei. Piekļuvepersonificētajai datu bāzei notiek tikai ar sertifikātu parakstītām procedūrām.EVK datu bāzē web servisam nav piekļuves dokumentu šifrēšanas atslēgai. Tā vietā tam iriespēja izpildīt tikai parakstītas procedūras. Šīs parakstītās procedūras ir ar tiesībām izmantotdokumentu šifrēšanas atslēgu. Tādējādi tiek nodrošināts, ka lietotājiem nav tiešas piekļuvesdatu bāzes tabulām. Procedūru izmaiņu gadījumā tās ir atkārtoti jāparaksta. EVK tiekizmantots speciāls sertifikāta lietotājs, tas ir speciāls lietotāja veids, kas tiešā veidā nevarpieslēgties SQL serverim, bet servera iekšienē var tikt izmantots ar sertifikātu parakstītāsprocedūrās un trigeros. Ja procedūra ir parakstīta ar sertifikātu, tad šī procedūra var piekļūtvisiem objektiem, kas ir atļauti šī sertifikāta lietotājiem.6.2.2 Datu integritāteEVK sistēmas datu kvalitāte, integritātes kontrole (ieskaitot biznesa loģikas noteiktos datuintegritātes nosacījumus) un datu pilnīgums tiek nodrošināti SQL datu bāzes līmenī ar SQLiebūvētajiem līdzekļiem. Datu līmenī tiek realizēta arī pieejas kontrole, ierobežojot pieeju nobiznesa loģikas tikai biznesa funkcijām nepieciešamā apjomā, kā arī audita funkcijas.EVK medicīnas dokumentu integritāte tiek nodrošināta, izmantojot elektronisko parakstu.Jebkurš ienākošais medicīniskais dokuments automātiski tiks elektroniski parakstīts,izmantojot pasūtītāja PKI infrastruktūru vai ārējas organizācijas pakalpojumus. Parakstīšanasmērķis nav dokumenta autora identificēšana, bet gan tikai dokumentu integritātesnodrošināšana, tāpēc dokumenti tiks parakstīti ar sistēmai izdotu X.509 sertifikātu. Tā kāsertifikātu derīguma termiņš ir īsāks nekā medicīnas dokumentu uzglabāšanas laiks, EVKnākotnes funkcionalitātē ir jāparedz dokumentu pār-parakstīšana ar jaunu parakstu.6.2.3 Elektroniskais parakstsMedicīniskos dokumentus būs iespējams saglabāt elektroniski parakstītus, izmantojotuzticama sertifikācijas pakalpojumu sniedzēja (turpmāk tekstā USPS) programmatūrasradītos elektroniskos dokumentus.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 59 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06USPS programmatūras radītais elektroniskais dokuments (parakstītais fails) tiek veidots kāOpen Packaging Conventions formātam atbilstošs fails. Šī formāta apzīmēšanai USPS izmantoterminu eDoc. eDoc formāta dokuments sastāv no metadatu, parakstāmo failu un parakstusekcijām. Tas ir veidots kā konteiners, kurš var saturēt jebkura formāta failus, tai skaitāmedicīnisko dokumentu, drošo elektronisko parakstu un laika zīmogu.eDoc formāts plašāk ir aprakstīts eDoc dokumenta formāta specifikācijā, skat. [12].EVK repozitorijā ir paredzēts saglabāt elektroniski parakstītus dokumentus (eDoc)neatpakotus - tādus, kādi tie ir saņemti no ārējām sistēmām. Elektroniski parakstītusdokumentus varēs apstrādāt un pārbaudīt, izmantojot standarta eDoc rīku eParakstītājs, koizplata sertifikācijas pakalpojumu sniedzējs (LVRTC).6.3 Sistēmas komponentu sadarbībaŠajā nodaļā aprakstīta sistēmas loģisko komponentu karte, kurā ilustrēta komponentusavstarpējā sadarbība un sadarbība ar ārējām sistēmām.Sistēmas loģisko komponentu karte, kurā ilustrēta komponentu savstarpējā sadarbība unsadarbība ar ārējām sistēmām, shematiski parādīta 20. attēlā. Ar raustītu elementa robežu irattēlotas nākotnē plānotās sistēmas vai moduļi.Attēlā redzams, ka EVK moduļi savu funkcionalitāti nodrošinās citām ārējām sistēmām, nokurām galvenās ir e-Veselības portāls, ārstniecības iestāžu IS, e-Pakalpojumi, e-Pieraksti,e-Nosūtījumi un e-Recepte. Lai gan komponentu kartē tas nav parādīts, visi izsaukumi noārējām sistēmām uz EVK tiks veikti ar IP starpniecību. Visi izsaukumi, kas nonāks EVKpublicētajās tīmekļa pakalpēs, tiks autentificēti un auditēti, izmantojot autentifikācijas unauditācijas moduli, kas sadarbojas ar IP auditu.EVK sistēmas moduļi tiek iedalīti šādās grupās: Pārvaldības moduļi, kas satur administratīvās funkcijas sistēmas darbībasnodrošināšanaiooAdministrēšanas modulisMetadatu pārvaldībaPamat funkcionalitātes moduļi, kas satur sistēmas pamatfunkcionalitātioooooooPamatdatu un pierakstu pārvaldībaeDoc pārbaudes servissFona uzdevumiDokumentu validācijas modulisJaundzimušo datu aktualizācijaĢimenes ārstu un EVAK datu aktualizācijaPersonas datu aktualizācijaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 60 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06o Vakcināciju modulisAtbalsta moduļi, kas satur pārvaldības un pamata funkcionalitātes atbalsta funkcijaso Autorizācijas moduliso Klasifikatoru moduliso IP audita un sistēmas žurnāla bibliotēkasPraktiski katrs no sistēmas moduļiem darbosies ar savu datu krātuvi, kurā tiks glabātamodulim nepieciešamā informācija. Datu noliktavas integrācijas modulis, fona uzdevumumodulis un klasifikatoru modulis piekļūst vairāku moduļu atbilstošajām datu krātuvēm.IP audita un sistēmas žurnāla bibliotēkas izmantos visi pārējie biznesa servisu līmeņa moduļi,lai veiktu audita un tehnisko notikumu informācijas fiksēšanu IP audita un sistēmas žurnāladatu bāzēs.Gadījumos, kur EVK moduļi izsauks ārējās sistēmas, kuru pieejamību nav iespējams garantēt,vai, kuras ienākošos ziņojumus varēs apstrādāt tikai noteiktos laika periodos, piemēram,naktīs, IP vide būs tā, kas nodrošinās ziņojumu uzkrāšanu, lai garantētu ziņojumu piegādi,kad ārējo sistēmu darbība vai to saskarņu darbība tiks atjaunota.Darbietilpīgu apstrādes uzdevumu veikšanai, kā arī regulāri veicamo uzdevumu izpildei tiksizmantota fona uzdevumu komponente.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 61 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0620. attēls. EVK loģiskie komponenti un to sadarbībaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 62 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.066.4 Sistēmas komponentiŠajā nodaļā aprakstīti svarīgākie projektējuma elementi, loģisko komponentu funkcionalitāteun izmantotie produkti un tehnoloģijas. EVK ir dalīta moduļos pēc funkcionalitātes principa.Precizējot klienta prasības un detalizējot EVK sistēmas arhitektūru, analīzes fāzes rezultātāradās nedaudz savādāks EVK sadalījums pa moduļiem, salīdzinot ar tehnisko piedāvājumu.EVK funkcionālā sadalījuma pa moduļiem atšķirības ir norādītas šī dokumenta pielikumā„EVK funkcionālais sadalījums pa moduļiem”.6.4.1 Autorizācijas modulisAutorizācijas modulis nodrošina EVK autorizācijas funkcionalitāti - aizliegumu, pilnvaru unatļauju apstrādi un lietotāju tiesību pārbaudi.Lietotāju autentifikācija un veselības aprūpes iestāžu darbinieku autorizācija tiks nodrošinātaintegrācijas platformas modulī. Pacientu autorizāciju nodrošinās EVK autorizācijas modulis.EVK autorizācijas modelis balstās uz EVK tiesību punktiem, lietotāju lomām, atļaujām unaizliegumiem. Katrai EVK tīmekļa pakalpei tiks izveidoti fiksēti tiesību punkti.IP lietotāju administrēšanas modulī administrators veidos veselības aprūpes iestāžudarbinieku lomas, kombinējot tiesību punktus, un lomas piesaistīs konkrētiem lietotājiem vailietotāju grupām.Savukārt pacienta loma tiek noteikta dinamiski. Atkarībā no personas vecuma grupas,pilngadības pazīmes un aizgādnības tiek izdalītas 8 pacientu lomas. Detalizētāk pacientalomas un to noteikšanas algoritms ir aprakstīti programmatūras prasību specifikācijas sadaļā„Lietotāju grupas un to raksturiezīmes”, skat. [1]. Paredzamais pacienta lomu un tiesībuattiecību sadalījums pieejams programmatūras prasību specifikācijas pielikumā „Lietotājutiesību matrica”, skat. [1].Papildus lietotāja tiesību pārbaudei tiks izmantotas atļaujas un aizliegumi. Informācija parpacientu atļaujām, aizliegumiem un pacientu dinamiskajām lomām tiek uzturēta EVKsistēmā, tāpēc pacientu autorizācijas gadījumā IP pieprasīs no EVK iedzīvotāju autorizācijainepieciešamos papildus atribūtus:vārds, uzvārdspersonas kodse-pasta adresepacienta dinamiskā loma:o „Lietotājs ir pacients”o „Lietotājs ir pacienta māte, tēvs vai aizbildnis”o „Lietotājs ir pacienta aizgādnis”atļaujas, aizliegumi, deleģētās tiesībasNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 63 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06lietotāja tiesību vektors – satur atļautās darbības konkrētajā e-Veselības centrālajāsistēmā, piemēram, iegūt pacienta karti no EVKŠie papildus atribūti tiks atgriezti izsaucošajai sistēmai drošības talona veidā. Precīzāk IPautorizācijas servisi, to izmantošanas scenāriji un konkrētie drošības talona atribūti iraprakstīti IP risinājuma arhitektūras vīzijas dokumentā, skat. [5].Aizbildņa vai aizgādņa pārbaude tiek veikta dinamiski, pacientam pieprasot pieeju savaaizbilstamā vai aizgādamā pacientu kartei. Ja informācija no PMLP IR apstiprinaaizbildniecības vai aizgādnības faktu, tad pieeja tiek atļauta.Autorizācijas modulis nodrošina šādu ārējo saskarni, kas ir publiski pieejama caur IP:checkDetailedRole – nosaka detalizēto lomu.Autorizācijas modulis papildus nodrošina šādas privātās metodes:checkRightsSetObjectAccessRights – pārbauda tiesības uzstādīt aizliegumu;checkRigthsAccessPatientCard – pārbauda tiesības piekļūt pacienta kartei;checkUserRightsAccessObject – pārbauda personas tiesību līmeni uz objektu;checkUserRight – pārbauda, vai lietotāja tiesību komplektā ir iekļauta specifiskatiesība.6.4.2 Metadatu pārvaldībaMetadatu pārvaldības komponents nodrošina administratīvu funkcionalitāti, kas saistīta ardokumentu metasistēmu – EVK dokumentu tipu, veidņu un modeļu pārvaldību.Tā kā EVK glabātā informācija varēs mainīties laika gaitā un varēs parādīties jauni EVKierakstu tipi, metadatu pārvaldības modulis satur informāciju par EVK pieļaujamiemmedicīnisko ierakstu tipiem, to sintaksi un semantiku. Informācija tiek izmantota visu EVKiesūtīto ierakstu pārbaudei pirms tie tiek akceptēti kā pacienta ieraksta sastāvdaļa.Dokumentu veidņu administrēšana ir administratīva funkcija, kurai tiek nodrošināta lietotājusaskarne. Metadatu informācijas pieejamība citām sistēmām tiek nodrošināta caur tīmekļapakalpēm.EVK dokumentu meta sistēma apraksta:dokumentu tipussekciju tipussekciju apstrādes uzdevumusKatram dokumentu tipam tiek izveidota arī XSLT transformācija, kas nodrošina HTMLformāta datu ģenerēšanu dokumenta atainošanai cilvēklasāmā formātā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 64 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Sekciju apstrādes uzdevumi ir nepieciešami, lai izgūtu no sekcijām noteiktu datu kopu, kasattiecas uz EVK pamatdatiem, un iekļautu to atbilstošajās pamatdatu tabulās. Sekcijuapstrādes uzdevumi tiks veidoti, izmantojot XPath un XSLT tehnoloģijas.Metadatu pārvaldības modulis nodrošina šādas ārējās saskarnes, kas ir publiski pieejamascaur IP:setDocumentTemplate – pievieno un papildina dokumenta veidni;getDocumentTemplate – iegūst dokumenta veidnes datus;getDocumentTemplateList – iegūst dokumentu veidņu sarakstu.Dokumenta veidņu modelēšanae-Veselības medicīnisko dokumentu elektroniskais formāts atbilst HL7 CDA specifikācijai.Detalizētāk tas ir aprakstīts programmatūras prasību specifikācijas sadaļā „Medicīniskiedokumenti”, skat. [1].Pilns dokumentu veidņu modelēšanas process ir aprakstīts programmatūras prasībuspecifikācijas sadaļā „Dokumentu veidņu modelēšana”, skat. [1].Kā CDA dokumentu modelēšanas rīks tiek izmantots Model-Driven Health Tools (MDHT),kurš nodrošina CDA dokumentu modelēšanu. Dokumenta izstrādes rezultāts ir dokumentaXSD shēma, kas nosaka kādi dokumenta elementi un atribūti ir obligāti, kādi var atkārtotiesvairākas reizes. Ārpus XSD shēmas tiek norādīts arī kas tiek glabāts CDA dokumentaelementos, piemēram, kādu klasifikatoru drīkst izmantot konkrētais CDA dokumentaelementa aizpildei. Zemāk 21. attēlā kā piemērs ir redzama „No stacionāra izrakstīta (miruša)pacienta karte”, jeb veidlapa Nr. 066/u MDHT modelēšanas rīkā. Piemērā redzams, ka šīveidlapa satur šādas sekcijas:administratīvā sekcija (administrativeSection)saslimšanas sākums (onsetOfTheDiseaseSection)slimnieka kustība (patientMovementSection)operācijas un anestēzijas (operationAndAnesthesiaSection)citas manipulācijas (otherManipulationsSection) manipulācijas, kuras veiktas citās ārstniecības iestādēs(manipulationInOtherHospitalsSection)Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 65 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0621. attēls. No stacionāra izrakstīta pacienta karte MDHT UML modelēšanas rīkāCDA dokumenti tiek veidoti no sekciju aprakstiem, kas tiek definēti atsevišķā sekciju UMLfailā. Arī piemērā izmantotie sekciju tipi ir definēti atsevišķi. Zemāk 22. attēlā kā piemērs irredzams sekciju tipu fails, kurš satur, piemēram, manipulāciju (Manipulation) sekcijas tipaaprakstu. Pacienta kartē gan sekcija „Citas manipulācijas”, gan sekcija „Manipulācijas, kurasveiktas citās ārstniecības iestādēs” abas manto manipulāciju sekciju tipu.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 66 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0622. attēls. EVK sekciju tipi MDHT UML modelēšanas rīkāDokumentu validācijas modulisKad dokumenta tipa UML modelis ir izstrādāts, tas tiek transformēts komponentēs, kasnepieciešamas dokumenta veidnes lietošanai. No UML modeļa automātiski tiek uzģenerētasdokumenta XSD shēma un Java bibiliotēka. Uzģenerētā Java bibliotēka sastāv no divāmbibliotēkām – viena satur pašu CDA dokumentu aprakstošās klases, bet otra satur EVKsekciju tipu klases. Katra CDA dokumenta sekcijai atbilst atsevišķa klase, piemēram,OperationAndAnesthesiaSection. Bibliotēka nodrošina metodes XML formāta failanolasīšanai, CDA dokumenta saglabāšanai XML formātā, dokumenta validācijai, dokumentasekciju un to elementu apstrādei.EVK pievienojot jaunu medicīnisko dokumentu, sinhronā režīmā tiek pārbaudīta tā atbilstībaXSD shēmai, tomēr netiek pārbaudīta attiecīgā dokumenta saturiskā atbilstība CDA modelim.MDHT nodrošina java klašu ģenerāciju, kas papildus XSD shēmu validācijai veic arīdokumenta saturisko atbilstību modelim. Dokumenta validācija notiek, veidojot attiecīgāsklases instanci un pārbaudot tās atbilstību modelim. Ja tiek konstatēta neatbilstība, tiekizvadīts kļūdu saraksts.Dokumentu validācijas modulis tiek realizēts kā Web Serviss, kuram ir dokumenta validācijaiparedzēta funkcionalitāte. Web servisam tiek padots CDA XML dokuments. Serviss nosaņemtā XML dokumenta veido klases instanci un pārbauda dokumentu atbilstību MDHTrīkā izveidotajam CDA dokumenta modelim, tai skaitā dokumenta saturisko pārbaudi. JaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 67 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06dokuments neatbilst modelim, tiek izvadīts kļūdu saraksts. Šis kļūdu saraksts tiek atgrieztsizsaucošajai metodei, un tas to tālāk saglabā pie dokumenta kļūdu sarakstā, vienlaicīginomainot dokumenta statusu.Zemāk 23. attēlā ir redzams koda paraugs, kas izveido neaizpildītu pacienta kartesdokumentu testēšanas mērķiem.23. attēls. Pacienta kartes testa dokumenta izveideSagatavotās komponentes tiek nodotas EVK IS administratoram, kas tās iekļauj dokumentutipu katalogā.Dokumentu validācijas moduli izmanto pamatdatu un pierakstu pārvaldības komponents,piemēram, jaunu dokumentu pievienošanas laikā, skat. šī dokumenta sadaļu 6.4.3.Dokumentu validācijas modulis nodrošina šādu privāto metodi:validateDocumentModel – validē dokumentu pret modeli.Prezentācijas katalogsPrezentācijas katalogs ir daļa no EVK metadatiem, kas nodrošina vienotu un vienādumedicīnisko ierakstu attēlošanu (transformāciju no EVK saglabātā ieraksta) HTML formātā,kā arī datu ievada formas. Tas nodrošina iespēju definēt nepieciešamās transformācijas XSLTformātā, kā arī gadījumos, kad tas ir nepieciešams, automātiski izpildīt datu priekšapstrādiEVK pirms atbildes nosūtīšanas pieprasītājam. HTML formāta datu ģenerēšana ir aprakstīta šīdokumenta sadaļā „EVK dokumentu iegūšana”, skat. šī dokumenta sadaļu 6.4.3.Katram EVK medicīnisko dokumentu tipam prezentāciju katalogā tiek izveidota un saglabātaXSLT transformācija, kas nodrošina dokumenta attēlošanu HTML formātā.Ar modelēšanas rīka (MDHT) palīdzību katram dokumenta tipam tiek izstrādāts tehniskaisdokumenta modelis, kas ir aprakstīts UML valodā, kas ļauj izstrādātājiem ģenerēt dokumentaievades formas e-Veselības portālā un citās ārstniecības iestāžu informācijas sistēmās,izvietojot lietotāja saskarnes elementus atbilstoši UML klašu diagrammām. Tās satur CDAdokumentu definīcijas, kas apraksta dokumentu struktūru un tā atribūtus, kā arī saistītoklasifikatoru identifikatorus. UML klašu diagrammās katram CDA dokumenta atribūtam vartikt norādīts, piemēram, tā nosaukums, atribūta tips, sākuma vērtība, kardinalitāte un citiparametri. Izmantojot šo informāciju, kā arī informāciju par klasifikatoriem, ir iespējamsautomātiski ģenerēt datu ievades formas. Informācija par pašu klasifikatoru metadatiem varNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 68 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06tikt ņemta no klasifikatoru reģistra. UML klašu diagrammu piemēri ir redzami attēlos 21 un22.UML dokumenta modelis tiek saglabāts (eksportēts) atbilstoši XMI standartam, kas aprakstaUML diagrammu saglabāšanu XML formātā. Tas tiek izmantots UML diagrammu un citumetamodeļu importēšanai un eksportēšanai starp modelēšanas rīkiem, kā arī tas nodrošinaizstrādātājiem platformu koda ģenerēšanai no UML vai citiem modeļiem. Tai skaitā tas vartikt izmantots arī CDA dokumentu ievades formu ģenerēšanai, jo tas satur pilnīgi visuinformāciju par CDA dokumentu, kas tiek radīta tā modeļa izstrādes laikā.Papildus tam izstrādātājiem ir pieejamas datu validācijas komponentes, kas tiek ģenerētaskatram CDA modelim. Tās tiek izmantotas, piemēram, Dokumentu validācijas modulī. Datuvalidācijas komponentes ir Java bibliotēkas (*.jar formāta fails), kas satur nepieciešamoloģiku, lai validētu CDA dokumentus uz atbilstošo modeli.EVK sistēmā CDA dokumenti nerodas, bet gan tie tiek iesūtīti no citām ārējām sistēmām.CDA dokumentu ievades formas tiek ģenerētas un izvietotas e-Veselības portālā un citāsārstniecības iestāžu informācijas sistēmās. Tās plašāk ir aprakstītas e-Veselības portālatehniskās arhitektūras dokumentā, skat. [6].6.4.3 Pamatdatu un pierakstu pārvaldībaModulis nodrošina elektronisko veselības pierakstu informācijas pārvaldību, darbības loģikue-Veselības pierakstu uzkrāšanai un pieejamības nodrošināšanai, ņemot vērā noteiktāspieejas tiesības un pieejas politikas, kā arī nodrošinot nepieciešamo datu aizsardzības līmeni.Tas nodrošina EVK pamata funkcionalitāti, kas saistīta ar pacientu kartēm un medicīniskajiemdokumentiem:Pacienta kartes funkcijas, kas nodrošina jauna ieraksta veidošanu, labošanu unanulēšanu tādām datu kopām kā pacienta karte, personas kontaktinformācija unkontaktpersonas; Medicīnisko dokumentu apstrādes funkcijas, kas nodrošina dokumentupievienošanu, validāciju, kā arī datu izgūšanu no sekcijām un anulēšanu.Pamatdatu un pierakstu pārvaldības modulis nodrošina šādas ārējās saskarnes, kas ir publiskipieejamas caur IP:addDocument – pievieno dokumentu;addComments – pievieno piezīmes;setDocumentStatus – labo dokumenta statusu;setAccessRights – uzstāda un noņem aizliegumus;createPatientCard – izveido pacienta karti;getDocument – iegūst dokumentu;Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 69 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06getDocumentsList – iegūst dokumentu sarakstu;getPatientCard – iegūst pacienta karti;mergePatientCards – sapludina pacienta kartes;setPatientCard – pievieno un papildina pacienta kartes datus;getProfileSettings – iegūst uzstādījumus;setProfileSettings – pievieno un maina uzstādījumus.Pamatdatu un pierakstu pārvaldības modulis papildus nodrošina šādas privātās (sistēmasiekšējo procesu nodrošināšanai izmantotas un lietotājam tiešā veidā nepieejamas) metodes:generateCCD – ģenerē CDA dokumentu ContinuityCareDocument ar iekļautiempacienta veselības pamatdatiem laika periodā;processDocument – dokumenta pievienošanas asinhronā daļa;internalTaskProcessing – pamatdatu uzdevumu apstrāde;externalTaskProcessing – ārējo uzdevumu apstrāde;generatePDF – ģenerē PDF;setPersonMajority – uzstāda personas pilngadības pazīmi.Pacienta kartes stāvokļiPacienta kartei ir iespējami šādi stāvokļi:Inicializācija – pacienta kartei ar personas koda identifikāciju šai laikā notiekpersonas, ģimenes ārsta un EVAK datu aizpildīšana. Šai statusā pacienta karte irdaļēji aizpildīta, tomēr ar to jau ir iespējams veikt darbības un pievienot medicīniskosdokumentus.Aktuāls – pacienta kartes pamata stāvoklis. Aktuāls kartes statuss saglabājas arīpersonai pēc nāves; miršanas faktu raksturo personas statuss.Neaktuāls – statuss rodas, piemēram, sapludināšanas rezultātā kartei, kura tieklikvidēta. Neaktuālās kartes nepiedalās sistēmas procesos, tām nevar pievienotdokumentus un veikt citas darbības.Pacienta kartes stāvokļa pārejas diagramma redzama 24. attēlā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 70 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0624. attēls. Pacienta kartes stāvokļiPacienta kartes izveideTā kā jaunu pacienta karšu izveide EVK ir pietiekoši sarežģīts un laikietilpīgs process, pacientakaršu izveide EVK tiek veikta asinhroni. Pacienta karšu izveides metode sākotnēji veic tikaitās pacienta karšu izveides darbības, kuras nav atkarīgas no ārējo sistēmu izsaukumiem unkuras līdz ar to ir iespējams veikt sinhroni. Savukārt datu savākšana no ārējām sistēmām unto aizpilde pacienta kartē tiek veikta asinhroni ar fona uzdevumu komponentes palīdzību.Asinhronie pieprasījumi tiek uzkrāti rindā, un apstrādāti sistēmā iepriekš definētā laikaposmā pēc kārtas.Pacienta kartes izveides rezultātā klientam tiek atgriezts unikāls pacienta kartesidentifikators. Lai uzzinātu, vai pacienta kartes izveidošana bija veiksmīga, klients vēlāk izsaucspeciālu pieprasījumu, kā parametru nododot iepriekš saņemto pacienta kartesidentifikatoru. Pēc šī identifikatora EVK identificē un atgriež pacienta kartes izveides statusu.Pacientu karšu personas dati tiek periodiski atjaunināti, izmantojot fona uzdevumus.Pacienta karšu izveide shematiski ir parādīta 25. attēlā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 71 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0625. attēls. Pacienta karšu izveideVeidojot jaunu pacientu karti EVK, tiek veiktas šādas darbības:1. Tiek pārbaudītas tiesības. Ja lietotājam nav tiesību izveidot jaunu pacienta karti, tiekatgriezts atbilstošais kļūdas paziņojums.2. Ja personu identificē personas kods, tiek izveidots personas ieraksts ar aizpildītupersonas kodu un izveidotajai pacienta kartei tiek uzstādīts statuss „Inicializācija”.Gadījumā, ja norādītajam personas kodam pacienta karte jau eksistē, tā tiek no jaunainicializēta.3. Ja personu identificē alternatīva identifikācija, piemēram, jaundzimušo gadījumā, tiekizveidots personas ieraksts ar aizpildītu alternatīvo identifikāciju un izveidotajai pacientakartei tiek uzstādīts statuss „Aktuāls”.4. Ja personu identificē personas kods, tiek izveidots jauns pacientu kartes apstrādesuzdevums un pievienots uzdevumu rindai, ko vēlāk apstrādās fona uzdevumukomponente.5. Izsaucējam tiek atgriezts pacienta kartes identifikators, izmantojot kuru, vēlāk iriespējams uzzināt, vai pacienta kartes izveide bija veiksmīga.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 72 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.066. Visi personas kartes izveides soļi tiek reģistrēti sistēmas žurnālā, izmantojot IP sistēmasžurnāla bibliotēku.7. Jebkurā procesa solī kritiskā kļūdas gadījumā tiek atgriezts atbilstošais kļūdas ziņojums.Detalizētāk šis process ir aprakstīts PPA dokumentā.Pacienta kartes tālākā apstrāde fona režīmāAsinhronā daļa nodrošina datu savākšanu no ārējām sistēmām un to aizpildi pacienta kartē.Fona uzdevumu komponente asinhronā režīmā veic tālāko pacienta kartes apstrādi, kas irshematiski parādīta 30. attēlā.26. attēls. Pacienta kartes asinhronā apstrādeIzveidojot jaunu pacienta karti EVK, tiek veiktas šādas darbības:1. Fona uzdevumu komponente periodiski pārbauda uzdevumu rindu un saņem jaunuspacienta kartes apstrādes uzdevumus.2. No PMLP IR tiek pielasīti personas dati. PMLP IR sistēmas nepieejamība vai citas kļūdassituācijas pēc iespējas tiek apstrādātas Integrācijas platformā.3. No NVD VIS tiek pielasīti personas ģimenes ārsta dati. NVD VIS sistēmas nepieejamība vaicitas kļūdas situācijas pēc iespējas tiek apstrādātas Integrācijas platformā.4. No NVD VIS tiek pielasīti personas EVAK dati. NVD VIS sistēmas nepieejamība vai citaskļūdas situācijas pēc iespējas tiek apstrādātas Integrācijas platformā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 73 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.065. Pacienta karte tiek papildināta ar papildus iegūtajiem datiem.6. Pēc asinhronās daļas izpildes pacienta kartei tiek uzstādīts statuss „Aktuāls”. Zinotpacienta kartes identifikatoru, pacienta kartes veidotājs vēlāk var noskaidrot, vaipacienta kartes izveide ir bijusi veiksmīga.7. Visi pacienta kartes izveides soļi tiek reģistrēti sistēmas žurnālā, izmantojot IP sistēmasžurnāla bibliotēku.8. Jebkurā procesa solī kritiskas kļūdas gadījumā pacienta karte paliek stāvoklī„Inicializācija” un EVK sistēmas žurnālā tiek ierakstīts kļūdas paziņojums ar visāmtehniskajām detaļām, lai sistēmas administrators varētu veikt kļūdas cēloņaizmeklēšanu.Detalizētāk šis process ir aprakstīts PPA dokumentā.EVK dokumentu stāvokļiDokumentam iespējami šādi stāvokļi:Apstrādē – dokuments izgājis sinhronās daļas apstrādi. Šai statusā dokumentaieraksts datu bāzē ir daļēji aizpildīts.Aktuāls – statuss rodas veiksmīgas asinhronās apstrādes rezultātā. Pilnvērtīgsdokuments.Kļūdains – statuss rodas neveiksmīgas asinhronās apstrādes rezultātā. Šāda statusadokumenti ir pieejami ārstniecības personām – dokumenta autoriem, lai sagatavotujaunu versiju vai to anulētu. Pacienti tos neredz. Kļūdainam dokumentam pieejamskļūdu saraksts, kas konstatētas validācijas laikā. Dokumentu pieejamība tiek noteiktaar tiesību mehānismu. Sistēmas administrators, izmantojot IP sistēmas lomu kontrolivar izmainīt tiesības pēc noklusēšanas.Anulēts – statuss rodas, piemēram, dokumentu anulējot pēc pieprasījuma vaidokumentam pievienojot jaunu versiju.EVK dokumentu stāvokļa pārejas diagramma redzama 27. attēlā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 74 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0627. attēls. EVK dokumenta stāvokļiEVK dokumentu pievienošanaEVK dokumentu pievienošanas metode pacientu kartēm pievieno vienu vai vairākusdokumentus pēc pieprasījuma. Pievienojāmam dokumentam jāatbilst CDA dokumentastandartam. Izmantojot šo metodi, pievieno arī veselības pamatdatu ierakstus (alerģiju,brīdinājumu, diagnozi, med. ierīci, medikamentu). Arī šajā gadījumā tiek veidots CDAdokuments ar veselības pamatdatu sekciju/entry. Dokuments var būt arī jauna versijaiepriekš pievienotam dokumentam.Saskaņā ar HL7 transporta specifikāciju e-Veselības ziņojumu apmaiņa notiek, izmantojotSOAP protokolu, kur SOAP aploksnes galvenē atrodas adresācijas un drošības dati, betaploksnes ķermenis satur HL7 mijiedarbības ziņojumu, piemēram,RCMR_IN000002UV01_LV01. SOAP ziņojums un tā sasaiste ar HL7 standartu shematiski irattēlota 28. attēlā zemāk. Detalizētāk e-veselības ziņojumapmaiņā izmantojamo datustruktūras ir aprakstītas IP HL7 izmantošanas standartos, skat. [18].Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 75 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0628. attēls. SOAP aploksnes satursVisos servisos pieprasījumiem tiek izmantots vienāds HL7 pārraides apvalks(MCCI_MT000100UV01_LV01). Tas ietver informāciju, kas nepieciešama sūtītāja sistēmai, laimaršrutētu HL7 V3 ziņojumu.Visos servisos tiek izmantots vienāds HL7 vadības darbības apvalks(MCAI_MT700201UV01_LV01). Tas ietver administratīvu informāciju, kas saistīta ar vadībasdarbību.Konkrēti EVK dokumenta pievienošanas scenārijā HL7 informatīvā daļa saturRCMR_MT000002UV02_LV01.ClinicalDocument datu struktūru, kas satur CDA dokumentu.Detalizētāk RCMR_IN000002UV01_LV01 un citas EVK HL7 mijiedarbības ir aprakstītassaskarņu izmantošanas rokasgrāmatā, skat. [19].Tā kā jaunu dokumentu saņemšana no ārējām sistēmām un saglabāšana EVK ir pietiekošisarežģīts un laikietilpīgs process, dokumentu pievienošana EVK tiek veikta asinhroni.Dokumentu pievienošanas metode sākotnēji veic tikai tās dokumenta pārbaudes unapstrādes darbības, kuras pēc iespējas nav atkarīgas no ārējo sistēmu izsaukumiem un kuraslīdz ar to ir iespējams veikt sinhroni. Vienīgais ārējās sistēmas izsaukums ir personas datuiegūšana no PMLP IR. Tas ir nepieciešams, lai nodrošinātu datu integritāti. Savukārt tālākāpievienoto dokumentu apstrāde, kuras izpildē ir iesaistīti ārējo sistēmu izsaukumi vailaikietilpīgas darbības, tiek veikta asinhroni ar fona uzdevumu komponentes palīdzību.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 76 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Asinhronie pieprasījumi tiek uzkrāti rindā, un apstrādāti sistēmā iepriekš definētā laikaposmā pēc kārtas.Dokumenta pievienošanas rezultātā klientam tiek atgriezts unikāls EVK dokumentaidentifikators. Lai uzzinātu, vai dokumenta pievienošana bija veiksmīga, klients vēlāk izsaucspeciālu pieprasījumu, kā parametru nododot iepriekš saņemto dokumenta identifikatoru.Pēc šī identifikatora EVK identificē un atgriež dokumenta pievienošanas statusu.EVK dokumentu pievienošana shematiski ir parādīta 29. attēlā.29. attēls. EVK dokumentu pievienošanaPievienojot jaunu dokumentu EVK, tiek veiktas šādas darbības:1. Tiek pārbaudītas tiesības.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 77 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.062. Ja dokuments ir elektroniski parakstīts, tiek pārbaudīts tā elektroniskais paraksts,izmantojot eDoc pārbaudes servisu. Kļūdas gadījumā tiek atgriezts atbilstošais kļūdasziņojums.3. Tiek veikta dokumenta sākotnējā validācija, izmantojot atbilstošā dokumenta tipavalidatoru. Validatori pārbauda tikai tās klasifikatoru vērtības, kuras ir atrodamas EVKklasifikatoru repliku glabātuvē. Ja dokumenta pārbaudei ir nepieciešams veikt tiešsaistespieprasījumus reģistriem, klasifikatoru modulim vai citām ārējām sistēmām, šīs darbībastiek veiktas asinhroni kā daļa no fona uzdevumiem. Tiek pārbaudīts, vai dokuments aršādu numuru un versiju jau nav pievienots. Šajā gadījumā tiek atgriezta kļūda.4. Ja pacienta karte sistēmā neeksistē, tiek veikta personas datu pieprasīšana noIedzīvotāju reģistra un izveidota jauna pacienta karte.5. Veiksmīgas validācijas rezultātā dokuments tiek saglabāts EVK dokumentu repozitorijāšifrētā veidā.6. Tiek izveidots jauns dokumentu apstrādes uzdevums un pievienots uzdevumu rindai, kovēlāk apstrādās fona uzdevumu komponente.7. Dokumenta statuss tiek nomainīts uz „Apstrādē”. Kamēr tas atrodas šinī statusā,dokuments citām komponentēm nav pieejams, izņemot fona uzdevumu komponentu.8. Izsaucējam tiek atgriezts EVK dokumenta identifikators, izmantojot kuru, vēlāk iriespējams uzzināt, vai dokumenta pievienošana bija veiksmīga.9. Visi dokumenta apstrādes soļi tiek reģistrēti sistēmas žurnālā, izmantojot IP sistēmasžurnāla bibliotēku.10. Kļūdas gadījumā tiek atgriezts atbilstošais kļūdas ziņojums.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 78 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06EVK dokumentu tālākā apstrāde fona režīmāFona uzdevumu komponente asinhronā režīmā veic tālāko dokumenta apstrādi, kas irshematiski parādīta 30. attēlā.30. attēls. EVK dokumentu asinhronā apstrādePievienojot jaunu dokumentu EVK, tiek veiktas šādas darbības:1. Fona uzdevumu komponente periodiski pārbauda uzdevumu rindu un saņem jaunusdokumentu apstrādes uzdevumus.2. Dokuments tiek nolasīts un atšifrēts.3. Tiek veikta dokumenta lauku vērtību pārbaude pret reģistriem un klasifikatoriem, kuriemnav pieejama lokāla replika un ir nepieciešams veikt tiešsaistes izsaukumus.4. Izmantojot metadatu pārvaldības komponentes, dokuments tiek sadalīts sekcijās.Izmantojot konkrēto sekciju tipu adapterus, no sekcijām tiek iegūtas datu kopas, kasattiecas uz EVK pamatdatiem.5. Dokuments tiek elektroniski parakstīts, izmantojot sistēmas X.509 sertifikātu.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 79 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.066. Ja tas ir nepieciešams, dokuments tiek saspiests, izmantojot ZIP failu formātu.EVK veiktspējas testu laikā tiks noteikts, vai EVK dokumentus ir nepieciešams saspiest vainē. Dokumentu saspiešana ekonomē vietu uz datu nesējiem, bet vienlaicīgi var ietekmētarī sistēmas ātrdarbību, papildus noslogojot sistēmas resursus. EVK medicīnasdokumenti satur XML formāta datus, kuri saspiestā veidā aizņem vidēji 8% no oriģinālādokumenta izmēra. Tādā veidā būtiski tiek ekonomēta vieta uz datu nesējiem, samazinotEVK risinājuma kopējās izmaksas. Tā kā EVK medicīnas dokumenti tiks saspiestiasinhronā režīmā un turpmāk tie tiks pieprasīti salīdzinoši reti, EVK kopējo veiktspējudatu saspiešana būtiski neietekmēs. Tomēr, lai noteiktu reālo dokumentu saspiešanasietekmi uz EVK ātrdarbību, vispirms ir nepieciešams veikt sistēmas veikspējas testus.7. Dokuments tiek saglabāts EVK dokumentu repozitorijā šifrētā veidā.8. Dokumenta veiksmīgas pievienošanas gadījumā dokumenta statuss tiek nomainīts uz„Aktuāls”. Kļūdas gadījumā dokumenta statuss tiek nomainīts uz „Kļūdains”, papildusatribūtā saglabājot arī atbilstošo kļūdas ziņojumu. Zinot dokumenta identifikatoru,dokumenta iesniedzējs vēlāk var noskaidrot, vai dokumenta pievienošana ir bijusiveiksmīga.9. Visi dokumenta apstrādes soļi tiek reģistrēti sistēmas žurnālā, izmantojot IP sistēmasžurnāla bibliotēku.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 80 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06EVK dokumentu iegūšanaEVK dokumentu iegūšana pieprasītajā formātā shematiski ir parādīta 31. attēlā.31. attēls. EVK dokumentu iegūšanaLai iegūtu EVK dokumentu pieprasītajā formātā, tiek veiktas šādas darbības:1. Tiek pārbaudītas tiesības.2. Ja dokuments ir pieprasīts HL7 formātā, tas tiek atšifrēts, ja nepieciešams, atspiests unatgriezts metodes izsaucējam. Tiek pārbaudīta arī dokumenta integritāte, pārbaudot tāelektronisko parakstu.3. HTML un citu formātu faili tiek ģenerēti tikai pēc vajadzības un uzglabāti kešatmiņā, laitos nevajadzētu atkārtoti ģenerēt pie katra dokumenta pieprasījuma. Ja dokumentspieprasītajā formātā jau eksistē kešatmiņā, tas tiek atgriezts metodes izsaucējam nokešatmiņas. Ja kešatmiņā vajadzīgais formāts nav pieejams, tas tiek dinamiskiNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 81 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06uzģenerēts, izmantojot atbilstošā formāta adapteri, saglabāts kešatmiņā un atgrieztsizsaucējam. Faili datu bāzē tiek uzglabāti šifrētā veidā.4. Visi dokumenta apstrādes soļi tiek reģistrēti sistēmas žurnālā, izmantojot IP sistēmasžurnāla bibliotēku.5. Kļūdas gadījumā tiek atgriezts atbilstošais kļūdas ziņojums.6.4.4 eDoc pārbaudes servisseDoc faila pārbaudes funkcionalitāte paredz eDoc faila formāta, tā integritātes, elektroniskāparaksta un izmantotā sertifikāta pārbaudi. Sertifikāta pārbaude notiek tiešsaistē, izmantojotOCSP klientu.eDoc pārbaudes serviss nodrošina elektronisko dokumentu iesniegšanu pārbaudei unpārbaudes rezultātu saņemšanu. Tā kā uzticamais sertifikācijas pakalpojumu sniedzējsgarantē OCSP servisu pieejamību, šis eDoc pārbaudes serviss var tikt veidots kā sinhronsserviss.eDoc pārbaudes serviss nodrošinās šādas funkcijas:pārbaudes pieprasījumu saņemšanu un izpildi;atbildes sinhronu atgriešanu;pieprasījumu, atbilžu un ar drošību saistītu darbību reģistrēšanu audita žurnālā.eDoc pārbaudes servisa loģiskais plānojums shematiski ir parādīts 32. attēlā.32. attēls. eDoc pārbaudes servisa loģiskais plānojumseDoc pārbaudes serviss sastāv no vairākām komponentēm:OCSP klients nodrošina sertifikātu statusu pārbaudi, izmantojot USPS publiskipieejamo OCSP servisu;Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 82 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06eDoc bibliotēka tiek izmantota, lai pārbaudītu eDoc dokumenta formāta pareizību undokumenta integritāti;Audita žurnāla mērķis ir uzkrāt informāciju par veiksmīgu vai neveiksmīgu pārbaudesrezultā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 serverainformācija atspoguļo pašreizējo sertifikāta statusu ar ļoti nelielu nobīdi starp, piemēram,sertifikāta apturēšanas pieprasījuma saņemšanu un reālo sertifikāta darbības apturēšanu.OCSP atbildes tiek radītas tieši izmantojot centrālo uzticama sertifikācijas pakalpojumusniedzēja sertifikātu datubāzi, neizmantojot CRL sarakstus vai LDAP katalogu kā starpslāņusinformācijas pieejai. Līdz ar to šī ir ieteicamākā no sertifikāta statusa pārbaudes metodēmprogrammatūras risinājumos.Visi USPS izsniegtie sertifikāti ir jebkurā laikā pārbaudāmi ar OCSP atbilžu servera palīdzību,izmantojot OCSP informācijas apmaiņas protokolu saskaņā ar RFC 2560 standartu.OCSP pieprasījumi un atbildes tiek kodēti ASN.1 kodējumā, tāpēc bibliotēkai ir jāpiedāvāfunkcijas, kas māk darboties ar ASN.1 kodējumu.OCSP klienta modulis satur vienu funkciju, kas nodrošina OCSP servera izsaukumu, nododottam kā parametru OCSP pieprasījumu un saņemot atbildi, kas satur sertifikātu statusus.Komunikācija ar OCSP servisu notiek, izmantojot HTTP vai HTTPS protokolu.eDoc bibliotēka nodrošina visas nepieciešamās pamatdarbības ar eDoc formātadokumentiem. Šī bibliotēka nodrošina šādas pamatfunkcijas:eDoc apstrāde – eDoc izveide, saglabāšana un ielāde;eDoc parakstīšana un paraksta pārbaude, izmantojot OCSP klienta bibliotēku;veidņu atbalsts – eDoc izveide, izmantojot iepriekš sagatavotu veidni;eDoc sekciju apstrāde – sekciju izveide un piekļuve to datiem;metadatu apstrāde – metadatu pievienošana, dzēšana, piekļuve to saturam;parakstāmo failu apstrāde – faila pievienošana, dzēšana, piekļuve to saturam;parakstu apstrāde – parakstu pievienošana, dzēšana, piekļuve to saturam.eDoc bibliotēka izmanto šādas papildus bibliotēkas:ASN.1 bibliotēka – tiek izmantoti OCSP pieprasījumu un atbilžu kodēšanai;XAdES bibliotēka – elektroniskais paraksts tiek veidots atbilstoši XAdES specifikācijai.To nodrošina XAdES bibliotēka;Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 83 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06ZIP formāta bibliotēka – eDoc faili tiek iepakoti kā ZIP formāta faili. To nodrošina ZIPformāta bibliotēka.eDoc pārbaudes serviss nodrošina šādu privāto metodi:extractXmlFromEdoc – izmantojot EDOCLibraries JAVA bibliotēku validē eDoc failuun veiksmīgas validācijas gadījumā atgriež CDA dokumentu.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 84 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.066.4.5 Fona uzdevumiFona uzdevumu modulis nodrošina asinhroni izpildāmos darbus. Tie iedalās:Regulārā datu sinhronizācijā, kas izpildās ar noteiktu periodiskumu, piemēram:o personas datu (tai skaitā pilngadības pazīmes) aktualizācija;o jaundzimušo datu aktualizācija;o NVD VIS ģimenes ārstu un EVAK datu aktualizācija;Rindu uzdevumos, kas izpildās nepārtraukti un kurus rindās ievieto citi procesi. Tiekizmantoti šādi rindu uzdevumi:o medicīnisko dokumentu asinhronā apstrāde;o personas datu pielasīšana;o pacienta karšu sapludināšana.EVK regulāri izpildāmie darbi tiek veikti kā atsevišķi veidots process (Windows serviss) fonadarbu veikšanai. Fona uzdevumu apstrādes komponenti nodrošina pakešveida uzdevumuveikšanu fona režīmā, piemēram, asinhronu datu apstrādi, informācijas aktualizēšanu vairegulāru datu nodošanu citām sistēmām.Rindas tiek realizētas ar SQL ServiceBroker iebūvētu funkcionalitāti.Fona uzdevumu komponenti shematiski ir parādīti 33. attēlā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 85 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0633. attēls. Fona uzdevumiFona uzdevumu modulis sastāv no šādiem komponentiem:uzdevumu plānotājs,konfigurācijas komponents,uzdevumu pārvaldība.Fona uzdevumi tiek izpildīti ar iepriekš konfigurējamu regularitāti. Katram uzdevumu tipamtā izpildes regularitāte tiek uzglabāta komponenta konfigurācijas tabulā, kā arī tam irizveidots atsevišķs adapteris, kas izpilda atbilstošo darbību loģiku.Uzdevumu plānotājs ir atbildīgs par uzdevumu izpildes plānošanu un kontroli. Uzdevumuizpilde var tikt uzsākta divos veidos, atkarībā no uzdevumu tipa:saņemot jaunu uzdevumu rindā, piemēram, sistēmai saņemot jaunu medicīniskodokumentu, kuram ir nepieciešama asinhrona apstrāde,pēc iepriekš konfigurējamas uzdevuma izpildes regularitātes, piemēram, reizi dienāārpus darba stundām sinhronizējot jaundzimušo datus.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 86 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Uzdevumu plānotājs tiek darbināts kā atsevišķs process. Tas veic šādas darbības:1. Uzdevumu plānotāja startēšanas laikā tas nolasa konfigurācijas informāciju, kas satursarakstu ar uzdevumu adapteriem un to izpildes regularitāti, un saglabā šoinformāciju operatīvajā atmiņā. Mainoties fona uzdevumu konfigurācijai, uzdevumuplānotājs ir jāpārstartē.2. Periodiski nolasa datus no uzdevumu rindas un uzsāk to apstrādi.3. Uzsāk jaunus uzdevumus atbilstoši katra uzdevuma tipa izpildes regularitātei.4. Katram nolasītajam uzdevumam tiek izsaukts atbilstošais uzdevuma adapteris, kāparametrus tam nododot katram uzdevuma tipam specifiskos papildus datus,piemēram, medicīniskā dokumenta identifikatoru, kuram ir nepieciešama apstrāde.5. Visi fona uzdevumu apstrādes soļi tiek reģistrēti sistēmas žurnālā, izmantojot IPsistēmas žurnāla bibliotēku.Konfigurācijas komponents ir atbildīgs par konkrēto uzdevumu adapteru konfigurācijas ielādiun to pārbaudi.Uzdevumu pārvaldība satur pašus uzdevumu adapterus, kas atkarībā no uzdevuma tipaizpilda nepieciešamo darbību secību.Personas datu aktualizācijaModulis nodrošina datu apmaiņu ar PMLP IR reģistru. Personas datu aktualizācijas moduliizmantos fona uzdevumu modulis periodiskai personas datu aktualizēšanai.Personas dati tiek aktualizēti/modificēti šādos gadījumos:Periodiski sinhronizējot ar IP (PMLP IR);Administratīvais lietotājs papildina/modificē personas pilngadības faktu.Alternatīvās identifikācijas personas dati tiek aktualizēti gadījumā, ja tā ir jaundzimušāidentifikācija. Šādi personu dati periodiski tiek sinhronizēti ar Jaundzimušo reģistru ar mērķiidentificēt personas kodu, jo personas kodu piesaiste jaundzimušajiem primāri tiek veiktašajā reģistrā.Kad personas kods identificēts, tiek veikta personas datu aizpilde no IP (PMLP IR), ģimenesārsta un EVAK datu aizpilde no NVD VIS.Vairumā gadījumu pilngadība iestājas 18 gadu vecumā, tomēr pastāv izņēmumi, kadpilngadība tiek piešķirta jau sākot ar 16 gadu vecumu, piemēram, ja persona dodas laulībāvai ar tiesas lēmumu, ja persona zaudējusi savus vecākus. PMLP IR netiek uzturētainformācija par personu pilngadību. Tādējādi pilngadības fakts līdz ar 18 gadu sasniegšanutiek uzstādīts automātiski personas datu aktualizēšanas laikā, savukārt administratīvaislietotājs personas pilngadības faktu var arī papildināt vai modificēt.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 87 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Personas dati tiks ņemti no PMLP IR, izmantojot IP publicētās tīmekļa saskarnes integrācijaiar PMLP IR. Datu saņemšana tiks veikta, norādot personas kodu, kā rezultātā tiks aktualizētipersonas personificēto un nepersonificēto datu ieraksti.PMLP IR nodrošina nepieciešamās saskarnes sākotnējo personas datu un vēlāko personasdatu izmaiņu saņemšanai.Personas datu aktualizācijas modulim ir nepieciešamas šādas metodes no PMLP IR sistēmas:getPersonName – iegūst personas vārdu un uzvārdu;getPersonDataChangeSet – atgriež personas izmaiņu datu kopu;checkRepresentation – pārbauda, vai pakalpojuma pieprasītājs ir likumīgais pārstāvispersonai, kuras personas kodu ir norādījis pakalpojuma izpildēgetIsPersonLegalyCapable – pārbauda vai personai ar doto personas kodu navierobežota rīcībspēja.Gadījumā, ja personai ir mainīiijies personas kods, abi kodi tiek pievienoti pacienta kartei(karte kļūs pieejama lietotājam ar jebkuru no tiem kodiem).Jaundzimušo datu aktualizācijaModulis nodrošina datu apmaiņu ar NVD Jaundzimušo reģistru. Jaundzimušo datuaktualizācijas moduli izmantos fona uzdevumu modulis personas koda atjaunošanai pacientakartē jaundzimušajiem, kuriem EVK nav aizpildīts personas kods. Jaundzimušo dati tiks ņemtino Jaundzimušo reģistra, izmantojot IP publicētās tīmekļa saskarnes integrācijai arJaundzimušo reģistru. Datu saņemšana tiks veikta, norādot mātes personas kodu un bērnadzimšanas datumu un laiku.Jaundzimušo datu aktualizācijas modulim ir nepieciešama šāda metode no Jaundzimušoreģistra sistēmas:getNewbornPersonCodes – bērna personas koda izgūšana pēc jaundzimušāalternatīvās identifikācijas.NVD VIS ģimenes ārstu un EVAK datu aktualizācijaModulis nodrošina datu apmaiņu ar NVD VIS ģimenes ārstu un EVAK karšu reģistriem.Ģimenes ārstu un EVAK datu datu aktualizācijas moduli izmantos NVD VIS sistēmaperiodiskai ģimenes ārstu un EVAK datu aktualizēšanai.Pacienta kartē tiks aktualizēti šādi ģimenes ārsta atribūti:ģimenes ārsts,specialitāte,ārstniecības iestāde,Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 88 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06līguma ar NVD spēkā no datums.Pacienta kartē tiks aktualizēti šādi EVAK atribūti:EVAK kartes numurs,tips,Izdevējiestāde,izsniegšanas datums,spēkā no,spēkā līdz,statuss.Ģimenes ārstu un EVAK datu aktualizācijas modulis nodrošina šādas ārējās saskarnes, kas irpubliski pieejamas caur IP:setFamilyDoctor – aktualizē pacienta ģimenes ārsta informāciju EVK pacienta kartē,ja notikušas izmaiņas NVD VIS sistēmā;setEhicData – aktualizē EVAK datus EVK pacienta kartē, ja notikušas izmaiņas NVDVIS sistēmā.6.4.6 Vakcināciju modulisVakcināciju modulis nodrošinās ar vakcināciju saistīto medicīnisko dokumentu glabāšanu EVKdokumentu repozitorijā HL7 CDA dokumentu veidā. Šiem dokumentiem tiks izveidoti jauniEVK ierakstu tipi, līdz ar to vakcināciju reģistra dati būs apakškopa no EVK dokumenturepozitorija datiem.Tiks nodrošināta:ar EVK kopīgās personas pamatdatu bāzes izmantošana;pieejas tiesību pārbaude personificētiem datiem;personificēto datu drošība, to lasīšanas un rakstīšanas audits;iespēja lasīt nepersonificētus datus pārskatu un analīzes vajadzībām, bez personasdatu pieejas tiesību pārbaudes un audita;meklēšanas un atlases iespējas datiem.Personas dati tiks saistīti ar šifrētām abpusējām atslēgām ar vakcināciju reģistra ierakstu.Tikai atšifrējot atslēgu, pēc tās varēs meklēt personificētu vakcināciju reģistra ierakstus.Vakcinācijas reģistra datu bāze ir izveidota kā relāciju datu bāze, kas ļauj datus ātri unvienkārši meklēt un analizēt. Nākotnē repozitorijā būs iespējams saglabāt elektroniskiparakstītus potēšanas faktu apstiprinošus dokumentus. Pārējiem vakcināciju moduļaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 89 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06strukturētajiem datiem, kam netiks definēti jauni EVK ierakstu tipi, dati tiek uzglabāti relācijudatu bāzē.Tiks nodrošināta iespēja veidot dažādas atskaites gan par paveikto profilakses darbu, gan arīplānot vakcināciju apjomus nākamajos periodos.Lietotājiem sistēma būs pieejama, izmantojot e-Veselības portālu. Vakcināciju moduļafunkcionalitāte tiks publicēta EVK tīmekļa saskarņu veidā, kas ārējām sistēmām būspieejama, izmantojot integrācijas platformu. Šos servisus varēs izmantot ārstniecības iestāžuiekšējās informācijas sistēmas. Piekļuve klasifikatoru informācijai tiks nodrošināta,izmantojot klasifikatoru moduļa ārējās saskarnes. Vakcinācijas reģistrs būs lietojams šādāmlietotāju grupām:pacients varēs apskatīt sev veiktās un nākotnē plānotās vakcinācijas;ārstniecības personāls varēs aplūkot vakcinēšanas faktus, reģistrēt jaunusvakcinēšanas faktus, kā arī pievienot piezīmes, reģistrēt plānotās vakcinēšanas;ārstniecības iestādes administrācija varēs iegūt pārskatus par iestādes veiktajiemvakcinācijas pasākumiem, iegūt pārskatus par plānotajiem vakcinēšanaspasākumiem (ĢĀ praksē par saviem pacientiem).Vakcinācijas reģistram tiks uzturēti vairāki klasifikatori, tai skaitā vakcinācijas veidu unalgoritmu klasifikators. Klasifikatorā tiks definēti kritēriji, pēc kuriem personai automātiskiģenerējamas nepieciešamās plānotās vakcinācijas. Tās tiek noteiktas, izmantojot pacientavecumu, dzimumu, ilgumu kopš iepriekšējās vakcinācijas, revakcinācijas reizi u.c.Vakcinācijas moduļa dekompozīcijas aprakstsVakcinācijas reģistrs savas funkcionalitātes nodrošināšanai izmanto Integrācijas platformasservisus, EVK klasifikatoru moduli, EVK relāciju datubāzi, VR datubāzi un HL7 dokumenturepozitoriju, kas ir Elektroniskās Veselības Kartes Informācijas Sistēmas sastāvdaļa.Vakcināciju reģistrs sastāv no vairākiem funkcionālajiem moduļiem. Moduļi dalās divosveidos: datu piekļuves un biznesa loģikas:Vakcinācijas reģistra biznesa loģikas modulis - nodrošina visu pamata funkcionalitātiEVK VR darbībai;CDA dokumentu apstrādes modulis – Windows Serviss, kas apstrādā nosaglabātajiem CDA dokumentiem izgūto informāciju;Asinhrono pieprasījumu pārvaldības modulis – nodrošina vakcināciju reģistraasinhrono pieprasījumu apstrādes rindas pārvaldību, kā arī biznesa loģikas funkcijuasinhronu izsaukšanu un izpildāmo uzdevumu rindas pārvaldību;Tīkla pakalpju modulis – nodrošina ārējo saskarni ar vakcinācijas moduli. Atkarībā nopakalpes un tās metožu veida, tas nodrošina vakcinācijas reģistra biznesa loģikasNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 90 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06sinhrono funkciju izsaukšanu vai arī asinhrono, izmantojot asinhrono pieprasījumupārvaldības moduli;o Šlirču un vakcīnu atlikumu/pasūtījumu tīkla pakalpe – eksponē metodes, kasnodrošina šļirču/vakcīnu pasūtīšanas/norakstīšanas apjoma pārvaldību;o Ar imunizāciju informācijas saņemšanas/nodošanas tīkla pakalpe – eksponēmetodes, kas ļauj saglabāt/atgriezt personas vakcinācijas faktu,pārslimošanas gadījumu utt.;o Atskaišu izveides tīkla pakalpe – eksponē metodes, kas veido, piemēram,pacienta profilaktiskās potēšanas kartes pārskatu, ārstniecības personasgada pārskatu u.c.;o Vakcinācijas kalendāra pārvaldes tīkla pakalpe – eksponē metodes, kas ļaujnodefinēt/rediģēt vakcinācijas kalendāru un to aktivizēt, lai ārstniecībaspersona varētu plānot savu reģistrēto pacientu vakcināciju atbilstoši tam;o Vakcinācijas plānošanas tīkla pakalpe – eksponē metodes ārstniecībaspersonas pacientu vakcinācijas plānošanai, kā arī LIC valsts iedzīvotājuvakcinācijas plānošanai (vakcinācijas aptverei).Atgādinājumu pārvaldības modulis – periodiski pārbauda ieplānotās vakcinācijas unpacientiem, kam tuvojas vakcinācijas datums, nosūta atgādinājumu par vakcinācijasveikšanu, izmantojot fona uzdevumu komponenti.6.4.7 Klasifikatoru modulisEVK darbam (pārsvarā ievietotās informācijas pārbaudei) nepieciešami klasifikatori no citāme-Veselības vides informācijas sistēmām. Tāpat EVK nodrošinās savu klasifikatoruinformācijas pieejamību citām sistēmām.Klasifikatori ir paredzēti dažādu EVK moduļu, piemēram, vakcināciju reģistra un EVKpamatdatu vērtību klasifikācijai. Piemēram, klasifikatori var būt: ārsti, ārstniecības iestādes,specialitātes, līgumi, dokumentu veidi u.c. Klasifikatoru modulis nodrošinās klasifikatoru unto versiju uzturēšanu. Klasifikatori tiek glabāti relāciju datu bāzes tabulu veidā, nodrošinotdatu integritātes kontroli. To struktūra ir definēta atbilstoši HL7 standartam, kas nodrošināssavietojamību starp dažādām e-Veselības sistēmām.Klasifikatoru vērtības tiek aizpildītas, tās kopējot vai importējot no IP. Šādu klasifikatoruieraksti EVK līmenī nebūs rediģējami. To varēs darīt klasifikatoru turētāju IS, publicējotjaunas klasifikatoru versijas IP.Klasifikatoru modulis nodrošinās klasifikatoru validācijas funkcionalitāti (piemēram EVK ISpirms jauna dokumenta saglabāšanas validēs tā saturu). Klasifikatoru validācijas mehānisms,pārbaudīs, vai klasifikators tiek glabāts relāciju datu bāzes tabulu veidā, tad validācijaiNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 91 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06jānotiek klasifikatoru moduļa līmenī, pretējā gadījumā tiek izmantota IP klasifikatoruvalidācijas funkcionalitāte.Klasifikatoru modulis nodrošinās uzturamo klasifikatoru vērtību saņemšanu, savukārt citu –neuzturamo jeb klasifikatoru, kas netiek izmantoti EVK pamatdatos un vakcināciju reģistrā,vērtību saņemšana, tiks nodrošināta, izmantojot IP funkcionalitāti.Klasifikatoru modulis nodrošinās klasifikatoru versiju uzturēšanu, izmantojot klasifikatoruizmaiņu informāciju no IP izmaiņu apziņošanas servisa.Klasifikatoru moduļa darbināšanai tiks izmantots klasifikatoru repozitorijs, kas uztur visu EVKizmantojamo klasifikatoru meta informāciju.Ar EVK klasifikatoru moduli tiks nodrošinātas šādas pamatfunkcijas:klasifikatoru importēšana no IP un to glabāšana relāciju veidā;uzturamo un citu klasifikatoru vērtību saņemšana, izmantojot IP klasifikatoruizplatīšanas servisu;uzturamo klasifikatoru vērtību saņemšana klasifikatoru moduļa līmenī;uzturamo un citu klasifikatoru validācija, izmantojot IP klasifikatoru validācijasservisu;uzturamo klasifikatoru validācija klasifikatoru moduļa līmenī;uzturamo klasifikatoru versiju uzturēšana relāciju veidā;EVK klasifikatoru izmaiņu publicēšana.Klasifikatoru modulis tiks veidots kā fona uzdevumu moduļa adapteris, skat. 6.4.4 nodaļu.Klasifikatoru moduļa dekompozīcijas aprakstsKM savas funkcionalitātes nodrošināšanai izmanto Integrāciju platformas servisus, EVKrelāciju datubāzi, kas ir Elektroniskās Veselības Kartes Informācijas Sistēmas sastāvdaļa.KM sastāv no vairākiem funkcionālajiem moduļiem: Administratīvās tīkla pakalpes – nodrošina visas klasifikatoru modulimnepieciešamās administratīvās darbības;Administrēšanas modulis – komponente nodrošina klasifikatoru administrēšanainepieciešamo funkcionalitāti;Klasifikatoru atjaunošanas modulis – komponente nodrošina visas funkcijas saistībāar klasifikatoru atjaunošanās procesu;Klasifikatoru atjaunošanas serviss – Windows serviss, kas noteiktos laika intervospārbauda klasifikatoru konfigurāciju un attiecīgi izsauc klasifikatoru atjaunošanasmoduļa funkcijas, kas pārbauda vai klasifikatoram ir jaunākas versijas;Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 92 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Iekšējās tīkla pakaplpes – nodrošina nepieciešamās funkcijas citiem EVK moduļiem,piemēram, Vakcinācijas reģistram un EVK kodolam;Iekšējais biznesa loģikas modulis – nodrošina citiem EVK moduļiem nepieciešamāsfunkcijas, piemēram, konceptu validāciju, klasifikatora datu iegūšanu;Vakcinācijas reģistra tīkla pakalpes – WCF serviss, kas paredzēts izmantošanai tikaivakcināciju reģistram. Vienīgā šī servisa funkcija būs atgriezt pieprasīto klasifikatoraierakstu identifikatorus;Konfigurēšanas modulis – consoles aplikācija, kas nodrošina sistēmas konfigurēšanainepieciešamo funkcionalitāti.6.4.8 IP audita un sistēmas žurnāla bibliotēkasAuditācijas mērķis ir uzkrāt informāciju par veiksmīgu vai neveiksmīgu piekļuvi sistēmasobjektiem, privilēģiju lietošanu un citām svarīgām lietotāju darbībām tās vēlākai analīzei.Auditācijas žurnāls ir domāts, piemēram, izmeklētājiem, lai veiktu lietotāju darbību analīzi.Sistēmas žurnāls ir domāts sistēmas administratoriem un izstrādātājiem, lai dotu iespējunoteikt sistēmas kļūdu cēloņus un noteiktu sistēmas komponenšu stāvokli.IP nodrošinās centrālo auditācijas servisu un speciālas bibliotēkas visām E-veselībascentrālajām sistēmām, kas nodrošinās gan sistēmas žurnāla, gan auditācijas žurnālafunkcionalitāti. Auditācijas pierakstu un sistēmas žurnāla pierakstu veidošanas process irlīdzīgs, atšķiras tikai aizpildāmie atribūti un mērķa datu bāze.Sistēmas žurnāla serviss atbalsta vairākus žurnalēšanas līmeņus, kas nosaka, kāda veidaziņojumi tiek rakstīti žurnālā. Žurnalēšanas līmenis tiek noteikts sistēmas konfigurācijas failā.Sistēmas izstrādes un atkļūdošanas laikā tiks lietots žurnalēšanas līmenis, kura rezultātāsistēmas žurnālā tiek rakstīts maksimāli daudz informācijas. Normālas sistēmas darbībaslaikā tiks lietots līmenis, kurš maksimālu atslogotu sistēmu no žurnālu rakstīšanas.6.4.9 Administrēšanas modulisModulis nodrošina administratora funkciju lietotāja interfeisu administratora darba vietā,kas izvietota uz IP platformas. Administrēšanas modulis ir programmu komplekts, ar kurupalīdzību administratīvie lietotāji administrē sistēmu un veic tās uzraudzību. Tas tiek veidotsar mērķi nodrošināt vienotu administratora darba vietu, kura dos iespēju veikt ar sistēmasadministrēšanu saistītos uzdevumus. Administratora darba vietā netiks realizētafunkcionalitāte uzdevumiem, kuru realizācija tiek nodrošināta ar piegādātās infrastruktūrasstandarta administrēšanas rīkiem, vai trešās puses administrēšanas rīkiem, piem., WindowsServer 2008 R2 Server Manager konsoli vai Microsoft SQL 2008 Server Management Studio,piemēram, Windows Server 2008 R2 standarta administrēšanas uzdevumi tiks veikti arRemote Server Administration Tools palīdzību.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 93 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Infrastruktūras komponentu (DNS, IP adreses, klasteru konfigurēšana) administrēšanailietotāji varēs attālināti pieslēgties sistēmai, izmantojot Remote Desktop Protocol, un veiktinfrastruktūras izmaiņas, izmantojot Windows Server, SQL Server un citu trešo pušukomponentu standarta administrēšanas rīkus.Administratora funkcijām, kuras nav iespējams veikt ar standarta administrēšanas rīkiem,tiks izstrādāta administratora darba vietas saskarne kā Web lietojums. Piekļuvi sistēmasadministratora funkcionalitātei nodrošinās Integrācijas platforma.EVK administratora darba vieta nodrošinās šādas galvenās funkcijas:klasifikatoru administrēšana;o klasifikatoru saraksta attēlošana;o jauna klasifikatora reģistrēšana replicēšanai no IP;o klasifikatora konfigurēšana;o klasifikatora versiju saraksta attēlošana;atļauju administrēšana;o atļauju saraksta attēlošana;o atļauju pievienošana;o atļauju labošana;dokumentu veidņu administrēšana;o dokumentu veidņu saraksta attēlošana;o dokumentu veidņu pievienošana un labošana;pilngadības pazīmes uzstādīšana;personas datu aktualizēšana;vakcinācijas kalendāra administrēšana;o iegūt vakcinācijas kalendāru;o reģistrēt un labot vakcinācijas kalendāru;fona uzdevumu administrēšana;o konfigurēt fona uzdevumu adapterus;o konfigurēt fona uzdevumu adapteru izpildes biežumu un laikus.Administrēšanas moduļa realizētā funkcionalitāte tiks ierobežota, ņemot vērā lietotājampiešķirtās tiesības. Administratora moduļa uzbūve dos iespēju ierobežot administrēšanasWeb lietojuma pieejamību no viena vai vairākiem IPv4 vai IPv6 adrešu apgabaliem.Administrēšanas modulis nodrošina šādas formas:pievienot/rediģēt dokumenta veidni – lietotājam tiek dota iespēja izveidot jaunudokumentu veidni vai rediģēt eksistējošo;Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 94 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06iegūt dokumenta veidņu sarakstu – lietotājam tiek dota iespēja apskatīt dokumentuveidņu sarakstu;iegūt atļauju sarakstu – lietotājam tiek dota iespēja apskatīt personas atļaujaspiekļūt pacienta kartēm;pievienot/rediģēt atļaujas – lietotājam tiek dota iespēja uzstādīt personai atļaujaspiekļūt pacienta kartēm;uzstādīt personas pilngadības status – lietotājam tiek dota iespēja uzstādīt pacientapilngadības pazīmi;vakcinācijas kalendāra versiju saraksta apskatīšana - paredzēta, lai administratīvaislietotājs kalendāra versijas var skatīt saraksta veidā, kā arī pievienot jaunas versijasun labot vai dzēst esošās kalendāra versijas;vakcinācijas kalendāra versijas ierakstu apskatīšana - paredzēta, lai administratīvaislietotājs var apskatīt izvēlēto kalendāra versiju;vakcinācijas kalendāra versijas labošana/izveidošana - paredzēta, lai administratīvaislietotājs var labot kalendāra versijas ierakstus, kā arī izveidot jaunas kalendāraversijas ierakstus;EVK IS KM reģistrēto klasifikatoru saraksta skatīšana - paredzēta, lai administratīvaislietotājs var skatīt klasifikatoru sarakstu;klasifikatora parametru rediģēšana - paredzēta, lai administratīvais lietotājs varētuskatīt klasifikatoru sarakstu;EVK IS KM reģistrēta klasifikatora versiju saraksta apskatīšana - paredzēta, laiadministratīvais lietotājs var skatīt izvēlētā klasifikatora versiju sarakstu.Administrēšanas modulis nodrošina šādas ārējās saskarnes, kas ir publiski pieejamas caur IP:setDocumentTemplate – pievieno un labo dokumenta veidni;getDocumentTemplate – iegūst dokumenta veidni;getDocumentTemplateList – iegūst dokumenta veidņu datus;setDelegation – pievieno un labo atļauju;getDelegation – iegūst atļauju datus;setMajority – uzstādīt pacienta pilngadības pazīmi.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 95 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.066.4.10 IP apziņošanas servissIP nodrošina apziņošanas (jeb notifikāciju) servisu, kurš paredzēts personu un/vai iestāžuapziņošanai. Sākotnēji IP nodrošinās tikai SMTP apziņošanas metodi. Apziņošanas servisseksponē tīmekļa pakalpes ar šādām metodēm:nosūtīt ziņojumu – nosūta ziņojumu, izmantojot norādīto ziņojumu sūtīšanas kanālu.Ziņojumu veidošana notiek, izmantojot saņemto XML un atbilstošo XSLtransformāciju;manis sūtītie ziņojumi – atgriež ziņojuma sūtītāja sūtītos ziņojumus, par norādītolaika periodu un/vai grupas kodu;man sūtītie ziņojumi – atgriež ziņojuma sūtītāja sūtītos ziņojumus, par norādīto laikaperiodu un/vai grupas kodu.6.4.11 e-Pakalpojumie-Veselības portāls ir pacienta primārais piekļuves kanāls e-Veselības e-Pakalpojumiem, taiskaitā EVK e-Pakalpojumiem.e-Veselības portāls nodrošinās centralizēti uzturēto e-Veselības vides pakalpojumupieejamību plašam lietotāju lokam, izmantojot pēc iespējas visiem plaši pieejamu tīmekļapārlūkprogrammās darbināmu lietotāju saskarni. Lielākā daļa EVK e-Pakalpojumu tiksizvietoti e-Veselības portālā. e-Pakalpojumu saraksts tiks uzturēts arī Latvijas e-Pakalpojumuvidē www.latvija.lv, kas nodrošinās plašam lietotāju lokam alternatīvu iespēju atrastvajadzīgo e-Pakalpojumu un uzsākt pakalpojuma izpildi bez atkārtotas autentifikācijas. Pašue-Pakalpojumu izpilde tiks nodrošināta Portāla vidē. Daļa no pacientiem paredzētajieme-Pakalpojumiem tiks izvietoti primāri www.latvija.lv vidē, izmantojot www.latvija.lv portālaun VISS komponentus.Tie e-Pakalpojumi, kas tiks izvietoti www.latvija.lv pakalpojumu izvietošanas vidē, lietotājuautentificēšanai, darbību auditēšanai, darba plūsmu nodrošināšanai un sadarbībai ar citāmsistēmām izmanto www.latvija.lv un VISS komponentus. EVK e-Pakalpojumu arhitektūrashematiski ir parādīta 34. attēlā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 96 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.0634. attēls. e-Pakalpojumu arhitektūrae-Pakalpojumu prezentācijas slānis nodrošina pakalpojuma saņēmējam saprotamas HTMLformas interneta pārlūkprogrammai. Ekrānformas nodrošina pieprasītās informācijasattēlošanu un datu izmaiņu ievadi, izmantojot e-Pakalpojuma biznesa loģikas bibliotēkas.Biznesa loģikas bibliotēkas nodrošina VISS pieprasījumu servisa metožu izsaukumu, datuapstrādi un biznesa loģikas izpildi, kas nepieciešama e-Pakalpojuma veiksmīgai darbībai.VISS infrastruktūras slānis sastāv no pieprasījumu servisa, kas nodrošina standartizētusaskarni ar valsts reģistru servisiem izmantojot tīmekļa pakalpi SubmitSync sinhronupieprasījumu veikšanai.e-Pakalpojumu funkcionalitātes realizācijai izmantojamās tīmekļa pakalpes definētasElektroniskās Veselības Kartes Informācijas sistēmas Interfeisu specifikācijas dokumentā [15]un Integrācijas Platformas interfeisu izmantošanas rokasgrāmatā [16].6.4.12 Datu noliktavas integrācijas modulis (nākotnes prasība)Datu noliktavas integrācijas modulis nākotnē nodrošinās EVK datu attīrīšanu(konsolidēšanu), depersonalizēšanu, izmantojot vienotu e-Veselības vidē izmantotualgoritmu, un depersonalizētās informācijas izlādēšanu nozares datu noliktavas vajadzībām.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 97 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.066.4.13 epSOS saskarne (nākotnes prasība)epSOS saskarne nākotnē nodrošinās datu apmaiņu ar epSOS projektā iesaistītajāme-veselības sistēmām. epSOS arhitektūra ir balstīta uz SOA principiem un paredz epSOSsaskarnei izmantot SOAP tīmekļa pakalpes. epSOS saskarne tiks veidota atbilstoši epSOSprojektā definētajai arhitektūrai un epSOS saskarnes specifikācijai, kas paredz katrai valstijizveidot īpašus nacionālos adapterus, kas spēs konvertēt konkrētās valsts specifiskose-veselības protokolus un datu formātus atbilstoši epSOS specifikācijām. Tiks izveidots īpašsEVK epSOS adapteris, kurš būs atbildīgs par datu formātu un protokolu konvertēšanu.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 98 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.067 Fiziskā arhitektūraŠajā nodaļā sniegts īss apskats par loģisko komponentu izvietošanas variantiem, kurusnodrošina izmantotie arhitektūras risinājumi.Detalizēts infrastruktūras apraksts, nepieciešamie infrastruktūras elementi, datu apjoma,transakciju skaita un sagaidāmās ātrdarbības novērtējumi, kā arī rekomendētie risinājumiaugstas pieejamības nodrošināšanai ir aprakstīti Infrastruktūras prasību dokumentā, skat.[2].EVK sistēmas loģiskie komponenti tiks izvietoti uz risinājuma infrastruktūras serveriematbilstoši 35. attēlā redzamajai shēmai.35. attēls. EVK loģisko komponentu izvietojums uz serveriem7.1 EVK tīmekļa pakalpesEVK tīmekļa pakalpes tiks izvietotas uz sistēmas aplikāciju serveriem APP1 un APP2.Uz šiem serveriem tiks darbināti:slodzes dalīšanas komponents, kas ir Internet Information Services ApplicationRequest Routing;Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 99 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06 EVK tīmekļa pakalpes, kas veidotas, izmantojot Windows CommunicationFoundation 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ītiuz vienu no vairākām Sistēmas tīmekļa pakalpju izvietošanas vidēm. EVK slodzi pa vairākiemfiziskiem resursiem sadala slodzes dalītāji, kuri veidoti, izmantojot Windows Server InternetInformation Services Application Request Routing komponenti.Sistēmas tīmekļa pakalpes veiks pieprasīto darbību pa tiešo sazinoties ar Sistēmas datubāzēm vai arī, izsaucot fona uzdevumu izpildes komponentes.7.2 Fona uzdevumiFona uzdevumu apstrādes komponenti un to adapteri tiks izvietoti uz fona uzdevumuveikšanas servera FON.Fona uzdevumu apstrādes komponenti tiks veidoti Microsoft .NET vidē kā Windows servisi.Fona uzdevumu izpildes komponente koordinēs pakešveida uzdevumu izpildes gaitu, veiks toietvaros nepieciešamās darbības un sazināsies ar ārējām sistēmām, izmantojot IP. Lai veiktutādus uzdevumus kā sistēmas ierakstu auditēšana vai, piemēram, datu sinhronizēšanu arIedzīvotāju reģistru vai klasifikatoru moduli noteiktos laika brīžos, tiks izmantoti fonauzdevumu izpildes komponenti, kuri darbosies neatkarīgi no biznesa servisu līmeņa tīmekļapakalpju izsaukumiem. Šis komponents piekļūs sistēmas datu bāzēm un ārējām sistēmām.Risinājuma fona apstrādes uzdevumi tiks veidoti, izmantojot Windows servisus, kurosdarbojas speciāli veidota fona uzdevumu apstrādes komponente.7.3 Dokumentu validācijas modulisDokumentu validācijas modulis tiks izvietots uz validācijas serveriem VAL1 un VAL2. Tas tiekizdalīts uz atsevišķiem serveriem, jo tas izmantos Java un GlassFish komponentus, bet uzpārējiem risinājuma serveriem tiks izmantotas Microsoft .NET tehnoloģijas.Uz šiem serveriem tiks darbināti:slodzes dalīšanas komponents, kas ir Internet Information Services ApplicationRequest Routing;medicīnas dokumentu validācijas rīki, kas validēs EVK dokumentus atbilstoši iepriekšdefinētajam datu modelim. Tie tiks veidoti kā GlassFish tīmekļa saskarnes, kasizmantos medicīnas dokumentu validācijas Java bibliotēkas.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 100 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.067.4 Datu bāzesSistēmas datu bāzes tiks izvietotas uz datu bāzes servera DB. Uz šī servera tiks darbinātasMicrosoft SQL Server DBVS un pārskatu izveides komponenti.Sistēmas datu bāzes nodrošinās Sistēmas relāciju datu un XML dokumentu uzglabāšanu unnodroš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 tiksuzglabātas uz dažādiem lōgiskajiem sējumiem.7.5 Infrastruktūras serveriUz infrastruktūras serveriem AD1 un AD2 tiks darbināti:Windows Active Directory Domain Services;DNS serviss;RDP serviss, lai nodrošinātu attālinātu pieslēgšanos;sistēmas infrastruktūras administrēšanas standarta komponenti.Visas Sistēmas komponentes darbosies slodzes dalīšanas režīmā, lai nodrošinātu:slodzes dalīšanu starp vairākiem fiziskiem resursiem;sistēmas darba turpināšanu gadījumā, ja viens no resursiem nav pieejams;sistēmas versiju izmaiņu veikšanu, neapturot Sistēmas darbu.EVK lietojumi tiks darbināti Microsoft Windows Server 2008 R2 operētājsistēmā, InternetInformation Services lietojumu serverī. Pašas komponentes veidotas, izmantojot .NETFramework. EVK datu bāzes tiks darbinātas, izmantojot Microsoft SQL Server DBVS.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 101 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.068 Pārvaldības arhitektūraŠajā nodaļā sniegta informācija par arhitektūras elementiem, kas ir izveidoti sistēmasuzturēšanas atvieglošanai.8.1 PārraudzībaŅemot vērā visai lielo risinājumā izmantoto fizisko un programmatūras komponentu skaitu,efektīvai pārvaldībai ir būtiski, lai problēmu ziņojumi par fiziskiem bojājumiem, resursutrūkumu vai programmatūras kļūmēm nonāk vienotā administratora centrālē.Izmantojot IP sistēmas žurnāla bibliotēku, visi sistēmas komponenti veic kļūdu informācijastrasēšanu IP sistēmas žurnāla datu bāzēs, kas nodrošina centralizētu kļūdu notikumumonitoringu un apstrādi.Papildus tam EVK komponentiem tiks izstrādāti veiktspējas rādītāji (performance counters),kas nodrošina sistēmas veikspējas rādītāju monitoringu. Tas ļauj identificēt situācijas, kadkāda no komponentēm ir pilnībā pārtraukusi darboties vai arī ģenerē nesamērīgi lielutransakciju skaitu, kas varētu liecināt, piemēram, par nesankcionētas ielaušanās gadījumu.Veiktspējas rādītāji tiks izstrādāti interfeisiem ar ārējām sistēmām, piemēram, lai mērītuienākošo medicīnas dokumentu skaitu, kā arī fona uzdevumu komponentam. Tie ir pieejamiapskatei un analīzei ar standarta Windows operētājsistēmas līdzekļiem, kā arī tos varēs vāktun analizēt monitoringa sistēma.Sistēmas ieviešanas laikā NVD ir ieteicams nokonfigurēt monitoringa sistēmu darbam ar IPsistēmas žurnāla datu bāzi un veiktspējas rādītājiem. Šāda konfigurēšana ir ārpus šī projektasfēras.8.1.1 Administrēšanas mehānismiEVK administrēšanas modulis nodrošinās sistēmas administrēšanai nepieciešamofunkcionalitāti. Administrēšanas modulis detalizētāk ir aprakstīts šī dokumenta sadaļā 6.4.9.8.2 Rezerves kopēšana, atjaunošana no rezerves kopijām8.2.1 Rezerves datu kopēšanaEVK nodrošinās iespēju veikt sistēmas rezerves kopēšanu un konsistentas kopijas iegūšanubez sistēmas darba apturēšanas, jo visi sistēmas dati tiks glabāti centralizēti EVK datu bāzē.Microsoft SQL Server DBVS nodrošina datu rezerves kopiju veikšanu, neapturot sistēmasdarbības ar datu bāzi. Rezerves kopēšanas laikā lielākā daļa operāciju, kā piemēram, INSERT,UPDATE un DELETE, ir atļautas.Ja sistēmas rezerves kopēšanai būs nepieciešama EVK un/vai infrastruktūras komponenšudarbināšana speciālā režīmā, tad šāda speciāla režīma ieslēgšana/izslēgšana tiks nodrošinātaar komandrindas interfeisa palīdzību.Sistēmas rezerves kopēšana ir daļa no EVK administrēšanas iespējām.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 102 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Rezerves datu kopēšanas pamatprincipi un atbildības:Rezerves datu kopēšanu nodrošina Sistēmas tehnisko resursu turētājs un to biežumsun apjoms tiek saskaņots ar Sistēmas informācijas resursu turētāju;Rezerves datu kopijas tiek uzglabātas ārpus datu centra, tā lai tās neietekmē vieni untie paši draudi. Rezerves datu kopijām ir jābūt pieejamām jebkurā laikā;Rezerves kopēšana tiek organizēta tā, lai būtu iespējams atjaunot datus, kas ir dienu,nedēļu, mēnesi, gadu vai vairākus gadus veci. Organizējot rezerves datu kopēšanu,tiek ņemtas vērā normatīvajos aktos noteiktās prasības;Rezerves kopiju integritāte tiek pārbaudīta vismaz vienu reizi ceturksnī;Ne retāk kā reizi gadā, Sistēmas tehnisko resursu turētājs sadarbībā ar informācijasresursu turētāju, veic pārbaudes, lai pārliecinātos, ka rezerves datu kopijas tieksagatavotas kvalitatīvi un no tām ir iespējams atjaunot Sistēmas darbību;Datu rezerves kopiju uzglabāšanas laiks tiek saskaņots ar Sistēmas informācijasresursu turētāju;Rezerves kopijas ir jāglabā ģeogrāfiski attālinātos datu centros ar striktu fiziskaspieejas kontroles mehānismu, ieskaitot vietu, kur atrodas pati sistēma, no kurasveidota rezerves kopija.8.2.2 Datu atjaunošana no rezerves kopijāmPirms uzsākt datu atjaunošanu no rezerves datu kopijām vispirms ir:Jāinformē Sistēmas informācijas resursu turētājs par incidentu un kopā jānovērtēincidenta ietekme;Jāinformē Sistēmas lietotāji;Jāizstrādā problēmu risināšanas scenārijs un, ja nepieciešams, Sistēmas informācijasresursu turētājam ir jāakceptē piedāvātais problēmu risināšanas scenārijs;Jānosaka atjaunojamie resursi (virtuālo mašīnu darbināšanas serveris, virtuālāmašīna vai Microsoft SQL Server datu bāze);Jāpārliecinās, ka ir pieejami nepieciešamie tehniskie resursi, piemēram, jaunsserveris vai rezerves datu kopijas.Datu atjaunošana tiek veikta ar virtualizācijas risinājuma vai Microsoft SQL Server datu bāzesiebūvētajiem līdzekļiem atbilstoši ražotāja instrukcijai. Ja problēmu apjoms ir ārpus sistēmasadministratora kompetences, jāiesaista sistēmas tehniskā atbalsta personāls.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 103 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Kad ir veikta datu atjaunošana, jāpārliecinās, ka Sistēma funkcionē atbilstoši un jāinformēSistēmas informācijas resursu turētājs un lietotāji.8.3 Jauninājumu instalēšanaPateicoties tam, ka sistēmas komponenti darbojas vienlaicīgi uz vairākiem serveriem,jauninājumu instalēšanu daudzos gadījumos būs iespējams veikt bez sistēmas darbībasapturēšanas.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ļapakalpes, web saskarnes komponenti, Active Directory), instalēšanas secība ir šāda:o no Network Load Balancing (NLB) vai slodzes dalītāja klastera tiek izņemtasatbilstošās instances (Active Directory tas nav nepieciešams);o tiek instalētas jaunākas versijas;o pēc tam šīs instances tiek pievienotas atpakaļ NLB vai slodzes dalīšanasklasterim;o pēc tam šī pati darbība tiek veikta ar citām instancēm;Datu bāžu struktūras izmaiņām pieeja ir tāda, ka strādājošā datu bāzē tiek veiktasizmaiņas, saglabājot struktūras atpakaļsavietojamību, t.i., darbojas gan komponenti,kas veidoti iepriekšējai DB versijai, gan jaunie;Fona komponentu izmaiņas tiek veiktas, apturot fona komponentus, veicot jaunāsversijas instalēšanu un pēc tam palaižot fona komponentus (fona komponentiemklienti nepiekļūst pa tiešo – tāpēc šinī gadījumā nerodas pieejamības problēmas).Veicot jauninājumu ieviešanas plānošanu, jāņem vērā, ka gadījumos, kad vienas versijaskomponenti nevar darboties ar otras versijas komponentiem vienlaicīgi (būtisku izmaiņugadījumā), tad plānota sistēmas darba apturēšana tomēr ir nepieciešama. Visriskantākāsizmaiņas šajā nozīmē ir saistītas ar platformas sistēmu izmaiņām, piemēram, jauna SQLServer versija vai Windows Server versija.Jauninājumu ātrākai ieviešanai arī ieteicams ieviest papildu automatizētās jauninājumuinstalēšanas rīkus, piemēram, Windows Server Update Services (WSUS) servisu Windowsserveru jauninājumu instalēšanai. Šādu rīku ieviešana ir ārpus šī projekta sfēras.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 104 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.069 Arhitektūras skatu nepretrunīgumsŠajā nodaļā aprakstīta arhitektūras skatu nepretrunīguma analīze, kā arī identificētas visaszināmās arhitektūras skatu neatbilstības.Arhitektūras skatu nepretrunīgums tiek panākts, arhitektūras izstrādes laikā pieturotiesšādiem principiem:Fokusējoties uz arhitektūras skatu nepretrunīgumu no paša sākumaSistēmas arhitektūra tiek izstrādāta pakāpeniski, sākot ar augsta līmeņadiagrammām un tālāk tās detalizējot, radot jaunas detalizētākas diagrammas. Ja kautkas tiek mainīts zemāka līmeņa diagrammās, vienmēr tiek pārbaudītas saistītāsaugsta līmeņa diagrammas un veiktas nepieciešamās izmaiņas.Katram arhitektūras elementam piešķirot precīzu nosaukumu un konsekventi toizmantojot visā arhitektūras dokumentā.Iekļaujot arhitektūras skatu nepretrunīguma pārbaudi kā dokumenta caurskatessastāvdaļu.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 105 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Pielikums. EVK funkcionālais sadalījums pa moduļiemTabulā 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.Atbilstoši tehniskajam piedāvājumam Atbilstoši tehniskās arhitektūras aprakstam Komentāri1. Pamatdatu un pierakstu pārvaldība 1. Pamatdatu un pierakstu pārvaldība -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ācijasfunkcionalitātes3. Meta datu un prezentācijas pārvaldībasmodulis3. Metadatu pārvaldība Mainīts nosaukums uz īsāku un saprotamāku4. Administrēšanas modulis 4. Administrēšanas modulis -5. Personas datu audita modulis 5. Auditācija un sistēmas žurnāls Apvienoti, jo no IP viedokļa personas datu audits un funkciju auditācija6. Funkciju auditācija (žurnalēšana)neatšķiras.7. e-Pakalpojumi 6. e-Pakalpojumi Apvienoti, jo no arhitektūras viedokļa ārsta un pacienta darba vieta ir e-8. Ārsta darba vietapakalpojumu apakškopa9. Pacienta darba vieta10. Sadarbība ar epSOS 7. epSOS saskarne Mainīts nosaukums, jo pēc būtības tā ir saskarne, ko piedāvājam priekš epSOS11. Vakcināciju reģistrs 8. Vakcināciju modulis Mainīts nosaukums12. Autonomo procesu modulis 9. Fona uzdevumi Mainīts nosaukums uz saprotamāku13. Klasifikatoru un terminoloģijas pārvaldības10. Klasifikatoru modulis Mainīts nosaukums uz īsāku un saprotamākumodulis11. eDoc pārbaudes serviss Arhitektūras dokuments satur papildus detalizāciju12. IP apziņošanas serviss Arhitektūras dokuments satur papildus detalizāciju13. Datu noliktavas integrācijas modulisNākotnes prasība(nākotnes prasība)Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 106 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06Pielikums. Tehniskās prasībasŠajā nodaļā ir aprakstīti tehnisko prasību risinājumi, kas attiecas uz EVK sistēmas arhitektūru. Citu tehnisko prasību risinājumi ir aprakstīti PPS un PPAdokumentos. Arhitektūras dokuments satur tikai vispārīgo prasību aprakstu, kas attiecas uz sistēmas arhitektūru.Prasības ID Prasības raksturojums RisinājumsLICS.3LICS.6LICS.7Piegādātais risinājums vai tā komponentes var tiktizmantotas uz VMware vSphere 4.0 vai jaunākasvirtualizācijas platformas. Fiziskais serveris var būt ar2,4, vai 8 Intel saimes procesoriem. Pretendentampiedāvājumā jānorāda vai un kādi licencēšanasierobežojumi un/vai papildus izmaksas ir attiecināmasizmantojot piedāvāto risinājumu zem virtualizācijasplatformas.Šis punkts nav jāinterpretē kā nepieciešamība iekļautpiedāvājumā VMware licences.Piedāvātais risinājums vai tā komponentes var tiktizmantotas komplektā ar VMware vSphere 4.0 vaijaunāku Fault Tolerance bojājumu izturīgu risinājumu.Pretendentam piedāvājumā jānorāda vai un kādilicencēšanas ierobežojumi un/vai papildus izmaksas irattiecināmas izmantojot piedāvāto risinājumu kopā arVMware bojājumu izturīgu risinājumu.Šis punkts nav jāinterpretē kā nepieciešamība iekļautpiedāvājumā VMware licences.Piedāvātais risinājums vai tā komponentes var tiktizmantotas komplektā ar VMware vSphere 4.0 vaijaunāku High Availability augstas pieejamībasrisinājumu. Pretendentam piedāvājumā jānorāda vai unkādi licencēšanas ierobežojumi un/vai papildus izmaksasRisinājuma arhitektūra paredz tās darbību, izmantojot virtualizācijas platformu VMware vSphere 4.0 vaijaunāku. Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2]Risinājuma arhitektūra paredz tās darbību komplektā ar VMware vSphere 4.0 vai jaunāku FaultTolerance bojājumu izturīgu risinājumu. Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasībudokumentā, skat. [2]Risinājuma arhitektūra paredz tās darbību komplektā ar VMware vSphere 4.0 vai jaunāku HighAvailability augstas pieejamības risinājumu. Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūrasprasību dokumentā, skat. [2]Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 107 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06INFS.1INFS.3INFS.4ir attiecināmas izmantojot piedāvāto risinājumu kopā arVMware augstas pieejamības risinājumu.Šis punkts nav jāinterpretē kā nepieciešamība iekļautpiedāvājumā VMware licences.Piegādājamās IS serveru daļai jābūt spējīgai strādāt uzkādas no NVD izmantojām serveru platformām:Windows 2003 R2, Windows Server 2008 vai Linuxsaimes operāciju sistēmas ar 2.6. sērijas kodolu.Visām IS darbināšanai nepieciešamajām infrastruktūraskomponentēm (OS, datu bāzes, lietojumu serveri) irjāatbalsta 64 bitu adresācijas režīms.Piegādājamās IS serveru daļai ir jāizmanto OS, kuras toizstrādātājs (ražotājs) attīsta un kurām Latvijā irpieejams serviss (drošības un funkcionalitātes labojumi,konsultanti (speciālisti)).Risinājuma arhitektūra paredz EVK darbināšanu, izmantojot NVD izmantoto serveru platformu WindowsServer 2008. Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2]Visi EVK darbināšanai paredzētie infrastruktūras komponenti – Windows Server 2008, InternetInformation Services lietojumu serveris un .NET framework izpildes vide – atbalsta 64 bitu adresācijasrežīmu un izmanto to, lai nodrošinātu piekļuvi visai infrastruktūras serveros pieejamajai operatīvajaiatmiņai.Risinājums tiek darbināts, izmantojot Windows Server 2008 operacionālo sistēmu.Windows Server 2008Korporācija Microsoft šo produktu turpina attīstīt, tai tiek publicēti drošības un funkcionalitātes labojumi,un Latvijā ir pieejams gan pamata bezmaksas atbalsts, gan maksas atbalsts Microsoft Premier Supportveidā, gan arī konsultāciju pakalpojumi no Microsoft Enterprise Services speciālistiem un no daudzajiemMicrosoft partneriem Latvijā.Microsoft Windows Server 2008 produktam nodrošina:5 (piecu) gadu bāzes atbalstu, kad pieejama tehniskā informācija par produktu mājas lapā, drošībaslabojumi, funkcionālie labojumi un iespējams pieprasīt funkcionālās izmaiņas),vēl 5 (piecu) gadu paplašināto atbalstu, kad tiek nodrošināta informācija par produktu un drošībaslabojumi,papildu atbalstu pēc iepriekš minētajiem 10 (desmit) gadiem, kas pieejams pēc klienta pieprasījumaun par papildu maksu.Sīkāk par Microsoft produktu atbalstu skat. http://support.microsoft.com/lifecycle/Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 108 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06INFS.5INFS.11INFS.12INFS.13Piegādājamās IS serveru daļai jābūt spējīgai strādāt uzNVD izmantojamās virtualizācijas platformas VMwarevSphere 4.0.Visām IS serveru daļai nepieciešamajām infrastruktūraskomponentēm ir jāatbalsta IPV4 un IPV6 internetasadarbības protokoli.Piegādātai IS ir jāatbalsta IPV4 un IPV6 internetasadarbības protokoli.Piegādātai IS ir jāatbalsta adresācija izmantojot internetadomēna vārdu servisu (DNS). Šī prasība attiecināma arīuz piegādātās IS parametru uzstādīšanu.Piegādājamā IS serveru daļa ir spējīga strādāt uz NVD izmantojamās virtualizācijas platformas VMwarevSphere 4.0.Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2], kur attēlots, kasistēmas operētājsistēmas tiek izvietotas VMware virtualizācijas risinājumā.EVK serveru daļas nepieciešamās infrastruktūras komponentes atbalsta IPV4 un IPV6 internetasadarbības protokolus.Windows Server atbalsts IPv6 protokolam aprakstīts http://technet.microsoft.com/enus/network/bb530961.aspxMicrosoft .NET Framework programmu darbināšanas vide ne tikai atbalsta jauno IPv6, bet vairākas tāspecifiskās iespējas, piemēram, saziņas nodrošināšana starp divām programmām NAT tīklos, pat iratkarīgas no tā – skat. Windows Communications Foundation saziņas platformas Peer-to-peer protokolaaprakstu http://msdn.microsoft.com/en-us/library/cc297274.aspxEVK atbalsta IPV4 un IPV6 interneta sadarbības protokolus, jo saziņai izmanto platformas elementus(.NET Framework un tā ietvaros esošo Windows Communication Foundation, kas nodrošina tīmekļapakalpju sadarbību, SQL Server), kuri šo atbalstu nodrošina.EVK komponenti neierobežo viena vai otra protokola lietošanu.EVK atbalsta tās komponentu adresāciju, izmantojot DNS servisu. Ir iespējams izmantot gan ārēju DNSservisu, kas translē DNS vārdus uz risinājuma izmantotajām IP adresēm (un otrādi), gan arī risinājumāparedzēto iekšējo DNS servisu (kas Infrastruktūras prasību dokumentā, skat. [2], esošajā aprakstā irizvietots uz AD serveriem).Papildu tam DNS informācija, kas tiek iekļauta HTTP pieprasījumu galvenēs (header), ir izmantojama,veicot pieprasījumu maršrutēšanu, izmantojot Internet Information Services iespējas, kurš ir šādā veidāparametrizējams.Arī risinājuma komponentu savstarpējās atkarības (ja viens komponents pa tīklu izsauc citu, piemēram,tīmekļa pakalpe izsauc datu bāzes servisu) tiek definētas, izmantojot DNS nevis IP adreses. Šāda pieeja arīatvieglo risinājuma pārnešanu no vienas (testa) vides uz citu (produkcijas) vidi, jo katrā no vidēm tāmNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 109 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06INFS.14INFS.15INFS.17INFS.31Piegādātās IS izmantotajiem tīkla protokoliem ir jābūtpieejamiem demilitarizētajā zonā (DMZ) izvietojamiemstarp-serveriem (proxy servers). Piedāvājumā irjānorāda šādu starp serveru piegādātājs, kā arī tolicencēšanas izmaksas (ja tādas ir) un noteikumi.Ja piegādājamā IS paredz iespēju lietotājam ielādēt(augšupielādēt) lietotāja sagatavotus failus, ir jāparedziespēja piegādāto IS integrēt ar antivīrusu līdzekļiemizmantojot ICAP[6] protokolu vai analogu mehānismu.Visām izmantojamām infrastruktūras komponentēm irjāatbalsta iespēja nomainīt operāciju sistēmas IP adresiveicot komponentes konfigurāciju bez atkārtotasinstalācijas un datu zudumiem.Datu integritātes līdzekļi ļauj noteikt un kontrolētpatvaļīgas sarežģītības datu integritātes noteikumus –datu integritātes pārbaudes bez standarta SQLlīdzekļiem var tikt aprakstītas ar datu bāzē glabājamuprocedurālu kodu, kuru datu bāzes serveris automātiskiizpilda datu izmaiņu gadījumā;pašām DNS adresēm var būt piekārtotas citas IP adreses, bet konfigurācijas vērtības nav jāmaina.EVK sadarbībai ar ārējiem klientiem (sistēmām un lietotājiem), izmanto HTTP un/vai HTTPS protokolus.Šos protokolus atbalsta daudzi DMZ izvietojamie starp-serveri (reverse proxy).Piemērs konkrētam reverse-proxy serverim, kas nodrošina risinājuma protokolu publicēšanu DMZ, irMicrosoft Forefront Threat Management Gateway 2010. Šis proxy serveris arī tiek atbalstīts darbamvirtualizētā vidē. Sīkāk skat. http://www.microsoft.com/forefront/threat-managementgateway/en/us/default.aspxEVK analīzes fāzes laikā tika konstatēts, ka lietotāju faili EVK netiks augšupielādēti. Tāpēc risinājumsneparedz īpašu vīrusu pārbaudes loģiku. Tomēr uz visiem EVK serveriem tiks uzstādīti antivīrusurisinājumi, lai nodrošinātu standarta aizsardzību pret vīrusiem.Kopumā e-Veselības risinājumam HTTP un HTTPS līmenī ir nepieciešama aizsardzība pret ļaunprātīgiem,piemēram denial-of-service attack, uzbrukumiem, bet tas ir nepieciešams tikai sistēmām, kas ireksponētas publiskajā Internet tīklā – portālam un integrācijas platformai. EVK saskarnes tiek izsauktastikai un vienīgi caur integrācijas platformas slāni, kuram tad arī tiks nodrošināta aizsardzība pretļaunprātīgiem uzbrukumiem HTTP/HTTPS līmenī.Risinājumā izmantotie infrastruktūras komponenti – Windows Server un Internet Information Services(kas ir daļa no Windows Server un kurā tiek darbināti sistēmas komponenti) – atbalsta IP adrešukonfigurēšanu, neveicot atbilstošā komponenta atkārtotu instalēšanu.Papildu tam izmantotais slodzes dalītājs – Internet Information Services Application Request Routingnodrošina, ka ir iespējams pievienot jaunus serverus, kuri apstrādās pieprasījumus, vai izņemt noapstrādes serveru klastera esošos serverus, piemēram, apkopes veikšanas nolūkos.SQL Server 2008 papildu standarta SQL vaicājumiem nodrošina arī vairākus mehānismus patvaļīgassarežģītības validācijas mehānismu un pat jaunu datu bāzes datu tipu izveidei, izmantojot datu bāzēglabājamu procedurālu (vai objektorientētu) kodu, kas rakstīts vai nu SQL Server speciālā valodāTransact-SQL, kas sintakses ziņā līdzīga SQL, vai arī jebkurā no .NET Framework valodām (C#, VB.NETu.c.), veidojot SQLCLR programmu moduļus.Šo procedurālo kodu, kas saglabāts un darbojas datu bāzē, izmantojot trigger mehānismu, var izsauktNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 110 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06INFS.32INFS.33Datu bāzē iebūvēta XML datu apstrāde (glabāšana,indeksēšana, verifikācija, meklēšana – XPath,transformēšana - XSLT);Transakciju mehānisms, tai skaitā, spēja sadarboties artrešo pušu transakciju monitoriem (piem. Tuxedo,Microsoft Transaction service u.c.);brīžos, kad notiek datu manipulācijas. To var arī izsaukt neatkarīgi, veicot DB glabāto procedūruizsaukumus.Sīkāk par izstrādes iespējām SQL Server 2008 platformā skat.http://www.microsoft.com/sqlserver/2008/en/us/programmability.aspxSQL Server 2008 nodrošina XML datu glabāšanu un apstrādi, izmantojot iebūvēto XML datu tipa atbalstu.Papildu XML apstrādi var veikt, izmantojot DB saglabātu procedurālu loģiku, kas rakstīts vai nu SQLServer speciālā valodā Transact-SQL, kas sintakses ziņā līdzīga SQL, vai arī jebkurā no .NET Frameworkvalodām (C#, VB.NET u.c.), veidojot SQLCLR programmu moduļus.SQL Server 2008 datu konsistences nodrošināšanai viena resursa (datu bāzes) ietvaros tiks nodrošinātsdatu 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āmjābūt izpildītām kopā vai atceltām kopā, tiks izmantots DBVS transakciju mehānisms.Ja būs nepieciešams nodrošināt datu konsistenci darbībām, kurās iesaistītas vairākas sistēmas datu bāzesun/vai failu sistēmas, vai arī vairākas tīmekļa pakalpes, tad tiks pielietots transakciju mehānisms, kurunodrošina Microsoft Distributed Transaction Coordinator (MS DTC) un ar kuru integrējas SQL Server 2008un NTFS failu sistēmas transakciju koordinators.MS DTC nodrošina dalīto transakciju atbalstu un var sadarboties ar vairākiem Microsoft un citu ražotājuveidotiem resursu kontrolieriem, piemēram, SQL Server 2008 datu bāzes transakciju integrēšanai,Windows Server failu sistēmas transakciju integrēšanai, Microsoft Message Queuing transakcijuintegrēšanai, WS-AtomicTransaction atbalstošiem servisiem tīmekļa pakalpju transakciju nodrošināšanai.Līdz ar to izmantotā datu bāžu vadības platforma nodrošina gan lokālo transakciju mehānismu, gan arīintegrāciju ar trešo pušu transakciju koordinatoriem.INFS.34 Datu bāze nodrošina iespēju izvietot datu bāzēpielietojuma loģikas kodu, kas nodrošina vienotu unstandartizētu datu apstrādi;SQL Server 2008 papildu standarta SQL vaicājumiem nodrošina arī vairākus mehānismus pielietojumaloģikas koda izveidei un pat jaunu datu bāzes datu tipu izveidei, izmantojot datu bāzē glabājamuprocedurālu (vai objektorientētu) kodu, kas rakstīts vai nu SQL Server speciālā valodā Transact-SQL, kassintakses ziņā līdzīga SQL, vai arī jebkurā no .NET Framework valodām (C#, VB.NET u.c.), veidojot SQLCLRprogrammu moduļus.Šo procedurālo kodu, kas saglabāts un darbojas datu bāzē, izmantojot trigger mehānismu, var izsauktbrīžos, kad notiek datu manipulācijas. To var arī izsaukt neatkarīgi, veicot DB glabāto procedūruNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 111 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06INFS.37INFS.38INFS.40IS izstrādē datu glabāšanai ir jāizmanto kādu no NVDizmantojamām datu bāzu platformām Microsoft SQLServer 2008 vai Oracle RDBMS 11G2;Datu bāzei jānodrošina UTF8 kodējuma datu glabāšanaun apstrāde;Izmantojamai datu bāzu tehnoloģijai ir jānodrošinaiespēja noteikt izpildes prioritātes dažādāmpieprasījumu grupām – piemēram zemāka prioritātefona atskaišu apstrādei.izsaukumus.Sīkāk par izstrādes iespējām SQL Server 2008 platformā skat.http://www.microsoft.com/sqlserver/2008/en/us/programmability.aspxIS izstrādē datu glabāšanai tiks izmantotas NVD izmantotā datu bāžu platforma Microsoft SQL Server2008.Microsoft SQL Server 2008 nodrošina UTF8 kodējuma datu glabāšanu un apstrādi, saglabāšanas vainolasīšanas brīdī konvertējot datus Unicode (UCS-2) formātā.Šāda pieeja nodrošina ļoti efektīvu darbu ar datiem .NET vidē, jo gan Windows Server, gan .NETFramework kā iekšējo datu apstrādes kodējumu izmanto UCS-2.Šo iespēju Microsoft SQL Server 2008 nodrošina, izmantojot Resource Governor komponentu, ar kurapalīdzību var definēt resursu grupas, resursu izmantotāju (workload) grupas un to prioritātes.Sīkāk par Resource Governor skat. http://msdn.microsoft.com/en-us/library/bb933866(v=SQL.100).aspxINFS.51 Transakciju mehānisma atbalsts, ieskaitot spējusadarboties ar populāro datu bāzu (Microsoft, Oracle)transakciju mehānismiem un trešo pušu transakcijumonitoriem (piem. Tuxedo, Microsoft Transactionservice u.c.);EVK IS lietojumu servera komponenti tiks veidoti, izmantojot .NET Framework programmu darbināšanasvidi..NET Framework izmanto ADO.NET tehnoloģijas sadarbībai ar relacionālo datu bāžu vadības sistēmām.ADO.NET adapteri ir pieejami visām populārākajām datu bāžu vadības sistēmām, tai skaitā MS SQL Serverun Oracle.Microsoft. NET Framework un ADO.NET adapteri atbalsta gan datu bāžu transakciju mehānismuizmantošanu pa tiešo, nodrošinot, ka darbības ar datu bāzēm tiek apvienotas loģiskās transakcijās, gantransakciju izmantošanu pastarpināti, ja tiek izmantots .NET Framework abstraktais transakcijumehānisms System.Transactions, kurš sadarbojas ar ADO.NET datu bāžu transakciju gadījumā, failusistēmas apstrādes komponentiem failu sistēmu transakciju gadījumā, un MSDTC transakcijukoordinatoru dalīto (distributed) transakciju gadījumā, kad transakcijā iesaistīti vairāki transakcionāliresursi .MS DTC, savukārt nodrošina tālāku sadarbību ar WS-AtomicTransaction atbalstošiem servisiem un trešoNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 112 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06pušu transakciju koordinatoriem.INFS.53Pielietojumu serverim jānodrošina UTF8 kodējuma datuapstrāde.EVK komponenti tiek veidoti un darbināti, izmantojot .NET Framework..NET Framework iekšēji visu informāciju glabā UCS-2 (Unicode) formātā, jo tas ir iekšējais formāts datuglabāšanai Windows un citos MS infrastruktūras komponentos, nodrošinot efektīvu informācijas iekšējoapstrādi..NET Framework nepieciešamības gadījumā nodrošina datu pārveidošanu UTF-8 un citos kodējumos,nodrošinot ļoti plašu globalizācijas funkcionalitātes atbalstu.Piemēram, ASP.NET Web lapu gadījumā, izmainot tikai konfigurācijas iestatījumus Web komponentam, iriespējams panākt, ka sistēmas attēlotās Web lapas ir kodētas UTF-8; atbilstošie HTTP galvenes lauki arīnorāda, ka dati kodēti UTF-8.INFS.54 Pielietojumu serverim jānodrošina iespēja nomainītInformācijas Sistēmas versiju pārtraucot lietotāju pieejuInformācijas Sistēmai uz laika periodu, kas nepārsniedz 5minūtes.Informācijas Sistēmas nomaiņa aplikāciju serverīneiekļauj datu struktūru izmaiņas un uzkrāto datumodifikācijas;Šī prasība attiecināma tikai uz tām Informācijas Sistēmaskomponentēm, kuras tieši ietekmē e-veselība lietotāju(Ārsti, Pacienti, Farmaceiti utt.) darbu ar InformācijasSistēmu.EVK izmantotais pielietojumu serveris Internet Information Services un tā komponentu izpildes videASP.NET nodrošina, ka, instalējot jaunu sistēmas komponentu versiju, lietojumu serveris iniciē jaunuprocesu, kurā darbojas jaunās versijas komponenti un visus jaunos pieprasījumus tas nosūta apstrādei uzšo jauno procesu.Iepriekš uzsākto pieprasījumu apstrādei tiek saglabāts vecais process līdz brīdim, kad visi vecie aktīviepieprasījumi tiek apstrādāti.Lietojumu servera stāvokļa informācija (aktuāla sesiju glabāšanai) un kešatmiņa (svarīga gan tīmekļapakalpēm, gan Web lapām) tiek glabāta dalītā kešatmiņā, kas pieejama visos lietojumu serveros un jaunaprocesa palaišana un vecā procesa apturēšana šos datus neietekmē.Līdz ar to klienti jaunas versijas uzlikšanu vispār nepamana, jo tiek saglabāts gan TCP/IP pieslēgums, gansesijas informācija, ja tāda ir (Web lietotāja saskarnes komponentu gadījumā).Aprakstītā jaunas versijas instalēšana lietojumu serverī neiekļauj datu struktūru izmaiņas un uzkrāto datumodifikācijas.PERF.1Lietotāju datu ievadam vai datu pieprasījumam (izziņai)uz ekrāna ir jāizpildās ne ilgāk kā 3 sekundes (neņemotvērā tīkla pārsūtīšanas aizturi un pieprasījumu izpildeslaiku ārējās sistēmās). Minētā ātrdarbība jānodrošinaLietotāju datu ievades vai datu pieprasījums (izziņa) uz ekrāna izpildīsies ne ilgāk kā 3 sekundes (neņemotvērā tīkla pārsūtīšanas aizturi un pieprasījumu izpildes laiku ārējās sistēmās). Minētā ātrdarbība tiksnodrošināta, ņemot vērā reālu datu bāzes aizpildījumu ražošanas režīmā un veicot datu ielasīšanu(cached) servera(u) operatīvā atmiņā ne vairāk kā 10% no kopējā pieprasījuma izpildei nepieciešamā,Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 113 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06ņemot vērā reālu datu bāzes aizpildījumu ražošanasrežīmā un nosacījumu, ka servera(-u) operatīvā atmiņāvar tikt ielasīti (cached) ne vairāk kā 10% no kopējā datuapjoma.PERF.11 Interaktīvas atskaites sagatavošanai uz ekrāna irjāizpildās ne ilgāk kā 15 sekundes (neņemot vērā tīklapārsūtīšanas aizturi). Minētā ātrdarbība jānodrošinaņemot vērā reālu datu bāzes aizpildījumu ražošanasrežīmā un nosacījumu, ka servera operatīvā atmiņā vartikt ielasīti (cached) ne vairāk kā 10% no kopējā datuapjoma.PERF.21 Fona atskaites sagatavošanai ir jāizpildās ne ilgāk kā 10minūtes, pieņemot ka fona atskaišu izpildes prioritātenav samazināta. Minētā ātrdarbība jānodrošina ņemotvērā reālu datu bāzes aizpildījumu ražošanas režīmā unnosacījumu, ka servera operatīvā atmiņā var tikt ielasīti(cached) ne vairāk kā 10% no kopējā datu apjoma.apstrādājamā datu apjoma.Interaktīvas atskaites sagatavošanai uz ekrāna ir izpildīsies ne ilgāk kā 15 sekundes (neņemot vērā tīklapārsūtīšanas aizturi). Minētā ātrdarbība tiks nodrošināta, ņemot vērā reālu datu bāzes aizpildījumuražošanas režīmā un nosacījumu, ka servera operatīvā atmiņā var tikt ielasīti (cached) ne vairāk kā 10%no kopējā datu apjoma.Atskaitēm, kurām nebūs iespējams nodrošināts šīs prasības izpildi, tiks nodrošināta iespēja veikt to izpildifona režīmā (background).Fona atskaites sagatavošanas laiks tiks nodrošināts ne ilgāk kā 10 minūtes, pieņemot ka fona atskaišuizpildes prioritāte nav samazināta. Minētā ātrdarbība tiks nodrošināta, ņemot vērā reālu datu bāzesaizpildījumu ražošanas režīmā un veicot datu ielasīšanu (cached) servera(u) operatīvā atmiņā ne vairākkā 10% no kopējā pieprasījuma izpildei nepieciešamā, apstrādājamā datu apjoma.Ja, apkopojot lietotāju prasības, tiek konstatēts, ka šīprasība konkrētai atskaitei ir tehniski neizpildāma,attiecīgai atskaitei var tikt noteikts cits izpildes laikarobežlielums izmantojot projekta izmaiņu procedūru.PERF.22PERF.31Informācijas sistēmai ir jāuzkrāj informācija par fonaatskaišu izpildes laikiem un jānodrošina sistēmasadministratoram pieeja pie uzkrātās statistikas.Sinhrono web servisu pieprasījumu apstrāde nedrīkstpārsniegt 3 sekundes (netiek ņemts vērā laiks, kas tiekpatērēts ārēju IS web servisu izsaukumiem).Izmantojot IP audita moduli, EVK uzkrās informāciju par fona atskaišu izpildes laikiem un sistēmasadministratoram tiks nodrošināta pieeja pie uzkrātās statistikas.Sinhrono web servisu pieprasījumu apstrāde tiks veikta ne ilgāk kā 3 sekunžu laikā, neņemot vērā laiku,kas tiks patērēts ārējo IS web servisu izsaukumiem. Ārējām sistēmām, kuras nevar garantēt pieprasījumuapstrādi mazāk kā 3 sekundēs, servisu izsaukumi galvenokārt tiek veikti asinhroni, skat. dokumentasadaļas 4 apakšpunktu 3).Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 114 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06PERF.32Asinhrono web servisu pieprasījumu apstrāde nedrīkstpārsniegt 60 sekundes (laiks tiek mērīts starppieprasījuma saņemšanu un atbildes nosūtīšanuizsaucējam. Netiek ņemts vērā laiks, kas tiek patērētsārēju IS web servisu izsaukumiem).Asinhrono web servisu pieprasījumu apstrāde tiks veikta ne ilgāk kā 60 sekunžu laikā, neņemot vērālaiku, kas tiks patērēts ārējo IS web servisu izsaukumiem.Laiks tiek mērīts starp pieprasījuma saņemšanu un atbildes izsūtīšanas brīdi izsaucējam.PERF.41 Izmantojamām tehnoloģijām (infrastruktūraskomponentēm) ir jāspēj izmantot apstrādesparalelizācijai visi sistēmā pieejamie procesori(procesoru kodoli) vismaz līdz 8 fiziskajiem procesoriem,32 procesoru kodoliem (32 cores). Ja šāda procesoru(kodolu) skaita izmantošana tiek ierobežota ar piegādātolicenci, piedāvājumā ir jānorāda papildus licencēšanasizmaksas un citi ierobežojumi, kas saistīti ar procesoruskaitapalielināšanu.Šī prasība nav interpretējama kā nepieciešamībapiegādāt licenci 32 procesu kodoliem, bet gan kāpiedāvātā risinājumu spēja mērogoties.PERF.42 Izmantojamām tehnoloģijām (infrastruktūraskomponentēm) ir jāspēj izmantot ievada izvadaoperāciju apstrādes palielināšanai un apstrādespaātrināšanai visa sistēmā pieejamā operatīvā atmiņa. Jašāda papildus liela mēroga operatīvās atmiņasizmantošana tiek ierobežota ar piegādāto licenci,piedāvājumā ir jānorāda papildus licencēšanas izmaksasun citi ierobežojumi, kas saistīti ar izmantojamāsatmiņas palielināšanu.Risinājumā izmantotās tehnoloģijas (infrastruktūras komponentēm – serveriem un trešo pušuprogrammatūrai) var nodrošināt apstrādes paralelizāciju visiem sistēmā pieejamiem procesoriem(procesoru kodoliem) vismaz līdz 8 fiziskajiem procesoriem.EVK fiziskā arhitektūra paredz izmantot 2 fiziskos serverus ar 4 procesoriem (katram 8 kodoli, kopā 32kodoli). Windows Server 2008 Datacenter Edition un SQL Server 2008 Enterprise spēj nodrošinātpilnvērtīgu visu servera resursu izmantošanu arī vairāku mezglu (node) gadījumā, ļaujot brīvi mērogot šorisinājumu.EVK fiziskā arhitektūra paredz divu SQL Server 2008 Enterprise DBVS serveru darbināšanu katru uz viena8-kodolu procesora, kas pilnībā nodrošina prasīto veiktspēju.Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2]Risinājuma arhitektūrā paredzētās infrastruktūras komponentes nav ierobežotas ar papildus operatīvāsatmiņas izmantošanu.PERF.43Izmantojamām datu bāzu un pielietojumu serveratehnoloģijām ir jāpieļauj automātiska slodzes dalīšanastarp mezgliem strādājot klasterī (cluster). Ja šāds darbsprasa papildus licencēšanu, piedāvājumā ir jānorādaRisinājuma arhitektūra paredz automātisku slodzes dalīšanu starp mezgliem strādājot klasterī (cluster).Pieeja automātiskai slodzes dalīšanai starp mezgliem ir aprakstīta Infrastruktūras prasību dokumentā,skat. [2]Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 115 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06PERF.44papildus licencēšanas izmaksas un citi ierobežojumi, kassaistīti ar darbu klāsterī.Šī prasība nav interpretējama kā nepieciešamībapiegādāt licenci klasterizētam risinājumam, bet gan kāpiedāvātā risinājumu spēja mērogoties.Izmantojamām datu bāzu un pielietojumu serveratehnoloģijām ir jāpieļauj klastera re-konfigurēšana(jauna mezgla pievienošana, mezgla atslēgšana)neapstādinot sistēmas darbu un automātiski nodrošinotlietotāju pieprasījumu migrēšanu starp klasteramezgliem.SQL Server un Windows Server tehnoloģijas pieļauj klastera re-konfigurēšanu (jauna mezglapievienošana, mezgla atslēgšana), neapstādinot sistēmas darbu un automātiski nodrošinot lietotājupieprasījumu migrēšanu starp klastera mezgliem. EVK risinājuma arhitektūrā ir paredzēts izmantot divusfiziskus serverus. Sistēmas infrastruktūras risinājumā ir paredzēts, ka viena servera failover gadījumā, tāfunkcijas pārņem otrs serveris. Laika gaitā risinājumu iespējams papildināt ar papildus serveriem,nemainot kopējo infrastruktūras uzbūvi.PERF.51 IS jānodrošina iespēja (administratoram) noteiktatšķirīgas prioritātes dažādām pieprasījumu grupām –piemēram fona atskaišu apstrādei;EVK nodrošinās iespēju (administratoram) noteikt atšķirīgas prioritātes dažādām pieprasījumu grupām –piemēram fona atskaišu apstrādei.PERF.52PERF.53IS izstrādātājam ir jāņem vērā, ka IS var tikt ekspluatētaklasterētā un/vai daudzprocesoru vidē un jāizmantotādi kritisko resursu bloķēšanas mehānismi, kuri neradapapildus aiztures sadarbojoties starp vairākiemprocesoriem un klastera mezgliem;Šī prasība nav interpretējama kā nepieciešamībapiegādāt licenci klasterizētam risinājumam, bet gan kāpiedāvātā risinājumu spēja apstrādāt kļūdu situācijasklastera slēgumā.Pretendenta piedāvātajam risinājumam ir jānodrošinaaugstas pieejamības īpašības. Risinājumam jāsaglabādarbaspēja un jānodrošina transakciju integritāte vismazšādosscenārijos:· Sakaru kanāla kļūda vai darba pārtraukums(transakciju sinhronizācija jāveic automātiski pēc sakaruEVK risinājumā ir paredzēts, ka sistēma tiks ekspluatēta klasterētā un daudzprocesoru vidē. Līdz ar tosistēmas risinājumā ir izmantoti tādi kritisko resursu bloķēšanas mehānismi, kuri neradīs papildusaiztures, sadarbojoties starp vairākiem procesoriem un klastera mezgliem.EVK risinājums nodrošinās iespēju apstrādāt kļūdu situācijas klastera slēgumā.EVK risinājums nodrošinās augstas pieejamības īpašības. Risinājums saglabās darbaspējas un nodrošināstransakciju integritāti vismaz šādos scenārijos:Sakaru kanāla kļūda vai darba pārtraukums (transakciju sinhronizācija tiks veikta automātiski pēcsakaru kanāla atjaunošanas);Operāciju sistēmas vai tehniska kļūda kādā (vienā) no serveriem; Risinājumam ir jāveic korektaNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 116 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06kanālaatjaunošanas);· Operāciju sistēmas vai tehniska kļūda kādā (vienā)no serveriem; Risinājumam ir jāveic korekta situācijasapstrāde, kad servera darbs tiek atjaunots;· Datubāzes servera, pielietojumu servera jeb pašapielietojuma programmatūras kļūda;Precīzi darbības turpināšanas scenāriji dažādāmsituācijām ir jādokumentē informācijas sistēmas analīzesfāzes laikā.PERF.54 IS ir jāatpazīst un jāspēj korekti apstrādātinfrastruktūras elementu ziņojumi par ārkārtassituācijām (sesijas pārtraukšana, piespiedu sesijaspārslēgšanu un tml.).situācijas apstrāde, kad servera darbs tiek atjaunots;Datubāzes servera, pielietojumu servera jeb paša pielietojuma programmatūras kļūda.Risinājuma augstas pieejamības un mērogošanas pieeja ir aprakstīta Infrastruktūras prasību dokumentā,skat. [2].EVK tiks nodrošināts, ka tiek atpazīti un korekti apstrādāti infrastruktūras elementu ziņojumi par ārkārtassituācijām (sesijas pārtraukšana, piespiedu sesijas pārslēgšanu un tml.). Sistēmas uzbūve tiks veidotatādā veidā, lai infrastruktūras elementu ziņojumi ārkārtas situācijām tiktu identificēti, apstrādāti,ierakstīti sistēmas funkciju žurnālā, un nepieciešamības gadījumā tiks veidota papildus sistēmas reakcijauz identificēto ārkārtas situāciju. Sistēmas izstrādes posmā tiks veikta iespējamo ārkārtas situācijuidentifikācija un tiks izstrādāti sistēmas darbības scenāriji šo identificēto ārkārtas situāciju apstrādei.Risinājuma augstas pieejamības un mērogošanas pieeja ir aprakstīta Infrastruktūras prasību dokumentā,skat. [2].PERF.55 Izmantojamām tehnoloģijām (infrastruktūraskomponentēm) ir jāspēj automātiski atjaunot darbībubez datu zudumiem vai bojājumiem, ja tiek bojāts viensno vairākiem alternatīviem pieslēgumiem disku atmiņai(storage).EVK IS infrastruktūras risinājums nodrošinās iespēju automātiski atjaunot darbību bez datu zudumiem vaibojājumiem, ja tiek bojāts viens no vairākiem alternatīviem pieslēgumiem disku atmiņai (storage),vaigadījumiem, kad disks, uz kura atradīsies datu bāze, pārtrauks savu darbību. Izmantotais EVKinfrastruktūras risinājums nodrošinās sistēmas darbību bez pārtraukumiem, un bez datu zudumiem, vaibojājumiem.EVK infrastruktūras līmeņa risinājums:tiks izmantoti RAID 10 konfigurācijas diski (tiek dublēti diski);tiks izmantoti vairāki slēdži (switch) uz disku masīvu (storage) (tiek dublēts fiziskais pieslēgums);tiks izmantoti vairāki porti datoros, kuri ar to strādā (tehniskā arhitektūrā tiks paredzēti 2 HBAadapteri katrā datorā – dublēts pieslēgums no katra datora);tiks izmantoti 2 disku masīva kontrolieri disku masīvam (izsargājoties pret gadījumu, kad iziet noNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 117 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06PERF.56Izmantojamām datu bāzu un pielietojumu serveratehnoloģijām ir jāveic automātiska klastera rekonfigurēšana(mezgla atslēgšana) gadījumā, ja klasteramezgls ir bojāts (tehnisks defekts, programmunodrošinājuma kļūda, pielietojuma kļūda), neapstādinotsistēmas darbu un automātiski nodrošinot lietotājusesiju migrēšanu starp klastera mezgliem. Sesijasmigrēšanas laikā ir pieļaujams pēdējās lietotājanepabeigtās darbības (transakcijas) pārtraukšana.Šī prasība nav interpretējama kā nepieciešamībapiegādāt licenci klasterizētam risinājumam, bet gan kāpiedāvātā risinājumu spēja apstrādāt kļūdu situācijasklastera slēgumā.ierindas viss disku masīva kontrolieris); datu krātuves (storage) kontrolieris (draiveriem) VMWare jāatbalsta MultiPath IO (laioperētājsistēma (OS) var izmantot abus HBA).Risinājums nodrošinās alternatīvo datu kanālu un tā izmantošanu infrastruktūras līmenī.Izmantojamām datu bāzu un pielietojumu servera tehnoloģijām tiek nodrošināta automātisku klasterare-konfigurēšana (mezgla atslēgšana) gadījumā, ja klastera mezgls ir bojāts (tehnisks defekts, programmunodrošinājuma kļūda, pielietojuma kļūda), neapstādinot sistēmas darbu, automātiski nodrošinot lietotājusesiju migrēšanu starp klastera mezgliem. Sesijas migrēšanas laikā var tikt veikta pēdējās lietotājanepabeigtās darbības (transakcijas) pārtraukšana.PERF.57 Pretendentam piedāvājumā jānorāda optimālāinfrastruktūras konfigurācija ņemot vērā paredzamosdatu apjomus, lietotāju skaitu, ātrdarbības unpieejamības prasības.SECR.1 Sistēmā visas lietotāju un administratoru veiktāsdarbības tiek identificētas (zināms kurš konkrēti izpildaminēto darbību). Šī prasība neattiecas uz funkcionalitāti,kas speciāli norādīta kā publiski pieejama;Optimālā infrastruktūras konfigurācija, ņemot vērā paredzamos datu apjomus, lietotāju skaitu,ātrdarbības un pieejamības prasības ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2]Sistēmā lietotāju un administratoru veiktās darbības tiek identificētas (zināms kurš konkrēti izpildaminēto darbību).Katrs EVK pakalpes izsaukums saturēs papildus drošības informācijas komplektu, kuru aizpildīs IPautorizācijas serviss veiksmīgas autorizācijas gadījumā. Drošības informācijas komplekts saturēs lietotājaidentifikāciju.SECR.2Ārēju pieprasījumu (WEB servisu) iniciējošie lietotāji iridentificējami tieši vai izmantojot e-veselībasĀrēju pieprasījumu (WEB servisu) iniciējošie lietotāji tiks identificēti, izmantojot e-veselības autorizācijasNacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 118 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06SECR.3SECR.4SECR.5SECR.6SECR.7autorizācijas moduli integrācijas platformā.Visām darbībām tiek pārbaudīta autorizācija darbībasizpildei. Pārbaudei jānotiek katra pieprasījumu līmenī;Jebkurš nesekmīgs autorizācijās vai autentifikācijasmēģinājums tiek reģistrēts sistēmas žurnālā;Lietotāju autorizācijas tiesību informācija tiek glabātaatmiņas apgabalā, kas aparātiski nodalīts no lietotājapieprasījuma izpildei izmantotās atmiņas. Ar nodalītutiek saprasts nodalījums izmantojot lietotājamneapejamus infrastruktūras elementu līdzekļus.Tiek realizēts autorizācijas princips, ka viss kas nav tiešāveidā atļauts ir aizliegts.IS izstrādē jāievēro OWASP rekomendētie sistēmuizstrādesprincipi:http://www.owasp.org/index.php/Category:Principle.moduli integrācijas platformā.EVK visas darbības tiks nodrošināta tikai pēc veiksmīgas autorizācijas. Pārbaude tiks nodrošināta katrapieprasījuma līmenī.Katrs EVK pakalpes izsaukums saturēs papildus drošības informācijas komplektu, kuru aizpildīs IPautorizācijas serviss veiksmīgas autorizācijas gadījumā. Drošības informācijas komplekts saturēs lietotājapilno tiesību komplektu.Nesekmīgie autorizācijās vai autentifikācijas mēģinājumi tiek reģistrēti sistēmas žurnālā, izmantojot IPaudita bibliotēku.Lietotāju autorizācija tiks izdalīta atsevišķā procesā, kas dos iespēju tam izdalīt atsevišķu atmiņasapgabalu, tādējādi to aparātiski nošķirot no lietotāja pieprasījuma izpildei izmantotās atmiņas.Tiks realizēts autorizācijas princips, ka viss, kas nav tiešā veidā atļauts, ir aizliegts.EVK IS izstrādē tiks ņemti vērā OWASP rekomendētie sistēmu izstrādes principi:http://www.owasp.org/index.php/Category:Principle.Precīzas rekomendācijas un to ievērošanas veids tiks saskaņots projekta projektēšanas fāzē.SECR.10 Izstrādē un IS ekspluatācijā nedrīkst izmantotkomponentes, kuras ražotājs pozicionē kā „Beta”, „Prerelease”,„Release candidate”„obsolete” vai arī kādācitā veidā nerekomendē izmantošanai ražošanassistēmās.EVK sistēmas arhitektūra paredz izmantot tikai attiecīgo ražotāju ražošanas sistēmās rekomendētaskomponentes. Detalizēta fiziskā arhitektūra ir aprakstīta Infrastruktūras prasību dokumentā, skat. [2]SECR.11IS Izstrādē nedrīkst izmantot komponentes, kurāmražotājs nepiegādā vai tuvāko 2 gadu laikā no izstrādesuzsākšanas brīža plāno pārtraukt izstrādi un/vai piegādātRisinājuma arhitektūrā netiek izmantotas komponentes, kurām ražotājs nepiegādā vai tuvāko 2 (divu)gadu laikā no izstrādes uzsākšanas brīža plāno pārtraukt izstrādi un/vai piegādāt drošības labojumus.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 119 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06SECR.12SECR.13SECR.14SECR.15drošības labojumus.WEB pielietojumiem sesiju pārvaldība jāorganizē pēcOWASP rekomendētajiem principiem:http://www.owasp.org/index.php/Session_ManagementAdministratoru pieeja sistēmai jāspēj ierobežot ar vienuvai vairākiem IP apgabaliem. Ar IP apgabalu šeit tieksaprasts IPV4 vai IPV6 adrešu intervāls.WEB pielietojumiem jāņem vērā OWASP rekomendācijasAJAX tehnoloģiju izmantošanaihttp://www.owasp.org/index.php/Ajax_and_Other_%22Rich%22_Interface_TechnologiesJāpielieto ražotāju un nozares ekspertu ieteiktās labāsprakses drošu informācijas sistēmu izstrādē.EVK lietotāju saskarnes komponenti tiks izvietoti e-Veselības portālā, kas ir balstīts uz Sitefinitytehnoloģijām. Sitefinity produkts ir veidots atbicltoši OWASP rekomendētajiem principiem.Sistēmu administratoriem pieeja sistēmai tiks nodrošināta, izmantojot Remote Desktop Protocol (RDP)pieeju, kurai tiek nodrošināta iespēja ierobežot konkrētu IP adrešu apgabalu.EVK lietotāju saskarnes komponenti tiks izvietoti e-Veselības portālā, kas ir balstīts uz Sitefinitytehnoloģijām. Sitefinity produkts ir veidots atbicltoši OWASP rekomendētajiem principiem.Tiks pielietotas ražotāju un nozares ekspertu ieteiktās labās prakses drošu informācijas sistēmu izstrādē.SECR.31 IS autentifikācija ir jāveic izmantojot E-veselībasIntegrācijas Platformas autentifikācijas servisu.Lietotāju un ārēju IS autentifikācija tiks veikta, izmantojot IP autentifikācijas servisu.SECR.32IS autorizācija ir izmantojot E-veselības IntegrācijasPlatformas autorizācijas servisu (E-veselībasautorizācijas servisu)Lietotāju un ārēju IS autorizācija tiks veikta, izmantojot IP autorizācijas servisu.AUDT.1 Visām IS ekspluatācijā izmantotajām infrastruktūraskomponentēm ir jānodrošina SNMP v2 vai v3 sistēmuuzraudzības interfeiss. Komponentēm, kurasnenodrošina SNMP interfeisu jāpiegādā nepieciešamierisinājumi uzraudzības interfeisa pārveidošanaiatbilstoši SNMP v2 vai v3 prasībām;Tiks nodrošināta iespēja attālināti uzraudzīt sistēmas veiktspēju un citus sistēmas kvalitātes rādītājus,iestrādājot sistēmā SNMP (Simple Network Management Protocol) atbalstu. Sistēmas uzraudzībasmehānisms nodrošinās iespēju izmantot pieejamos šo standartu atbalstošos monitoringa rīkus.Pretendenta izstrādātajām komponentēm SNMP (v2c; detalizētu informāciju skat.http://msdn.microsoft.com/en-us/library/aa379141(v=VS.85).aspx)) atbalsts IS komponentēs tiksnodrošināts, izmantojot Windows SNMP Service (detalizētu informāciju skat.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 120 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06AUDT.2 Visām IS ekspluatācijā izmantotajām infrastruktūraskomponentēm jānodrošina automātiska iespēja sūtītSNMP ziņojumus (SNMP trap) situācijās, kurāsnepieciešama cilvēka (administratora) iejaukšanāssistēmas darbā;http://msdn.microsoft.com/en-us/library/aa379100(VS.85).aspx).SNMP Service tiek nodrošināta divus programmatūras sadarbībai ar ārējām aplikācijām WinSNMP APIv2.0 un SNMP Extension Agent API (detalizētu informāciju skat. http://msdn.microsoft.com/enus/library/aa379207(v=VS.85).aspx).Optimālākā SNMP standarta implementācija tiks izraudzīta sistēmasprojektēšanas fāzē.AUDT.3Visu infrastruktūras komponenšu SNMP interfeisiem irjābūt brīvi pieejamām vai jātiek piegādātām SNMP MIBdefinīcijām;Sistēmas infrastruktūrā tiks izmantoti ražotāja Microsoft standarta programmatūras produkti, kuriem irnodrošināts IPv6 atbalsts. Windows SNMP Service tiek nodrošināts, sākot ar Windows Server 2008versiju (detalizētu informāciju skat. http://msdn.microsoft.com/en-us/library/aa377981(v=VS.85).aspx).AUDT.5Informācijas Sistēmai jānodrošina SNMP v2 vai v3interfeiss IS darba uzraudzībai (tikai lasīšana). Konkrētosrādītājus jāprecizē Informācijas Sistēmas projektēšanaslaikā.AUDT.6 IS jānodrošina programmatūras kļūdu un izņēmumusituāciju (exceptions) paziņošana uzraudzības serverimizmantojot SNMP ziņojumus (SNMP trap).Microsoft SQL Server un Microsoft IIS veiktspējas pārraudzībai tiks izmantots jau tajos iebūvētais SNMPpārraudzības atbalsts. Programmatūras ražotājs (Microsoft) publicētos SNMP objektus (MIB) piegādākopā ar attiecīgo produktu instalācijām: Microsoft SQL Server (detalizētu informāciju skat. http://technet.microsoft.com/enus/library/dd316347.aspx#ECAA); Microsoft IIS (detalizētu informāciju skat. http://technet.microsoft.com/enus/library/bb726987.aspx#EAAA).AUDIT.7AUDIT.8AUDT.11ADMN.31IS jānodrošina programmatūras kļūdu un izņēmumasituāciju (exceptions) paziņošana izmantojot e-pastu.SNMP ziņojumu (SNMP trap) saturam ir jātiek dublētamsistēmas LOG-failos.IS jāsniedz informācija Personas datu uzraudzībasservisam par visiem ar personas datiem saistītiemnotikumiem ņemot vērā Fizisko personu datuaizsardzības likuma[2] prasības.Sistēmai jānodrošina iespēja uzstādīt funkcionālos undrošības labojumus. Ja šādu labojumu uzstādīšanai tas irnepieciešams, IS administratīvajā interfeisā irjānodrošinaiespējas:EVK tiks nodrošināta programmatūras kļūdu un izņēmuma situāciju (exceptions) paziņošana, izmantojote-pastu. Tas tiks nodrošināts, izmantojot centralizētu NVD monitoringa rīku.SNMP ziņojumu (SNMP trap) saturs tiks dublēts sistēmas LOG-failos.EVK IS nodrošinās informācijas sniegšanu Personas datu uzraudzības servisam par visiem ar personasdatiem saistītiem notikumiem, ņemot vērā Fizisko personu datu aizsardzības likuma prasības.EVK tiks nodrošināta iespēja uzstādīt funkcionālos un drošības labojumus.EVK administratīvajā interfeisā tiks nodrošinātas iespējas nepieciešamības gadījumā:Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 121 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06· Apturēt/Atsākt jaunu lietotāju pieslēgumuveidošanu;· Pārtraukt esošās lietotāju sesijas (visas vai tikainorādītās) saglabājot atsevišķo lietotāju veikto operācijuintegritāti;· Apturēt/Atjaunot datu apmaiņu caur interfeisiem;· Apturēt/Atjaunot fona procesu un uzdevumuizpildi;Apturēt/Atsākt jaunu lietotāju pieslēgumu veidošanu;Pārtraukt esošās lietotāju sesijas (visas vai tikai norādītās), saglabājot atsevišķo lietotāju veiktooperāciju integritāti;Apturēt/Atjaunot datu apmaiņu caur interfeisiem;Apturēt/Atjaunot fona procesu un uzdevumu izpildi.ADMN.41Informācijas sistēmai jānodrošina iespēja veikt sistēmasrezerves kopēšanu un konsistentas kopijas iegūšanu bezsistēmas darba apturēšanas. Ja sistēmas rezerveskopēšanai nepieciešama IS un/vai infrastruktūraskomponenšu darbināšana speciālā režīmā, tad šādaspeciāla režīma ieslēgšana/izslēgšana jānodrošina arkomandrindas interfeisa palīdzību.EVK nodrošinās iespēju veikt sistēmas rezerves kopēšanu un konsistentas kopijas iegūšanu bez sistēmasdarba apturēšanas.Ja sistēmas rezerves kopēšanai būs nepieciešama EVK un/vai infrastruktūras komponenšu darbināšanaspeciālā režīmā, tad šāda speciāla režīma ieslēgšana/izslēgšana tiks nodrošināta ar komandrindasinterfeisa palīdzību.ADMN.42 Izmantojamām infrastruktūras komponentēm (datubāzei, pielietojumu serverim) ir jānodrošina iespējaveidot rezervēšanas politiku pamatojoties uz IS turētājanoteikto atjaunošanas laiku (piemēram, atjaunošana neilgāka kā 2h).ARCH.1 Informācijas Sistēmu arhitektūra ir jāveido kādaudzlīmeņu arhitektūra ar uzskaitītajiem loģiskinodalītiem funkcionalitātes līmeņiem:· Datu līmenis – nodrošina datu uzglabāšanu un datuintegritātes kontroli (ieskaitot biznesa loģikas noteiktosdatu integritātes nosacījumus). Datu līmenis jārealizēdatu bāzes vadības sistēmā. Datu līmenī tiek realizētapieejas kontrole limitējot pieeju no biznesa loģikas tikaibiznesa funkcijām nepieciešamā apjomā, kā arī auditafunkcijas.Izmantojamām infrastruktūras komponentēm (datu bāzei, pielietojumu serverim) tiks nodrošinātaiespēja veidot rezervēšanas politiku, pamatojoties uz IS turētāja noteikto atjaunošanas laiku (piemēram,atjaunošana ne ilgāka kā 2h).EVK loģiskā arhitektūra ir aprakstīta 3.2 Loģiskā arhitektūra sadaļā, bet tās realizācija fiziskajā līmenī -Infrastruktūras prasību dokumentā, skat. [2].Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 122 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06· Biznesa loģikas līmenis nodrošina lietotājufunkcionālo pieprasījumu pārvēršanu datu apstrādespieprasījumos. Šajā līmenī tiek veikta pieejas kontrole,kā arī nodrošināta datu apstrādes loģika. Biznesa loģikaslīmeni ieteicams realizēt datu bāzes vadības sistēmā.· Integrācijas līmenis nodrošina biznesa loģikasfunkciju publicēšanu WEB pakalpojumu (WEB servisu)veidā, kā arī ārēju WEB pakalpojumu pieejamību biznesaloģikas līmenim. Integrācijas līmeni ieteicams realizētpielietojumuserverī.· Lietotāju Interfeisa loģikas līmenis nodrošinabiznesa loģikas līmeņa funkcionalitātes prezentācijuatbilstoši lietotāju vajadzībām, lietotājiem ērtā unsaprotamā veidā. Interfeisa loģikas līmeni ieteicamsrealizēt pielietojumu serverī.· Lietotāju interfeisa prezentācijas līmenis nodrošinainformācijas attēlošanu lietotājamARCH.2ARCH.3Līmeņu sadarbība jāorganizē definētu un dokumentētuinterfeisu veidā. Līmeņu un to sadarbības tehniskaisapraksts jāpiegādā kā daļa no Sistēmas arhitektūrasdokumenta.Izstrādājot sistēmas arhitektūru ir jāparedz papildusfunkcionalitāte, kas nepieciešama efektīvai sistēmutestēšanai un diagnostikai. Iespēju robežās sistēmai irjāveic pašdiagnostika, nodrošinot izsaukumu parametruvērtību un pieejas tiesību kontroli starp dažādiemarhitektūras līmeņiem.Komponentu savstarpējā sadarbība un sadarbība ar ārējām sistēmām ir aprakstīta 6.3 Sistēmaskomponentu sadarbība sadaļā. Loģisko komponentu izvietošanas varianti ir aprakstīti 7 Fiziskāarhitektūra sadaļā.EVK pārvaldības arhitektūra ir aprakstīta 8 Pārvaldības arhitektūra sadaļā.ARCH.4 Arhitektūra veidojama minimizējot nepieciešamoinfrastruktūras komponenšu un programmu bibliotēkuskaitu un sarežģītību.EVK arhitektūra paredz izmantot nelielu skaitu infrastruktūras komponenšu un programmu bibliotēku.Detalizēts nepieciešamo komponenšu apraksts atrodams 6.4 Sistēmas komponenti sadaļā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 123 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06ARCH.5 Arhitektūra veidojama minimizējot nepieciešamotehnoloģiju (programmēšanas valodu, bibliotēku,izstrādes tehnoloģiju u.c.) skaitu.EVK arhitektūra paredz izmantot nelielu skaitu izmantojamo tehnoloģiju. Detalizēts izmantojamotehnoloģiju apraksts atrodams 6.4 Sistēmas komponenti sadaļā.ARCH.7ARCH.21ARCH.25Visas sistēmas arhitektūra veidojama ņemot vērāiespējamos informācijas sistēmas datu plūsmaspārrāvumus:· Visas lietotāju darbības sistēmā jāaizsargā artransakcijumehānismiem;· Datu apmaiņa starp sistēmām ir jāaizsargā artransakciju mehānismu, vai jānodrošina iespējaautomātiski atjaunot/atkārtot apmaiņu pēc pārrāvumasaglabājot pilnu datu integritāti;Datu apmaiņa starp sistēmām realizējama vienā nošādiem ` veidiem:· Sinhronu un/vai Asinhronu WEB servisu izsaukumi;· XML standarta formāta failu apmaiņa;· Teksta formāta failu apmaiņa;Atsevišķos gadījumos, kad nav iespējams ietekmētpieejamā interfeisa tehnoloģiju, var tikt izmantotas citassadarbības tehnoloģijas. Konkrēts datu apmaiņasmehānisms tiks precizēts Informācijas Sistēmas izstrādesanalīzes fāzes laikā.Iespēja simulēt ārējo interfeisu darbu situācijās, kadārējas sistēmas nav pieejamas. Simulācija veicamalimitētam datu apjomam, pietiekošam sistēmastestēšanasveikšanai.Interfeisi, kuri izmantos E-veselība Integrācijas platformu(IP) šīs prasības nodrošināšanai, var izmantot IPfunkcionalitāti.Datu plūsmas starp EVK komponentēm tiks nodrošināta izmantojot transakciju mehānismu.Datu apmaiņai starp sistēmām tiks izmantoti sinhronu un asinhronu Web servisu izsaukumi. Ārējāmsistēmām, kuras nevar garantēt pieprasījumu apstrādi mazāk kā 3 sekundēs, servisu izsaukumigalvenokārt tiek veikti asinhroni.Testēšanas nolūkiem Sistēmas interfeisiem tiks izveidota funkcionalitāte to simulētam izsaukumam, kuriatgriezīs testēšanas piemēros definētus rezultātus.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 124 no 125

Elektroniskas Veselības Kartes Informācijas sistēmaTehniskās arhitektūras aprakstsVersija 3.0.06ARCH.27ARCH.41Jānodrošina iespēja kontrolēt ārējām sistēmām nosūtītopieprasījumu izpildes ilgumu un apstrādāt situācijas, kadtiek pārsniegts pieļaujamais atbildes gaidīšanas laiks;Informācijas Sistēmai jānodrošina ārējo klasifikatorusaņemšana un ielāde no Integrācijas platformas (eveselībaklasifikatori) un citiem avotiem, ja klasifikatorsnav pieejams integrācijas platformā.Sistēmas pielietojumu serverī tiks nodrošināta iespēja kontrolēt ārējām sistēmām nosūtīto pieprasījumuizpildes ilgumu un apstrādāt situācijas, kad tiek pārsniegts pieļaujamais atbildes gaidīšanas laiks. Sistēmasžurnālos tiks reģistrēti ziņojumi par pārsniegtiem pieprasījumu izpildes laikiem ārējās sistēmās.Prasību nodrošinās Klasifikatoru modulis, kas aprakstīts 6.4.7 Klasifikatoru modulis sadaļā.Nacionālais veselības dienests NVD.EVK.ARCH.3.0.06 A/S „Datorzinību centrs”Lapa 125 no 125