Lietuvos Respublikos kos sveikatos apsaugos apsaugos ......rija prendimo naujumo, vimo plėtros ikatos paslaugų mendacijų DOKUMENTO PATVIRTINIMAS Lietuvos Respublikos sveikatos apsaugos

Nacionalinės elek

tinkamumo eksplo

klausimais paslau

E.1, E.2, E.3.1 Esa

uždavinių ir e. svei

ataskaita

v.2.0

Lietuvos Respublikosapsaugos ministerija

2009 m. gruodžio 24 d.

lektroninės sveikatos sistemos spren

sploatuoti įvertinimo ir konsultavimo

slaugos

Esamos situacijos, taikomųjų e. sveikat

veikatos standartų įvertinimo ir rekome

kos sveikatos apsaugos rija

prendimo naujumo,

vimo plėtros

ikatos paslaugų

mendacijų

DOKUMENTO PATVIRTINIMAS

Lietuvos Respublikos sveikatos apsaugos ministerija

„Nacionalin÷s elektronin÷s sveikatos sistemos sprendimo, naujumo, tinkamumo eksploatuoti įvertinimo ir konsultavimo pl÷tros klausimais paslaugos“ projekto kuratorius

Parašas Data Vardas, Pavard÷

Nacionalin÷s elektronin÷s sveikatos sistemos sprendimo, naujumo, tinkamumo eksploatuoti įvertinimo ir konsultavimo pl÷tros klausimais

paslaugos 3 lapas iš 123

E.1, E.2, E.3.1 Esamos situacijos, taikomųjų e. sveikatos paslaugų uždavinių ir e. sveikatos standartų įvertinimo ir rekomendacijų ataskaita

SVEIKATOS APSAUGOS

MINISTERIJA

TURINYSTURINYSTURINYSTURINYS SĄVOKOS IR TRUMPINIASĄVOKOS IR TRUMPINIASĄVOKOS IR TRUMPINIASĄVOKOS IR TRUMPINIAIIII 5

SANTRAUKASANTRAUKASANTRAUKASANTRAUKA 7

1.1.1.1. ĮVADASĮVADASĮVADASĮVADAS 16

2.2.2.2. TAIKOMIEJI E. SVEIKATAIKOMIEJI E. SVEIKATAIKOMIEJI E. SVEIKATAIKOMIEJI E. SVEIKATOS PASLAUGŲ UŽDAVINTOS PASLAUGŲ UŽDAVINTOS PASLAUGŲ UŽDAVINTOS PASLAUGŲ UŽDAVINIAI IR E. SVEIKATOS IAI IR E. SVEIKATOS IAI IR E. SVEIKATOS IAI IR E. SVEIKATOS PASLAUGŲ IR BENDRADAPASLAUGŲ IR BENDRADAPASLAUGŲ IR BENDRADAPASLAUGŲ IR BENDRADARBIAVIMO RBIAVIMO RBIAVIMO RBIAVIMO

INFRASTRUKTŪROS VIZIINFRASTRUKTŪROS VIZIINFRASTRUKTŪROS VIZIINFRASTRUKTŪROS VIZIJAJAJAJA 17

2.1.2.1.2.1.2.1. VERTINIMO METODIKA BVERTINIMO METODIKA BVERTINIMO METODIKA BVERTINIMO METODIKA BEI ATLIKTI DARBAIEI ATLIKTI DARBAIEI ATLIKTI DARBAIEI ATLIKTI DARBAI 17

2.1.1.2.1.1.2.1.1.2.1.1. PRIEMONIŲ PLANE PATEPRIEMONIŲ PLANE PATEPRIEMONIŲ PLANE PATEPRIEMONIŲ PLANE PATEIKTŲ UŽDAVINIŲ VERTIIKTŲ UŽDAVINIŲ VERTIIKTŲ UŽDAVINIŲ VERTIIKTŲ UŽDAVINIŲ VERTINIMASNIMASNIMASNIMAS 18

2.2.2.2.2.2.2.2. E. SVEIKATOS TIKSLAIE. SVEIKATOS TIKSLAIE. SVEIKATOS TIKSLAIE. SVEIKATOS TIKSLAI IR ĮGYVENDINIMO PRINIR ĮGYVENDINIMO PRINIR ĮGYVENDINIMO PRINIR ĮGYVENDINIMO PRINCIPAICIPAICIPAICIPAI 19

2.3.2.3.2.3.2.3. E. SVEIKATOS UŽDAVINE. SVEIKATOS UŽDAVINE. SVEIKATOS UŽDAVINE. SVEIKATOS UŽDAVINIŲ ĮGYVENDINIMO ETAPIŲ ĮGYVENDINIMO ETAPIŲ ĮGYVENDINIMO ETAPIŲ ĮGYVENDINIMO ETAPAIAIAIAI 20

2.4.2.4.2.4.2.4. SIŪLOMA E. SVEIKATOSSIŪLOMA E. SVEIKATOSSIŪLOMA E. SVEIKATOSSIŪLOMA E. SVEIKATOS PASLAUGŲ IR BENDRADAPASLAUGŲ IR BENDRADAPASLAUGŲ IR BENDRADAPASLAUGŲ IR BENDRADARBIAVIMO INFRASTRUKTRBIAVIMO INFRASTRUKTRBIAVIMO INFRASTRUKTRBIAVIMO INFRASTRUKTŪROS INFORMACINöS SIŪROS INFORMACINöS SIŪROS INFORMACINöS SIŪROS INFORMACINöS SISTEMOS STEMOS STEMOS STEMOS

ARCHITEKTŪRAARCHITEKTŪRAARCHITEKTŪRAARCHITEKTŪRA 21

3.3.3.3. NESS FUNKCIJŲ REALIZNESS FUNKCIJŲ REALIZNESS FUNKCIJŲ REALIZNESS FUNKCIJŲ REALIZAVIMUI NAUDOTOS TAIKAVIMUI NAUDOTOS TAIKAVIMUI NAUDOTOS TAIKAVIMUI NAUDOTOS TAIKOMŲJŲ SISTEMŲ ARCHITOMŲJŲ SISTEMŲ ARCHITOMŲJŲ SISTEMŲ ARCHITOMŲJŲ SISTEMŲ ARCHITEKTŪROS ĮVERTINIMASEKTŪROS ĮVERTINIMASEKTŪROS ĮVERTINIMASEKTŪROS ĮVERTINIMAS 27


3.2.3.2.3.2.3.2. PAGRINDINIAI PASTEBöPAGRINDINIAI PASTEBöPAGRINDINIAI PASTEBöPAGRINDINIAI PASTEBöJIMAIJIMAIJIMAIJIMAI 28

3.3.3.3.3.3.3.3. PASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMENDACIJOSNDACIJOSNDACIJOSNDACIJOS 44

4.4.4.4. ESAMŲ NESS DUOMENŲ MESAMŲ NESS DUOMENŲ MESAMŲ NESS DUOMENŲ MESAMŲ NESS DUOMENŲ MAINŲ SĄSAJŲ SU IŠORIAINŲ SĄSAJŲ SU IŠORIAINŲ SĄSAJŲ SU IŠORIAINŲ SĄSAJŲ SU IŠORINöMIS IS KATALOGASNöMIS IS KATALOGASNöMIS IS KATALOGASNöMIS IS KATALOGAS 50




4.3.1.4.3.1.4.3.1.4.3.1. PASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMENDACIJOS DUOMENŲ MAINDACIJOS DUOMENŲ MAINDACIJOS DUOMENŲ MAINDACIJOS DUOMENŲ MAINŲ SĄSAJŲ SU IŠORINöNŲ SĄSAJŲ SU IŠORINöNŲ SĄSAJŲ SU IŠORINöNŲ SĄSAJŲ SU IŠORINöMIS SISTEMOMIS PLöTIMIS SISTEMOMIS PLöTIMIS SISTEMOMIS PLöTIMIS SISTEMOMIS PLöTIMUIMUIMUIMUI 57

4.3.2.4.3.2.4.3.2.4.3.2. PASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMENDACIJOS DöL GALIMYBNDACIJOS DöL GALIMYBNDACIJOS DöL GALIMYBNDACIJOS DöL GALIMYBöS NAUDOTIS KITOMIS,öS NAUDOTIS KITOMIS,öS NAUDOTIS KITOMIS,öS NAUDOTIS KITOMIS, TIESIOGIAI SU SVEIKATIESIOGIAI SU SVEIKATIESIOGIAI SU SVEIKATIESIOGIAI SU SVEIKATOS APSAUGA TOS APSAUGA TOS APSAUGA TOS APSAUGA

NESUSIJUSIOMIS, ELEKNESUSIJUSIOMIS, ELEKNESUSIJUSIOMIS, ELEKNESUSIJUSIOMIS, ELEKTRONINTRONINTRONINTRONINöMIS PASLAUGOMISöMIS PASLAUGOMISöMIS PASLAUGOMISöMIS PASLAUGOMIS 58

5.5.5.5. NESS SPRENDIMO TECHNNESS SPRENDIMO TECHNNESS SPRENDIMO TECHNNESS SPRENDIMO TECHNINöS INFRASTRUKTŪROSINöS INFRASTRUKTŪROSINöS INFRASTRUKTŪROSINöS INFRASTRUKTŪROS NAUJUMO IR TINKAMUMONAUJUMO IR TINKAMUMONAUJUMO IR TINKAMUMONAUJUMO IR TINKAMUMO GAMYBINEI EKSPLOATACGAMYBINEI EKSPLOATACGAMYBINEI EKSPLOATACGAMYBINEI EKSPLOATACIJAI ĮVERTINIMASIJAI ĮVERTINIMASIJAI ĮVERTINIMASIJAI ĮVERTINIMAS

60




5.3.1.5.3.1.5.3.1.5.3.1. PASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMENDACIJOS TECHNINöS INDACIJOS TECHNINöS INDACIJOS TECHNINöS INDACIJOS TECHNINöS INFRASTRUKTŪROS TOBULNFRASTRUKTŪROS TOBULNFRASTRUKTŪROS TOBULNFRASTRUKTŪROS TOBULINIMUIINIMUIINIMUIINIMUI 69

5.3.2.5.3.2.5.3.2.5.3.2. PASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMENDACIJOS SISTEMINEI NDACIJOS SISTEMINEI NDACIJOS SISTEMINEI NDACIJOS SISTEMINEI PROGRAMINEI ĮRANGAIPROGRAMINEI ĮRANGAIPROGRAMINEI ĮRANGAIPROGRAMINEI ĮRANGAI 70

5.3.3.5.3.3.5.3.3.5.3.3. PASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMEPASIŪLYMAI IR REKOMENDACIJOS SAUGOS VALDNDACIJOS SAUGOS VALDNDACIJOS SAUGOS VALDNDACIJOS SAUGOS VALDYMUIYMUIYMUIYMUI 71

5.3.4.5.3.4.5.3.4.5.3.4. REKOMENDACIJOS IS INREKOMENDACIJOS IS INREKOMENDACIJOS IS INREKOMENDACIJOS IS INFRASTRUKTŪROS IR SAFRASTRUKTŪROS IR SAFRASTRUKTŪROS IR SAFRASTRUKTŪROS IR SAUGOS VALDYMUIUGOS VALDYMUIUGOS VALDYMUIUGOS VALDYMUI 71

6.6.6.6. INFORMACIJOS SAUGOS INFORMACIJOS SAUGOS INFORMACIJOS SAUGOS INFORMACIJOS SAUGOS ARCHITEKTŪROS TECHNOARCHITEKTŪROS TECHNOARCHITEKTŪROS TECHNOARCHITEKTŪROS TECHNOLOGINIO NAUJUMO VERTLOGINIO NAUJUMO VERTLOGINIO NAUJUMO VERTLOGINIO NAUJUMO VERTINIMASINIMASINIMASINIMAS 73






SVEIKATOS APSAUGOS

MINISTERIJA


7.7.7.7. ELEKTRONINöS SVEIKATELEKTRONINöS SVEIKATELEKTRONINöS SVEIKATELEKTRONINöS SVEIKATOS SRITIES STANDARTŲOS SRITIES STANDARTŲOS SRITIES STANDARTŲOS SRITIES STANDARTŲ APŽVALGAAPŽVALGAAPŽVALGAAPŽVALGA 77

7.1.7.1.7.1.7.1. ELEKTRONINöS SVEIKATELEKTRONINöS SVEIKATELEKTRONINöS SVEIKATELEKTRONINöS SVEIKATOS ISTORIJOS IR KLINOS ISTORIJOS IR KLINOS ISTORIJOS IR KLINOS ISTORIJOS IR KLINIKINIŲ DUOMENŲ STRUKIKINIŲ DUOMENŲ STRUKIKINIŲ DUOMENŲ STRUKIKINIŲ DUOMENŲ STRUKTŪRŲ STANDARTAITŪRŲ STANDARTAITŪRŲ STANDARTAITŪRŲ STANDARTAI 77

7.2.7.2.7.2.7.2. SĄVEIKUMO IR DUOMENŲSĄVEIKUMO IR DUOMENŲSĄVEIKUMO IR DUOMENŲSĄVEIKUMO IR DUOMENŲ MAINŲ SVEIKATOS PRIEMAINŲ SVEIKATOS PRIEMAINŲ SVEIKATOS PRIEMAINŲ SVEIKATOS PRIEŽIŪROS SRITYJE STANDŽIŪROS SRITYJE STANDŽIŪROS SRITYJE STANDŽIŪROS SRITYJE STANDARTAI, ĮSKAITANT MEDARTAI, ĮSKAITANT MEDARTAI, ĮSKAITANT MEDARTAI, ĮSKAITANT MEDICININIŲ VAIZDŲ ICININIŲ VAIZDŲ ICININIŲ VAIZDŲ ICININIŲ VAIZDŲ

PERDAVIMO BEI MEDICIPERDAVIMO BEI MEDICIPERDAVIMO BEI MEDICIPERDAVIMO BEI MEDICININIŲ ĮRENGINIŲ KOMUNINIŲ ĮRENGINIŲ KOMUNINIŲ ĮRENGINIŲ KOMUNINIŲ ĮRENGINIŲ KOMUNIKAVIMO STANDARNIKAVIMO STANDARNIKAVIMO STANDARNIKAVIMO STANDARTUSTUSTUSTUS 81

7.3.7.3.7.3.7.3. SVEIKATOS INFORMACIJSVEIKATOS INFORMACIJSVEIKATOS INFORMACIJSVEIKATOS INFORMACIJOS SAUGOS STANDARTAIOS SAUGOS STANDARTAIOS SAUGOS STANDARTAIOS SAUGOS STANDARTAI IR ASMENS DUOMENŲ TVIR ASMENS DUOMENŲ TVIR ASMENS DUOMENŲ TVIR ASMENS DUOMENŲ TVARKYMĄ REGLAMENTUOJAARKYMĄ REGLAMENTUOJAARKYMĄ REGLAMENTUOJAARKYMĄ REGLAMENTUOJANTYS AKTAINTYS AKTAINTYS AKTAINTYS AKTAI

87

7.4.7.4.7.4.7.4. KLASIFIKATORIAI, ŽODKLASIFIKATORIAI, ŽODKLASIFIKATORIAI, ŽODKLASIFIKATORIAI, ŽODYNAI IR TERMINOLOGIJYNAI IR TERMINOLOGIJYNAI IR TERMINOLOGIJYNAI IR TERMINOLOGIJĄ APRAŠANTYS STANDARĄ APRAŠANTYS STANDARĄ APRAŠANTYS STANDARĄ APRAŠANTYS STANDARTAITAITAITAI 91

7.5.7.5.7.5.7.5. SISTEMŲ IR PASLAUGŲ SISTEMŲ IR PASLAUGŲ SISTEMŲ IR PASLAUGŲ SISTEMŲ IR PASLAUGŲ STANDARTAI, REGLAMENSTANDARTAI, REGLAMENSTANDARTAI, REGLAMENSTANDARTAI, REGLAMENTUOJANTYS E. SVEIKATTUOJANTYS E. SVEIKATTUOJANTYS E. SVEIKATTUOJANTYS E. SVEIKATOS SRITYJE TAIKOMAS OS SRITYJE TAIKOMAS OS SRITYJE TAIKOMAS OS SRITYJE TAIKOMAS INFORMACINIŲ INFORMACINIŲ INFORMACINIŲ INFORMACINIŲ

TECHNOLOGIJŲ PRIEMONTECHNOLOGIJŲ PRIEMONTECHNOLOGIJŲ PRIEMONTECHNOLOGIJŲ PRIEMONESESESES 94

7.6.7.6.7.6.7.6. KITI STANDARTAIKITI STANDARTAIKITI STANDARTAIKITI STANDARTAI 99

7.7.7.7.7.7.7.7. REKOMENDUOJAMI ESPBIREKOMENDUOJAMI ESPBIREKOMENDUOJAMI ESPBIREKOMENDUOJAMI ESPBI INFORMACINEI SISTEMAINFORMACINEI SISTEMAINFORMACINEI SISTEMAINFORMACINEI SISTEMAI TAIKYTINI STANDARTI TAIKYTINI STANDARTI TAIKYTINI STANDARTI TAIKYTINI STANDARTAI IR REIKALAVIMAIAI IR REIKALAVIMAIAI IR REIKALAVIMAIAI IR REIKALAVIMAI 100

PRIEDAIPRIEDAIPRIEDAIPRIEDAI 102

PRIEDAS NR. 1 PRIEDAS NR. 1 PRIEDAS NR. 1 PRIEDAS NR. 1 –––– SĄSAJOSSĄSAJOSSĄSAJOSSĄSAJOS 103

PRIEDAS NR. 2 PRIEDAS NR. 2 PRIEDAS NR. 2 PRIEDAS NR. 2 –––– NESS I APIMTYJE APRANESS I APIMTYJE APRANESS I APIMTYJE APRANESS I APIMTYJE APRAŠYTI DUOMENŲ MAINAI ŠYTI DUOMENŲ MAINAI ŠYTI DUOMENŲ MAINAI ŠYTI DUOMENŲ MAINAI TARP NESS IR SPĮ ISTARP NESS IR SPĮ ISTARP NESS IR SPĮ ISTARP NESS IR SPĮ IS 108

PRIEDAS NR. 3 PRIEDAS NR. 3 PRIEDAS NR. 3 PRIEDAS NR. 3 –––– KLASIFIKATORIAI IR IKLASIFIKATORIAI IR IKLASIFIKATORIAI IR IKLASIFIKATORIAI IR INFORMACIJOS KANFORMACIJOS KANFORMACIJOS KANFORMACIJOS KATALOGAITALOGAITALOGAITALOGAI 113

PRIEDAS NR. 4PRIEDAS NR. 4PRIEDAS NR. 4PRIEDAS NR. 4–––– NESS I PROJEKTO REZUNESS I PROJEKTO REZUNESS I PROJEKTO REZUNESS I PROJEKTO REZULTATŲ PANAUDOJIMASLTATŲ PANAUDOJIMASLTATŲ PANAUDOJIMASLTATŲ PANAUDOJIMAS 114

PRIEDAS NR. 5 PRIEDAS NR. 5 PRIEDAS NR. 5 PRIEDAS NR. 5 –––– SUSIJUSIŲ DOKUMENTŲ SUSIJUSIŲ DOKUMENTŲ SUSIJUSIŲ DOKUMENTŲ SUSIJUSIŲ DOKUMENTŲ IR INFORMACIJOS ŠALTIR INFORMACIJOS ŠALTIR INFORMACIJOS ŠALTIR INFORMACIJOS ŠALTINIŲ SĄRAŠASINIŲ SĄRAŠASINIŲ SĄRAŠASINIŲ SĄRAŠAS 123




SVEIKATOS APSAUGOS

MINISTERIJA

Sąvokos ir trumpiniaiSąvokos ir trumpiniaiSąvokos ir trumpiniaiSąvokos ir trumpiniai

Sąvokos ir trumpiniai Paaiškinimas

Aktas Angl. „act“, „healthcare activity“. HL7 srityje aktas tai sveikatos priežiūros įvykį, veiksmą apibr÷žianti sąvoka. Tai gali būti steb÷jimas (angl. „observation“) kaip matavimas, įvykis – kaip tiesioginis arba virtualus apsilankymas pas gydytoją, procedūra arba pacientui suteikiama paslauga, medžiagos priskirimas kaip receptas, medicininio produkto (pvz. vaisto) išdavimas, finansiniai duomenis, sveikatinimo paslaugos suteikimo informacija (bendra arba detalizuota), dokumentas (nes dokumentas gali būti sveikatos priežiūros veiksmo rezultatu).

CDA (CDA level 1) CDA Level-1 (angl. „Clinical Document Architecture Level-1“), kaip sveikatos informatikos standarto Health Level 7 dalis, nustato reikalavimus klinikinių dokumentų struktūrai, siekiant užtikrinti e. sveikatos sistemų sąveikumą ir suderinamumą

CobIT CobIT (angl. „Control Objectives for Information and Related Technologies“) yra ISACA standartas, aprašantis gerąją praktiką informacinių sistemų valdymo srityje

e. sveikata Sveikatos apsaugos, medicinin÷s informatikos ir administracin÷s veiklos darna, kuri užtikrinama diegiant informacines ir ryšių technologijas, organizacinius veiklos pokyčius ir naujus įgūdžius ir skirta sveikatinimo (asmens, visuomen÷s, farmacijos) paslaugoms tobulinti operatyviai pateikiant išsamią veiklai reikalingą informaciją

ESI Elektronin÷ sveikatos istorija

eSPBI E. sveikatos paslaugų ir bendradarbiavimo infrastruktūra

IS Informacin÷ sistema

KMUK VšĮ Kauno medicinos universiteto klinikos

KUL VšĮ Klaip÷dos universitetin÷ ligonin÷

NESS Nacionalin÷ elektronin÷s sveikatos (informacin÷) sistema - Lietuvos Respublikos sveikatos sistemos teisinių, organizacinių, informacinių ir ryšių technologijų bei duomenų bazių visuma, skirta centralizuotam elektroninių sveikatos istorijų tvarkymui ir apsikeitimui jomis tarp sveikatinimo įstaigų, jų specialistų ir kitų




SVEIKATOS APSAUGOS

MINISTERIJA

Sąvokos ir trumpiniai Paaiškinimas

darbuotojų, kurta 2005 – 2007 metais

Perkančioji organizacija arba SAM

Lietuvos Respublikos sveikatos apsaugos ministerija

Projektas Nacionalin÷s elektronin÷s sveikatos sistemos sprendimo, naujumo, tinkamumo eksploatuoti įvertinimo ir konsultavimo pl÷tros klausimais paslaugos, pagal Sutartį

SANTA VšĮ Vilniaus universiteto ligonin÷s Santariškių klinikos

SPĮ Sveikatos priežiūros įstaiga

Ernst & Young arba Paslaugų teik÷jas

UAB „Ernst & Young Baltic“

Sutartis Konsultavimo paslaugų sutartis Nr.S-266, pasirašyta 2009 m. spalio 14 d. tarp UAB „Ernst & Young Baltic“ ir Lietuvos Respublikos sveikatos apsaugos ministerijos

Technin÷ specifikacija Priedas Nr. 1 prie 2009 m. spalio 14 d. Konsultavimo paslaugų sutarties Nr. S-266 arba supaprastinto atviro konkurso nacionalin÷s elektronin÷s sveikatos sistemos sprendimo, naujumo, tinkamumo eksploatuoti įvertinimo ir konsultavimo pl÷tros klausimais paslaugų pirkimo sąlygų 9 priedas

VLK Valstybin÷ Ligonių kasa prie Sveikatos apsaugos ministerijos

SPoF Sistemos patikimumą mažinantis sistemos architektūros principas – vieno elemento neveiksnumas padaro sistemą nepasiekiamą (angl. „Single Point of Failure“)

NESS klientas Techninių ir programinių priemonių visuma, kuri suteikia galimybę sveikatos priežiūros įstaigai, neturinčiai lokalios informacin÷s sistemos, naudotis NESS funkcijomis (kaip dalis prie NESS)

DBVS Duomenų bazių valdymo sistema

JRE Java Runtime Environment

HP OVSA HO Open View Select Access programin÷s įrangos produktas

VAIISIS Viešojo administravimo institucijų informacinių sistemų interoperabilumo sistema




SVEIKATOS APSAUGOS

MINISTERIJA

SantraukaSantraukaSantraukaSantrauka

Iki šiol Lietuvoje vykdytos e. Sveikatos iniciatyvos, taip pat ir Nacionalin÷s elektronin÷s sveikatos sistemos (NESS) kūrimo iniciatyva, pasižym÷jo didel÷mis ambicijomis – iniciatyvos buvo didel÷s apimties automatizuotinų sričių prasme. Jas buvo siekiama įgyvendiniti per trumpą laiką – 2-3 metų trukmę1. Iniciatyvos kilo daugiau iš IT kompetencijos atstovų nei sveikatos priežiūros paslaugų teikimo veiklos ar pacientų poreikių. Patys e. sveikatos sprendimai buvo stipriai orientuojami į tradicinių centralizuotų transakcinių sistemų kūrimą.

D÷mesio trūkumas galutiniams rezultatų naudotojams, juos įtraukiant į įgyvendinimo procesą pačioje pradžioje ir pasiektų, kad ir dalinių, rezultatų sklaidai nebuvimas pasmerk÷ pasiektus rezultatus likti su nepašalintais trūkumais, senti morališkai ir technologiškai.

E. sveikatos pl÷tros formavimas

Pagal išmoktas pamokas ir šiuo metu vykdomą sveikatos sektoriaus reformą, e. sveikatos pl÷tros strateginis modelis apibr÷žiamas šiomis perspektyvomis:

► E. Sveikatos iniciatyvų vizija turi būti formuojama pagal ilgalaikius sveikatos strategijos prioritetus;

► E. Sveikatos priemonių ir sprendimų poreikis turi būti grindžiamas pacientų ir sveikatos priežiūros

įstaigų (specialistų) keliamais tikslais – įgyvendinimas negali būti savitikslis – tik d÷l informacinių technologijų panaudojimo sveikatos priežiūros sektoriuje;

► E. Sveikatos iniciatyvos turi būti įgyvendinamos ir esminiai sprendimai priimami pagal paprastus ir aiškius principus.

1 NESS 1, 2005 m. – 2007 m.




SVEIKATOS APSAUGOS

MINISTERIJA

Įgyvendinant E. Sveikatos iniciatyvas, esminiai sprendimai ir pasirinkimo problemos spręstini pagal šiuos principus:

► Įgyvendinimas turi būti inkrementalus, mažais žingsniais, susitelkiant ties esme ir apčiuopiamas naudojimo prasme;

► Turi būti numatomas įgyvendinamų rezultatų įgyvendinimo ir panaudojimo nuoseklumas – įgyvendinant vieną rezultatą, turi būti numatoma ir siekiama, kad jis turi būti panaudojamas tolesniuose etapuose;

► Iš pradžių sukuriami būtini baziniai ilgalaikiam ir daugkartiniam panaudojimui skirti teisinių, organizacinių ir techninių priemonių elementai ir jų pagrindu paprastesn÷s esm÷s rezultatai – paprastos e. sveikatos paslaugos, kurias plačiai naudotų pacientai ir sveikatos priežiūros įstaigos (specialistai);

► E. sveikatos sprendimai turi būti kuriami pagal „Service Oriented Architecture“ principus.

► Patčių taikomųjų sprendimų kūrimas turi būti grindžiamas pagal e. paslaugų paradigmą, apimančią šiuos pagrindinius elementus: paslaugos gav÷ją, paslaugos iniciavimą, paslaugos teik÷ją, paslaugos teikimo procesą, paslaugos teikimo procese naudojamus duomenis, sąveiką ir bendradarbiavimą tarp paslaugos teikimo proceso dalyvių, paslaugos rezultatą ir jo pateikimą paslaugos gav÷jui.

e. Sveikatos tikslai –Paciento perspektyva e. Sveikatos tikslai –SPĮ perspektyva

► Gauti patikimas ir kokybiškas sveikatos priežiūros paslaugas

► Būti informuotam ir lengvai pasiekti reikalingas sveikatos paslaugas

► Būti tikram dėl Sveikatos priežiūros paslaugų tęstinumo:

► Geografiškai

► Laike

► Gauti ir naudoti esamą informaciją apie pacientą laiku ir patogioje

vietoje

► Bendradarbiauti su kitomis SPĮ ir kitais sveikatos priežiūros sektoriaus

dalyviais teikiant sveikatos priežiūros paslaugas

► Didinti efektyvumą administraciniame SPĮ ir sveikatos priežiūros

sektoriaus institucijų darbe

e. Sveikatos įgyvendinimo prioritetiniai principai

► E. sveikatos paslaugų „Vienas prieigos taškas“ gyventojui ir specialistams

► Bendradarbiavimo tarp sveikatos priežiūros sektoriaus dalyvių užtikrinimas

► Vieninga prieiga prie sveikatos sektoriaus informacinių išteklių - registrų ir klasif ikatorių, e. sveikatos istorijos (ESI)

► Vieninga prieiga prie viešojo administravimo sektoriausinformacinių išteklių ir e. valdžios paslaugų

Sveikatos strategijos prioritetai

► Sveikatingumas:

► Ligų ir sveikatos problemų prevencija

► Mirtingumo ir sergamumo mažinimas

► Ekonominis sveikatinimo paslaugų efektyvumas

► Kokybiškos, saugios ir prieinamos sveikatos

priežiūros paslaugos suteikimas

e. Sveikatos įgyvendinimo uždaviniai

► Plėsti e. sveikatą, ją orientuojant į gyventoją, jo sveikatą, teikiant jam tiesiogines ir

netiesiogines (per sveikatos specialistus) paslaugas

► Valdymo, statistikos ir atsiskaitymo ataskaitų, analizės priemonių diegimas

► e. sveikatos dalyvių žinių ir gebėjimų gerinimas, pagalbos naudojant e. sveikatos priemones

teikimas ir informavimo apie e. sveikatos priemonių naudojimą užtikrinimas

► SPĮ IS diegimas, plėtra ir integravimas į nacionalinę

e. sveikatos sistemą

► Medicininių vaizdų valdymo ir telemedicinos

priemonių diegimas

► Klinikinių sprendimų palaikymo priemonių diegimas




SVEIKATOS APSAUGOS

MINISTERIJA

Įvertinus (1) esamą NESS sprendimą, naudojamą (2) techninę ir (3) taikomųjų sprendimų infrastruktūrą, (4) įgyvendintą informacijos saugos sistemą, (5) esamas duomenų mainų priemones bei realizuotas sąsajas su kitomis sistemomis, siūloma:

► Esamus NESS rezultatus pertvarkyti ir perorientuoti į e. Sveikatos paslaugų ir bendradarbiavimo

infrastruktūros informacinę sistemą (toliau - eSPBI).

► Pasiektus rezultatus (žinias, produktus, sprendimų prototipus) kiek įmanoma ir tinkama panaudoti toliau įgyvendinant eSBI.

Toliau schemoje pateikiamas siūloma funkcin÷ eSPBI funkcin÷ architektūra, pažymint, kiek esami rezultatai gali būti panaudojami jiems įgyvendinti.




SVEIKATOS APSAUGOS

MINISTERIJA

1 paveikslas. Esamų NESS rezultatų panaudojimas galimoje e. Sveikatos paslaugų ir bendradarbiavimo infrastruktūros informacin÷s sistemos įgyvendinimui2

► Pasiektų rezultatų panaudojimo galimyb÷s (apibendrintos)NESS ir koncepcinę dokumentaciją galima naudoti kaip prototipą, kuris duotų žinių apie kuriamą sprendimą ir išmoktas pamoka.

Pagrindinis toliau panaudojamo rezultato šaltinis: [NESS-1];

► Esamas NESS sprendimas, gal÷tų būti pertvarkytas į IS kūrimo ir funkcinio testavimo aplinką.

Pagrindinis toliau panaudojamo rezultato šaltinis: [NESS-1];

► Galima panaudoti turimą licencijuotą programinę įrangą.

Pagrindinis rezultato šaltinis: [NESS-1];

Pastaba: Būtų reikalingas programin÷s įrangos produktų licencijų ir palaikymo sutarčių atnaujinimas/ pratęsimas.

► Parengtų organizacinių dokumentų ir reikalavimų panaudojimas atnaujinimas, adaptavimas.

Pagrindinis rezultato šaltinis: [NESS-1][eSP TPP, SAM, NESS VP];

► Parengtų naujų teis÷s aktų ir teis÷s aktų pakeitimų projektų derinimas ir tvirtinimas.

Pagrindinis rezultato šaltinis: [eSP TPP].

Žemiau pateikiami pagrindiniai pasteb÷jimai bei rekomendacijos pagal sritis.

NESS taikomosios sistemos įgyvendinimo aspektas

► Pasteb÷jimas: Įsigytos standartin÷s programin÷s įrangos galimyb÷s n÷ra pilnai išnaudotos, pavyzdžiui, integracinei terpei realizuoti.

• Rekomendacija: NESS pasiektus rezultatus ir dokumentaciją galima naudoti kaip pradinius

rezultatus, kurie duotų žinių apie kuriamą sprendimą bei išmoktas pamokas.

• Rekomendacija: Pertvarkyti esamus NESS programin÷s įrangos sprendimus sistemos pl÷trai ir vystymui, panaudojant egzistuojančią sistemos dalių realizaciją kaip programų bibliotekas ar galimas „ištraukas“, toliau kuriant naujus programin÷s įrangos komponentus.

2 E. sveikatos paslaugų ir bendradarbiavimo infrastruktūros sistemos architektūrą sudarančių komponentų aprašymas pateikiamas 3.4. skyriuje „Siūloma e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros informacin÷s sistemos architektūra“. [NESS-1] - 2007 m. baigtas vykdyti pirmasis NESS diegimo etapas, kurio metu buvo sukurta NESS branduolio struktūra bei bandomajai eksploatacijai pateiktos 4 NESS funkcijos [eSP TPP] - ES struktūrinių fondų ir LR bendrojo finansavimo l÷šomis finansuojamo projekto „E. sveikatos paslaugos“ technin÷s pagalbos paslaugos [SAM] – Sveikatos apsaugos ministerijos parengti dokumentai [NESS VP] - NESS, naujumo, tinkamumo eksploatuoti įvertinimo ir konsultavimo pl÷tros klausimais paslaugos




SVEIKATOS APSAUGOS

MINISTERIJA

► Pasteb÷jimas: Įgyvendinant NESS nebuvo užtikrintas aiškus integracin÷s terp÷s, skirtos duomenų mainams, ir duomenų saugojimo lygmens atskyrimas nuo funkcinio (veiklos) lygmens – dabar duomenų mainų terp÷ yra orientuota į sąveiką su “NESS klientu”. Tod÷l tolimesnio NESS sprendimo, koks yra dabar, pl÷tra būtų nesuderinama su NESS prioritetine paskirtimi veikti kaip integracin÷ terp÷ ir vieningas prieigos taškas prie sveikatos sektoriaus informacinių išteklių.

• Rekomendacija: Siekiant užtikrinti vieningą prieigą prie sveikatos sektoriaus informacinių išteklių, siūlome įgyvendinti eSPBI IS integracinę terpę, skirtą centralizuotam sveikatos duomenų tvarkymui ir apsikeitimui. Klinikinių duomenų apsikeitimui rekomenduojame realizuoti HL7 v3 standartu pagrįstas duomenų mainų sąsajas su išorin÷mis sistemomis. Įgyvendinant integracinę terpę, siūlome atskirti NESS vidines sistemines paslaugas (pavyzdžiui, paslaugas skirtas NESS klientui) nuo sisteminių paslaugų skirtų išorin÷ms IS bei realizuoti integracin÷s terp÷s adapterius.

► Pasteb÷jimas: N÷ra numatytos priemon÷s NESS taikomųjų dalių našumo bei naudotojų veiksmų analiz÷s ar sistemos klaidų steb÷jimo priemon÷s. Nesant šioms priemon÷ms, neįmanoma užtikrinti tinkamą sistemos darbo steb÷seną bei atitinkamai atlikti naudotojų veiksmų auditą bei reguliuoti sistemos paj÷gumus pagal egzistuojančius ir numatomus apkrovimus.

• Rekomendacija: Rekomenduojame įgyvendinti automatines eSPBI IS sistemos veikimo steb÷senos priemones. Siekiant užtikrinti efektyvų sistemos pl÷timą naujomis administravimo, sistemos steb÷jimo, audito bei analiz÷s funkcijomis siūlome užtikrinti vieningą prieigą prie šių funkcijų.

► Pasteb÷jimas: Yra realizuotos registrų, katalogų ir klasifikatorių tvarkymo priemon÷s, tačiau n÷ra įgyvendintos priemon÷s jų sinchronizavimui su duomenų šaltiniu (pavyzdžiui, su sveikatos priežiūros įstaigų sąrašu, fizinių asmenų registru).

• Rekomendacija: Siekiant užtikrinti aktualios registrų informacijos gavimą ir pateikimą išorin÷ms informacin÷ms sistemoms panaudojant integracinę terpę, siūlome:

• Realizuoti registrų ir klasifikatorių duomenų sinchronizavimo funkcionalumą su pirminiais duomenų šaltiniais (jei eSPBI IS n÷ra pirminis duomenų šaltinis).

• Šis funkcionalumas gal÷tų būti realizuotas, įgyvendinant NESS branduolio teikiamas klasifikatorių ir registrų duomenų pateikimo ar gavimo užklausų paslaugas, kurias gal÷tų naudoti išorin÷s informacin÷s sistemos.

• Registrų ir klasifikatorių duomenų mainų sąsajos su išorin÷mis sistemomis turi būti išsamiai dokumentuotos ir viešai prieinamos arba turi būti pagrįstos standartu.




SVEIKATOS APSAUGOS

MINISTERIJA

Taikomųjų sistemų programin÷s įrangos ir sistemin÷s programin÷s įrangos aspektas

► Pasteb÷jimas: Licencijuojamos programin÷s įrangos palaikymo / atnaujinimo sutartys yra pasibaigusios, versijos pasenusios, nebepalaikomos, arba n÷ra saugios (n÷ra atnaujintos saugos pakeitimais).

• Rekomendacija: Kadangi kai kurių taikomosios programin÷s įrangos produktų vystymas ir palaikymas yra nutraukti (HP OpenView SelectAccess), tod÷l būtų reikalingas tokių komponentų pakeitimas kitais. Priklausomai nuo pasirinktos sistemos taikomosios architektūros ir technin÷s infrastruktūros sprendimo, galima būtų panaudoti turimą licencijuotą programinę įrangą, tačiau būtų poreikis programin÷s įrangos licencijų įsigijimui, licencijų atnaujinimui ar programin÷s įrangos palaikymui atnaujinti (Oracle, webMethods).

Technin÷s infrastruktūros aspektas

► Pasteb÷jimas: Esama technin÷s įrangos sąranka neatitinka aukšto veikimo patikimumo ir saugos

poreikių – esamas NESS sprendimas yra nepakankamas tenkinti nacionalinio lygmens sprendimo naudojimui keliamus reikalavimus.

• Rekomendacija: Programinių ir techninių komponentų paj÷gumai tur÷tų būti plečiami, užtikrinamas aukštas sistemos patikimumas ir sauga. Esamas NESS sprendimas, gal÷tų būti pertvarkytas į IS kūrimo ir funkcinio testavimo aplinką.

Informacin÷s sistemos organizacinis aspektas

► Pasteb÷jimas. N÷ra parengti ir/ arba patvirtinti organizaciniai bei sistemos įteisinimui reikalingi

dokumentai. Anksčiau parengta NESS dokumentacija yra techninio ir koncepcinio pobūdžio, n÷ra patvirtintų sistemos nuostatų bei informacijos saugą reglamentuojančių dokumentų, kurie apibr÷žtų atsakomybes už sistemos valdymą bei administravimą.

► Pasteb÷jimas: N÷ra įsteigtas ir įteisintas eSPBI tvarkytojas.

• Rekomendacija: Įteisinti eSPBI IS kaip valstyb÷s informacinę sistemą – atnaujinti, adaptuoti bei patvirtinti informacin÷s sistemos nuostatus bei duomenų saugos nuostatų dokumentus, reikalingus eSPBI IS įteisinimui, apibr÷žiant sistemos valdytoją, tvarkytoją bei jų pareigas ir atsakomybes. Įsteigti ir įteisinti eSPBI tvarkytoją. Taip pat parengti ir patvirtinti, kitus saugą reglamentuojančius dokumentus, apibr÷žiant informacijos klasifikavimo, rizikos vertinimo, sistemos patikimumo bei informacijos saugos lygio bei priemonių nustatymo ir įgyvendinimo aspektus. Įgyvendinti ir įteisinti organizacines ir technines saugos priemones, numatyti steb÷senos priemones informacijos atitikčiai užtikrinti.

Teisinis aspektas




SVEIKATOS APSAUGOS

MINISTERIJA

► Pasteb÷jimas: Teisin÷ elektronin÷s sveikatos bei duomenų tvarkymo elektroniniu būdu baz÷ n÷ra parengta. N÷ra patvirtinti teis÷s aktai, reglamentuojantys elektroninių sveikatos duomenų

tvarkymą.

• Rekomendacija: Patvirtinti su sveikatos duomenų tvarkymui elektroniniu būdu reglamentuoti reikalingus teis÷s aktus.

• Rekomendacija: Parengti ir patvirtinti teisinę bazę, reikalingą e. sveikatos paslaugų teikimui. Pritaikyti egzistuojančius teis÷s aktus, reglamentuojant e. sveikatos paslaugų teikimą.

Pl÷tros prioritetų aspektas

► Rekomendacija: Sutelkti d÷mesį žemiau išvardintiems bazin÷s infrastruktūros pradinio panaudojimo taikomiesiems sprendimams:

• gydytojo ir paciento sąryšio fakto ir rezultato registravimas bazin÷je elektronin÷je sveikatos

istorijoje (ESI);

• siuntimų konsultacijai, gydymui ar tyrimui elektronin÷ paslauga;

• sukuriama medicininių vaizdų sistemos pradin÷ infrastruktūra.

Atkreiptinas d÷mesys, kad šių taikomųjų sprendimų diegimui būtinas bazin÷s bendro naudojimo infrastruktūros sukūrimas, apimantis: • E. sveikatos portalo (paslaugų katalogo gyventojams (pacientams) ir į jį įtrauktos prieigos

prie kitų sveikatos sektoriaus institucijų ir dalyvių e. paslaugų) sukūrimą;

• Bazin÷s ESI (pagal CDA level-1), ), dokumentų saugyklos ir dokumentų nuorodų saugyklos įgyvendinimą ir esamų SPĮ IS prijungimą duomenims į ESI teikti;

• Bazinei ESI būtinų sveikatos sektoriaus registrų, katalogų ir klasifikatorių sukūrimą ir įteisinimą;

• Prieigos prie viešojo administravimo informacinių išteklių ir e. valdžios paslaugų sukūrimą.

e. Sveikatos programos įgyvendinimo organizavimas ir s÷km÷s užtikrinimas

E. sveikatos iniciatyvų įgyvendinimui turi būti paskirtas aiškus programos įgyvendinimo savininkas ir vykdytojas – Projektų įgyvendinimo biuras (PMO - angl. Project management office)

► PMO SAM viduje arba juridinis subjektas prie SAM, kurio galimos funkcijos yra šios:

• Programos lygmenyje – efektyviam programos valdymui ir vykdymui:

• Darbo grupių darbo organizavimas;

• Pažangos steb÷sena, ataskaitų rengimas ir pagalba pristatant;




SVEIKATOS APSAUGOS

MINISTERIJA

• Programos projektų eigos ir jų rezultatų tarpusavio koordinavimas ir derinimo kontrol÷.

• Projektų lygmenyje – kokybiškam programos projektų vykdymui ir tarpusavio derinimui:

• Vykdymo technin÷ priežiūra ir kokyb÷s užtikrinimas;

• Technin÷ pagalba projektų vykdytojams (įstaigoms);

• Aiškus specifikavimo ir projektavimo fazių atskyrimas nuo konstravimo (programavimo) ir diegimo;

• Veiklos pokyčių įgyvendinimo priežiūra.

• Efektyvus informacijos apie rezultatus pateikimas į viešąją erdvę:

• Viešinimas pagal parengtą viešinimo planą;

• Vidin÷s komunikacijos (tarp įstaigų) vykdymas;

• Neigiamos informacijos (“krizių”) valdymas.

• Efektyvus ir skaidrus viešųjų pirkimų vykdymas

• Kokybiškų pirkimo sąlygų ir techninių specifikacijų parengimas;

• Technin÷ pagalba atsakant į tiek÷jų užklausimus ir nagrin÷jant pretenzijas;

• Operatyvus techninių pasiūlymų vertinimas;

• Projektų sutarčių vykdymo priežiūra.

Galimi greiti pasiekimai per 2010 – 2011 metus

► 2010 metais gyventojams matomas greitas pasiekimas - į pacientus orientuoto portalo sukūrimas:

• Pateikiama viena prieiga prie esamų e. sveikatos paslaugų (pavyzdžiui, VLK teikiama e. paslauga apie suteiktas sveikatinimo paslaugas, finansuotas iš PSDF, būtų prieinama, pavyzdžiui, www.esveikata.lt);

• Informacija apie įstaigas ir specialistus;

• Aktuali informacija sveikatinimo klausimais (pvz. kaip apsisaugoti nuo gripo);

• Informacija apie e. Sveikatos programos vykdymą.

► 2011 metais:

• bazin÷s ESI ir vieningos prieigos prie registrų, katalogų ir klasifikatorių sukūrimas – būtinas ir veikiantis pagrindas e. sveikatos paslaugų pl÷trai;

• Gydytojo ir paciento sąryšio fakto ir rezultato registravimas bazin÷je ESI;




SVEIKATOS APSAUGOS

MINISTERIJA

• Siuntimų konsultacijai, gydymui ar tyrimui elektronin÷ paslauga.




SVEIKATOS APSAUGOS

MINISTERIJA

1.1.1.1. ĮvadasĮvadasĮvadasĮvadas

2009 m. spalio 14 d. Lietuvos Respublikos sveikatos apsaugos ministerija ir UAB „Ernst & Young Baltic” pasiraš÷ Paslaugų teikimo sutartį Nr. S-266 d÷l nacionalin÷s elektronin÷s sveikatos sistemos sprendimo, naujumo, tinkamumo eksploatuoti įvertinimo ir konsultavimo pl÷tros klausimais paslaugų.

Šio Projekto etapo, Esamos situacijos, taikomųjų e. sveikatos paslaugų uždavinių ir e. sveikatos standartų įvertinimo ir rekomendacijų ataskaitos rengimo, metu buvo įvertintas esamas NESS sprendimas, atsižvelgiant į naudojamą techninę ir taikomųjų sprendimų infrastruktūrą, įgyvendintą informacijos saugos sistemą, esamus duomenų mainus bei realizuotas sąsajas su kitomis sistemomis. Įvertinus esamą situaciją buvo parengti pasteb÷jimai ir rekomendacijos sprendimui tobulinti. Taip pat išanalizuoti ir pateikti taikytini elektronin÷s sveikatos srities standartai.

Ši ataskaita parengta remiantis Sutarties reikalavimais. Ataskaitos paskirtis – pateikti NESS sprendimo įvertinimo bei standartų apžvalgos aprašymą. Įvertinus pasteb÷jimus, siekiamus tikslus bei gerąsias praktikas, parengti pasiūlymai ir rekomendacijos NESS sprendimo techninei infrastruktūrai, taikomųjų sprendimų infrastruktūrai, duomenų mainams ir informacijos saugos architektūrai tobulinti.

Susijusių dokumentų ir informacijos šaltinių, kuriais remiantis buvo parengta ši ataskaita, sąrašas pateikiamas Priede Nr. 9.




SVEIKATOS APSAUGOS

MINISTERIJA

2.2.2.2. Taikomieji e.Taikomieji e.Taikomieji e.Taikomieji e. sveikatossveikatossveikatossveikatos paslaugųpaslaugųpaslaugųpaslaugų uždaviniai ir uždaviniai ir uždaviniai ir uždaviniai ir e. sveikatos paslaugų ir bendradarbiavimo e. sveikatos paslaugų ir bendradarbiavimo e. sveikatos paslaugų ir bendradarbiavimo e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros infrastruktūros infrastruktūros infrastruktūros vizijavizijavizijavizija

2.1.2.1.2.1.2.1. Vertinimo metodika bei atlikti darbaiVertinimo metodika bei atlikti darbaiVertinimo metodika bei atlikti darbaiVertinimo metodika bei atlikti darbai Siekiant įvertinti strateginius e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros prioritetus bei nustatyti prioritetinių taikomųjų e. sveikatos paslaugų uždavinius, Ernst & Young pateik÷ pastabas bei pasiūlymus e. sveikatos programai [21] bei priemonių planui [22]. E. sveikatos programa ir priemonių planas apima pagrindinius e. sveikatos tikslus ir uždavinius, nusako kontekstą, būdus ir priemones, kaip efektyviai panaudoti informaciją gyventojų sveikatai gerinti ir sveikatos priežiūros paslaugų kokybei užtikrinti. E. sveikatos programai teikiami pastabos ir pasiūlymai ap÷m÷:

► e. sveikatos programos tikslų ir uždavinių nustatymą bei tikslų ir uždavinių formuluočių patikslinimą;

► e. sveikatos programos įgyvendinimo etapų apibr÷žimą bei pagrindiniu šių etapų metu atliekamus veiksmus, siekiant užtikrinti evoliucinę Lietuvos e. sveikatos sistemos pl÷trą;

► naujų SPĮ IS diegimo, ar esamų SPĮ IS pl÷tros projektų įgyvendinimo alternatyvų nustatymą bei finansavimo galimybių aprašymą.

Priemonių plane nurodytiems uždaviniams, Ernst & Young pasiūlymai ap÷m÷:

► naujų uždavinių įtraukimą ar esamų pašalinimą;

► keistinas uždavinių formuluotes;

► uždavinio svarbos nurodymą (išreiškiamas per laikotarpį, kuriame turi būti įgyvendinamas uždavinys) bei nustatytų uždavinių vertinimą toliau šiame skyriuje nurodytais kriterijais;

► uždavinio įgyvendinimo trukmes;

► uždavinio sąsajas su kitomis informacin÷mis sistemomis. Strateginių e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros prioritetų vertinimo metu, e. sveikatos programa bei priemonių planas buvo peržiūr÷ti ir pasiūlyti patikslinimai programos ir plano suderinamumui tarpusavyje. Tikslinant programą bei priemonių planą buvo atsižvelgta į kitų institucijų pateiktas pastabas bei susitikimų su SAM atstovais metu išsakytas nuomones.

Žemiau apibendrintai pateikiami SAM pristatyti e. sveikatos tikslai ir įgyvendinimo principai, siūlomi įgyvendinimo etapai ir galima e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros sistemos architektūros vizija. Jais remiantis buvo parengti siūlymai ir rekomendacijos d÷l esamo NESS sprendimo taikomųjų sistemų architektūros pakeitimų ir papildomos taikomosios programin÷s įrangos įsigijimų, duomenų mainų, technin÷s infrastruktūros ir informacijos teikimo ir tvarkymo saugos architektūros.




SVEIKATOS APSAUGOS

MINISTERIJA

2.1.1.2.1.1.2.1.1.2.1.1. Priemonių plane pateiktų uždavinių vertinimasPriemonių plane pateiktų uždavinių vertinimasPriemonių plane pateiktų uždavinių vertinimasPriemonių plane pateiktų uždavinių vertinimas Priemonių plane nurodyti uždaviniai buvo įvertinti tokiais kriterijais:

► Poveikis: • Sveikatingumui; • Ekonominei naudai; • Patogumui / pasiekiamumui.

► Reikalingos pastangos: • Dalyvaujančių institucijų skaičius; • Darbų apimtis; • Reglamentavimo sud÷tingumas.

Atlikus įvertinimą, buvo nustatyta, kad esamame e. sveikatos priemonių plane didel÷ dalis rezultatų reikalauja didelių pastangų per 6 metų laikotarpį, kuris, lyginant su siekiamų rezultatų apimtimi, n÷ra ilgas. Per trumpą laikotarpį įgyvendinamų rezultatų bendra apimtis taip pat ambicinga, tačiau tik÷tinai su žymiu postūmiu e. Sveikatos pl÷trai. 1 lentel÷je yra pateikiamas nustatytų taikomųjų e. sveikatos paslaugų uždavinių įvertinimas pagal aukščiau šiame skyriuje išvardintus kriterijus ir realizuotinus pirmame e. sveikatos programos įgyvendinimo etape (žr. šio dokumento 3.3 skyriuje) 1 lentel÷. Taikomųjų uždavinių vertinimas Taikomojo uždavinio formuluote

Trukm÷ Poveikis (nauda)

Pastangos Sąsajos su kitomis IS

Gydytojo ir paciento sąryšio fakto ir rezultato registravimas bazin÷je ESI.

1 metai Aukštas (patogumui / pasiekiamumui)

Žemos (dalyvaujančių institucijų skaičius, darbų apimtis)

SPĮ IS, VAIISIS SVEIDRA (tolimesniuose etapuose, kai bus įgyvendinamas apsilankymo informacijos (diagnoz÷s, gydymo ir kt.) registravimas paciento ESI

Siuntimų konsultacijai, gydymui ar tyrimui elektronin÷ paslaugos I etapas: orientuota į siuntimus iš pirminio į antrinį ir tretinį lygius, be grįžtamojo ryšio, pagal siuntimą suteiktos paslaugos rezultatams pateikti

1 metai Aukštas (ekonominei naudai, patogumui / pasiekiamumui)

Žemos (darbų apimtis, reglamentavimo sud÷tingumas)

SPĮ IS, Laboratorijos IS SVEIDRA




SVEIKATOS APSAUGOS

MINISTERIJA

Medicininių vaizdų sistemos pradin÷ infrastruktūra

1 metai Aukštas (ekonominei naudai, patogumui / pasiekiamumui)

Aukštos (dalyvaujančių institucijų skaičius, darbų apimtis)

SPĮ IS VAIISIS SVEIDRA Vaistin÷s IS

2.2.2.2.2.2.2.2. EEEE. sveikatos tikslai ir įgyvendinimo . sveikatos tikslai ir įgyvendinimo . sveikatos tikslai ir įgyvendinimo . sveikatos tikslai ir įgyvendinimo principaiprincipaiprincipaiprincipai Lentel÷je pateikiami pagrindiniai e. sveikatos tikslai ir įgyvendinimo principai. 2 lentel÷. E. sveikatos tikslai ir įgyvendinimo principai

Sveikatos strategijos prioritetai ► Sveikatingumas:

• Ligų ir sveikatos problemų prevencija; • Mirtingumo ir sergamumo mažinimas; • Ekonominis sveikatinimo paslaugų efektyvumas; • Kokybiškos, saugios ir prieinamos sveikatos priežiūros paslaugos suteikimas.

e. Sveikatos tikslai – Paciento perspektyva e. Sveikatos tikslai – SPĮ perspektyva ► Gauti patikimas ir kokybiškas sveikatos

priežiūros paslaugas; ► Būti informuotam ir lengvai pasiekti

reikalingas sveikatos paslaugas; ► Būti tikram d÷l Sveikatos priežiūros

paslaugų tęstinumo: • Geografiškai; • Laike.

► Gauti ir naudoti esamą informaciją apie pacientą laiku ir patogioje vietoje;

► Bendradarbiauti su kitomis SPĮ ir kitais sveikatos priežiūros sektoriaus dalyviais teikiant sveikatos priežiūros paslaugas;

► Didinti efektyvumą administraciniame SPĮ ir sveikatos priežiūros sektoriaus institucijų darbe.

e. Sveikatos įgyvendinimo prioritetiniai principai

► E. sveikatos paslaugų „Vienas prieigos taškas“ gyventojui ir specialistams;

► Bendradarbiavimo tarp sveikatos priežiūros sektoriaus dalyvių užtikrinimas;

► Vieninga prieiga prie sveikatos sektoriaus informacinių išteklių - registrų ir klasifikatorių, e. sveikatos istorijos (ESI);

► Vieninga prieiga prie viešojo administravimo sektoriaus informacinių išteklių ir e. valdžios paslaugų, įgyvendinant sąveiką tarp e. Sveikatos paslaugų ir bendradarbiavimo infrastruktūros ir Viešojo administravimo institucijų informacinių sistemų interoperabilumo sistemos (VAIISIS).

e. Sveikatos įgyvendinimo uždaviniai




SVEIKATOS APSAUGOS

MINISTERIJA

► Pl÷sti e. sveikatą ją orientuojant į gyventoją, jo sveikatą, teikiant jam tiesiogines ir netiesiogines (per sveikatos specialistus) paslaugas;

► Valdymo, statistikos ir atsiskaitymo ataskaitų, analiz÷s priemonių diegimas;

► e. sveikatos dalyvių žinių ir geb÷jimų gerinimas, pagalbos naudojant e. sveikatos priemones teikimas ir informavimo apie e. sveikatos priemonių naudojimą užtikrinimas;

► SPĮ IS diegimas, pl÷tra ir integravimas į nacionalinę e. sveikatos sistemą;

► Medicininių vaizdų valdymo ir telemedicinos priemonių diegimas;

► Klinikinių sprendimų palaikymo priemonių diegimas.

2.3.2.3.2.3.2.3. E. sveikatos uždavinių E. sveikatos uždavinių E. sveikatos uždavinių E. sveikatos uždavinių įgyvendinimo etapaiįgyvendinimo etapaiįgyvendinimo etapaiįgyvendinimo etapai Atsižvelgiant į e. sveikatos tikslų ir uždavinių svarbą, siūloma priemonių planą įgyvendinti dviem etapais. Siūlomi e. sveikatos priemonių įgyvendinimo etapai: I etapas 2010 – 2011 m.

► Būtinos bazin÷s bendro naudojimo infrastruktūros sukūrimas: sukuriamos technologin÷s, organizacin÷s ir metodin÷s priemon÷s e. sveikatos paslaugoms ir sveikatos sektoriaus dalyvių bendradarbiavimui. Rezultatas:

• Sukurtas e. sveikatos portalas: paslaugų katalogas gyventojams (pacientams) ir į jį įtraukta prieiga prie kitų sveikatos sektoriaus institucijų ir dalyvių e. paslaugų;

• Sukurta Bazin÷ ESI: (pagal CDA level-1), dokumentų saugyklos ir dokumentų nuorodų saugyklos įgyvendinimą ir esamų SPĮ IS prijungimą duomenims į ESI teikti;

• Sukurti ir įteisinti bazinei ESI būtini sveikatos sektoriaus registrai, katalogai ir klasifikatoriai;

• Sukurta prieiga prie viešojo administravimo sektoriaus informacinių išteklių ir e. valdžios paslaugų.

► Sukuriamos bazin÷s bendro naudojimo infrastruktūros pradinis panaudojimas taikomiesiems sprendimams. Rezultatai:

• Gydytojo ir paciento sąryšio fakto ir rezultato registravimas bazin÷je ESI;

• Siuntimų konsultacijai, gydymui ar tyrimui elektronin÷ paslauga (pirmas etapas - žr. Programos įgyvendinimo priemonių planą);

• Sukuriama medicininių vaizdų sistemos pradin÷ infrastruktūra.




SVEIKATOS APSAUGOS

MINISTERIJA

II etapas 2012 - 2015

► Įgyvendinamos naujos e. sveikatos paslaugos ir taikomieji e. Sveikatos sprendimai:

• Sukurtos naujos interaktyvios ir tarpinstitucin÷s e. sveikatos paslaugos gyventojams ir sveikatos priežiūros specialistams;

• Sukurti ir įteisinti nauji sveikatos sektoriaus registrai ir klasifikatoriai ar prieiga prie jų.

► Įgyvendinamos aukštesnio sud÷tingumo e. sveikatos paslaugos ir taikomieji e. Sveikatos sprendimai:

• Prapl÷sta ir labiau struktūrizuota ESI, apimanti antrą ir trečią lygius pagal CDA (CDA level-2 ir level-3);

• Įgyvendintos aukštesnio sud÷tingumo interaktyvios ir tarpinstitucin÷s e. sveikatos paslaugos gyventojams ir sveikatos priežiūros specialistams (pavyzdžiui, siuntimas su rezultato grąžinimu).

► Sukuriamos kitos, daugiau pastangų reikalaujančios, priemon÷s (pavyzdžiui, analitin÷s);

► Pradedama vykdyti e. sveikatos paslaugų ir bendradarbiavimo tarp įstaigų priemonių sklaida – vykdomas SPĮ prijungimas prie vieningos sistemos:

• SPĮ informaciniai ištekliai (pavyzdžiui, vaizdų saugyklos) ar SPĮ informacin÷s sistemos (palaipsniui) sujungiamos su e. Sveikatos paslaugų ir bendradarbiavimo infrastruktūra:

ｇ per duomenų mainų terpę duomenų mainams tarp SPĮ tvarkomų EMI ir ESI vykdyti;

ｇ prieigai prie medicininių vaizdų.

• SPĮ (palaipsniui) prijungiamos prie sukurtų e. sveikatos paslaugų.

2.4.2.4.2.4.2.4. Siūloma e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros informacin÷s Siūloma e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros informacin÷s Siūloma e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros informacin÷s Siūloma e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros informacin÷s sistemos architektūrasistemos architektūrasistemos architektūrasistemos architektūra

Toliau paveiksl÷lyje pateikiama galima e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros informacin÷s sistemos architektūra, parengta atsižvelgiant į e. sveikatos pl÷tros programą bei priemonių planą, siūlomus e. sveikatos tikslus bei jų įgyvendinimo principus bei etapus. Kaip numatyta priemonių įgyvendinimo etapuose, siūloma pirma parengti bazinę bendro naudojimo infrastruktūrą, v÷liau prie jos jungiant naujas paslaugas bei priemones, pagal pl÷tros poreikius. Svarbu: tolimesniuose e. Sveikatos pl÷tros etapuose siūloma atsisakyti NESS sąvokos ir naudoti e. Sveikatos paslaugų ir bendradarbiavimo infrastruktūros – eSPBI – sąvoką. Atitinkamai NESS sąvoka naudotina vertinant esamą ir buvusią pad÷tį e. sveikatos kontekste.




SVEIKATOS APSAUGOS

MINISTERIJA

2 paveikslas. Galima e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros sistemos architektūros vizija

Toliau pateikiamas apibendrintas architektūros funkcinių komponentų aprašymas. 3 lentel÷. Funkciniai komponentai

Komponentas Aprašymas

1. Portalas:

Kompiuterinių priemonių visuma, skirta įgyvendinti “vieno langelio” prieigos principą gyventojams ir sveikatos priežiūros specialistams. Portalas naudojamas e. sveikatos sistemoje įgyvendintų e. paslaugų vykdymo steb÷jimui, informavimui/ komunikavimui. Jis turi veikti kaip terp÷, kurioje yra atliekama naudotojo identifikacija ir kurioje




SVEIKATOS APSAUGOS

MINISTERIJA


naudotojui yra pateikiamas skaitmeninis turinys pagal Autorizacijos funkcinio komponento nustatytas prieigos teises.

1.1. ► gyventojų sritis Komponentas, realizuojantis e. sveikatos paslaugų, skirtų gyventojams, teikimą „vieno langelio“ principu.

1.2. ► sveikatos priežiūros specialistų sritis

Komponentas, realizuojantis e. sveikatos paslaugų, skirtų sveikatos priežiūros specialistams, teikimą „vieno langelio“ principu.

2. E. paslaugos e. sveikatos sistemoje įgyvendintų paslaugų, prieinamų elektronin÷mis priemon÷mis, sąrašas. Pagal poreikį, paslaugų sąrašas gali būti plečiamas, prijungiant naujas e. paslaugas.

3. Taikomieji sprendimai Techninių ir programinių priemonių visuma, kuri leidžia sveikatos priežiūros sektoriaus, neturinčiomis savo informacinių sistemų, naudotis e. sveikatos sistemos funkcijomis.

4. E. paslaugų teikimo funkcinis komponentas

Kompiuterinių priemonių visuma, įgalinanti ir palaikanti paslaugų teikimo procesą. E. paslaugų teikimo funkcinis komponentas yra terp÷, kurioje vyksta sąveika tarp paslaugos gav÷jo, paslaugos teik÷jo ir sistemos, t.y. kur yra inicijuojamas paslaugų teikimas (suformuojama užduotis), pateikiami rezultatai, vyksta komunikavimas (apsikeičiama informacija) ir paslaugos teikimo būkl÷s steb÷sena ir/ ar pateikiami suteiktos paslaugos rezultatai bei yra vykdomi ar yra užtikrinamas vyksmas tų veiklos procesų, kurie yra susiję su paslaugų teikimu. Paslaugų teikimo funkcinis komponentas pateikia visas reikalingas priemones paslaugoms suteikti ir užtikrina paslaugų teikimo proceso vyksmą pagal nustatytas taisykles ir reikalavimus.

4.1. ► Procesų ir darbo sekų valdymas

Funkcinis komponentas, užtikrinantis nustatytų veiklos procedūrų (žingsnių) vykdymo eiliškumą, paskirstymą (dalyvaujantiems naudotojams ir kitoms sistemoms per duomenų mainų platformą), vykdymo savalaikiškumą ir nustatymų lankstumą.




SVEIKATOS APSAUGOS

MINISTERIJA


4.2. ► Dokumentinių įrašų

valdymas Funkcinis komponentas, užtikrinantis duomenų/ dokumentų, dalyvaujančių paslaugos teikimo procese, tvarkymo funkcionalumą.

5. Informaciniai ištekliai E. sveikatos sistemoje tvarkoma, saugoma, apdorojama ar teikiama informacija, susijusi su sveikatos priežiūros paslaugų teikimu bei tam naudojamų priemonių visuma. Pagrindinis informacinių išteklių ir jų tvarkymo komponentas yra ESI. Informaciniai ištekliai apima šiuos e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros IS katalogus ir klasifikatorius: ► Pacientų katalogas; ► SPĮ klasifikatorius; ► Sveikatos priežiūros specialistų katalogas.

5.1. ESI informacin÷ sistema Šis funkcinis komponentas aprašomas, apibr÷žiant Aktų

katalogo ir Aktų nuorodų katalogų komponentus.

5.1.1. Aktų katalogas, įskaitant dokumentų saugyklą

Funkcinis komponentas skirtas saugoti sveikatos priežiūros veiksmų duomenis ir dokumentus tais atvejais, jei jie n÷ra saugomi sveikatos paslaugų teik÷jo infrastruktūroje (pvz. SPĮ IS). Aktų katalogas apima ir dokumentų saugyklą, nes Aktu gali būti ir sveikatos priežiūros įvykio rezultatas - dokumentas.

5.1.2. Aktų nuorodų katalogas, įskaitant dokumentų nuorodų saugyklą

Pagrindinis ESI funkcinis komponentas. Šio komponento paskirtis: ► Nuorodų į sveikatos priežiūros veiksmus - Aktus

saugojimas; ► Meta duomenų, tokių kaip sveikatos priežiūros

veiksmų tipas, laiko aspektai, saugojimas; ► Sąryšių (tokių kaip paciento ir sveikatos priežiūros

specialisto) saugojimas; ► „Akto – Akto“ sąryšių (pvz. laboratorinio tyrimo

siuntimo ir atsakymo) saugojimas; • Pagrindinių sąveikų valdymas: • Aktų nuorodos pranešimo aktyvavimas; • Aktų nuorodos pranešimo patikslinimas; • Aktų nuorodos pranešimo anuliavimas; • Aktų nuorodų katalogo elemento paieška; • Aktų nuorodos katalogo elemento paieškos




SVEIKATOS APSAUGOS

MINISTERIJA


atsakymas. Sąveikos su kitais komponentais, pavyzdžiui, dokumentų saugykla, ir pacientų katalogu, užtikrinimas.

5.2. Terminologijos paslaugų teikimas

Funkcinis komponentas naudojamas semantiniam interoperabilumui (sąveikumui) užtikrinti. Šio komponento paskirtis – užtikrinti bazinių terminologijos paslaugų teikimą, remiantis CTS (Bendrų terminologijos paslaugų) standartu. Tolimesniuose e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros vystymo etapuose galimas šio komponento funkcionalumo pl÷timas nuo reikšmių aibių bei kodo sistemų užklausų ir pateikimo iki kodų sistemų palaikymo ir tarpusavio susiejimo.

5.3. Objektų ID katalogas Unikalių objektų identifikatorių katalogas, kuris apima pagrindines sąveikas objektų identifikatorių, naudojamų eSPBI, informacijos pateikimui.

6. Duomenų mainų terp÷ Informacinių ir ryšių technologijų pagalba realizuota sistemin÷ aplinka, užtikrinanti duomenų mainus tarp informacinių sistemų paslaugų teikime.

7. E. paslaugų kūrimas ir konfigūravimas:

Priemon÷s e. paslaugoms kurti ir valdyti.

7.1. ► Paslaugų ir procesų gyvavimo ciklo valdymas

Funkcinis komponentas, užtikrinantis atliekamų paslaugų ir jų procesų apibr÷žimų kūrimą ir jų valdymą per visą jų gyvavimo ciklą. Šis funkcinis komponentas turi suteikti priemones, įgalinančias realizuoti šiuos paslaugų ir procesų etapus: ► Paslaugų specifikavimas; ► Paslaugų konstravimas; ► Paslaugų publikavimas; ► Paslaugų sustabdymas.

7.2. ► Turinio valdymas Funkcinis komponentas, skirtas skaitmeninio turinio, sudaryto pagal apibr÷žtas e. paslaugas ir jų procesus, valdymui bei turinio (įskaitant informacinio pobūdžio), parengto pagal apibr÷žtas e. paslaugas ir jų procesus, pateikimui į portalo terpę.

7.3. ► Duomenų mainų terp÷s valdymas

Priemon÷s, skirtos duomenų mainų su išorin÷mis sistemomis apibr÷žimui, nustatymui ir metaduomenų tvarkymui.




SVEIKATOS APSAUGOS

MINISTERIJA


8. Duomenų sauga Kompiuterinių priemonių visuma, užtikrinanti saugos ir tapatyb÷s valdymo funkcionalumą.

8.1. ► Autentikavimas Funkcinis komponentas, realizuojantis sistemos naudotojo tapatyb÷s nustatymą skaitmenin÷mis priemon÷mis.

8.2. ► Autorizacija Autorizacijos funkcinis komponentas, realizuojantis mechanizmą, užtikrinantį tinkamos prieigos prie informacijos kontrolę tiek Portale, tiek kituose sistemos komponentuose, ir teikiantis priemones prieigos kontrolių nustatymui.

9. Sistemos valdymas Kompiuterinių priemonių visuma, skirta sistemos nustatymų valdymui bei sistemos darbo techniniame lygmenyje steb÷senai ir auditui atlikti.

9.1. Administravimas Techniniai įrankiai ir priemon÷s, užtikrinančios sistemos valdymo galimybes.

9.2. Steb÷sena Funkcinis komponentas, užtikrinantis sistemoje vykstančių techninių/ sisteminių procesų steb÷seną.

9.3. Auditas Funkcinis komponentas, skirtas duomenų (reikalingų audito tikslais) apie vykstančius sisteminius ir paslaugų teikimo procesus fiksavimui.

9.4. Archyvavimas Funkcinis komponentas, įgalinantis sistemos įrašų archyvavimą.

9.5. Rezervinis kopijavimas Komponentas skirtas programin÷s įrangos, duomenų bazių valdymo sistemų ir informacinių sistemų, kitos svarbios informacijos periodinių kopijų darymui. Kopijos naudojamos avarijų, technin÷s sistemin÷s programin÷s įrangos gedimų ar kitų incidentų atvejais, kad būtų galima atstatyti sistemos veikimą ar duomenis.




SVEIKATOS APSAUGOS

MINISTERIJA

3.3.3.3. NESS funkcijų realizavimui naudotos taikomųjų sistemų architektūros įvertinimasNESS funkcijų realizavimui naudotos taikomųjų sistemų architektūros įvertinimasNESS funkcijų realizavimui naudotos taikomųjų sistemų architektūros įvertinimasNESS funkcijų realizavimui naudotos taikomųjų sistemų architektūros įvertinimas

Atsižvelgiant į tai, kad NESS sprendimo projektin÷ dokumentacija buvo prad÷ta rengti daugiau nei prieš keturis metus (2005-2006 metais) bei į informacinių technologijų vystymosi ir pl÷tros spartą, buvo vertinama, ar suprojektuoti (ir įgyvendinti) taikomųjų sistemų architektūros sprendimai:

► atitinka dabartines, šiuo metu egzistuojančias taikomosios architektūros tendencijas;

► gali būti panaudojami ateityje, besivystant technologiniams modeliams ar keičiantis NESS taikomųjų sistemų architektūrai.

Šiame skyriuje yra pateikiamas atlikto NESS taikomųjų sistemos architektūros įvertinimo aprašymas – esamos situacijos įvertinimas naujumo, praktinio pritaikomumo ir plečiamumo aspektais.

3.1.3.1.3.1.3.1. Vertinimo metodika bei atlikti darbaiVertinimo metodika bei atlikti darbaiVertinimo metodika bei atlikti darbaiVertinimo metodika bei atlikti darbai

NESS taikomųjų sistemos architektūros vertinimo metu buvo:

► Išanalizuoti esami NESS sistemos architektūrą aprašantys dokumentai ([2, 3, 7, 10]);

► Išanalizuoti esami NESS programin÷s įrangos išeities tekstai;

► Panaudota informacija, gauta organizuojant pokalbius su:

• SAM atstovu Mindaugu Mineikiu, 2009 11 10;

• KMUK atstovu Vyteniu Puniu, 2009 11 19;

• KUL atstovu Virgilijumi Vanagu, 2009 11 24;

• SANTA atstovu Romualdu Kizlaičiu, 2009 11 17;

• VLK atstovu Justinu Vyšniausku, 2009 11 20.

NESS taikomųjų sistemų vertinimui atlikti, buvo remtasi tarptautiniame standarte ISO 9126 apibr÷žtu programin÷s įrangos kokyb÷s vertinimo modeliu bei AEF (angl. Architecture Evaluation Framework) standarto rekomendacijomis.

Atlikus ekspertinį esamos NESS taikomųjų sistemų architektūros vertinimą, buvo nustatyti ir šiame skyriuje aprašyti:

► architektūros atitikimas taikomiesiems uždaviniams, aprašytiems 3 skyriuje (eSPBI vizijai);

► architektūros atitikimas vyraujančioms taikomosios architektūros modeliams ir jų tendencijoms;

► architektūros moduliarumo ir plečiamumo galimyb÷s;

► sistemos ankstesnių funkcijų palaikymas, modifikuojant esamas arba įgyvendinant naujas funkcijas (angl. „backward compatibility“);

► taikomųjų programų darbo našumo rodiklių steb÷jimo galimyb÷s;




SVEIKATOS APSAUGOS

MINISTERIJA

► sistemos veiksmų steb÷senos vykdymo galimyb÷s.

Taip pat vertinimo metu buvo parengtas taikomųjų sistemų architektūros katalogas, kuriame pateikiamas apibendrintas NESS taikomosios architektūros komponentų aprašymas (žr. 1 priedą „IS katalogas“).

3.2.3.2.3.2.3.2. Pagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimai Atlikus esamo NESS funkcijų įgyvendinimui naudotos taikomųjų sistemų įvertinimą buvo išskirti tokie esminiai pasteb÷jimai:

► NESS pasiektus rezultatus ir dokumentaciją galima naudoti kaip pradinius rezultatus, kurie duotų žinių apie toliau įgyvendintiną sprendimą ir išmoktas pamokas – sprendimo įgyvendinimo ir naudojimo metu padarytas išvadas, nustatyti galimus veiksmai ar įgytą patirtis, kurią panaudojus įgyvendinant panašius ar vystant esamus sprendimus būtų pagerinta sprendimo kokyb÷, darbų efektyvumas, laiku identifikuojamos rizikos ar sumažinama jų įtaka.

► Įsigytos standartin÷s programin÷s įrangos galimyb÷s (galimyb÷s n÷ra pilnai išnaudotos (pavyzdžiui, integracinei terpei realizuoti).

► Įgyvendinant NESS nebuvo užtikrintas aiškus integracin÷s terp÷s, skirtos duomenų mainams, ir duomenų saugojimo lygmens atskyrimas nuo funkcinio (veiklos) lygmens– dabar duomenų mainų terp÷ yra orientuota į sąveiką su “NESS klientu”. Tod÷l tolimesnio NESS sprendimo, koks yra dabar, pl÷tra būtų nesuderinama su NESS prioritetine paskirtimi veikti kaip integracin÷ terp÷ ir vieningas prieigos taškas prie sveikatos sektoriaus informacinių išteklių.

► Licencijuojamos programin÷s įrangos palaikymo / atnaujinimo sutartys yra pasibaigusios, versijos pasenusios, n÷ra saugios (n÷ra atnaujintos saugos pakeitimais), kai kurių taikomosios programin÷s įrangos produktų vystymas ir palaikymas yra nutraukti (pavyzdžiui, HP OpenView SelectAccess), tod÷l pasirinkus sprendimo pl÷tros esamų produktų pagrindu alternatyvą būtų reikalingas tokių komponentų pakeitimas kitais bei poreikis programin÷s įrangos licencijų įsigijimui,

atnaujinimui, programin÷s įrangos palaikymo sutarčių atnaujinimui.

► N÷ra numatytos NESS taikomųjų dalių našumo bei naudotojų veiksmų analiz÷s ar sistemos klaidų steb÷jimo priemon÷s. Nesant šioms priemon÷ms, neįmanoma užtikrinti tinkamą sistemos

darbo steb÷seną bei atitinkamai atlikti naudotojų veiksmų auditą bei reguliuoti sistemos paj÷gumus pagal egzistuojančius ir numatomus apkrovimus.

Žemiau esančioje lentel÷je yra detalizuojami pagrindiniai pasteb÷jimai d÷l esamo NESS funkcijų įgyvendinimui naudotų taikomųjų sistemų.

4 lentel÷. NESS funkcijų realizavimui naudotų taikomųjų sistemų architektūros įvertinimo pasteb÷jimai




SVEIKATOS APSAUGOS

MINISTERIJA

Pasteb÷jimas Poveikis

NESS taikomosios architektūros atitikimas taikomiesiems uždaviniams

T.S.1. E. paslaugų kūrimui ir administravimui skirtos priemon÷s NESS yra įsigytos, tačiau n÷ra įdiegtos ir naudojamos priemon÷s paslaugų valdymui. NESS n÷ra numatytos priemon÷s procesų gyvavimo ciklo valdymui. NESS n÷ra numatytos priemon÷s turinio valdymui. NESS numatytos priemon÷s duomenų mainų terp÷s valdymui. Svarbu: šiam funkciniam komponentui realizuoti neišnaudotos įsigyto Software AG webMethods tarpin÷s programin÷s įrangos produkto galimyb÷s.

Priemon÷s e. paslaugų kūrimui ir konfigūravimui NESS sukurtos tik iš dalies. Yra realizuotos priemon÷s duomenų mainų terp÷s valdymui, tačiau n÷ra įdiegtos priemon÷s paslaugų ir numatytų bei sukurtų priemonių procesų – jų komponentų – gyvavimo ciklo ir turinio valdymui, kurios yra būtinos e. paslaugoms realizuoti.

T.S.2. Portalas NESS n÷ra sukurtas portalas. Sveikatos priežiūros specialistams prieigai prie NESS sukurtas NESS klientas.

NESS n÷ra sukurtas portalas, leidžiantis gyventojams (pacientams) bei sveikatos priežiūros specialistams pasiekti e. paslaugas. Nors n÷ra sukurtas portalas, tačiau sveikatos priežiūros specialistai prieigai prie NESS gali naudoti NESS klientą, tod÷l prieiga prie e. sveikatos paslaugų realizuota iš dalies.

T.S.3. E. paslaugos

NESS n÷ra realizuotų e. paslaugų.

NESS n÷ra realizuotų e. paslaugų bei priemon÷s e. paslaugoms tvarkyti realizuotos tik iš dalies.

T.S.4. Taikomieji sprendimai NESS realizuotas NESS klientas.

NESS yra realizuotas NESS klientas, esamos priemon÷s užtikrina pl÷tros galimybes, tačiau n÷ra pl÷tros metodą nustatančios ir palengvinančios infrastruktūros.

T.S.5. E. paslaugų teikimo funkcinis komponentas NESS n÷ra realizuotų procesų ir darbo sekų bei dokumentų valdymo įrankių, panaudojant duomenų mainų terp÷s d÷ka

NESS nebuvo kuriama kaip duomenų mainų platforma, užtikrinanti e. paslaugų teikimui būtinus funkcinius komponentus. NESS n÷ra realizuotų e. paslaugų bei priemon÷s e.




SVEIKATOS APSAUGOS

MINISTERIJA


galimus duomenų mainus tarp SPĮ ir institucijų, būtinų e. paslaugų kūrimui ir funkcionavimui. Svarbu: šiam funkciniam komponentui realizuoti neišnaudotos įsigyto Software AG webMethods tarpin÷s programin÷s įrangos produkto galimyb÷s.

paslaugoms įgyvendinti realizuotos tik iš dalies.

T.S.6. Informaciniai ištekliai NESS yra galimyb÷ kaupti ESI duomenis, tačiau n÷ra nustatyta ESI struktūra. NESS numatytos priemon÷s klasifikatorių saugojimui bei administravimui. Terminologijos paslaugos realizuotos per TLK – 10 klasifikatorių. NESS n÷ra numatytos priemon÷s vaizdų ar nuorodų į juos (nuorodų registro) tvarkymui. NESS n÷ra įgyvendintas aktų ir aktų nuorodų katalogas, tačiau yra įgyvendintas dokumentų ir dokumentų nuorodų katalogas. Objektų ID generuojami duomenų baz÷s priemon÷mis kuriant bei saugant objektus.

NESS numatytos klasifikatorių administravimo priemon÷s, tačiau klasifikatoriai n÷ra užpildyti. Yra priemon÷s įkelti TLK – 10 klasifikatorių sistemos diegimo metu, tačiau n÷ra nuolatinio automatinio klasifikatoriaus duomenų atnaujinimo iš pirminio duomenų šaltinio. Terminologijos paslaugos teikiamos tik iš dalies. NESS n÷ra numatytų techninių priemonių, užtikrinančių vaizdų saugojimo ir prieinamumo galimybes. Kadangi n÷ra apibr÷žta ESI struktūra, nes esantys duomenys ESI formavimui gali neatitikti keliamų reikalavimų. Dokumentų ir dokumentų nuorodų katalogas yra sud÷tin÷ aktų ir aktų nuorodų katalogo dalis. NESS yra įgyvendintas dokumentų ir dokumentų nuorodų katalogas, tačiau jį reiktų pritaikyti bei pl÷sti, kad būtų įgyvendintas aktų ir aktų nuorodų katalogas. Objektų unikalūs ID yra generuojami duomenų baz÷s priemon÷mis, tačiau n÷ra galimyb÷s konfigūruoti ar apsibr÷žti ID formatą. NESS informaciniai ištekliai užtikrinami iš dalies.

T.S.7. Duomenų mainų terp÷ NESS realizuota duomenų mainų terp÷.

NESS duomenų mainų terp÷s realizacijai panaudotos tinklin÷s paslaugos, tačiau veiklos logikos sluoksnis n÷ra atskirtas nuo integracijos sluoksnio.




SVEIKATOS APSAUGOS

MINISTERIJA


NESS taikomosios architektūros komponentai ir jų paskirtis

T.S.8. ► Duomenų mainai ir integracija: NESS duomenų mainai ir integracija su kitomis išorin÷mis informacin÷mis sistemomis įgyvendinti naudojant Software AG webMethods tarpin÷s programin÷s įrangos produktą. SPĮ naudojasi integracin÷s sąsajos realizuotomis tinklin÷mis paslaugomis. Tinklinių paslaugų saugai realizuoti naudojamas OASIS WSS standartas.

► Klasifikatorių tvarkymas ir sinchronizavimas Klasifikatorių sinchronizavimas atliekamas vykdant periodines sistemos užduotis, įgyvendintas webMethods ir vykdomas webMethods Scheduler sistemų pagalba. NESS klasifikatorių tvarkymas realizuotas Oracle Forms pagalba.

► Duomenų tvarkymas Struktūrizuotų duomenų saugojimui naudojama Oracle duomenų bazių valdymo sistema.

► Naudotojų autentifikavimas ir autorizavimas HP OpenView SelectAccess vykdo naudotojų autentifikavimą ir sistemos funkcijų autorizavimą bei įgyvendina NESS naudotojų ir jų prieigų administravimo funkcijas. Prieigų valdymui naudojami OASIS WSS standartas ir RBAC autorizacijos mechanizmas. NESS naudotojų administravimas įgyvendintas Java Applet technologijos pagalba, o naudotojų ir jų prieigos teisių informacijos saugojimui naudojamas openLDAP.

Kiekvienas taikomųjų sistemos architektūros komponentas įgyvendina jam nustatytas funkcijas. Žemiau yra pateikiamas programin÷s įrangos pasirinkimo komponentų įgyvendinimui įvertinimas.




SVEIKATOS APSAUGOS

MINISTERIJA


► NESS klientas

NESS klientas yra sukurtas naudojant Eclipse JFace bibliotekas, kurios įgyvendina Java Web Start karkaso funkcijas. Šis architektūrinis sprendimas leidžia dirbti su sistema pasitelkus internetinę naršyklę ir yra plačiai naudojamas, realizuojant naudotojo sąsajas. Sprendimas tur÷tų leisti naudotis NESS klientu ir nesant internetiniam ryšiui. NESS klientas naudojasi jam skirtomis tinklin÷mis paslaugomis, realizuotomis Software AG webMethods integracin÷je platformoje.

T.S.9. Oracle Forms pagalba realizuotas NESS klasifikatorių tvarkymas prieinamas per internetinę naršyklę. Klasifikatorių duomenų administravimui reikia įdiegti papildomą nemokamą programin÷s įrangos komponentą (angl. plugin) JInitiator. Tai ActiveX komponentas, atsakingas už ryšio su taikomųjų programų tarnybine stotimi nustatymą ir taikomosios sistemos programin÷s įrangos sąsajos atvaizdavimą. NESS klasifikatorių administravimo svetain÷je (testin÷je aplinkoje) įdiegta JInitiator 1.3.1.17 versija. Paskutin÷ rinkoje išleista šio komponento versija yra 1.3.1.30 [15].

NESS administratorius gali visus klasifikatorių veiksmus atlikti iš bet kurios darbo vietos tais atvejais, jei prieiga n÷ra ribojama technin÷mis priemon÷mis, pvz. ugniasien÷s pagalba. nes tai nereikalauja jokios papildomos ar specializuotos programin÷s įrangos naudotojo kompiuteryje, nereikia tiesioginio prisijungimo prie duomenų baz÷s. Papildomas JInitiator komponentas darbo vietoje turi būti įdiegiamas tik vieną kartą. Šį programinį komponentą galima įdiegti daugelyje modernių naršyklių, išskyrus Google Chrome, bei naudoti įvairiose platformose (Windows, Linux, Mac OS X) (detaliau žiūr÷ti [12]). Pasikeitus veiklos logikai, atlikus klaidų pataisymus, galutiniam naudotojui nebūtina įdiegti nieko papildomo savo kompiuteryje, visa logika atliekama sistemos serverio dalyje. NESS klasifikatorių administravimo priemon÷je neįgyvendintos klasifikatorių paieškos funkcijos. Tai gali ženkliai apsunkinti klasifikatorių tvarkymą, ypač tais atvejais, kai administruojamas didelis kiekis duomenų.

T.S.10. Software AG webMethods Scheduler Esamos NESS taikomosios architektūros




SVEIKATOS APSAUGOS

MINISTERIJA


užtikrina periodinių klasifikatorių duomenų sinchronizavimo užduočių vykdymą, valdymą ir konfigūravimą.

apimtyje šis sinchronizavimo mechanizmas būtų pakankamas, tačiau šiuo metu n÷ra naudojamas. Plečiant eSPBI, šio mechanizmo taip pat tur÷tų pakakti, nes registrų, klasifikatorių, kurie gali būti naudojami eSPBI reikm÷ms, kiekis yra baigtinis.

T.S.11. Duomenų saugojimui naudojama patikima ir brandi, didelio našumo Oracle DBVS.

Oracle DBVS leidžia užtikrinti aukšto lygio duomenų integralumą. Ši DBVS turi resursus tiek sprendimų įgyvendinimui tiek tolesniam jų palaikymui bei dažnai naudojama panašios apimties ir sud÷tingumo sistemose.

T.S.12. NESS naudotojų prieigos kontrolei naudojamas kontrol÷s pagal naudotojo rolę (angl. Role based control - RBAC ) principas. Jo įgyvendinimui pasirinktas organizacijos (angl. enterprise) lygio komercinis produktas HP OpenView SelectAccess. NESS naudoja šį produktą: ► naudotojų prieigos teisių

konfigūravimui; ► patikrinimui, ar naudotojas gali

atlikti konkretų veiksmą, naudojant integracinę platformą.

HP OpenView SelectAccess produkto naudojimas NESS reikm÷ms yra neadekvatus, nes naudojama tik maža šio, daug pritaikymo sričių apimančio, produkto išpildomų funkcijų dalis. Taip pat atkreiptinas d÷mesys, jog HP OpenView SelectAccess produkto kūrimas ir palaikymas nutrauktas.

HP OpenView Select Access naudoja nuosavybinį (angl. proprietary) naudotojų LDAP katalogo schemos formatą. Tai sumažina sistemos lankstumą ir pernešamumą (angl. portability). Ateityje, nusprendus naudoti kitą produktą (d÷l teikiamo funkcionalumo, licencijų kainos, našumo), gali prireikti migruoti duomenis. Be to turima šio produkto versija šiuo metu jau nebepalaikoma. Kyla rizika, kad nesant galimyb÷ms atnaujinti programin÷s įrangos versijas, nebus galimyb÷s užtikrinti pakankamo sistemos saugos lygio bei sistemos pl÷trą. Atsižvelgiant į produkto naudojimo kituose projektuose patirtį, HP OpenView SelectAccess produktas turi ribotas pl÷timo galimyb÷s - prijungus didesnį naudotojų skaičių, šio produkto naudojimas tampa nepatikimu. Standartin÷ naudotojų ir jų teisių administravimo priemon÷ leidžia priskirti naudotojams roles. Naudotojų ir rolių išd÷stymas ekrane bei priskyrimo būdas labai




SVEIKATOS APSAUGOS

MINISTERIJA


padidina klaidų tikimybę, nes visi naudotojai ir jų rolių priskyrimai atvaizduojami matricos pavidalu. Tod÷l sistemoje priregistravus daug naudotojų ir sukūrus daug rolių sunku tiksliai priskirti roles naudotojams.

T.S.13. NESS klientas yra realizuotas kaip „storas“ klientas (angl. fat client arba rich client). Tai reiškia, kad didel÷ dalis funkcionalumo realizuota klientin÷je dalyje ir nepriklauso nuo serverio. Neįgyvendinta NESS kliento nepriklausomyb÷ nuo internetinio ryšio, nors pasirinkti taikomosios architektūros komponentai tur÷tų leisti naudotis NESS klientu ir nesant internetiniam ryšiui.

NESS kliento įgyvendinimo būdas apsunkina sistemos plečiamumą bei lankstumą - įdiegus naują funkcionalumą, visi naudotojai privalo atnaujinti NESS kliento programinę įrangą savo darbo vietose.

Atitikimas vyraujančioms taikomosios architektūros modeliams ir tendencijoms

T.S.14. NESS sistema suprojektuota remiantis SOA sistemų architektūros principais, tačiau įgyvendintos tinklin÷s paslaugos šiuos principus atitinka tik iš dalies. Paslaugos tur÷tų pasižym÷ti tokiomis savyb÷mis kaip: ► autonomiškumas (angl. self-

containment); ► moduliarumas – paslaugai nustatytų

ir apibr÷žtų funkcijų vykdymas (angl. granularity);

► nepriklausomyb÷ nuo sistemos ar naudotojo sesijos būsenos.

Beveik visos realizuotos tinklin÷s paslaugos pritaikytos ir skirtos NESS kliento funkcionalumui. Išorin÷s ir vidin÷s tinklin÷s paslaugos neatskirtos.

Nepakankamas funkcinių dalių bei išorinių ir vidinių paslaugų atskyrimas gali neigiamai įtakoti paslaugų pl÷timo bei naudojimo ir pritaikymo galimybes. Sistemos pl÷timo metu galimos situacijos, kai nepavyks pakartotinai panaudoti jau įgyvendintų sistemos paslaugų naujoms sistemos funkcijoms realizuoti, d÷l nepakankamo funkcinio atskyrimo.

T.S.15. NESS suprojektuota ir įgyvendinta, išskaidant sistemos funkcijas į 3 „realizavimo“ sluoksnius ir naudojant tokius architektūrinius komponentus:

Gerosios sistemų projektavimo ir realizavimo, remiantis SOA sistemos architektūros principais, praktikos rekomenduoja laikytis integracinio ir veiklos logikos sluoksnių




SVEIKATOS APSAUGOS

MINISTERIJA


► informacijos pateikimo ar vaizdavimo, naudojant Eclipse JFace karkasą (skirtą Java programavimo kalbai), Oracle Forms, HP OpenView SelectAccess security administration modulius

► veiklos logikos: naudojant webMethods, Oracle SPROC;

► duomenų saugojimo, naudojant Oracle DB.

Pastaba: Veiklos logikos ir integracijos sluoksnio įgyvendinimui pasirinkta Software AG webMethods integracin÷ platforma.

atskyrimo principo. Laikantis šio principo sistemos veiklos logika realizuojama atskiruose vienas nuo kito nepriklausančiuose komponentuose (angl. services), kurie gali būti diegiami, konfigūruojami ir testuojami nepriklausomai vienas nuo kito. Dabartin÷je NESS veiklos logika realizuojama integraciniame lygyje. Tai apriboja sistemos lankstumą, testavimo, derinimo ir keitimo galimybes. Tuo pačiu apribojamos atskirų sistemos modulių, išpildančių tam tikras veiklos logikos funkcijas, diegimo siekiant pagerinti sistemos našumą galimyb÷s.

T.S.16. Integraciniam sluoksniui įgyvendinti naudojama tarpin÷ programin÷ įranga (angl. middleware) Software AG webMethods programin÷ įranga.

Sistemose, kuriose svarbus integracijos su kitomis sistemomis aspektas, dažnai naudojamas tarpin÷s programin÷s įrangos komponentas duomenų tarp skirtingų sistemų perdavimui. Tai palengvina skirtingų sistemų tarpusavio integraciją.

Sistemos moduliarumo ir plečiamumo galimyb÷s

T.S.17. Sistemos moduliarumas apibr÷žiamas kaip sistemos dalių tarpusavio nepriklausomumas ir galimyb÷ naudotis bei jungti esančius sistemos komponentus. Dabartin÷je NESS n÷ra laikomasi pagrindinio atsakomyb÷s padalinimo (angl. SoC - Separation of Concerns) principo, nes veiklos logikos įgyvendinimo sluoksnis pasislinkęs į Software AG webMethods platformą, kuri buvo panaudota kaip tinklinių paslaugų konteineris.

Esant glaudžiam integracijos ir veiklos logikos išpildymo lygių susiejimui, sumaž÷ja sistemos lankstumas bei galimyb÷s pl÷sti sistemą, pakartotinai panaudojant jau realizuotas sistemos funkcijas.

T.S.18. Paslaugos ir integracin÷s sąsajos realizuojamos pasitelkiant komerciniam Software AG webMethods 6.5. produktui sukurtas priemones. Projekto vykdymo metu galiojo webMethods licencijos, tačiau garantinis

Software AG webMethods sistemos kūrimo ir derinimo priemon÷s įsigyjamos ir veikia tik kartu su Software AG webMethods produktu. Software AG webMethods priemon÷mis sukurti komponentai ir jų konfigūracija saugomi nuosavybinio formato failuose. Tokiu būdu




SVEIKATOS APSAUGOS

MINISTERIJA


NESS palaikymo laikotarpis buvo pasibaigęs. Garantinio palaikymo paslauga taip pat apima ir naujų webMethods programin÷s įrangos versijų pateikimą ir sistemos atnaujinimą. webMethods priemonių prieinamumas yra ribotas: ► n÷ra galimyb÷s naudotis kitomis, ne

webMethods pateikiamomis, sistemos kūrimo ir derinimo priemon÷mis;

► sistemos specifikacijos yra uždaros.

sistema ir jos dalys tampa priklausomos nuo programin÷s įrangos tiek÷jo (angl. vendor lock-in), ribojamos galimybes pritaikyti ar įdiegti kitų gamintojų programin÷s įrangos produktus ir įgyvendintų komponentų keitimą, atnaujinimą ar diegimą naudojant kitų gamintojų programinę įrangą. Naudojama ne pati naujausia webMethods produkto versiją, o jos atnaujinimas pareikalaus ženklių sąnaudų (SAM atstovų duomenimis – iki 100.000 litų per metus).

T.S.19. Duomenų apdorojimui naudojamos Oracle Stored Procedures.

Oracle tampa vienintele naudotina DBVS. Tai savo ruožtu mažina sistemos lankstumą ir pernešamumą.

T.S.20. Galimyb÷s atnaujinti programinę įrangą, PĮ palaikymas. Pagrindiniai NESS sistemos komponentai turi savo konfigūravimo ir aptarnavimo taikomąsias programas.

Sistemos administratoriui prieinamos reikiamos NESS sistemoje naudojamos taikomosios programin÷s įrangos komponentų konfigūravimo ir priežiūros priemon÷s.

Ankstesnių funkcijų palaikymo, modifikuojant esamas arba įgyvendinant naujas funkcijas

(angl. „backward compatibility“)

T.S.21. Šiuo metu NESS naudojama DBVS yra Oracle 10g kartos. Naujausia Oracle versija rinkoje yra 11g kartos. Oracle duomenų baz÷ gali būti tiesiogiai atnaujinta iš 10g į 11g versiją [16].

Pereinant prie naujos versijos netur÷tų kilti suderinamumo problemų. Oracle 11g produktas savyje turi automatinio migravimo programines priemones [19].

T.S.22. NESS įgyvendinimui naudojama openLDAP 2.2.29 versija. Šios ataskaitos rengimo metu naujausia prieinama openLDAP programin÷s įrangos versija - 2.4.19. Abi openLDAP versijos palaiko LDAP v3 protokolą.

Pereinant prie naujausios (2.4.19) оpenLDAP versijos netur÷tų kilti suderinamumo problemų, nes naudojama openLDAP versija yra suderinama su naujausia LDAP versija rinkoje [17, 18]. Integracija tarp HP Open View Select Access ir openLDAP tur÷tų veikti nepriklausomai nuo openLDAP versijos, kadangi naudojama ir




SVEIKATOS APSAUGOS

MINISTERIJA


naujausia versija palaiko tuos pačius LDAP protokolus.

T.S.23. NESS naudojama integracin÷ platforma webMethods 6.5 versija. Naujausia versija rinkoje yra webMethods 7.1.2. Yra numatytos priemon÷s migravimui nuo webMethods 6.5 į webMethods 7.1.x. Kadangi webMethods yra komercinis produktas, nepavyko rasti viešai pasiekiamos informacijos apie versijos atnaujinimą, išskyrus tai, kad toks procesas yra numatytas.

Naujų Software AG webMethods sistemos versijų teikimas įeina į garantinio palaikymo paslaugą. Atkreiptinas d÷mesys, kad šiuo metu garantinis palaikymas jau pasibaigęs. Svarbu: Yra galimyb÷ atnaujinti Software AG webMethods programinę įrangą bei pratęsti garantinį palaikymą. Atsakydami į pateiktą 2009-11-11 dienos informacijos užklausimą, SAM nurod÷, kad nepriklausomų ekspertų teigimu yra galimyb÷ Software AG webMethods atnaujinti į naujausią versiją ir NESS sistema veiks naujos webMethods versijos aplinkoje. Paslauga vertinama apie 100.000 Lt.

T.S.24. NESS naudojama HP Open View Select Access 6.2 versija. Ataskaitos rengimo metu produktas buvo nebepalaikomas ir produkto atnaujinimo galimyb÷s nebuvo prieinamos.

Iškilus našumo, funkcionalumo ar kitoms problemoms, šio produkto atnaujinimas būtų neįmanomas ir iškiltų poreikis pasirinkti kitą produktą, atliekantį analogiškas funkcijas. Kadangi HP Open View Select Access dirba su LDAP ir naudoja nuosavybinį LDAP schemos formatą, keičiant HP Open View Select Access produktą, gali tekti migruoti openLDAP naudotojų katalogo duomenis. Pereinant prie kito, analogiško programin÷s įrangos produkto, galimas poreikis perrašyti ir webMethods integracijos su HP Open View Select Access adapterį.

T.S.25. NESS klientas realizuotas Java 1.5 (arba Java 5) pagrindu. Šiuo metu naujausia versija yra Java 6. Programos kurtos Java 5 yra suderinamos su Java 6. Vertinant ankstesnių funkcijų palaikymą, buvo įvertintas tik suderinamumas su integracine platforma bei galutinio naudotojo kompiuteryje esančia JRE. Nebuvo vertintas suderinamumas su NESS

NESS klientas yra suderinamas su naujausia Java 6 versija. Per÷jimui prie naujausios versijos modifikacijos ar pakeitimai n÷ra būtini. NESS klientas su integracine platforma bendrauja tinklinių paslaugų pagalba, tai yra NESS klientas priklauso tik nuo sąsajų, kurias teikia integracin÷ platforma. Atliekant sąsajų pakeitimus, galimas automatinis




SVEIKATOS APSAUGOS

MINISTERIJA


kliento įgyvendinimui naudotų trečiųjų šalių bibliotekomis.

NESS kliento versijos atnaujinimas, įgyvendinant ir perkeliant visus reikalingus pakeitimus vienu metu. Pakeitus integracinę platformą, jos versiją, tačiau išlaikius tas pačias tinklinių paslaugų sąsajas, klientas tur÷tų veikti kaip ir anksčiau.

Taikomųjų programų darbo našumo rodiklių steb÷jimo galimyb÷s

T.S.26. NESS techninio aprašymo dokumentuose nepateikiama informacija apie galimybes derinti ar steb÷ti sistemos taikomųjų dalių našumą.

Nesant našumo steb÷jimo priemon÷ms, neįmanoma užtikrinti tinkamą sistemos darbo steb÷seną bei reguliuoti sistemos paj÷gumus pagal egzistuojančius ir numatomus apkrovimus.

T.S.27. Papildomos programin÷s priemon÷s, skirtos sistemos taikomųjų programų našumo analizei, neįtrauktos į sistemos diegimo paketą. Neaiškus jų licencijavimo statusas (pvz. Software AG webMethods Optimize programinis paketas, ar ALIDEO OpenStats for WebMethods, HP Smart Plug-in for HP Operation Console).

NESS taikomosioms programoms reikalingos specifin÷s našumo steb÷jimo priemon÷s, kurių diegimas bei pritaikymas gali pareikalauti NESS diegimui nenumatytų išteklių bei kompetencijų.

T.S.28. N÷ra duomenų apie įdiegtos sistemos bei jos dalių- taikomųjų programų našumo vertinimą naudojant sistemos apkrovos testavimą (angl. stress testing).

Neturint pradinių duomenų neįmanoma nustatyti kada reikalingas atskirų taikomųjų programų našumo vertinimas ir derinimas, kokie yra sistemos darbo našumą įtakojantys faktoriai ir kaip sistema gali būti reguliuojami sistemos paj÷gumai, atsižvelgiant į apkrovimus.

T.S.29. Nerealizuoti sistemos dalių greitaveikos testavimo atvejai (angl. TestCases), skirti atskiroms sistemos dalims.

Kyla rizika, kad sistemos funkcijos, kurių vykdymas reikalauja daugiausiai laiko, nebus identifikuotos sistemos derinimo ir pl÷timo metu. Tod÷l nebus įmanomas efektyvus sistemos darbo našumo tobulinimas bei galimų reikalavimų darbo našumui atitikimas.

T.S.30. NESS sistemos vertinimo metu nepavyko pilnavertiškai įvertinti sistemos našumo. Sistemos vertinimo metu SAM įgaliotas atstovas negal÷jo pateikti duomenų apie

Būtina numatyti sistemos našumo gerinimo priemones tolimesniems sistemos pl÷tros etapams. Plečiant sistemos funkcionalumą augs sistemos naudotojų skaičius bei apdorojamų




SVEIKATOS APSAUGOS

MINISTERIJA


NESS sistemos ir jos dalių našumą jos bandomojo eksploatavimo metu. Kadangi vertinimo metu gamybin÷je aplinkoje taip pat neveik÷ Oracle duomenų bazių serveris, nebuvo jokios galimyb÷s įvertinti įrašų apimtis. Atkreiptinas d÷mesys, kad nenumatytos priemon÷s sistemos našumui gerinti tolimesniuose sistemos vystymo etapuose. Nepateikiama informacija kaip įmanoma pagerinti sistemos našumą pridedant papildomą techninę įranga tokiems uždariems sistemos komponentams kaip: ► Software AG webMethods; ► HP OpenView SelectAccess.

duomenų kiekis. Nenumačius ir neišbandžius sistemos paj÷gumų pl÷timo priemonių kyla rizika, kad tolimesniuose sistemos pl÷tros etapuose sistema neatitiks jai keliamų našumo reikalavimų bei naudotojų poreikių.

Sistemos veiksmų steb÷senos galimyb÷s (auditavimas)

T.S.31. Visi naudotojų veiksmai saugomi duomenų baz÷je, tačiau n÷ra pateikiami jokie naudotojų veiksmų analiz÷s ar sistemos klaidų steb÷jimo įrankiai. Norint atlikti bet kokią sistemoje atliktų veiksmų analizę, reikalingas tiesioginis prisijungimas prie duomenų baz÷s. Taip pat yra būtina žinoti audito duomenų lentelių struktūrą.

Nepateikiant sistemos veiksmų steb÷senos priemonių, sistemos auditavimas gali tapti sud÷tinga ir daug laiko reikalaujančia užduotimi. Kyla rizika, kad auditavimas bus atliekamas tik tais atvejais, kad tai bus kritiškai svarbu. Taip pat atsiranda priklausomyb÷ nuo NESS dieg÷jo, kuriam yra prieinama NESS duomenų lentelių struktūros informacija, arba atsiranda poreikis atlikti papildomą analizę, siekiant tą informaciją nustatyti.

T.S.32. NESS klientas visus veiksmus atlieka per NESS integracin÷s platformos teikiamas tinklines paslaugas, ir visi audito veiksmai fiksuojami iš Software AG webMethods integracin÷s platformos.

Sistemos veiksmų steb÷senos fiksavimo funkcijos išskirtos į atskirą paslaugą. Tai geras SOA (angl. Service Oriented Architecture) pavyzdys. Esant tokiai realizacijai pakankamai lengva taisyti pildyti ar keisti veiksmų steb÷senos fiksavimo paslaugų realizaciją.

T.S.33. Klasifikatorių keitimo veiksmai fiksuojami tiesiogiai duomenų baz÷je. Galima steb÷ti klasifikatoriaus pasikeitimo istoriją klasifikatorių valdymo sistemos naudotojo sąsajoje.

Sistemos veiksmai fiksuojami skirtingose sistemos vietose ir duomenų struktūrose. Tai apsunkina bendrą sistemos veiksmų analizę. Tokiu būdu sistemos priežiūros metu veiksmų analiz÷ turi būti atliekama sugretinant sistemos veiksmų įrašus iš įvairių sistemos komponentų




SVEIKATOS APSAUGOS

MINISTERIJA


(pvz. NESS kliento naudotojų sistemos veiksmų įrašai turi būti sugretinami su klasifikatorių keitimo sistemos veiksmų įrašais). N÷ra sukurta efektyvių priemonių bendrai sistemos veiksmų analizei.

T.S.34. NESS dokumentacijoje neaprašytas audituojamų veiksmų ir įvykių saugojimo funkcionalumas, saugomi duomenys bei techniniai sprendimai. Taip pat n÷ra nurodoma kokių išorinių sąsajų iškvietimo metu yra numatytos galimyb÷s atlikti naudotojų veiksmų auditą.

D÷l dokumentacijos trūkumo sistemos vystymo metu tektų atlikti dar ir papildomą analizę, norint išsiaiškinti esamą funkcionalumą.

Atitikimas poreikiams

T.S.35. Funkcionalumas Sistemos analiz÷s metu nebuvo galimyb÷s patikrinti sistemos funkcionalumo, nes sistema neveik÷ nei jos gamybin÷je, nei SAM testavimo aplinkose.

NESS sistema vertinimo metu neveik÷, taigi nebuvo galimyb÷s įvertinti sistemos realizuojamų funkcijų atitikimo jų specifikacijoms.

T.S.36. Patikimumas (duomenų sauga). Sistemos moduliai, įdiegti skirtingose tarnybin÷se stotyse, o duomenys yra saugomi tos pačios tarnybin÷s stoties diskuose. Oracle duomenų bazei yra numatytos procedūros ir priemon÷s sukurti rezervines duomenų kopijas pagal nustatytą rezervinių duomenų kopijų kūrimo planą, aprašoma [2] dokumente (su nuoroda į FP602 dokumentą, kuris nebuvo pateiktas sistemos vertinimo metu). Sistemos dalys, kurioms nenumatytos priemon÷s ir procedūros rezervinių duomenų kopijų kūrimui: ► Software AG webMethods; ► openLDAP serveris. Kritiškai svarbūs sistemos duomenys neapsaugoti nuo galimų pažeidimų tokių kaip: ► duomenų kaupiklių gedimai- sistemos

Kritiškai svarbūs sistemos duomenys neapsaugoti nuo galimų pažeidimų. Neužtikrinta duomenų sauga bei nenumatyta rezervinių duomenų atstatymo procedūra visoms sistemos dalims, duomenų praradimo atveju gal÷tų visiškai sustabdyti sistemos veiklą neprognozuojamam laikotarpiui.




SVEIKATOS APSAUGOS

MINISTERIJA


duomenims, kuriems nenumatytos priemon÷s ir procedūros atsarginių duomenų kopijų kūrimui;

► didesnio mąsto įvykiai susiję su šiuo metu vienintelio sistemos įdiegimo taško daliniu ar visišku sunaikinimu (tokie kaip gaisras, stiprios elektros iškrovos ir pan.).

T.S.37. Pasiekiamumas / patikimumas

(sistemos funkcijos) NESS diegimas įvykdytas pagal numatytą ir aprašytą sistemos diegimo planą [2]. Sistema įdiegta trijose tarnybin÷se stotyse. Dar viena tarnybin÷ stotis naudojama testiniam sistemos diegimui ir nedalyvauja užtikrinant sistemos funkcijų pasiekiamumą. Sistemos diegimo plane numatyta, ir gamybin÷je aplinkoje įdiegta, po vieną šių sistemos dalių kopiją: ► Oracle duomenų bazių serveris; ► Software AG webMethods serveris; ► Apache HTTP serveris; ► HP OpenView SelectAccess serveris; ► openLDAP serveris. Nei viena iš sistemos dalių neužtikrina sistemos pasiekiamumo reikalavimų, nurodytų [2].

Pasirinktas NESS diegimas neužtikrina pakankamo sistemos funkcijų pasiekiamumo / patikimumo lygio. Neveikiant nors vienai sistemos tarnybinei stočiai, ar nustojus veikti kuriai nors iš sistemos dalių, darbas su sistema tampa neįmanomas, tod÷l visos sistemos dalys gali būti įvardinamos kaip SPoF (angl. Single Point of Failure). Pavyzdžiui: ► neveikiant HP OpenView SelectAccess

neįmanomas naudotojų autentifikavimas ir autorizavimas;

► neveikiant Software AG webMethods integracinei terpei neįmanomas duomenų apsikeitimas, neveiktų ir NESS klientas, kuris tiesiogiai priklauso nuo webMethods tinklinių paslaugų;

► NESS sistema nustotų veikti ir nesant ryšio su DBVS.

T.S.38. Pasiekiamumas Sistemos funkcijos pasiekiamos dviem būdais: ► įdiegiant NESS kliento programinę

įrangą naudotojo kompiuteryje. Apache HTTP serveris, įdiegtas vienoje iš NESS tarnybinių stočių, leidžia parsisiųsti reikalingus duomenis naudotojo programos diegimui ir automatiniam atnaujinimui.

► naudojantis sistemos integracin÷mis

N÷ra užtikrinamos galimyb÷s bei n÷ra įgyvendintos priemon÷s: ► įdiegti NESS kliento programinę įrangą, jei

vienintelis Apache HTTP serveris su reikalingais duomenimis yra nepasiekiamas d÷l tarnybin÷s stoties neveikimo;

► naudotis sistemos integracin÷mis sąsajomis jei vienintelis Software AG webMethods serveris yra nepasiekiamas.




SVEIKATOS APSAUGOS

MINISTERIJA


sąsajomis. Įdiegtos NESS tinklin÷mis paslaugomis išpildytos integracin÷s sąsajos pasiekiamos SOAP protokolu. NESS sistemos tinklin÷s paslaugos realizuotos ir pasiekiamos naudojant Software AG webMethods serverį.

Įdiegtos pagal numatytą diegimo planą [2] NESS pasiekiamumas vertintinas nepakankamu, o visos sistemos dalys gali būti įvardinamos kaip SPF (angl. Single Point of Failure).

T.S.39. Pernešamumas NESS vertinimo metu aptinkami kodo fragmentai leidžia manyti, kad suderinamumas su kita (nei Microsoft Windows) sistemine programine įranga buvo numatytas, tačiau praktiškai pernešamumas nebuvo užtikrintas.

NESS diegimo metu neįtraukus reikiamų resursų (bibliotekų) į gamybinę aplinką, nebus įmanoma naudotis NESS klientu kompiuteriuose, turinčiuose kitokią nei Microsoft Windows programinę įrangą.

T.S.40. Atsparumas gedimams NESS projektin÷je bei diegimo dokumentacijoje [2] užsimenama apie sistemos veiklos peradresavimą į atsarginę įdiegtos NESS aplinką. NESS, įdiegtos gamybin÷je aplinkoje, vertinimo metu neaptikta nei viena įdiegta NESS sistemos kopija. Pagal susitikime su konsultacijas ir informaciją teikiančiu SAM atsakingu asmeniu pateiktą informaciją, tokia kopija nebuvo sukurta. Sistemos dokumentuose nepavyko rasti informacijos apie atsargin÷s kopijos kūrimo procedūras ir periodiškumą.

Nenumatytos ir neįgyvendintos galimyb÷s peradresuoti sistemos veikimą užtikrinančias funkcijas į įdiegtas rezervines sistemos dalių kopijas, gali įtakoti tai, kad sistema bus neatspari jos dalių gedimams.

Kiti aspektai

T.S.41. Testavimo galimyb÷s Pateikta NESS dokumentacija neapima sistemos testavimo ir derinimo galimybes aprašančių dokumentų. Sistemoje aptikta mažiau nei 30 Java TestCase realizuotų testų. Dauguma iš realizuotų testų skirti SPĮ

Neužtikrinus sistemos testavimo, n÷ra galimybių tiksliai nustatyti ar sistemos funkcionalumas atitinka naudotojų poreikius ir sistemai keliamus reikalavimus. Be to, aptiktų klaidų šalinimas bei sistemos




SVEIKATOS APSAUGOS

MINISTERIJA


integracijos sąsajos testavimui. Veiklos logikos perk÷limas į integracinį išpildymo sluoksnį komplikuoja NESS sistemos derinimo ir testavimo galimybes. Atkreiptinas d÷mesys į sistemos dalis, kurių testavimo galimyb÷s ribotos: ► Oracle Stored Procedures. Dalis

vykdymo logikos išpildomos Oracle Stored Procedures pagalba. Veiklos logikos testavimas sud÷tingas d÷l sud÷tingo būsenų modeliavimo, rezultatų tikrinimo bei testavimo atvejų (angl. test cases) pritaikymo. N÷ra galimyb÷s simuliuoti (angl. mock) sistemos dalis ar duomenis.

► Sistemos tinklin÷s paslaugos realizuotos webMethods pagalba. Testavimui naudojama webMethods testavimo aplinka. Veiklos logikos testavimas sud÷tingas d÷l sud÷tingo būsenų modeliavimo, rezultatų tikrinimo bei testavimo atvejų (angl. test cases) pritaikymo.

► Integravimosi su HP OpenView SelectAccess testavimas sud÷tingas d÷l jo administravimo funkcijų specifikos.

versijos atnaujinimas testavimo metu pareikalauja mažiau išteklių, nei šių klaidų šalinimas sistemos eksploatavimo metu.

T.S.42. Programinis kodas NESS sistemos sukurto programin÷s įrangos išeities kodas mažai dokumentuotas, komentarai reti. Nepasirinkta ir nesilaikoma jokio išeities kodo dokumentavimo standarto (pvz. JavaDoc). NESS išeities kode aptinkami kodo fragmentai naudojantys kode įrašytas (angl. hardcoded) tekstines reikšmes (pvz. sistemos pranešimų tekstai, pradin÷s užklausų reikšm÷s). Pvz:

public String getTitle() {

Mažai dokumentuotas ir komentuotas išeities kodas reikalauja didelių laiko sąnaudų analizuojant bei modifikuojant esamą NESS realizaciją. Sistemos išeities kode įrašytos tekstin÷s reikšm÷s apsunkina tiek sistemos priežiūrą/keitimą tiek sistemos pl÷timą (pvz. keleto kalbų palaikymo galimyb÷).




SVEIKATOS APSAUGOS

MINISTERIJA


return "Paciento sveikatos istorija"; }

T.S.43. Sistemos diegimas Pradinis sistemos paruošimas atliekamas vykdant tam paruoštas komandines paketines užduotis. Sistemos dokumentuose [2] pateikiamas nepilnas sistemos diegimo planas. Nepateikiama informacija apie šių sistemos dalių diegimą ir konfigūravimą NESS reikm÷ms: ► Software AG webMethods; ► Apache HTTP Server; ► HP OpenView SelectAccess; ► openLDAP naudotojų katalogas.

Sistemos diegimo proceso aprašymas yra labai fragmentuotas. Diegimo procesas suskirstytas į daug tarpusavyje susijusių veiksmų. Kyla rizika, kad sistemos diegimas remiantis tik pateiktu diegimo planu bus neefektyvus, nes planas n÷ra detalus ir aiškus ir nepateikia pakankamai informacijos sistemos veikimo principų ar komponentų tarpusavio sąryšių supratimui.

3.3.3.3.3.3.3.3. Pasiūlymai ir rekomendacijosPasiūlymai ir rekomendacijosPasiūlymai ir rekomendacijosPasiūlymai ir rekomendacijos

Įvertinus NESS funkcijų realizavimui taikytą taikomųjų sistemų architektūrą bei atsižvelgiant į esamos NESS diegimo ir naudojimo situaciją, siūloma:




SVEIKATOS APSAUGOS

MINISTERIJA

Bendros rekomendacijos taikomųjų programų atnaujinimui ir panaudojimui

► Pertvarkyti esamus NESS programin÷s įrangos sprendimus sistemos pl÷trai ir vystymui, panaudojant egzistuojančią sistemos dalių realizaciją kaip programų bibliotekas ar galimas „ištraukas“, toliau kuriant naujus programin÷s įrangos komponentus; (Pagal pasteb÷jimus T.S.1, T.S.2, T.S.3, T.S.4, T.S.5, T.S.6, T.S.7, T.S.8, T.S.9, T.S.10, T.S.11, T.S.12, T.S.16, T.S.17, T.S.18, T.S.19, T.S.20, T.S.21, T.S.22, T.S.23, T.S.24, T.S.25, T.S.35, T.S.36)

► Saugoti ir, esant poreikiui, naudoti esamą NESS programin÷s įrangos techninę ir projektinę dokumentaciją, kaip žinių apie ankstesnio sprendimo siekius, realizavimo principus bei išmoktas pamokas, šaltinį; (Pagal pasteb÷jimus T.S.8, T.S.20, T.S.35, T.S.36)

► Egzistuojančios NESS sistemos esamus rezultatus pertvarkyti ir perorientuoti į e. Sveikatos

paslaugų ir bendradarbiavimo infrastruktūros informacinę sistemą ir dalį naudojamos aparatūrin÷s įrangos pertvarkyti į testinę aplinką. (Pagal pasteb÷jimus T.S.1, T.S.2, T.S.3, T.S.4, T.S.5, T.S.6, T.S.7, T.S.8, T.S.9, T.S.10, T.S.11, T.S.12, T.S.16, T.S.17, T.S.18, T.S.19, T.S.20, T.S.21, T.S.22, T.S.23, T.S.24, T.S.25, T.S.35, T.S.36)

► Atnaujinti Oracle RDBMS versiją į naujausią šiuo metu esančią rinkoje. (Pagal pasteb÷jimus T.S.9, T.S.11, T.S.19, T.S.21)

► Šiuo metu naudojamą, tačiau jau nebepalaikomą, HP OpenView SelectAccess, pakeisti į kitą, atvirais standartais ir technologijomis paremtą produktą, palaikantį SAML 1.1/2.0 standartą, pavyzdžiui, Shibboleth, Sun Identity Manager. (Pagal pasteb÷jimus T.S.12, T.S.24)

► Šiuo metu naudojamą webMethods produkto versiją atnaujinti ir naudoti kaip integracinę

platformą kaip integracinę platformą ir e. paslaugų procesų valdymo priemonę. (Pagal pasteb÷jimus T.S.10, T.S.16, T.S.17, T.S.23).

Svarbu: šiuo metu SAM turimų webMethods programinio produkto licencijų pakanka tiek (1) kūrimo ir

testinei aplinkai, tiek ir (2) gamybin÷s aplinkos veikimo reikm÷ms.

► Atnaujinti openLDAP versiją į naujausią šiuo metu esančią rinkoje. (Pagal pasteb÷jimą T.S.22)

► Atsisakyti NESS kliento, o prieigą prie resursų organizuoti portalo ir e. paslaugų pagalba. (Pagal pasteb÷jimus T.S.13, T.S.25, T.S.39)




SVEIKATOS APSAUGOS

MINISTERIJA

Rekomendacijos integracin÷s NESS funkcin÷s dalies vystymui

► Realizuoti eSPBI IS integracinę duomenų mainų terpę, į kurią jungtųsi SPĮ. eSPBI IS integracinę terpę vystyti ir naudoti duomenų su išorin÷mis sistemomis apsikeitimui bei SPĮ integracijai. (Pagal pasteb÷jimus T.S.15, T.S.17, T.S.38)

► Realizuoti eSPBI IS integracines sąsajas skirtas SPĮ integracijai. (Pagal pasteb÷jimus T.S.15, T.S.38)

► Realizuoti prisijungimui prie eSPBI IS integracin÷s terp÷s skirtą eSPBI IS Adapterį, kuris palengvintų SPĮ integraciją su eSPBI IS. eSPBI IS Adapteris tur÷tų būti realizuojamas remiantis atvirais standartais ir atviro kodo karkasais bei bibliotekomis. (Pagal pasteb÷jimus T.S.15, T.S.25, T.S.38, T.S.39)

► Realizuoti eSPBI IS adapterio funkcijas, užtikrinančias SPĮ darbą ir dingus interneto ryšiui (pvz. kaupiant eSPBI IS registruojamus pranešimus lokaliai, o juos registruojant atsiradus ryšiui). (Pagal pasteb÷jimus T.S.37, T.S.38)

► Realizuoti eSPBI IS adapterio funkcijas, užtikrinančias duomenų kodavimą duomenis siunčiant į eSPBI IS duomenų mainų terpę ir duomenų, gautų iš eSPBI IS integracin÷s terp÷s, dekodavimą. (Pagal pasteb÷jimą T.S.36)

► eSPBI IS Adapterio išeities tekstai, dokumentacija turi būti skelbiami viešai ir prienami trečiosioms šalims taip palengvinant skatinant SPĮ integraciją su eSPBI IS. (Pagal pasteb÷jimą T.S.25)

► Sukurti adapterių testavimo priemones: leisti parsisiųsti eSPBI IS platformos imitacinę (angl. mock) versiją. (Pagal pasteb÷jimą T.S.41)

► eSPBI IS integracin÷ terp÷ turi būti diegiama serverių sankaupose (angl. cluster). Tokiu būdu užtikrinama galimyb÷ didinti sistemos našumą did÷jant sistemos apkrovai, užtikrinamas aukštesnis sistemos prieinamumas (angl. availability). (Pagal pasteb÷jimus T.S.37, T.S.38, T.S.40

► Visi pranešimai ir užklausos į eSPBI IS integracinę platformą turi būti pasirašomi elektroniniu parašu (užklausą atliekančio asmens parašu), naudojant kvalifikuotus skaitmeninius sertifikatus. (Pagal pasteb÷jimą T.S.36)




SVEIKATOS APSAUGOS

MINISTERIJA

Rekomenduojami standartai ir principai

► Integracin÷s terp÷s architektūra ir įgyvendinimas turi būti paremti atvirais standartais ir specifikacijomis (pavyzdžiui, HTTP 1.1, HTTPS, SOAP, XML1.0, WSDL, WS-Security (Pagal pasteb÷jimus T.S.14, T.S.15, T.S.16, T.S.17, T.S.18)

► Medicininius duomenis perduoti ir saugoti laikantis HL7v3, HL7 CDA reikalavimus. (Pagal pasteb÷jimus T.S.14, T.S.15)

► Medicininius vaizdus perduoti ir saugoti laikantis DICOM standarto. (Pagal pasteb÷jimą T.S.14)

► Laikytis 3-sluoksnių architektūros principų: (Pagal pasteb÷jimus T.S.14, T.S.15, T.S.16, T.S.17)

• Atskirti veiklos logikos sluoksnį nuo integracinio sluoksnio, o visas veiklos logikos funkcijas (pavyzdžiui, automatinių procesų valdymą, audito įrašų registravimą) realizuoti atskirose sistemos dalyse.

• Atskirti veiklos logikos sluoksnį nuo duomenų sluoksnio. Duomenų apdorojimo funkcionalumą perkelti į atskirus sistemos modulius, o DB naudoti tik duomenų saugojimui.

Rekomendacijos klasifikatorių valdymui

► Klasifikatoriai turi būti automatiškai sinchronizuojami su pirminiais duomenų šaltiniais. (Pagal pasteb÷jimą T.S.14)

► Klasifikatoriai turi būti lengvai pasiekiami visoms sistemoms. Realizuoti aktualios klasifikatorių kopijos gavimą ir pasikeitimų publikavimo mechanizmą naudojantis eSPBI IS tinklin÷mis paslaugomis. eSPBI IS sistemos ribose klasifikatoriai turi būti unikaliai identifikuojami. (Pagal pasteb÷jimą T.S.14)




SVEIKATOS APSAUGOS

MINISTERIJA

Rekomendacijos duomenų kaupimui

► Pacientų informacijos valdymas turi būti remiantis MDM (angl. Master Data Management) principais ir jų įgyvendinimą užtikrinančiomis priemon÷mis. Tai užtikrins informacijos iš daugelio šaltinių (poliklinikų, ligoninių ir pan.) apjungimą, bus išvengta duomenų dubliavimo. (Pagal pasteb÷jimą T.S.19)

► eSPBI IS turi palaikyti (būti suderinama su) paciento ESI. Taip pat turi užtikrinti šių duomenų saugą, kad niekas, įskaitant net ir sistemos ar duomenų bazių administratorius/ sisteminius naudotojus, be paciento žinios ar atitinkamo įgaliojimo negal÷tų peržiūr÷ti šių duomenų ar susieti asmens duomenis su asmens klinikiniais duomenimis. Pavyzdžiui, duomenys ar sąryšis tarp jų koduojami paciento viešu raktu, ir gali būti perskaityti ar ryšys tarp duomenų nustatytas tik panaudojus paciento privatų raktą). (Pagal pasteb÷jimą T.S.36)

► Realizuoti specializuotą duomenų saugyklą (angl. data warehouse) skirtą statistinių ir nuasmenintų medicininių duomenų kaupimui. Šiam tikslui naudoti specializuotą duomenų saugyklų programinę įrangą. Sukaupti duomenys bus naudojami duomenų analizei, prognozei, ataskaitų generavimui. (Pagal pasteb÷jimą T.S.19)

► Realizuoti medicininių vaizdų saugyklą (angl. content repository), kaip prioritetą svarstant jos įgyvendinimą pagal paskirstytos architektūros principus. (Pagal pasteb÷jimą T.S.19)

Rekomendacijos sistemos administravimo ir steb÷senos priemonių pl÷timui

► eSPBI IS administravimą realizuoti Web technologijų pagrindu ir užtikrinti visų administracinių funkcijų (sistemos nustatymų, automatinių procesų konfigūravimo, NESS naudotojų ir kt.) prieigą per vieną tašką. (Pagal pasteb÷jimus T.S.20, T.S.26, T.S.27)

► Sistemos administratorių autentikavimas turi būti realizuotas panaudojus SSO (angl. Single Sign-On) principą (keliomis sistemomis dirbantis NESS sistemos administratorius autentikuojamas vieną kartą). Tokiu būdu plečiant sistemos funkcionalumą bus galima prijungti ir naujas administravimo, sistemos steb÷jimo, analiz÷s funkcijas. (Pagal pasteb÷jimus T.S.20, T.S.26, T.S.27, T.S.28, T.S.29, T.S.30, T.S.31, T.S.32, T.S.33, T.S.34)

► Įgyvendinti automatines eSPBI IS steb÷senos (audito įrašų, našumo analiz÷s) priemones. (Pagal pasteb÷jimus T.S.26, T.S.27, T.S.28, T.S.29, T.S.30, T.S.31, T.S.32, T.S.33, T.S.34)




SVEIKATOS APSAUGOS

MINISTERIJA

Rekomendacijos susijusios su NESS sistemos elektronin÷mis paslaugomis

► Sukurti internetinį portalą, skirtą pacientams ir sveikatos priežiūros specialistams. (Pagal pasteb÷jimą T.S.1)

► Internetinio portalo dalis, skirta sveikatos priežiūros specialistams. Ši portalo dalis turi veikti kaip virtuali Sveikatos priežiūros įstaigos informacin÷ sistema (angl. HIS) pagal „Application Service Provision“ principus, o ja naudotis turi būti suteikta galimyb÷ sveikatos specialistams, gydymo įstaigoms, kurios neturi savo informacinių sistemų. (Pagal pasteb÷jimą T.S.1)

► Realizuoti portalo turinio valdymo priemones. (Pagal pasteb÷jimą T.S.1)




SVEIKATOS APSAUGOS

MINISTERIJA

4.4.4.4. Esamų NESS duomenų mainų sąsajų su išorin÷mis IS katalogasEsamų NESS duomenų mainų sąsajų su išorin÷mis IS katalogasEsamų NESS duomenų mainų sąsajų su išorin÷mis IS katalogasEsamų NESS duomenų mainų sąsajų su išorin÷mis IS katalogas


Šios analiz÷s tikslas – įvertinti NESS duomenų mainų su išorin÷mis sistemomis esamą pad÷tį bei pateikti pasiūlymus tobulinimui. Dabartin÷s NESS sistemos analiz÷s ir poreikių vertinimo analiz÷s metu buvo susitikta su SAM atstovu Mindaugu Minekiu bei su didžiųjų Lietuvos ligoninių atstovais.

Susitikimų tvarkaraštis: ► 2009-11-10 susitikimas su SAM atstovu Mindaugu Mineikiu VLK patalpose;

► 2009-11-17 susitikimas SANTA su Romualdu Kizlaičiu;

► 2009-11-19 susitikimas KMUK su Vyteniu Puniu;

► 2009-11-24 konferencija su KUL atstovu Virgilijumi Vanagu.

Taip pat buvo peržiūr÷ta pateikta dokumentacija, kuri yra susijusi su duomenų mainais tarp sistemų, ir peržiūr÷ti programų išeities tekstai. Analizuojant NESS duomenų mainų sąsajų su išorin÷mis sistemomis situaciją buvo kreipiamas d÷mesys į techninius realizavimo būdus, duomenų mainų būdus, kaip vyksta duomenų apsikeitimas (automatiškai, rankiniu būdu).

Taip pat buvo išanalizuotas Viešojo administravimo pl÷tros iki 2010 metų strategijos įgyvendinimo 2007 – 2010 metų priemonių planas (toliau – Viešojo administravimo pl÷tros priemonių planas), patvirtintas Lietuvos Respublikos Vyriausyb÷s 2006 m. lapkričio 6 d. nutarimu Nr. 1097. Atsižvelgiant į esamos situacijos analizę, galimus duomenų mainus tarp e. Sveikatos paslaugų ir bendradarbiavimo infrastruktūros ir kitų informacinių sistemų pagal SAM, SPĮ ir kitų institucijų poreikius, bei Viešojo administravimo pl÷tros priemonių plane numatytas priemones, buvo parengti ir pateikti pasiūlymai ir rekomendacijos d÷l galimyb÷s naudotis kitomis, tiesiogiai su sveikatos apsauga nesusijusiomis, elektronin÷mis paslaugomis.

4.2.4.2.4.2.4.2. Pagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimai Atlikus esamų NESS duomenų mainų su išorin÷mis IS įvertinimą išskiriami tokie esminiai pasteb÷jimai:

► Įvertinimo metu NESS nebuvo eksploatuojama, realizuotos duomenų mainų sąsajos su išorin÷mis

sistemomis nebuvo naudojamos;

► Yra realizuotos registrų, katalogų ir klasifikatorių tvarkymo priemon÷s, tačiau n÷ra įgyvendintos priemon÷s jų sinchronizavimui su duomenų šaltiniu (pavyzdžiui, su sveikatos priežiūros įstaigų sąrašu, fizinių asmenų registru). Daugelio klasifikatorių ir žinynų duomenų rinkinių įk÷limui į NESS yra tik vienkartinio duomenų įk÷limo (importo) priemon÷s;

► Dalis NESS apimtyje numatytų ir rezlizuotų integracinių sąsajų toliau n÷ra tinkamos duomenų mainams tarp NESS ir išorinių sistemų užtikrinti;




SVEIKATOS APSAUGOS

MINISTERIJA

► NESS branduolyje realizuotos tinklin÷s paslaugos yra ribotos, susiaurintos ir orientuotos į NESS

klientą, tod÷l daugeliu atvejų negali būti naudojamos vykdyti duomenų mainus su kitomis, išorin÷mis informac÷mis sistemomis.

Licencijuojamos programin÷s įrangos palaikymo / atnaujinimo sutartys yra pasibaigusios, versijos pasenusios, nebepalaikomos, arba n÷ra saugios (n÷ra atnaujintos saugos pakeitimais). Priklausomai nuo pasirinktos sistemos taikomosios architektūros ir technin÷s infrastruktūros sprendimo, būtų poreikis programin÷s įrangos licencijų įsigijimui, licencijų atnaujinimui ar programin÷s įrangos palaikymui atnaujinti (pvz. Oracle, webMethods).

Žemiau esančioje lentel÷je yra detalizuojami pagrindiniai pasteb÷jimai d÷l esamų NESS duomenų mainų su išorin÷mis informacin÷mis sistemomis.

5 lentel÷. Esamų NESS duomenų mainų sąsajų su išorin÷mis IS vertinimo pasteb÷jimai


Duomenų mainai – bendri pasteb÷jimai

D.M.1. Visas duomenų mainų ir integracines sąsajas teikia NESS integracin÷ platforma webMethods. Visus integracinius procesus taip pat valdo integracin÷ platforma (pvz. webMethods Scheduler pagalba).

Integracin÷s platformos naudojimas suteikia papildomų privalumų, apjungia daugelio duomenų šaltinių, formatų naudojimą. Integracin÷s platformos naudojimas palengvina sistemų integraciją, nes skirtingai realizuotų sistemų funkcijos pasiekiamos unifikuotų tinklo paslaugų pagalba. Naudojama webMethods platforma turi vizualias integracinių procesų ir sąsajų modeliavimo priemones.

D.M.2. Duomenų mainai su išorin÷mis sistemomis realizuoti trimis būdais: ► Tinklin÷mis paslaugomis (pvz. asmens

sveikatos draudimo patikrinimui) ► Per tranzitinę duomenų bazę (pvz.

Paciento demografin÷s informacijos pakrovimas iš SVEIDRA sistemos)

► Pradinių duomenų SQL bylos (naudojama pradiniams duomenims užkrauti)

Duomenų mainai su IS SVEIDRA atliekami ir tinklinių paslaugų pagalba ir naudojant tranzitinę DB.

Duomenų mainų būdus apsprendžia prie NESS prijungiamos sistemos, su kuriomis NESS atlieka duomenų mainus. Naudojama integracin÷ platforma palengvina duomenų mainus iš įvairialypių duomenų šaltinių ir leidžia teikti klientams (NESS klientui, SPĮ) unifikuotas paslaugas.

D.M.3. Duomenų apsikeitimas tinklinių paslaugų pagalba vykdomas pagal SOAP (angl. Simple Object Access Protocol) protokolo

Pagrindinis SOAP privalumas tas, kad jis nepriklauso nuo platformos ir nuo programavimo kalbos. SOAP paremtas XML




SVEIKATOS APSAUGOS

MINISTERIJA


specifikaciją.

naudojimu, galima naudoti įvairius transportavimo protokolus (dažniausiai HTTP(S), tačiau galimas ir SMTP).

D.M.4. Visų XML pranešimų schemos aprašomos naudojant XSD (angl. XML Schema document, W3C organizacijos rekomendacija XML schemoms aprašyti).

Naudojama W3C organizacijos rekomendacija XML schemoms aprašyti padidina sistemų suderinamumą. Apibr÷žus XML pranešimų formatą XML schema, pagal ją galima sugeneruoti pranešimų siuntimo ir apdorojimo priemones įvairiomis programin÷mis kalbomis.

D.M.5. Visų tinklinių paslaugų sąsajos aprašomos naudojant WSDL (angl. Web Services Description Language).

WSDL kalbos (W3C rekomendacija) privalumas tas, kad ji yra paremta XML ir gali būti naudojama nepriklausomai nuo platformos ar programavimo kalbos. WSDL naudojamas kartu su XSD aiškiai apibr÷žia tinklinių paslaugų sąsajas bei nusako tinklinių paslaugų užklausų ir atsakymų formatus.

Integracija su NESS klientu

D.M.6. NESS klientas su NESS branduoliu bendrauja per tinklines paslaugas.

NESS branduolyje realizuotos tinklin÷s paslaugos yra ribotos, susiaurintos ir orientuotos į NESS klientą, tod÷l būtinos sąsajos nepakankamos naudoti susiejimui su kitomis informacin÷mis sistemomis.

D.M.7. NESS kliento programos kodo kataloguose yra ir HL7 pranešimų schemos, tačiau jos n÷ra naudojamos. NESS klientas su NESS branduoliu bendrauja nuosavybiniu formatu, nesilaikoma jokio sveikatos duomenų apsikeitimo standarto.

Tik NESS klientui skirtos sąsajos reiškia, kad mažai galimybių kad jomis naudosis kitos, su NESS planuojančios integruotis sistemos – pranešimų ir jų apsikeitimui vykdyti skirtų sąsajų neatitikimas standartui HL 7 v3 sumažina NESS kaip sveikatos informacinių sistemų sąveikumui užtikrinti skirtos terp÷s vaidmenį, taikant tarptautinius atvirus standartus sąveikumui užtikrinti. Gera praktika yra naudoti jau esančius standartus duomenų apsikeitimui, šiuo atveju HL7.




SVEIKATOS APSAUGOS

MINISTERIJA


Integracija su SVEIDRA

D.M.8. 025-a/LK formos duomenų perdavimo į IS SVEIDRA funkcionalumas neveikia, nes NESS sistemoje trūksta duomenų laukų, kurie būtini pilnaverčiams duomenų mainams įgyvendinti.

Įgyvendintas 025-a/LK formos duomenų perdavimas yra nepilnavertis. Šios formos duomenys negali būti perduoti IS SVEIDRA.

D.M.9. 025-a/LK formos duomenų perdavimui n÷ra išorin÷s NESS branduolio paslaugos, kuria naudojantis gal÷tų kitos informacin÷s sistemos ir per NESS integracinę platformą perduoti duomenis į IS SVEIDRA. Šiuo metu tik WebMethods integracin÷ platforma gali nuspręsti kada formuoti perduodamus duomenis (pagal žinomą įvykį ar vykdant automatinį procesą) ir į IS SVEIDRA gali perduoti tik tuos duomenis, kurie buvo registruoti per NESS klientą. Tačiau SPĮ, kurios turi ir naudoja savo informacines sistemas, negali naudotis NESS paslaugomis 025-a/LK perdavimui į IS SVEIDRA.

SPĮ neturi galimyb÷s naudotis vieninga NESS teikiama sąsaja - 025-а/LK formos informacijos apsikeitimas įgyvendintas atskirai tarp SVEIDRA ir kiekvienos SPĮ. 025-a/LK formos duomenų perdavimo sąsaja NESS realizuota per tranzitinę duomenų bazę. Jei kiekviena SPĮ realizuoja savo sąsają tokiu pat būdu, kiekvienai SPĮ reikalinga įdiegti atskirą tranzitinę duomenų bazę bei užtikrinti būtinus saugos reikalavimus. Naudojant NESS sąsają tinklinių paslaugų pagalba, integracijai su SVEIDRA pakaktų tik vienos tranzitin÷s duomenų baz÷s, taip užtikrinant paprastesnį tokių sąsajų tvarkymą ir valdymą.

D.M.10. Paciento demografin÷s informacijos pateikimo iš SVEIDRA sistemos paslauga yra pasiekiama kaip NESS branduolio paslauga. Šia paslauga naudojasi NESS klientas, tačiau potencialiai gal÷tų naudotis ir kitos sistemos.

Kadangi paciento informacijos paieškos paslauga su IS SVEIDRA realizuota per tranzitinę DB, toks paslaugos publikavimas iš NESS branduolio suteikia privalumų. Paslauga potencialiai gal÷tų naudotis ne tik NESS klientas, bet ir kitos sistemos, tačiau d÷l IS SVEIDRA ypatumų atsiranda apribojimai, nes paieška galima tik pagal asmens kodą. Norint publikuoti šią paslaugą, reik÷tų įtraukti daugiau paieškos parametrų (pvz. vardą, pavardę, gimimo datą). Paslauga taptų universalesn÷, palengvintų SPĮ darbuotojų darbą, jei pacientas neprisimena asmens kodo.

D.M.11. Galutinis naudotojas informaciją apie asmens sveikatos draudimą gali patikrinti tik naudodamas web pagrindu įgyvendintą grafinę naudotojo sąsają, kurią galima pasiekti jungiantis prie WebMethods integracinio serverio.

Duomenys apie paciento draustumą n÷ra automatiškai užpildomi NESS. Šiam patikrinimui būtina atskira integracija su IS SVEIDRA.




SVEIKATOS APSAUGOS

MINISTERIJA


NESS branduolys (WebMethods integracin÷ platforma) neteikia asmens sveikatos draudimo patikrinimo tinklin÷s paslaugos, kurią gal÷tų naudoti NESS kliento programin÷ įranga arba kitos sistemos, kurios yra integruotos su NESS.

D.M.12. Vaistų informacijos atnaujinimas iš IS SVEIDRA galimas automatiniu būdu. Atnaujinimo periodiškumą galima konfigūruoti standartin÷mis webMethods Scheduler priemon÷mis, tačiau jokių reikalavimų pageidautinam dažnumui nepavyko aptikti. Pagal pokalbio su SAM atstovu metu pateiktą informaciją, automatinis vaistų informacijos iš IS SVEIDRA atnaujinimas nebuvo testuojamas. Gamybin÷je aplinkoje ši paslauga išjungta, o testin÷je aplinkoje ji buvo testuojama rankiniu būdu.

Kadangi nebuvo atlikti testavimai ir bandymai su realiais duomenimis, neaišku ar automatinis vaistų informacijos atnaujinimas apskritai veiktų. Neįmanoma nustatyti koks yra mažiausias periodiškumas (per kiek laiko ir kokie duomenų kiekiai atnaujinami vieno duomenų atnaujinimo seanso metu). Taip pat sunku įvertinti ar toks automatinis procesas netur÷s įtakos bendram sistemos našumui.

Integracija su VAISKIS

D.M.13. Numatytas duomenų mainų funkcionalumas su IS VAISKIS realiai neveikia. NESS klasifikatorių administravimo priemon÷se vaistų informacijos sąsaja galima tik skaitymo režime. Vaistų informacija gaunama tik iš IS SVEIDRA.

Neįmanomas duomenų gavimas iš pirminio šaltinio. IS SVEIDRA gali netur÷ti pilnos naujausios informacijos apie vaistus. Pateikiama vaistų informacija gali būti nekorektiška ir neigiamai įtakoti teikiamų sveikatingumo paslaugų kokybę. Taip pat gali sąlygoti neatitikimų atsiradimą derinant mok÷jimo sąskaitas už kompensuojamus vaistus.

D.M.14. Vaistų informacijos atnaujinimo iš VAISKIS ir NESS branduolio teikiamos vaistų paieškos funkcijos naudoja skirtingas XML schemas. Tačiau NESS branduolio teikiama vaistų paieškos paslauga yra labai ribota, grąžina tik pagrindinę informaciją ir yra skirta tik NESS klientui.

Skirtingų schemų naudojimas aiškiai atskiria duomenų atnaujinimą iš pirmin÷s sistemos (IS VAISKIS) ir duomenų teikimą suinteresuotoms šalims (ligonin÷ms, poliklinikoms, vaistin÷ms). Tod÷l, norint pasinaudoti NESS teikiama vaistų paieškos paslauga, nebūtina analizuoti sud÷tingos duomenų apsikeitimo schemos su papildomais tarnybin÷s informacijos elementais. NESS sistemoje vaistų registro informacija pildoma ne tik iš IS VAISKIS, bet ir iš IS




SVEIKATOS APSAUGOS

MINISTERIJA


SVEIDRA. Tod÷l apie vaistus yra kaupiama daugiau informacijos, nei grąžina NESS branduolio paslauga. Itin svarbi vaisto kompensavimo informacija, kurios egzistuojanti paslauga negrąžina. Skiriant vaistus, sveikatos priežiūros specialistai gal÷tų remtis pilna informacija apie vaistą.

Registrai ir klasifikatoriai

D.M.15. Daugelis klasifikatorių NESS užkraunami tik sistemos diegimo metu, o v÷liau nevyksta joks sinchronizavimas su duomenų šaltiniu (pvz. savivaldybių sąrašas, gydymo įstaigų sąrašas).

Daugeliu atveju reikalingas perteklinis duomenų sinchronizavimas su duomenų šaltiniais, išauga rankinio administravimo apimtys, did÷ja neatitikimų ir klaidų tikimyb÷. Naudojant neatnaujintus klasifikatorių duomenis, kyla rizika sveikatinimo paslaugų suteikimui panaudoti klaidingą informaciją ir taip neigiamai įtakoti tokių paslaugų kokybę.

D.M.16. Sveikatos priežiūros ir farmacijos įstaigų klasifikatoriui n÷ra numatyta integracija su Juridinių asmenų registru.

Integracija palengvintų sistemos naudotojų darbą tiek laiko, tiek klaidų tikimyb÷s prasme - naudotojams nereik÷tų Juridinių asmenų informacijos, esančios juridinių asmenų registre, įvedin÷ti rankiniu būdu.

D.M.17. NESS esantys klasifikatoriai perkeliami iš statinio sąrašo, kuris pateikiamas dokumente „Duomenų konvertavimo strategija ir darbų planas“ [13, 14]: ► Dokumentų tipai; ► Tyrimų rūšys ir parametrai; ► Valstyb÷s; ► Savivaldyb÷s; ► Licencijuojančios institucijos; ► Ekonomin÷s veiklos rūšys. NESS branduolys teikia klasifikatorių paieškos tinklines paslaugas skirtas NESS klientui. Šia sąsaja gal÷tų naudotis ir kitos sistemos.

Yra sukurtos klasifikatorių administravimo priemon÷s. Tačiau n÷ra sinchronizavimo su pirminiais duomenų šaltiniais (pvz. su Registrų centru, iš kurio galima gauti savivaldybių sąrašą). Tod÷l atlikus pakeitimus pirminiame duomenų šaltinyje (pvz., Registrų centre) jie neatsispind÷tų NESS sistemoje. NESS sistemos klasifikatorius juos tur÷tų atnaujinti, pasinaudodamas NESS klasifikatorių administravimo priemon÷mis, tod÷l kyla rizika, kad NESS klasifikatoriaus duomenys konkrečiu momentu nebus suderinti su pirminio šaltinio duomenimis.




SVEIKATOS APSAUGOS

MINISTERIJA


D.M.18. Nenumatytas būdas duomenis sinchronizuoti importo/eksporto būdu (pvz. įkeliant į sistemą failus gautus iš kitų duomenų šaltinio/ informacinių sistemų), jei n÷ra galimyb÷s keistis duomenimis elektroniniu automatizuotu būdu (pvz. sveikatos priežiūros specialistų registro sinchronizavimui). Duomenų pakeitimus galima atlikti tik rankiniu būdu, naudojantis tam skirta naudotojo sąsaja (ekranin÷mis formomis).

Duomenų tvarkymas rankiniu būdu didina sistemos palaikymo sąnaudas bei klaidų tikimybę. Visa informacija tur÷tų būti tvarkoma kuo arčiau duomenų šaltinio, o v÷liau perduodama kitiems. Taip pat neišlaikomas svarbus duomenų tvarkymo principas, kad registrų, klasifikatorių, žinynų ir informacijos katalogų duomenys turi būti tvarkomi pirminiame duomenų šaltinyje, o kitur naudojamos tik jų kopijos.

Integracija su SPĮ IS

D.M.19. Numatytos keturios tinklin÷s paslaugos [11] su kitomis sistemomis, kurias teikia NESS branduolys: ► Vizito planavimas pagal konkretų

siuntimą (CareTransferPromise); ► Siuntimas specialisto konsultacijai

(CareTransferRequest); ► Paslaugos teikimo pabaiga

(CompleteCareProvision); ► Paciento registracija

(PRPA_IN201311). Šios paslaugos realiai n÷ra naudojamos išorinių IS. NESS klientas šių paslaugų taip pat nenaudoja. Neįmanoma įvertinti sąsajų efektyvumo, nes: ► n÷ra nei vienos SPĮ realiai naudojančios

šią sąsają; ► n÷ra realizuota integracinių testų sąsajos

veiklos tikrinimui. Reali integracija naudojantis šiomis paslaugomis nevyksta. Prie vienos iš šių paslaugų dokumentacijoje pažym÷ta, kad šiame etape ji netur÷tų būti naudojama. Dar viena paslauga visiškai nedokumentuota ir neįgyvendinta.

SPĮ skirtomis paslaugomis realiai niekas nesinaudoja. SPĮ naudojančioms savo informacines sistemas. SPĮ skirtos sąsajos arba nerealizuotos, arba neištestuotos. Visos kitos NESS branduolio teikiamos paslaugos orientuotos į NESS kliento aptarnavimą. Tad šių paslaugų panaudojimas iš SPĮ informacinių sistemų taip pat ribotas (ankstesniuose punktuose pateikiama informacija apie šias paslaugas).




SVEIKATOS APSAUGOS

MINISTERIJA


Yra užuomazgų, kad buvo įgyvendinta siuntimo specialisto konsultacijai paslauga iš NESS kliento. Tačiau ji nenaudojama (iš programinio kodo nesimato, kad būtų formuojami atitinkamos struktūros pranešimai).

4.3.4.3.4.3.4.3. Pasiūlymai ir rekomendacijosPasiūlymai ir rekomendacijosPasiūlymai ir rekomendacijosPasiūlymai ir rekomendacijos Atsižvelgiant į esamos situacijos analiz÷s metu užfiksuotus pasteb÷jimus bei galimą eSPBI IS architektūrą, siūloma:

4.3.1. Pasiūlymai ir rekomendacijos duomenų mainų sąsajų su išorin÷mis sistemomis pl÷timuiPasiūlymai ir rekomendacijos duomenų mainų sąsajų su išorin÷mis sistemomis pl÷timuiPasiūlymai ir rekomendacijos duomenų mainų sąsajų su išorin÷mis sistemomis pl÷timuiPasiūlymai ir rekomendacijos duomenų mainų sąsajų su išorin÷mis sistemomis pl÷timui

► Duomenų mainų sąsajos su išorin÷mis sistemomis, kai keičiamasi klinikiniais duomenimis, turi būti pagrįstos standartu (pvz. HL7 v3). Jei tai ne klinikiniai duomenys, pavyzdžiui, Registrų duomenys, klasifikatoriai, tai duomenų apsikeitimo formatas turi būti išsamiai dokumentuotas ir viešai prieinamas. (Pagal pasteb÷jimus D.M.1, D.M.2, D.M.3, D.M.4, D.M.5, D.M.6, D.M.7)

► Naujai diegiamoms duomenų mainų paslaugoms parengti detalią dokumentaciją apie duomenų mainus su išorin÷mis sistemomis, nurodant (Pagal pasteb÷jimus D.M.1, D.M.2, D.M.3, D.M.4, D.M.5, D.M.19):

• detalias XML schemas ir WSDL;

• prisijungimo prie testin÷s aplinkos būdus ir galimybes;

• pranešimų siuntimo eigą (pateikiant proceso aprašymą ir diagramas);

• testavimo scenarijus su testinių pranešimų pavyzdžiais (tiek užklausų, tiek atsakymų).

► Pašalinti trūkumus, susijusius su 025-a/LK formos (ar jos duomenų rinkinio ekvivalento) perdavimu į IS SVEIDRA (pridedant trūkstamus laukus). (Pagal pasteb÷jimą D.M.8)

► Realizuoti išorinę NESS branduolio teikiamą paslaugą, skirtą SPĮ, 025-a/LK formos (ar jos duomenų rinkinio ekvivalento) perdavimui. (Pagal pasteb÷jimus D.M.6, D.M.7, D.M.9, D.M.19)

► Realizuoti išorinę NESS branduolio teikiamą paslaugą demografiniams duomenims iš IS SVEIDRA apie pacientą gauti. (Pagal pasteb÷jimus D.M.6, D.M.7, D.M.10, D.M.19)

► NESS kliente realizuoti automatinį asmens sveikatos draudimo būsenos patikrinimą. (Pagal pasteb÷jimus D.M.6, D.M.7, D.M.11, D.M.19)

► Realizuoti registrų ir klasifikatorių duomenų sinchronizavimo funkcionalumą su pirminiais duomenų šaltiniais (jei eSPBI IS n÷ra pirminis duomenų šaltinis). (Pagal pasteb÷jimus D.M.15, D.M.16, D.M.17, D.M.18)




SVEIKATOS APSAUGOS

MINISTERIJA

► Realizuoti išorines NESS branduolio teikiamas klasifikatorių ir registrų duomenų užklausų paslaugas, kurias gal÷tų naudoti SPĮ. (Pagal pasteb÷jimus D.M.6, D.M.7, D.M.15, D.M.16, D.M.17, D.M.18, D.M.19)

► Visoms SPĮ turi būti realizuotos vieningos duomenų apsikeitimo sąsajos, o su trečiųjų šalių sistemomis (SVEIDRA, SODRA, VAISKIS ir kt.) duomenų apsikeitimas turi vykti taip pat per eSPBI IS duomenų mainų platformą. (Pagal pasteb÷jimus D.M.1, D.M.12, D.M.13, D.M.14, D.M.19)

► Diskusijų ir pokalbių metu su SANTA, KMUK ir KUL buvo pamin÷ta nemažai duomenų apsikeitimo scenarijų, kurie gal÷tų palengvinti SPĮ ir gydymo specialistų darbą. Galima išskirti šiuos pagrindinius duomenų mainų scenarijus: (Pagal pasteb÷jimą D.M.19)

• Siuntimas pas specialistą ir atsakymo perdavimas atgal (epikriz÷).

• Tyrimų informacijos perdavimas.

• Tyrimų informacijos užklausos ir atsakymai su laboratorijomis.

• Duomenų apsikeitimas su SVEIDRA (025-a/LK, sveikatos specialistų ir gydymo įstaigų klasifikatoriai).

• Nedarbingumo pažym÷jimų registravimas SODROS IS.

• Elektroniniai receptai.

• Įvairių pažymų išdavimas (šiuo metu tai atliekama rankiniu būdu).

• Užklausos nedarbingumo ir neįgalumo lygio nustatymui.

4.3.2. Pasiūlymai ir rekomendacijos d÷l galimyb÷s naudotis kitomis, tiesiogiai su sveikatos apsauga Pasiūlymai ir rekomendacijos d÷l galimyb÷s naudotis kitomis, tiesiogiai su sveikatos apsauga Pasiūlymai ir rekomendacijos d÷l galimyb÷s naudotis kitomis, tiesiogiai su sveikatos apsauga Pasiūlymai ir rekomendacijos d÷l galimyb÷s naudotis kitomis, tiesiogiai su sveikatos apsauga nesusijusiomis, elektronin÷mis paslaugomisnesusijusiomis, elektronin÷mis paslaugomisnesusijusiomis, elektronin÷mis paslaugomisnesusijusiomis, elektronin÷mis paslaugomis

Atsižvelgiant į Viešojo administravimo pl÷tros priemonių plane numatytas priemones, svarstytina šių tiesiogiai su sveikatos apsauga nesusijusių, elektroninių paslaugų realizacija: (Pagal pasteb÷jimą D.M.19)

► Galimyb÷ teikti ir pasitikrinti institucijų teikiamų e. paslaugų būklę;

► Galimyb÷ naudoti tapatyb÷s nustatymo elektronin÷je erdv÷je priemones;

► Galimyb÷ pasitikrinti informaciją apie paciento valstybinio socialinio draudimo statusą;

► Galimyb÷ pateikti informacinius pranešimus gyventojams el. paštu;

► Galimyb÷ naudotis elektronin÷mis Europos sveikatos draudimo kortel÷mis;

► Galimyb÷ užsiregistruoti į pri÷mimą pas sveikatos priežiūros specialistą (bendradarbiavimo lygiu) elektroniniu būdu;




SVEIKATOS APSAUGOS

MINISTERIJA

► Galimyb÷ teikti duomenis Statistikos departamentui prie Lietuvos Respublikos Vyriausyb÷s elektroniniu būdu;

► Galimyb÷ užsakyti gimimo ir mirties liudijimus elektroniniu būdu;

► Galimyb÷ teikti ir gauti pacientų medicininius duomenis d÷l darbingumo, neįgalumo lygio, specialistų ar profesin÷s reabilitacijos paslaugų poreikio nustatymo elektroniniu būdu;

► Galimyb÷ užsiregistruoti iš anksto d÷l neįgalumo ir darbingumo nustatymo elektroniniu būdu;

► Galimyb÷ teikti ir gauti informaciją apie socialines išmokas ir kompensacijas, susijusias su sveikatos paslaugomis, elektroniniu būdu;

► Galimyb÷ naudotis Valstybinio socialinio draudimo fondo valdybos prie Socialin÷s apsaugos ir darbo ministerijos teikiamomis socialin÷mis paslaugomis elektroniniu būdu;

► Galimyb÷ patikrinti informaciją apie vaistus elektroniniu būdu.




SVEIKATOS APSAUGOS

MINISTERIJA

5.5.5.5. NESS sprendimo technin÷s infrastruktūros naujumo ir tinkamumo gamybinei NESS sprendimo technin÷s infrastruktūros naujumo ir tinkamumo gamybinei NESS sprendimo technin÷s infrastruktūros naujumo ir tinkamumo gamybinei NESS sprendimo technin÷s infrastruktūros naujumo ir tinkamumo gamybinei eksploatacijai eksploatacijai eksploatacijai eksploatacijai įvertinimasįvertinimasįvertinimasįvertinimas

5.1.5.1.5.1.5.1. Vertinimo metodika bei atlikti darbaiVertinimo metodika bei atlikti darbaiVertinimo metodika bei atlikti darbaiVertinimo metodika bei atlikti darbai Vertinimo metu buvo atlikta:

► egzistuojančios NESS technin÷s įrangos fizin÷ apžiūra (2009-11-10, VLK duomenų centre);

► atlikti interviu su SAM darbuotoju (2009-11-10, Mindaugas Mineikis);

► įvertinta technin÷ infrastruktūra pagal CobIT apibr÷žiamus informacinių sistemų kriterijus: našumas (angl. effectiveness), rezultatyvumas (angl. efficiency), konfidencialumas (angl. confidenciality), vientisumas (angl. integrity), prieinamumas (angl. availability), atitiktis (angl. compliance), patikimumas (angl. reliability).

Toliau lentel÷je pateikiamas kiekvieno kriterijaus apibūdinimas.

6 lentel÷. Vertinimo kriterijų aprašymas.

Elektronin÷s informacijos savyb÷ Apibūdinimas

Konfidencialumas Su informacin÷je sistemoje tvarkoma elektronine informacija gali susipažinti tik tam įgalioti asmenys.

Našumas Elektronin÷ informacija tvarkoma efektyviai, automatizuotai, minimizuojant klaidų kiekį.

Rezultatyvumas Elektronin÷ informacija tvarkoma pagal jos tvarkymo tikslus.

Vientisumas Elektronin÷ informacija nebuvo atsitiktiniu ar neteis÷tu būdu pakeista ar sunaikinta.

Prieinamumas Elektronin÷ informacija gali būti tvarkoma reikiamu metu.

Patikimumas Elektronin÷ informacija gali būti tvarkoma nepertraukiamai reikiamu metu.

Atitiktis Elektronin÷ informacija tvarkoma ir apsaugoma pagal visus ją reglamentuojančius dokumentus ir procedūras.




SVEIKATOS APSAUGOS

MINISTERIJA

Analiz÷s metu surinkta informacija apibendrintai pateikiama 1 priede „IS katalogas“, detali informacija pateikiama 2 priede „Detali infrastruktūros analiz÷s informacija“.

NESS infrastruktūra yra grįsta 4 „blades“ tipo modulin÷mis tarnybin÷mis stotimis, atliekančiomis duomenų bazių, autentikavimo-saugos, branduolio-tinklinių paslaugų ir testavimo funkcijas. Šios tarnybin÷s stotys yra sujungtos tarpusavyje komutatoriais ir per ugniasienę prijungtos prie išorinio tinklo. Išorin÷s duomenų saugyklos yra dvi, prijungtos per duomenų saugyklų komutatorių. Išorin÷s duomenų saugyklos yra apsaugotos nepertraukiamu elektros šaltiniu. NESS esama infrastruktūros schema pateikta žemiau esančiuose paveiksluose (žr. 2 pav. ir 3 pav.):

Internetas

ISP “Infostruktūra“

NetScreen

3x HP BL 120p

1x HP BL 60p

PSU

FC Switch

UPS

HP StorageWorks MSA1000

14x 72,8 Gb Ultra320 SCSI 15k

HP StorageWorks MSA1500

6x 300 Gb Ultra320 SCSI 10k

VLK duomenų centras

3 pav. Apibendrinta esamos NESS infrastruktūros schema.




SVEIKATOS APSAUGOS

MINISTERIJA

4 pav. Apibendrinta NESS tarnybinių stočių schema.

5.2.5.2.5.2.5.2. Pagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimai

Atsižvelgiant į analiz÷s metu išnagrin÷tuose dokumentuose bei interviu metu surinktą bei pateiktą informaciją, toliau lentel÷je pateikiami pagrindiniai pasteb÷jimai NESS sprendimo technin÷s infrastruktūros vertinimui: ► Esama technin÷s įrangos sąranka neatitinka aukšto veikimo patikimumo ir saugos poreikių (esamas

NESS sprendimas yra nepakankamas tenkinti nacionalinio lygmens sprendimo naudojimui keliamus reikalavimus). Programinių ir techninių komponentų paj÷gumai tur÷tų būti plečiami, užtikrinamas aukštas sistemos patikimumas ir sauga.

7 lentel÷. NESS sprendimo technin÷s infrastruktūros vertinimo pasteb÷jimai


T.I.1. Vertinta technin÷s įrangos infrastruktūra pagal našumą, patikimumą ir prieinamumą yra nepakankama tenkinti nacionaliniam NESS naudojimui keliamus reikalavimus [2].

Įdiegtas technin÷s įrangos sprendimas veikia kaip pilotinis diegimas, yra tinkamas funkciniam testavimui ar informacin÷s sistemos vystymui. Esama infrastruktūra negali užtikrinti stabilaus ir kokybiško nacionalinio lygmens informacin÷s sistemos darbo.

Pastaba: šiuo metu naudojama NESS technin÷s

įrangos sąranka yra nuomojama pagal technin÷s

įrangos nuomos sutartį.

Technin÷ įrangos infrastruktūra

T.I.2. Tarnybin÷s stotys. Keturiose (4-iose) atskirose tarnybin÷se stotyse yra įdiegtos atskirtos funkcijos (duomenų baz÷s

Tarnybinių stočių našumas NESS pradiniame naudojime (pilotiniame diegime) yra pakankamas, tačiau neadekvatus nacionaliniam




SVEIKATOS APSAUGOS

MINISTERIJA


tarnybin÷ stotis, autentikavimo tarnybin÷ stotis, NESS branduolio-tinklinių paslaugų (WebMethods) tarnybin÷ stotis, testin÷ tarnybin÷ stotis). N÷ra įdiegtas funkcijų dubliavimo (aukšto prieinamumo sprendimai technin÷s įrangos gedimo atveju). Dalis tarnybinių stočių buvo neprieinamos laikotarpiais 5/17/2008 - 3/29/2009, 4/29/2009- 11/10/2009 (informacija paremta rezervinio duomenų kopijavimo audito įrašais).

naudojimui, pagal planuotas apkrovas [2]. Informacin÷s sistemos funkcijos yra įdiegtos į fiziškai atskiras tarnybines stotis, atskiriant ir izoliuojant kiekvienai komponentei tenkančią apkrovą nuo kitų komponentų. Tokiu atveju, pavyzdžiui, duomenų baz÷s tarnybin÷s stoties apkrova neįtakoja kitų komponentų funkcionalumo ir greitaveikos. Esamos technin÷s įrangos sąrankos tarnybin÷s stotys yra pasenusios ir jų gamyba yra nutraukta, tod÷l nuoseklus sistemos plečiamumas yra apribotas (nutraukta ir nebepalaikoma gamyba „blades chassis“). Esamoje informacin÷s sistemos architektūroje aukštas prieinamumas ir patikimumas n÷ra realizuoti. Sugedus vienai tarnybinei stočiai visa sistema bus neprieinama ir negal÷s funkcionuoti. Neegzistuojantys informacin÷s sistemos komponentų steb÷jimo bei persp÷jimo mechanizmai neleidžia operatyviai gauti informaciją apie gedimą, tod÷l kyla rizika, kad diagnostika ir atstatymas bus organizuojami neefektyviai. Tarnybin÷s stotys n÷ra apsaugotos nuo elektros trūkio (kitaip nei diskų masyvai), o tai gali įtakoti ir sutrikdyti ne tik informacin÷s sistemos prieinamumą bei funkcionalumą, bet ir padidinti duomenų vientisumo praradimo tikimybę duomenų baz÷se. Šiuo atveju, visos tarnybin÷s stotys yra SPoF taškai (angl. single point of failure).

T.I.3. Duomenų saugyklos. Operacin÷s sistemos tarnybin÷se stotyse yra įdiegtos į tarnybinių stočių vidinius kietuosius diskus. Kiekviena tarnybin÷ stotis turi po du (2) kietuosius diskus, sukonfigūruotus į RAID1 diskų

Tarnybinių stočių bei diskų masyvų našumas NESS pradiniame naudojime (pilotiniame diegime) yra pakankamas pagal numatytas apkrovas [2], tačiau neadekvatus nacionaliniam naudojimui .




SVEIKATOS APSAUGOS

MINISTERIJA


masyvus. Šie diskai taip pat yra naudojami ir informacin÷s sistemos duomenims laikyti. Esami išoriniai diskų masyvai yra naudojami rezervin÷ms duomenų kopijoms saugoti. Pastaba:Jų konfigūracijos nepavyko patikrinti d÷l signalinio konsolinio kabelio nebuvimo.

Duomenų saugyklos n÷ra skirtos didel÷ms sistemoms ir n÷ra pritaikytos plečiamumo poreikiams [2], taip pat jų gamyba yra nutraukta. Esama kietųjų diskų konfigūracija tarnybin÷se stotyse apsaugo nuo vieno kietojo disko gedimo kiekvienoje tarnybin÷je stotyje. Tačiau nesant įdiegtų informacin÷s sistemos komponentų steb÷jimo bei persp÷jimo mechanizmų, apie tokį gedimą nebus pateikta savalaik÷ informacija. Sugedus antram tos pačios tarnybin÷s stoties kietajam diskui visa informacin÷ sistema nebefunkcionuos. Vienas iš esamų diskų masyvų turi tik vieną diskų valdiklį. Sutrikus diskų valdiklio funkcionalumui d÷l technin÷s įrangos gedimo, visa tame diskų masyve esanti informacija bus nepasiekiama. Diskų masyvai prie tarnybinių stočių n÷ra prijungti dubliuotomis jungtimis. Technin÷s įrangos gedimo atveju, diskų masyvuose esanti informacija bus nepasiekiama. Informacijos konfidencialumas organizuojamas tik standartin÷mis Operacin÷s sistemos priemon÷mis, o operacin÷s sistemos saugos spragos n÷ra reguliariai taisomos. Technin÷s įrangos gedimo atveju, kyla rizika, nes diskų masyvai yra SPoF taškai.

T.I.4. Tinklo topologija. Tarnybin÷s stotys yra dubliuotais prievadais sujungtos į 1 Gbps greitaveikos vietinį kompiuterinį tinklą, kurį užtikrina „blade“ šasi sumontuoti vidiniai kompiuterių tinklo komutatoriai. Sujungimas su išore (ugniasiene) n÷ra dubliuotas. Diskų masyvai sujungti į SAN FC tipo

Tarnybinių stočių bei diskų masyvų našumas NESS pradiniame naudojime (pilotiniame diegime) yra pakankamas pagal numatytas apkrovas [2], tačiau neadekvatus nacionaliniam naudojimui. N÷ra žinoma išorinio prisijungimo greitaveika, d÷l to negalime daryti išvadų apie interneto




SVEIKATOS APSAUGOS

MINISTERIJA


duomenų perdavimo tinklą, tačiau nebuvo technin÷s galimyb÷s prisijungti prie SAN duomenų perdavimo tinklo komponentų patikrinimui (n÷ra konsolinio laido). Login÷ prieigos kontrol÷ iš išor÷s yra organizuojama ugniasiene keičiant jos konfigūraciją.

greitaveiką bei galimybes užtikrinti pakankamą duomenų srauto pralaidumą išor÷s vartotojams darbui su informacine sistema. Login÷ prieigos kontrol÷ tvarkoma rankin÷mis (neautomatizuotomis) priemon÷mis, tod÷l yra didel÷ klaidų rizika ir nenašus darbas prijungus daug naudotojų. Duomenų perdavimo tinklas organizuojamas standartin÷mis priemon÷mis – Ethernet, FC ir TCP/IP protokolais, tod÷l tinklas yra lengvai valdomas. Aukštas prieinamumas ir patikimumas vidiniame kompiuterių tinkle yra užtikrinamas iš dalies. Prieiga su išore (ryšys su ugniasiene) n÷ra dubliuota, tod÷l nutrūkus ryšiui, sistema nebus pasiekiama. Šiuo atveju, yra keletas SPoF taškų („single point of failure“).

T.I.5. Fizin÷ prieigos kontrol÷ organizuojama VLK duomenų centro taisykles.

Fizin÷ prieigos kontrol÷ organizuojama pagal veikiančias ir apibr÷žtas VLK vidines tvarkas, nustatančias patekimo į tarnybinių stočių patalpas sąlygas (pvz. privalomas lydintis asmuo, įrašai žurnale apie įeinančius ir išeinančius asmenis).

T.I.6. Atsarginių duomenų kopijavimas s÷kmingai vyko tik tarp 3/18/2008 ir 5/17/2008. V÷liau jis buvo arba nes÷kmingas, arba tarnybin÷s stotys buvo neprieinamos. Įdiegti rezervinio kopijavimo agentai neatitinka tarnybinių stočių funkcijų. N÷ra rezervinio kopijavimo veikimo aprašo, rezervinių kopijų testavimo dokumentacijos. Rezervinių kopijų testavimas nebuvo atliekamas. Vykdant rezervinį kopijavimą, duomenys n÷ra koduojami, kas yra būtina išvežant rezervines kopijas iš pirminio duomenų centro d÷l saugos.

Rezervinio duomenų kopijavimo sprendimo patikimumas ir našumas NESS pradiniame naudojime (pilotiniame diegime) yra pakankamas, tačiau neadekvatus nacionaliniam naudojimui. Rezervin÷s kopijos n÷ra išvežamos iš duomenų centro, tod÷l sunaikinus duomenų centrą, visi duomenys dingtų. Įdiegtos rezervinio kopijavimo audito priemon÷s, rezervinių kopijų įrašymo statistikos yra pateiktos priede (žr. . Prieinamumas ir patikimumas yra žemas d÷l steb÷jimo sistemos ir rezervinio kopijavimo veikimo aprašo bei rezervinių kopijų testavimo




SVEIKATOS APSAUGOS

MINISTERIJA


Rezervinių duomenų kopijų suderinamumas yra tik su HP Data Protector programine įranga.

dokumentacijos nebuvimo. Kadangi rezervinių kopijų vientisumas n÷ra testuojamas, sugedus rezervinio kopijavimo mechanizmui, kyla rizika, kad bus sud÷tinga atkurti duomenis iš rezervinių kopijų d÷l informacijos apie rezervinę duomenų kopijavimo sistemą trūkumo.

T.I.7. Veiklos atstatymo po katastrofos (Disaster Recovery) sprendimas n÷ra realizuotas. Duomenų bei informacin÷s sistemos atstatymas galimas tik iš rezervinių kopijų, kurios saugomos esamuose diskų masyvuose, arba naujai diegiant visą informacinę sistemą. Pastaruoju atveju, visi duomenys būtų prarasti.

Prieinamumo ir patikimumo yra žemo laipsnio. Sunaikinus duomenų centrą (užliejus vandeniu, gaisro atveju, pastato griūties metu ir pan.), kyla rizika, kad bus sunaikinama visa NESS sistema, neišsaugomi jokie duomenys, visa sistemos infrastruktūra bus kuriama iš naujo.

T.I.8. Testin÷ NESS sistema yra realizuota atskiroje tarnybin÷je stotyje nuo darbin÷s aplinkos. Oracle platforma testin÷je aplinkoje skiriasi nuo Oracle platformos gamybin÷je aplinkoje (Windows 2003 testin÷je ir HP-UX gamybin÷je).

Testin÷s aplinkos našumas NESS pradiniame naudojime (pilotiniame diegime) yra pakankamas, tačiau neadekvatus nacionaliniam naudojimui. Duomenų bazių valdymo sistema testin÷je aplinkoje operacin÷s sistemos lygyje n÷ra suderinta su gamybine aplinka. D÷l to gali iškilti papildomų sunkumų realizuojant programinio kodo perk÷limą iš testin÷s aplinkos į gamybinę. N÷ra išskirta testin÷ aplinka SPĮ integracijų testavimui (angl. sandbox), tod÷l išauga rizikos gamybin÷s aplinkos prieinamumui ir našumui, nekorektiškai suintegravus prijungiamas sistemas. Testin÷ aplinka n÷ra kritin÷, tod÷l jos prieinamumas ir patikimumas yra pakankamas.

Programin÷s įrangos infrastruktūra

T.I.9. Tarnybin÷se stotyse yra įdiegtos operacin÷s sistemos Microsoft Windows Server 2003 R2 Standard Edition Service Pack 1 ir HP-UX B.11.23. Aukšto prieinamumo

Našumas ir prieinamumas NESS pradiniame naudojime (pilotiniame diegime) yra pakankamas, tačiau neadekvatus nacionaliniam naudojimui.




SVEIKATOS APSAUGOS

MINISTERIJA


sprendimai n÷ra įdiegti ir sukonfigūruoti (tarnybinių stočių klasteriai). Sistemin÷s programin÷s įrangos naujumo užtikrinimo priemon÷s įdiegtos, tačiau nenaudojamos.

N÷ra vykdomas reguliarus OS atnaujinimų diegimas, tod÷l galimos saugos skyl÷s. Saugos lygio steb÷jimas neatliekamas. N÷ra realizuoti operacinių sistemų aukšto veikimo prieinamumo ir patikimumo mechanizmai, tod÷l OS klaidos arba OS tvarkymo darbai (perkrovimai) žemins prieinamumo rodiklius. Esamos Microsoft Windows operacinių sistemų versijos neturi funkcionalumo aukšto prieinamumo sprendimams realizuoti (klasterizavimo).

T.I.10. Virtualizuotų aplinkų n÷ra. N÷ra įdiegta OS virtualizacijos sprendimų, tod÷l techniniai resursai n÷ra optimaliai išnaudojami.

T.I.11. Duomenų replikavimo bei archyvavimo mechanizmai nesuplanuoti ir nerealizuoti. Yra įdiegta tik HP Data Protector programin÷s įrangos pagrindu veikianti rezervinio kopijavimo sistema, atliekama į išorines diskines saugyklas.

Replikavimo ir archyvavimo mechanizmai yra reikalingi tik nacionaliniam naudojimui ir prognozuojamam duomenų kiekio valdymui, o pilotiniame diegime nenaudojami.

T.I.12. Duomenų bazių valdymo sistema Oracle 10g Enterprise Edition

Našumas NESS pradiniame naudojime (pilotiniame diegime) yra pakankamas, tačiau neadekvatus nacionaliniam naudojimui. Duomenų bazių valdymo sistema atitinka reikalavimus, keliamus patikimoms informacin÷ms sistemoms. Tačiau papildomas duomenų bazių valdymo sistemos aukšto patikimumo sprendimas (RAC) turi būti įgyvendinamas atskirai.

T.I.13. Autentifikavimo mechanizmai : ► OS: standartin÷s Windows ir HP-UX

priemon÷s (administratorių naudotojai su slaptažodžiais);

► Oracle DB: standartiniai mechanizmai;

Autentifikavimo mechanizmai yra pagrįsti „ką žinai“ principu – n÷ra „ką turi“ ir „kas esi“ autentifikavimo mechanizmų, tod÷l sistemos naudojimo autentifikavimo mechanizmas n÷ra pakankamas ir yra lengvai pažeidžiamas.




SVEIKATOS APSAUGOS

MINISTERIJA


► Taikomosios programos – standartiniai mechanizmai;

► Tinklo prieigos – per ugniasien÷s konfigūraciją, ir kliento DNS lenteles.

Prieiga iš nutolusių taškų yra organizuojama rankiniu būdu tinkinant ugniasienę, tod÷l saugos valdymas yra sud÷tingas ir n÷ra efektyviai valdomas ar plečiamas. Įsiv÷lusios konfigūracijų klaidos yra sunkiai aptinkamos ir diagnozuojamos. N÷ra integruoto saugos (autentikacijos, autorizacijos, auditavimo, rolių valdymo, steb÷jimo) mechanizmo, tod÷l saugos incidentų valdymas tampa sud÷tingesnis.

T.I.14. Sistemos steb÷jimo ir valdymo įrankiai: ► Tik rezervinio kopijavimo konsol÷. Tarnybin÷ stotis, skirta steb÷jimui (monza), naudojama kaip testin÷ aplinka.

N÷ra bendros informacin÷s sistemos steb÷jimo ir valdymo priemonių sistemos, automatizuotos priemon÷s padengia tik rezervinį kopijavimą. Tod÷l neefektyvus sistemos steb÷jimas bei valdymas.

T.I.15. Įdiegtų programin÷s įrangos licencijų sąrašas, aptikta: ► Windows Server 2003 R2 Std – 3 lic. ► HP-UX – 1 lic. ► Oracle DB – 2 CPU lic. ► Data Protector įdiegta :

• 3 configured hosts. • 3 Disk Agents • 3 Media Agents • 2 User Interfaces • 3 Oracle Integrations • 1 Automatic Disaster Recovery

Module. ► WebMethods – 2 CPU lic, testavimo

aplinka – 1 lic. ► HP OpenView Select Access 100

naudotojų lic. ► OpenLDAP - nereikalaujama

licencijuoti naudojimą.

Licencijuojamos programin÷s įrangos aptarnavimo sutartys pasibaigusios, versijos pasenusios, nebepalaikomos, arba n÷ra saugios (n÷ra atnaujintos saugos pakeitimais).

Kita:

T.I.16. Geografinis duomenų centrų pasiskirstymas. Informacin÷ sistema n÷ra geografiškai paskirstyta, technin÷ įranga įdiegta VLK duomenų centre, Kalvarijų

Našumas ir prieinamumas NESS pradiniame naudojime (pilotiniame diegime) yra pakankamas, tačiau neadekvatus nacionaliniam naudojimui.




SVEIKATOS APSAUGOS

MINISTERIJA


gatv÷ 147, 9 a. N÷ra įgyvendintas atsparumas duomenų centro neveiksnumui. Praradus esamą duomenų centrą būtų prarasta ir informacin÷ sistema bei visi joje saugomi duomenys.

T.I.17. NESS1 saugos procedūros ir taisykl÷s. Saugos procedūros ir administravimo taisykl÷s n÷ra dokumentuotos ar apibr÷žtos. Vadovaujamasi SAM bendromis taisykl÷mis. Fizin÷ prieiga prie duomenų centro organizuojama pagal VLK vidaus taisykles.

Nesant saugos procedūroms ir administravimo taisykl÷ms, n÷ra reglamentuoti reikalingi saugos lygiai, paskirtos atsakomyb÷s d÷l informacin÷s sistemos ir jos komponentų priežiūros ir administravimo funkcijų vykdymo.

T.I.18. Sistema n÷ra suskaidyta į saugos zonas (demilitarizuota, vidin÷, išorin÷).

Saugos zonų nebuvimas padidina saugos incidentų, konfidencialumo praradimo rizikas.


Atsižvelgiant į esamos situacijos vertinimo metu užfiksuotus pasteb÷jimus bei galimą eSPBI IS architektūrą, siūloma:

5.3.1. Pasiūlymai ir Pasiūlymai ir Pasiūlymai ir Pasiūlymai ir rekomendacijos technin÷s infrastruktūros tobulinimuirekomendacijos technin÷s infrastruktūros tobulinimuirekomendacijos technin÷s infrastruktūros tobulinimuirekomendacijos technin÷s infrastruktūros tobulinimui

► Apibr÷žti plečiamos eSPBI IS tikslus atitinkančius veiklos tęstinumo planus, sistemos, naudotojų ir rolių administravimo taisykles, pokyčių valdymo tvarkas, rizikų įvertinimą, reglamentuoti sistemos atitikties (angl. compliance) teis÷s aktams valdymą. (Pagal pasteb÷jimus T.I.1, T.I.2, T.I.3, T.I.4, T.I.5, T.I.6, T.1.7, T.1.12, T.I.13, T.I.14, T.I.17)

► Po sutarties pasibaigimo 2009 lapkričio 22d nebepratęsti turimos infrastruktūros nuomos sutarties, nes technin÷ įranga yra morališkai pasenusi ir jos palaikymas yra finansiškai nenaudingas. (Pagal pasteb÷jimus T.I.1, T.I.2, T.I.4, T.I.15)

Pastaba: esamų licencijų panaudojimo galimybes reikia įvertinti pagal nacionalin÷s informacin÷s sistemos naują architektūrą, ypač tik testavimo ir sistemos kūrimo aplinkos reikm÷ms. Priklausomai nuo pasirinktų NESS pl÷tros architektūros ir infrastruktūros sprendimų, testavimo ir kūrimo aplinkos programin÷s įrangos licencijų ir jų palaikymo rinkiniai tur÷s būti papildomi ir/ arba atnaujinami. Naujajai eSPBI IS gamybinio naudojimo infrastruktūrai bus reikalingas naujas (pilnas) ir/ arba atnaujintas licencijų rinkinys.

► Sukurti eSPBI IS gamybinę infrastruktūrą, kuri būtų grįsta plečiamumo, 24x7x365 prieinamumo, patikimumo, konfidencialumo, duomenų nepraradimo, efektyvaus valdymo, bei




SVEIKATOS APSAUGOS

MINISTERIJA

ekonomiškumo principais. (Pagal pasteb÷jimus T.I.1, T.I.2, T.I.3, T.I.4, T.I.6, T.I.7, T.I.8, T.I.9, T.1.12, T.I.13, T.I.14)

► Gamybin÷s eSPBI IS infrastruktūros komponentai (tarnybin÷s stotys, duomenų saugyklos, komunikacijos) turi būti: (Pagal pasteb÷jimus T.I.1, T.I.2, T.I.3, T.I.4, T.I.6, T.I.7, T.I.9, T.1.12, T.I.14, T.I.16)

• Universalūs, pvz., tokios pačios tarnybin÷s stotys turi tikti bet kuriai sistemos posistemei realizuoti bei grįsti virtualizacijos (fizinių resursų nuo loginių atskyrimo) principu.

• Pradinis fizinių komponentų kiekis ir jų išsid÷stymas turi būti be SPoF taškų (sugedus bet kuriam komponentui sistema privalo veikti po rankinio ar automatinio tinkinimo pilnu funkcionalumu, tačiau galimas mažesnis našumas).

• Sistemos komponentų apkrovai pasiekus tam tikrą apibr÷žtą lygį, turi būti galimyb÷ prijungti papildomą tokį pat komponentą ir taip padidinti sistemos našumą, be sistemos prieinamumo sutrikimų. Infrastruktūros plečiamumo bendri kaštai turi proporcingai (ne eksponentiškai) augti plečiant infrastruktūrą augant funkcionalumui.

• Paskirstyti geografiškai bent per du duomenų centrus, kad vienam iš jų tapus neveiksniam, kito duomenų centro infrastruktūra užtikrintų visą sistemos funkcionalumą su galimai mažesniu našumu. Pirmam duomenų centrui atgijus, sistemos našumas turi būti atstatomas į normalaus veikimo režimą.

• Turi būti vieninga ir integruota infrastruktūros valdymo sistema, skirta steb÷ti, informuoti ir valdyti infrastruktūros komponentus, informacijos rezervinio kopijavimo procesų būseną, saugos elementų būsenas bei incidentus. Ši sistema turi sugeb÷ti aptarnauti plečiamą infrastruktūrą ir atskirtus duomenų centrus.

• Rinktis standartais grįstus sprendimus, taip gerinant suderinamumą ir tolimesnį vystymą.

5.3.2. Pasiūlymai ir rePasiūlymai ir rePasiūlymai ir rePasiūlymai ir rekomendacijos sisteminei programinei įrangaikomendacijos sisteminei programinei įrangaikomendacijos sisteminei programinei įrangaikomendacijos sisteminei programinei įrangai

► Visa naudojama sistemin÷ programin÷ įranga (OS, rezervinio kopijavimo posistem÷, duomenų baz÷s, saugos sistemos) privalo palaikyti centralizuotą valdymą, funkcionalumo ir saugos atnaujinimų galimybes neįtakojant sistemos pasiekiamumo. Taip pat ji turi tur÷ti centralizuoto saugos ir įvykių auditavimo funkcionalumą. (Pagal pasteb÷jimus T.I.1, T.I.3, T.I.9, T.I.11, T.I.12, T.I.14)

► Rekomenduojama naudoti tarnybinių stočių virtualizacijos programinę įrangą taip ekonomiškai ir lanksčiai gerinant prieinamumą, valdomumą, patikimumą. Kita programin÷ įranga turi būti suderinta su virtualizacijos sprendimais, taip mažinant priklausomybę nuo konkrečios fizin÷s įrangos. (Pagal pasteb÷jimus T.I.10)

► Turi būti naudojama sistemos steb÷jimo, valdymo programin÷ įranga. (Pagal pasteb÷jimus T.I.1, T.I.3, T.I.14)




SVEIKATOS APSAUGOS

MINISTERIJA

5.3.3. Pasiūlymai ir rekomendacijos saugos valdymuiPasiūlymai ir rekomendacijos saugos valdymuiPasiūlymai ir rekomendacijos saugos valdymuiPasiūlymai ir rekomendacijos saugos valdymui

► Apibr÷žti ir audituoti fizin÷s prieigos valdymo saugos procedūras ir priemones; (Pagal pasteb÷jimus T.I.1, T.I.5, T.I.17)

► Apibr÷žti ir audituoti login÷s prieigos valdymo saugos procedūras ir priemones; (Pagal pasteb÷jimus T.I.1, T.I.4, T.I.13, T.I.17)

► Naudoti integruotą sistemos saugos sistemą su sistemos steb÷jimo ir valdymo sistema; (Pagal pasteb÷jimus T.I.1, T.I.4, T.I.13, T.I.14)

► Saugos sistema turi valdyti: (Pagal pasteb÷jimus T.I.1, T.I.4, T.I.13, T.I.14)

• Universalų unikalų autentikavimą visų dalyvių (sistemos naudotojus, kūr÷jus, testuotojus, administratorius), nesvarbu kokiomis priemon÷mis autentikuojamasi (vardu ir slaptažodžiu, skaitmeniniu sertifikatu, ar kitu metodu). Turi būti apibr÷žtas vartotojų sistemoje gyvavimo laikas.

• Autorizavimą ir autorizavimo valdymą. Autorizacijos organizavimas turi būti grįstas rol÷mis (RBAC) metodais ir naudojamas visiems autentikuotiems vartotojams.

Pastaba: Autorizacijos pirmin÷ prielaida – su pacientu susiję duomenys yra paciento nuosavyb÷ ir gali būti

prieinami tik su paciento leidimu/ sutikimu.

• Auditą.

► Audito posistem÷ turi užtikrinti renkamos informacijos integralumą ir kaupti informaciją apie: (Pagal pasteb÷jimus T.I.1, T.I.4, T.I.13, T.I.14)

• Visas informacijos tvarkymo operacijas NESS sistemoje;

• Visas autentikavimosi operacijas;

• Visus autorizavimo teisių pokyčius.

► Duomenų konfidencialumas turi būti užtikrintas gamybin÷je, testin÷je, vystymo, rezervinio kopijavimo, informacijos perdavimo, veiklos atstatymo aplinkose loginio atskyrimo (saugos zonomis, infrastruktūriškai), užkodavimo, autorizacijos ir duomenų nuasmeninimo priemon÷mis, jas parenkant pagal susijusių rizikų ir gr÷smių įvertinimus bei teisinius atitikties reikalavimus. (Pagal pasteb÷jimus T.I.1, T.I.4, T.I.6, T.I.7, T.I.8, T.I.10, T.I.13, T.I.17, T.I.18)

5.3.4. Rekomendacijos IS infrastruktūros ir Rekomendacijos IS infrastruktūros ir Rekomendacijos IS infrastruktūros ir Rekomendacijos IS infrastruktūros ir saugos valdymuisaugos valdymuisaugos valdymuisaugos valdymui

► Apibr÷žti programin÷s įrangos licencijų valdymo procesą (apimant licencijų atnaujinimus, pratęsimus, palaikymus, plečiamumą), taip efektyviai valdant ir planuojant finansus ir atitiktį licencijavimo reikalavimams. (Pagal pasteb÷jimus T.I.1, T.I.3, T.I.4, T.I.9, T.I.15)




SVEIKATOS APSAUGOS

MINISTERIJA

► Apibr÷žti programin÷s įrangos atnaujinimo valdymo procesą (apima pataisymus, saugos skylių lopymus), siekiant apsisaugoti nuo konfidencialumo d÷l įsilaužimų pasinaudojus saugos skyl÷mis. (Pagal pasteb÷jimus T.I.1, T.I.3, T.I.4, T.I.8, T.I.9, T.I.13)

► Apibr÷žti atitikties valdymo procesą reglamentuojančius teisinius dokumentus, siekiant apsisaugoti nuo teisinių ir administracinių pažeidimų bei efektyviai planuoti atitiktį. (Pagal pasteb÷jimus T.I.1, T.I.11)

► Infrastruktūros priežiūros ir administravimo tvarkas integruoti su duomenų apsaugos, integralumo, pasiekiamumo taisykl÷mis (rezervinio kopijavimo tvarkos, veiklos atstatymo tvarkos). (Pagal pasteb÷jimus T.I.1, T.1.2, T.I.3, T.I.6. T.I.7, T.I.11, T.I.17)

► Paj÷gumų valdymo procesas turi apimti infrastruktūros plečiamumo procedūras: (Pagal pasteb÷jimus T.I.1, T.I.2, T.I.3, T.I.4, T.I.6, T.I.7, T.I.8, T.I.14, T.I.17)

• Komponentų apkrovos ribas, kurias pasiekus infrastruktūra plečiama naujais komponentais.

• Paskaičiavimus, kokių papildomų komponentų reik÷s pl÷trai plečiant techniniu komponentu (technin÷s įrangos, programin÷s įrangos licencijų – virtualizacijos, OS, rezervinio kopijavimo, duomenų saugojimo, valdymo, duomenų atstatymo, saugos valdymo, ir pan. )

• Sąsajas su pakeitimų valdymo procesu – naujo komponento įvedimo tvarkas (testavimą, įdiegimo į gamybinę aplinką tvarkas, susiejimą su valdymo ir saugos sistemomis).

► Pakeitimų valdymo procesas turi apimti infrastruktūros pakeitimų tvarkas ir mažinti nepasiekiamumo tikimybę d÷l klaidų sistemos keitimo metu. (Pagal pasteb÷jimus T.I.1, T.I.7, T.I.8, T.I.11, T.I.17)




SVEIKATOS APSAUGOS

MINISTERIJA

6.6.6.6. Informacijos saugos architektūros technologinio naujumo vertinimasInformacijos saugos architektūros technologinio naujumo vertinimasInformacijos saugos architektūros technologinio naujumo vertinimasInformacijos saugos architektūros technologinio naujumo vertinimas


Nagrin÷jant informacin÷s sistemos saugą buvo tikrinamos taikomųjų sistemų pakeitimų valdymo ir login÷s prieigos suteikimo procesų pagrindin÷s kontrol÷s. Taip pat buvo remtasi pasaulyje pripažintos gerosios praktikos informacinių sistemų valdymo srityje CobIT nuostatomis bei atsižvelgiama į ISO 27001 standarto nuostatas.

Techninių ir architektūrinių sprendimų vertinimas buvo atliekamas pagal konfidencialumo, vientisumo, prieinamumo, atitikties bei patikimumo kriterijus, taikomus informacijai (kriterijų aprašymas pateiktas 6.1. skyriuje „Vertinimo metodika bei atlikti darbai“).

Analiz÷s metu buvo apklausiami: ► SAM atstovas Mindaugas Mineikis, 2009 11 10, 2009 11 16, bei išsiųsti informacijos užklausimai

lapkričio 3 ir 11 dienomis;

► Širvintų pirmin÷s sveikatos priežiūros centro atstov÷ Nijol÷ Dimšien÷, 2009 11 16.

Taip pat buvo nagrin÷jama pateikta [1] – [7] dokumentacija.

Atsižvelgiant į pasteb÷jimus bei eSPBI IS viziją, aprašytą 2 skyriuje „Taikomieji e. sveikatos paslaugų uždaviniai ir e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros vizija“, parengti pasiūlymai informacijos saugos architektūrai tobulinti.

6.2.6.2.6.2.6.2. Pagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimaiPagrindiniai pasteb÷jimai

Atsižvelgiant į analiz÷s metu išnagrin÷tuose dokumentuose bei interviu metu pateiktą informaciją, toliau lentel÷je pateikiami pagrindiniai pasteb÷jimai informacijos saugos vertinimui.

8 lentel÷. Informacijos saugos architektūros vertinimo pasteb÷jimai


I.S.1. N÷ra patvirtintų sistemos nuostatų bei informacijos saugą reglamentuojančių dokumentų, kurie apibr÷žtų atsakomybes už sistemos valdymą bei administravimą.

Įteisintų Sistemos saugos dokumentų nebuvimas kelia riziką, kad informacija n÷ra klasifikuojama, n÷ra užtikrinamas pakankamas saugos lygis prieigai prie konfidencialios ar kitų kategorijų informacijos kontroliuoti. Kyla rizika d÷l neteisingo suvokimo, priemonių ir atsakomybių paskirstymo sistemų saugos bei jų tvarkomų duomenų konfidencialumui ir vientisumui užtikrinti. Kadangi n÷ra parengtų informacijos tvarkymą reglamentuojančių dokumentų, n÷ra numatytų steb÷senos priemonių užtikrinti informacijos atitiktį.




SVEIKATOS APSAUGOS

MINISTERIJA


I.S.2. N÷ra patvirtintų naudotojų bei

administratorių prieigos valdymą reglamentuojančių dokumentų. Naudotojų prieigos administravimo NESS saugos sistemoje dokumente numatyti sisteminiai naudotojų kūrimo žingsniai, tačiau n÷ra apibr÷žtas procesas bei procedūros organizacine prasme. Dokumente aprašytos galimyb÷s kurti naujas naudotojų grupes bei vaidmenis, tačiau n÷ra dokumento, apibr÷žiančio standartines naudotojų grupes bei vaidmenis. Šiuo metu NESS sistemoje sukurtiems naudotojams bei administratoriams prieigos teis÷s buvo suteiktos NESS diegimo metu. Po sistemos pri÷mimo naudotojų (ir administratorių) teis÷s nebuvo keistos, peržiūr÷tos ar panaikintos.

Standartinių naudotojų grupių bei vaidmenų matricos neapibr÷žimas kelia riziką, kad darbuotojams, atliekantiems tas pačias funkcijas, bus suteiktos skirtingos prieigos teis÷s sistemoje. Nepatvirtinus naudotojų login÷s prieigos valdymo tvarkos, n÷ra apibr÷žtos atsakomyb÷s už prieigos inicijavimą, tvirtinimą, kūrimą, peržiūrą ir naikinimą. Nesant aiškiai procedūrai, kyla rizika, kad sistemoje prieigos neatitiks realiai reikalingų prieigų darbuotojams, pagal jų atliekamas funkcijas. Taip pat kyla rizika, kad pasikeitus naudotojų pareigoms ar funkcijoms, prieigos teis÷s nebus atitinkamai pakeistos, o iš÷jusių darbuotojų teis÷s nebus panaikintos sistemoje, taip suteikiant galimybę naudotojams pasiekti informaciją, prie kurios jie netur÷tų gauti pri÷jimo. Tod÷l n÷ra užtikrinama login÷s prieigos suteikimo ir tvarkymo bei informacijos atitikimo keliamiems saugos ir vientisumo ir konfidencialumo reikalavimams užtikrinimo kontrol÷.

I.S.3. N÷ra tikrinamos sistemos apsisaugojimo nuo nesankcionuoto išorinio įsiskverbimo galimyb÷s (angl. penetration testing).

Neatliekant nesankcionuoto išorinio įsiskverbimo galimybių testavimo, n÷ra įvertinamas saugos lygis, bei saugos spragų buvimas. Periodiškai neatliekant nesankcionuoto išorinio įsiskverbimo galimybių testavimo, kyla rizika, kad sistemoje nebus įdiegtos atitinkamos saugos priemon÷s apsisaugoti nuo naujausių nesankcionuoto įsiskverbimo metodų ir bus pažeistas ar nebus išlaikytas informacijos vientisumas, konfidencialumas ar patikimumas.

I.S.4. N÷ra reglamentuotos bei patvirtintos pakeitimų valdymo tvarkos. Tarnybin÷ stotis, skirta steb÷jimui (monza), naudojama kaip testin÷ aplinka. Testin÷ bei gamybin÷ sistemos aplinka yra atskirose tarnybin÷se stotyse.

D÷l pakeitimų valdymo tvarkos nebuvimo, n÷ra apibr÷žtos bei reglamentuotos atsakomyb÷s už pakeitimų inicijavimą, tvirtinimą, testavimą ir diegimą. Tod÷l kyla rizika, kad bus diegiami nepatvirtinti pakeitimai, galintys įtakoti tinkamą sistemos veikimą.




SVEIKATOS APSAUGOS

MINISTERIJA


Operacin÷s sistemos šiose tarnybin÷se stotyse yra skirtingos. N÷ra atskiros sistemos kūrimo aplinkos, tačiau yra galimyb÷ įdiegti kūrimo priemones testin÷je ar gamybin÷je aplinkoje. N÷ra įteisintos programin÷s įrangos versijų valdymą reglamentuojančios tvarkos. Taip pat n÷ra įdiegtų įrankių programin÷s įrangos versijoms valdyti.

Versijų valdymo dokumentacijos ir įrankių nebuvimas apsunkina pakeitimų steb÷senos procesą. Atskiros kūrimo aplinkos nebuvimas riboja galimybes užtikrinti sistemos pl÷tros tęstinumą. Tarnybin÷se stotyse, kuriose yra testin÷ bei gamybin÷ sistemos aplinka, Operacin÷s sistemos yra skirtingos. D÷l to gali iškilti papildomų sunkumų realizuojant programų perk÷limą iš testin÷s aplinkos į gamybinę. Netinkamai įdiegti pakeitimai gali įtakoti informacijos prieinamumą, patikimumą bei pažeisti duomenų vientisumą.

I.S.5. N÷ra dokumentuotų bei patvirtintų rezervinio kopijavimo vykdymo bei testavimo procedūrų. Yra įdiegti įrankiai rezerviniam kopijavimui vykdyti. Atsarginių duomenų kopijavimas s÷kmingai vyko tik tarp 3/18/2008 ir 5/17/2008. V÷liau jis buvo arba nes÷kmingas, arba tarnybin÷s stotys buvo neprieinamos. Rezervinių kopijų testavimas nebuvo atliekamas.

D÷l dokumentacijos bei informacijos apie rezervinę duomenų kopijavimo sistemą trūkumo, n÷ra užtikrinamas pakankamas informacijos patikimumas bei prieinamumas. Įvykus nes÷kmingam ar nepilnam duomenų rezerviniam kopijavimui, kyla rizika, kad bus sud÷tinga arba neįmanoma atkurti duomenis iš rezervinių kopijų.

I.S.6. Veiklos atstatymo po katastrofos (angl. Disaster Recovery) tvarka bei planas n÷ra parengtas bei patvirtintas, sprendimas n÷ra realizuotas.

Kadangi n÷ra parengta atstatymo po katastrofos tvarka bei planas ir n÷ra realizuotos atitinkamos priemon÷s, n÷ra užtikrinamas pakankamas duomenų saugos lygis bei savalaikis sistemos atstatymas nelaim÷s atveju (užliejus vandeniui, gaisro atveju, pastato griūties metu ir pan.). Kyla rizika, kad bus sunaikinama visa NESS sistema, neišsaugomi jokie duomenys, visą sistemos infrastruktūrą reiks kurti iš naujo. Tod÷l n÷ra užtikrinamas pakankamas informacijos patikimumas bei prieinamumas.




SVEIKATOS APSAUGOS

MINISTERIJA


Atsižvelgiant į 6.2 skyriuje „Pagrindiniai pasteb÷jimai“ pateiktas pastabas, siūloma:

► Atnaujinti, adaptuoti bei patvirtinti eSPBI IS nuostatus bei saugos nuostatus, reikalingus sistemos įteisinimui. Taip pat parengti ir patvirtinti, kitus saugą reglamentuojančius dokumentus, apibr÷žiant informacijos klasifikavimo, rizikos vertinimo, sistemos patikimumo bei informacijos saugos lygio bei priemonių nustatymo ir įgyvendinimo aspektus. Galimas tvarkų sąrašas pateikiamas 3 priede „Tvarkų sąrašas“. (Pagal pasteb÷jimus I.S.1 – I.S.6)

► Įgyvendinti ir įteisinti organizacines ir technines saugos priemones, numatyti steb÷senos priemones informacijos atitikčiai užtikrinti. (Pagal pasteb÷jimus I.S.1 – I.S.6)

► Atlikti nuolatinius nesankcionuoto išorinio įsiskverbimo galimybių testavimus. Atsižvelgiant į testavimų rezultatus parengti planus bei numatyti priemones atitinkamam saugos lygio užtikrinimui. (Pagal pasteb÷jimą I.S.3)

► Įdiegti automatizuotas priemones pakeitimų, login÷s prieigos valdymo procesams valdyti. (Pagal pasteb÷jimus I.S.2, I.S.4)




SVEIKATOS APSAUGOS

MINISTERIJA

7.7.7.7. Elektronin÷s sveikatos srities standartų apžvalgaElektronin÷s sveikatos srities standartų apžvalgaElektronin÷s sveikatos srities standartų apžvalgaElektronin÷s sveikatos srities standartų apžvalga

Šio skyriaus paskirtis – pateikti rekomenduojamų pagrindinių e. sveikatos sektoriaus standartų apžvalgą. Standartai yra vienas iš pagrindinių aspektų, užtikrinant sistemų sąveikumą (interoperabilumą).

E. sveikatos srities standartų, taikytinų Lietuvos e. sveikatos paslaugų ir bendradarbiavimo infrastruktūrai, sąrašas pateikiamas pagal šias taikymo sritis:

► elektronin÷s sveikatos istorijos ir klinikinių duomenų struktūrų standartai;

► sąveikumo ir duomenų mainų sveikatos priežiūros srityje standartai, įskaitant ir medicininių vaizdų perdavimo bei medicininių įrenginių komunikavimo standartus;

► sveikatos informacijos saugos standartai ir asmens duomenų tvarkymą reglamentuojantys aktai;

► klasifikatoriai, žodynai ir terminologiją aprašantys standartai;

► sistemų ir paslaugų standartai, reglamentuojantys e. sveikatos srityje taikomas informacinių technologijų priemones;

► kiti standartai.

Pateiktų e. sveikatos standartų taikymas Lietuvoje yra prioretizuojamas, naudojant šias reikšmes: ► 1 – aukšto prioriteto;

► 2 - vidutinio prioriteto;

► 3 - žemo prioriteto;

► X – netaikoma;

► ? – neapibr÷žtas prioriteto laipsnis – turi būti vertinamas papildomai.

7.1.7.1.7.1.7.1. Elektronin÷s sveikatos istorijos ir klinikinių duomenų struktūrų standartaiElektronin÷s sveikatos istorijos ir klinikinių duomenų struktūrų standartaiElektronin÷s sveikatos istorijos ir klinikinių duomenų struktūrų standartaiElektronin÷s sveikatos istorijos ir klinikinių duomenų struktūrų standartai

Šiuolaikin÷s, į paciento poreikius ir paslaugų tęstinumą orientuotos sistemos koncepcija remiasi elektronine sveikatos istorija (ESI). ESI yra e. sveikatos sistemos pagrindas, o pilnai veikianti ESI sistema yra svarbiausias e. sveikatos sistemos tikslas.

ESI taikomi standartai yra pateikiami žemiau esančioje lentel÷je.

Pastaba: Standarto pavadinimas, kodas ir trumpas aprašymas pateikiami originalo kalba ir simboliniu žym÷jimu.




SVEIKATOS APSAUGOS

MINISTERIJA

Eil. Nr.

Standarto pavadinimas arba kodas

Trumpas aprašymas

Prioritetas

1. Elektronin÷s sveikatos istorijos ir klinikinių duomenų struktūrų standartai

1.1. GEHR Good Electronic Health Record – a standard, which offers object models and archetypes, used for standardizing electronic health record (EHR). It also provides an open source middleware software implementation. The GEHR was the precursor of the openEHR.

X, precursor of openEHR

1.2. openEHR Archetypes, systems sharing EHR information by implementing elements compatible with those freely available from openEHR website. These elements support specified openEHR reference and archetypes models and use common definitions of clinical information, provided via shared archetype repository.

2, input for CDA templates

1.3. ENV 12018 Identification, administrative, and common clinical data structure for ICDs. This standard proposes a standardized framework for data structures used with respect to Intermittently Connected Devices (ICDs). An ICD is a device that stores and transmits person related data in such a fashion that the originator of the information may not receive confirmation of receipt by the recipient.

?

1.4. ENV 13606

(EHRcom (EHR communications))

ENV (CEN-EN) 13606 is electronic health record pre-standard of CEN TC251. It provides comprehensive framework for defining communications of shared EHR content via archetypes. The standard aims to define rigorous and stable information architecture for communicating part or all of the electronic health record (EHR) of a single subject of care (patient).

It is divided in four parts: ｇ Part 1: Extended architecture ｇ Part 2: Domain term list ｇ Part 3: Distribution rules ｇ Part 4: Messages for the exchange of information

This is to support the interoperability of systems and components that need to communicate (access, transfer,

2, input for CDA templates




SVEIKATOS APSAUGOS

MINISTERIJA

Eil. Nr.


Trumpas aprašymas

Prioritetas


add or modify) EHR data via electronic messages or as distributed objects: ｇ preserving the original clinical meaning intended by

the author; ｇ reflecting the confidentiality of that data as intended

by the author and patient. Note: This standard can also be assigned to the clinical data exchange standards’ group.

1.5. HL7 CDA Clinical Document Architecture is based on the reference information model (RIM) and is designed to capture information as a document and then be stored in EHR systems. A feature of the CDA is its ability to be viewed in a browser using a single style sheet, ensuring everyone can read the record. Structured information can also be recorded and be used in different systems. The information is recognizable by different systems through use of shared terminology, such as SNOMED and LOINC.

1

1.6. HL7 EHR functional model

The HL7 EHR System Functional Model is intended to provide a summary understanding of functions that may be present in an Electronic Health Record System (EHR-S). EHR-S Model describes the behavior of a system from a functional perspective and provides a common basis upon which EHR-S functions are communicated.

1-2

1.7. IHD XDS The Cross document sharing (XDS) specification, developed by the Integrating the Healthcare Enterprise organization (IHE) defines an information architecture and service interfaces for shareable repository of clinical documents. It includes both the Document Registry and Document Repository actors.

1

1.8. ISO TC 215 - ISO TC 215 - ISO/TR 20514 describes a pragmatic 2




SVEIKATOS APSAUGOS

MINISTERIJA

Eil. Nr.


Trumpas aprašymas

Prioritetas


ISO/TR 20514 classification of electronic health records, provides simple definitions for the main categories of EHR and provides supporting descriptions of the characteristics of electronic health records and record systems.

1.9.

E1239-00 Standard guide for description of reservation/registration-admission, discharge, transfer systems for Electronic Health Record (EHR) systems. This guide identifies the minimum information capabilities needed by an ambulatory care system or a resident facility R-ADT system.

3, all ASTM standards may be useful to look at but they are US realm

1.10. E1384-02a Standard guide for content and structure of the Electronic Health Record (EHR) - This guide covers all types of healthcare services, including those given in acute care hospitals, nursing homes, skilled nursing facilities, home healthcare, and specialty care environments as well as ambulatory care. They apply both to short term contacts (for example, emergency rooms and emergency medical service units) and long term contacts (primary care physicians with long term patients).

3

1.11. E1744-98 Standard guide for view of emergency medical care in the computerized-based patient record - It addresses the identification of the information that is necessary to document emergency medical care in a computerized patient record that is part of a paperless patient record system.

3

1.12. E1715-01 An object-oriented model for registration, admitting, discharge, and transfer functions in computer-based patient record systems - Details the objects that make up the reservation, registration, admitting, discharge, and transfer functional domain of the computer-based record of care. It is intended to amplify guide E1239 with an object-oriented focus.

3




SVEIKATOS APSAUGOS

MINISTERIJA

Eil. Nr.


Trumpas aprašymas

Prioritetas


1.13. E2211-02 Specification for relationship between a person and a supplier of an electronic personal health record. This specification covers the relationship between a consumer, organization or custodian and a managing organization (such as a web site or other organization).

This specification will not address personal health records (PCHR) that are created and managed by patients on paper records.

3

1.14 ASTM CCR Continuity of Care Record (CCR) is a health record standard specification developed jointly by ASTM International and other health informatics vendors. The CCR standard is a patient health summary standard. It is a way to create flexible documents that contain the most relevant and timely core health information about a patient, and to send these electronically from one care giver to another. It contains various sections such as patient demographics, insurance information, diagnosis and problem list, medications, allergies and care plan. These represent a "snapshot" of a patient's health data that can be useful or possibly lifesaving, if available at the time of clinical encounter. The ASTM CCR standard is designed to permit easy creation by a physician using an electronic health record system at the end of an encounter.

3

7.2.7.2.7.2.7.2. Sąveikumo ir duomenų mainų sveikatos priežiūros srityje standartai, įskaitant Sąveikumo ir duomenų mainų sveikatos priežiūros srityje standartai, įskaitant Sąveikumo ir duomenų mainų sveikatos priežiūros srityje standartai, įskaitant Sąveikumo ir duomenų mainų sveikatos priežiūros srityje standartai, įskaitant medicininių vaizdų perdavimo bei medicininių įrenginių kommedicininių vaizdų perdavimo bei medicininių įrenginių kommedicininių vaizdų perdavimo bei medicininių įrenginių kommedicininių vaizdų perdavimo bei medicininių įrenginių komunikavimo standartusunikavimo standartusunikavimo standartusunikavimo standartus

Eil. Nr.


Trumpas aprašymas Prioritetas




SVEIKATOS APSAUGOS

MINISTERIJA

2. Sąveikumo ir duomenų mainų sveikatos priežiūros srityje standartai

2.1. HL7 v3 Normative Edition, 2009

The HL7 version 3 standard has the aim to support any and all healthcare workflows. The Version3 Normative Edition represents all of the Version 3 Standards and Documents that have achieved normative status as an American National Standard (ANS), have achieved status as an HL7 draft standard for trial use (DSTU), or have been published as HL7 informative documents

1

2.2. HL7 RIM and HL7 HDF

HL7 Reference information model RIM and Development Framework provides means of modeling information across the health domain and then deriving consistent messages from the resulting models.

RIM is a unique representation of the health care domain set of information and data. Its design supports health informatics details of clinical events, their results and their context. RIM represents the semantic and lexical connections between the information carried in the fields of HL7 messages.

The models used in the HDF development methodology, use the UML as the preferred syntax. The HDF is a replacement for and an extension to the Message Development Framework (MDF). The HDF differs from and enhances the MDF by more closely aligning the underlying meta model governing well-formed HL7 models with the meta model of UML and applying the model driven process to all of the technical specifications of HL7, not just messages.

1

2.3. HL7, CMET Common message element types, consisting of relevant entities, relationships and roles.

1

2.4. HISA (ENV 12967)

Health informatics service architecture - logical design for information systems serving the needs of large or small healthcare enterprises. HISA seeks to enable the development of modular open systems to support healthcare.

The architecture of any generic healthcare information system is described as a federation of heterogeneous applications, interacting and co-operating through a middleware layer of common services. It specifies the structure of the data maintained and retrieved by each service, without prescribing its internal structure. Both applications and the middleware rely on a set of technological facilities (a bitways layer) to

3, ?




SVEIKATOS APSAUGOS

MINISTERIJA

Eil. Nr.



2. Sąveikumo ir duomenų mainų sveikatos priežiūros srityje standartai enable the physical connection and interaction of various modules.

Two main classes of common services are identified: ｇ Healthcare-related Common Services (HCS) meeting the

particular requirements and activities of users in the healthcare business domain. These relate to the subject of care, activities, resources, authorization, health characteristics, concepts.

ｇ Generic Common Services (GCS) which may be common to any information system in any business domain.

2.5. CEN CONTSYS

System of concepts to support continuity of care across care teams and healthcare enterprises. There are at least two perspectives on continuity of care: ｇ local information management about the subject of care; ｇ enabling health care providers the interchange of

information.

Continuity of care depends on the effective transfer and linkage of data and information about the clinical situation and the care provided to a subject of care, between different parties involved in the process, within the framework of ethical, professional and legal, rules.

This European pre-standard seeks to identify and define those processes which relate to the continuity of care. It specifically addresses aspects of sharing patient related information needed in the process of care. It identifies and defines relevant data and information flows, together with their relationships to "time slots".

?

2.6. GPIC General Purpose Information components, which are UML model fragments used to represent distinct health informatics business objects that are frequently required within healthcare messages. This European Standard includes a large number of objects which are technically similar to descriptions in draft documents of HL7, although partly described differently due to the fact that CEN is following the ISO rules for drafting and presentation of standards which HL7 is not.

3, maybe input for CDA templates but is not for direct use here




SVEIKATOS APSAUGOS

MINISTERIJA

Eil. Nr.




General Purpose Information Components to be used in standards for information exchange and information models supporting various health specific business requirements. The components defined in this standard are the most commonly needed basic building blocks for such standardization but these components may require further specialization and be complemented by other objects required for specific purposes not met by these generally useful components. Such standardization using these general purpose information components could be performed both on a European (CEN) level or be done nationally or for specific user communities regionally as well as internationally. This European Standard provides an informative overview of this series of standards and includes rules for using the components defined in the other parts and on conformance claims.

2.7. ENV 12612 Messages for the exchange of healthcare administrative information. Specifies messages for the exchange of healthcare administrative information to provide safe, efficient and effective healthcare delivery within hospitals and in primary care The messages do not cover the reimbursement nor the admission, discharge and transfer processes themselves, but make such processes much easier because of the overall availability of registration and identification data.

3, all ENV pre standards are subject for input3

2.8.

ENV 12538 Messages for Patient Referral and Discharge. It refers to referral and discharge but also covers the request for specialist services and the reports by the specialist service provider, including clinic letters and discharge summaries. Graphical or image information that forms part of a request for or report of a specialist healthcare service is excluded.

3

2.9. ENV 12539 Request and Report Messages for Diagnostic Services Departments. It provides the description of the scope of the messages and its functionality and implementation guidelines for different scenarios. It is used in X-rays, CAT, NMR, ultrasound scans, ECGs, lung-function tests, anatomic

3




SVEIKATOS APSAUGOS

MINISTERIJA

Eil. Nr.



2. Sąveikumo ir duomenų mainų sveikatos priežiūros srityje standartai pathology and nuclear medicine. The scope is limited to character-based messages, therefore is not related to multimedia.

2.10.

ENV 13607 This European pre-standard specifies general messages for electronic information exchange between computer systems used by healthcare parties prescribing, dispensing or administering medicinal products/medicinal appliances). The content and structure of the messages specified in this European pre-standard have been developed with the aim of optimizing the safety of prescribing and dispensing and to facilitate compliance monitoring and secure audit trails.

This European pre-standard is applicable to messages for electronic information exchange of prescription sets issued (i.e. prescribed) by healthcare persons (and possibly other persons who on this occasion act as healthcare persons) authorized by national regulations.

3

2.11. ENV 1613 Messages for exchange of laboratory information. Provides a complete implementable specification of the laboratory messages by implementation guidelines to supplement the message definitions. It also provides comprehensive data and structured tables. These coding schemes are commonly used to provide precise and unambiguous representation of the data.

3

2.12. ISO/TR 18307:2001

Interoperability and compatibility in messaging and communication standards. Describes a set of key characteristics to achieve interoperability and compatibility in trusted health information interchange between communicant application systems. The key characteristics describe inter-application interoperability needs of the healthcare community, in particular the subject of care, the healthcare professional/caregiver, the healthcare provider organization, its business units and the integrated data.

3




SVEIKATOS APSAUGOS

MINISTERIJA

Eil. Nr.




2.13. ISO 18812 Clinical analyser interfaces to laboratory information systems. Specifies general messages for electronic information exchange between analytical instruments and laboratory information systems within a clinical laboratory. Covers the specification of messages used by communicating parties and the syntax in which they are communicated. It does not cover the transport mechanisms used for the message interchange.

3

2.14. DTR 16056 Interoperability of Telehealth Systems and Networks. Part 2 of the standard is related to real-time e-Health systems.

?

Medicininių vaizdų perdavimo bei medicininių įrenginių komunikavimo standartai

2.15. DICOM DICOM is a global Information-Technology standard that is used in virtually all hospitals worldwide. DICOM is used for exchange of diagnosis and image data. DICOM will be required by all EHR systems that include imaging information as an integral part of the patient record.

DICOM is also an integral part of Integrating the Healthcare Enterprise (IHE), which is an initiative to help both users and vendors develop approaches for integrating various medical imaging and information systems. The DICOM Standards Committee has an active liaison to ISO’s TC 215.

Wherever possible, DICOM utilizes relevant parts of other mature standards such as LOINC, SNOMED, JPEG, MPEG, BIRADS, TCP/IP.

2

2.16. ENV 1064 Computer-assisted electrocardiography. Used for Medical Device Communications.

3

2.17. ENV 13734 (VITAL)

VITAL specifies a common representation of vital signs information. It is non-device dependent. Used in medical device communication. It was specially created for real time services.

3, maybe 2 if medical devices come earlier into play




SVEIKATOS APSAUGOS

MINISTERIJA

Eil. Nr.




2.18. ENV 13939 Medical Data Interchange: HIS/RIS-PACS and HIS/RIS. Describes the interchange of sanitary data. HIS/RIS-PACS and HIS/RIS.

3

2.19. ENV 13735 Interoperability of patient connected medical devices. The standard sets up the basis of interoperability among patient connected devices taking account of VITAL standard to achive device and signal interoperability. This standard and VITAL standard are designed to work together. Each one specifies a level of interoperability.

3

2.20. CR 14300 Interoperability of healthcare multimedia report systems. Provides interoperability of healthcare multimedia report systems. It is not mandatory. It is a recommendation.

3, British standards

2.21. CR 12069 Profiles for medical image interchange. Provides the set of profiles for a given user scenario. Defines greyscale, colour, volumetric and time sequences. CR 12069 is not a mandatory standard, it is a report.

3

7.3.7.3.7.3.7.3. Sveikatos informacijos saugoSveikatos informacijos saugoSveikatos informacijos saugoSveikatos informacijos saugossss standartai ir asmens duomenų tvarkstandartai ir asmens duomenų tvarkstandartai ir asmens duomenų tvarkstandartai ir asmens duomenų tvarkymą ymą ymą ymą reglamentuojantys aktaireglamentuojantys aktaireglamentuojantys aktaireglamentuojantys aktai


Trumpas aprašymas Prioritetai

3. Sveikatos informacijos saugos standartai ir asmens duomenų tvarkymą reglamentuojantys aktai

3.1. E1762-95 (2003)

Standard Guide for Properties of Electronic Health Records and Record Systems - The standard defines a document structure for use by electronic signature mechanisms and the characteristics of the electronic signature itself.

3




SVEIKATOS APSAUGOS

MINISTERIJA




3.2. E1902-02 Specification for management of the confidentiality and security of dictation, transcription, and transcribed health records - It describes certain steps that shall be taken by those involved in the processes of dictation and transcription of healthcare documentation. It also seeks to identify certain dictation and transcription practices that may increase the risks of infringing on privacy and violating security of healthcare documentation.

3

3.3. E1986-98 Standard guide for information access privileges to health information. This guide covers the process of granting and maintaining access privileges to health information. It directly addresses the maintenance of confidentiality of personal, provider, and organizational data in the healthcare domain.

3

3.4. E1987-98 Standard guide for individual rights regarding health information. This guide outlines the rights of individuals, both patients and providers, regarding health information and recommends procedures for the exercise of those rights. This guide is intended to amplify Guide E1869.

3

3.5. E2085-00a Standard guide on security framework for healthcare information. Describes a framework for the protection of healthcare information. It addresses both storage and transmission of information. It makes use of well-known security algorithms such as SHA-1, triple-DES and others.

3

3.6. E2084-00 Standard Specification for Authentication of Healthcare Information Using Digital Signatures. This specification covers the use of digital signatures to provide authentication of healthcare information, as described in Guide E 1762. It describes how the components of a digital signature system meet the requirements specified in Guide E 1762. This includes specification of allowable signature and hash algorithms, management of public and private keys, and

3




SVEIKATOS APSAUGOS

MINISTERIJA



3. Sveikatos informacijos saugos standartai ir asmens duomenų tvarkymą reglamentuojantys aktai specific formats for keys, certificates, and signed healthcare documents.

3.7. E2212-02a Standard Practice for Healthcare Certificate Policy - Adresses the policy for digital certificates that support the authentication, authorization, confidentiality, integrity, and non-repudiation requirements of persons and organizations that electronically create or transact health information.

There are 3 types of certificate: one for computerized entities, one for individual person and the last one for clinical individuals.

3

3.8.

ENV 12388 Algorithm for Digital Signature Services in Health Care. Defines the algorithm used for digital signatures in medicine information exchange. It is required to achieve legal acceptability of the information exchange.

3, see IHE profiles

3.9.

ENV 12924 Medical informatics. Security categorization and protection for healthcare information systems.

3

3.10. ENV 13608 Security for healthcare communication. Defines concepts for secure systems. Besides that, secure data objects and secure data channels are addressed.

2

3.11. ENV 14301 System for ensuring security of healthcare communication.

2-3

3.12. UNE-CR 13694

Safety and Security Related Software Quality Standards for Healthcare (SSQS). Proposes several quality norms related to security and protection in e-Health software.

2

3.13. Asmens duomenų

Asmens duomenų teisin÷s apsaugos įstatymas Nr. I-1374, patvirtintas Lietuvos Respublikos Seimo, 1996 m. birželio 11 d.

1




SVEIKATOS APSAUGOS

MINISTERIJA



3. Sveikatos informacijos saugos standartai ir asmens duomenų tvarkymą reglamentuojantys aktai teisin÷s apsaugos įstatymas Nr. I-1374

Šis Įstatymas reglamentuoja santykius, kurie atsiranda tvarkant asmens duomenis automatiniu būdu, taip pat neautomatiniu būdu tvarkant asmens duomenų susistemintas rinkmenas: sąrašus, kartotekas, bylas, sąvadus ir kita. Įstatymas nustato fizinių asmenų kaip duomenų subjektų teises, šių teisių apsaugos tvarką, juridinių ir fizinių asmenų teises, pareigas ir atsakomybę tvarkant asmens duomenis.

3.14. 95/46/EC EU Data Protection Directive (also known as Directive 95/46/EC) is a directive adopted by the European Union designed to protect the privacy and protection of all personal data collected for or about citizens of the EU, especially as it relates to processing, using, or exchanging such data. Directive 95/46/EC encompasses all key elements from article 8 of the European Convention on Human Rights, which states its intention to respect the rights of privacy in personal and family life, as well as in the home and in personal correspondence. The Directive is based on the 1980 OECD "Recommendations of the Council Concerning guidelines Governing the Protection of Privacy and Trans-Border Flows of Personal Data."

In the context of the Directive, personal data means "any information relating to an identified or identifiable natural person ('data subject'); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity". Data is considered personal when it enables anyone to link information to a specific person, even if the person or entity holding that data cannot make that link. Examples of such data include address, bank statements, credit card numbers, and so forth. Processing is also broadly defined and involves any manual or automatic operation on personal data, including its collection, recording, organization, storage, modification, retrieval, use, transmission, dissemination or publication, and even blocking, erasure or destruction.

1




SVEIKATOS APSAUGOS

MINISTERIJA




3.15. 13/2/97(5) Council of Europe Recommendation on the protection of medical data.

1

3.16. (EC) 45/2001

Regulation No 45/2001 of the European parliament and of the council of 18 December 2000 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data.

1

3.17. DPA 1998 Data protection act of 1998 directs organizations in the United Kingdom to collect, process and pass on personal information in accordance with strict rules.

3

7.4.7.4.7.4.7.4. Klasifikatoriai, žodynai ir terminologiją aprašantys standartaiKlasifikatoriai, žodynai ir terminologiją aprašantys standartaiKlasifikatoriai, žodynai ir terminologiją aprašantys standartaiKlasifikatoriai, žodynai ir terminologiją aprašantys standartai

Eil.

Nr.



4. Klasifikatoriai, žodynai ir terminologiją aprašantys standartai

4.1. ICPC International classification of primary care is a classification method for primary care encounter. It allows for the classification of the patient’s reason for encounter, the problems/diagnosis managed, primary care interventions, and the ordering of the data of the primary care session in an episode of care structure.

1

4.2. LOINC Logical observation Identifiers names and codes. The purpose of LOINC is to facilitate the exchange and pooling of clinical results for clinical care, outcomes management, and research by providing a set of universal codes and names to identify laboratory and other clinical observations.

1




SVEIKATOS APSAUGOS

MINISTERIJA

Eil.

Nr.




The LOINC database provides a set of universal names and ID codes for identifying laboratory and clinical test results in the context of existing HL7, ASTM E1238, and CEN TC251 observation report messages. One of the main goals of LOINC is to facilitate the exchange and pooling of results for clinical care, outcomes management, and research. LOINC codes are intended to identify the test result or clinical observation. Other fields in the message can transmit the identity of the source laboratory and special details about the sample.

4.3. SNOMED CT

The Systematized Nomenclature of Medicine (SNOMED) is a multi-axial, hierarchical classification system. As in any such system, a disease may be located in a body organ which results in a code in a topography axis and may lead to morphological alterations represented by a morphology code.

The standard is developed by The International Health Terminology Standards Development Organisation.

Pastaba: Lietuva yra įtraukta kaip šios organizacijos nar÷.

1

4.4. ICD The International Statistical Classification of Diseases and Related Health Problems (most commonly known by the abbreviation ICD) provides codes to classify diseases and a wide variety of signs, symptoms, abnormal findings, complaints, social circumstances and external causes of injury or disease. Every health condition can be assigned to a unique category and given a code, up to six characters long. Such categories can include a set of similar diseases.

The International Classification of Diseases is published by the World Health Organization and used worldwide for morbidity and mortality statistics, reimbursement systems and automated decision support in medicine. This system is designed to promote international comparability in the collection, processing, classification, and presentation of these statistics.

1




SVEIKATOS APSAUGOS

MINISTERIJA

Eil.

Nr.




The ICD is a core classification of the WHO Family of International Classifications (WHO-FIC).

4.5. UMLS The Unified Medical Language System is a compendium of many controlled vocabularies in the biomedical sciences. It provides a mapping structure among these vocabularies and thus allows one to translate among the various terminology systems; it may also be viewed as a comprehensive thesaurus and ontology of biomedical concepts. UMLS further provides facilities for natural language processing. It is intended to be used mainly by developers of systems in medical informatics.

UMLS can be used to design information retrieval or patient record systems, to facilitate the communication between different systems, or to develop systems that parse the biomedical literature. For many of these applications, the UMLS will have to be used in a customized form, for instance by excluding certain source vocabularies that are not relevant to the application. The Library of Medicine itself uses it for its PubMed and ClinicalTrials.gov systems.

2

4.6. E1714-00 Standard guide for properties of a Universal Healthcare Identifier - This guide covers a set of requirements outlining the properties of a national system creating a universal health care identifier (UHID).

Use of the UHID is expected to be limited to the population of the United States.

3

4.7. ENV 12017 Medical Informatics Vocabulary (MIVoc). Defines the Medical Informatics Vocabulary, which is a foundation for the development of a vocabulary of terms used in Medical Informatics.

2-3

4.8. ENV 12264 Categorical structures of systems of concepts - Model for representation of semantics. The standard provides the

2




SVEIKATOS APSAUGOS

MINISTERIJA

Eil.

Nr.




vocabulary and the guidelines to describe the categorical structure of a concept system: the structure consists in practice of a list of involved categories with reference to the available authoritative sources for detailed value. Medical Informatics deals with a great number of large, overlapping coding systems that are facing each other and conflicting in the coming Integrated Healthcare Information Environment. This standard tries to solve these conflicts.

4.9. ENV 12381 Time Standards for Healthcare Specific Problems. Provides a set of basic entities, with precisely defined properties and interrelationships among them, that is sufficient to allow an unambiguous representation of time-related expressions.

2

4.10 HL7 CTS CTS deliberately steered clear of producing a dynamic model of terminology, avoiding issues related to terminology distribution and versioning. The value set, or sub-setting section of CTS focused on static value sets and didn’t fully address the definition or resolution of value sets that define post-coordinated expressions – issues that are now in scope due to the maturing Terminfo/SNOMED Concept Model Working Group (CMWG) model and Terminfo.

1

7.5.7.5.7.5.7.5. Sistemų ir paslaugų standartai, reglamentuojantys e. sveikatosSistemų ir paslaugų standartai, reglamentuojantys e. sveikatosSistemų ir paslaugų standartai, reglamentuojantys e. sveikatosSistemų ir paslaugų standartai, reglamentuojantys e. sveikatos srityje taikomas srityje taikomas srityje taikomas srityje taikomas informacinių technologijų priemonesinformacinių technologijų priemonesinformacinių technologijų priemonesinformacinių technologijų priemones

Eil.

Nr.



5. Sistemų ir paslaugų standartai, reglamentuojantys e. sveikatos srityje taikomas informacinių technologijų priemones

5.1. CORBA-Med

Division of CORBA devoted to healthcare. CORBA-Med is dedicated to improve the quality of care and reduce costs by

3




SVEIKATOS APSAUGOS

MINISTERIJA

Eil.

Nr.




the use of CORBA technologies in the heterogeneous and evolving healthcare environment. It has over fifty members representing vendors, healthcare providers, payers and end users.

5.2. TCP/IP v. 4 Transmission Control Protocol/Internet Protocol, the suite of communications protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP and IP. TCP/IP is built into the UNIX operating system and is used by the Internet, making it the de facto standard for transmitting data over networks. Even network operating systems that have their own protocols, such as Netware, also support TCP/IP. In the healthcare IT, it is used for internet data exchange.

1

5.3. IEEE 802 IEEE 802 refers to a family of IEEE standards dealing with local area networks and metropolitan area networks. More specifically, the IEEE 802 standards are restricted to networks carrying variable-size packets. In healthcare IT, it is used for wireless data exchange.

1

5.4. ENV 12251 Management and security of authentication by passwords. addresses the management and security of authentication by passwords.

2

5.5. XML 1.0 Extensible Markup Language is a general-purpose specification for creating custom markup languages. It is classified as an extensible language, because it allows the user to define the mark-up elements. XML's purpose is ｇ to aid information systems in sharing structured data,

especially via the Internet; ｇ to encode documents; ｇ to serialize data.

XML's set of tools helps developers in creating web pages but its usefulness goes well beyond that. XML, in combination with

1




SVEIKATOS APSAUGOS

MINISTERIJA

Eil.

Nr.




other standards, makes it possible to define the content of a document separately from its formatting, making it easy to reuse that content in other applications or for other presentation environments. Most importantly, XML provides a basic syntax that can be used to share information between different kinds of computers, different applications, and different organizations without needing to pass through many layers of conversion.

ebXML Electronic Business using eXtensible Markup Language. is a family of XML based standards sponsored by OASIS and UN/CEFACT whose mission is to provide an open, XML-based infrastructure that enables the global use of electronic business information in an interoperable, secure, and consistent manner by all trading partners.

While the ebXML standards adopted by ISO and OASIS seek to provide formal XML-enabled mechanisms that can be implemented directly, the ebXML architecture is focused on concepts and methodologies that can be more broadly applied to allow practitioners to better implement e-business solutions.

A particular instance is the Core Components Technical Specification (CCTS) work that continues within UN/CEFACT, whereas its cousin - UBL - Universal Business Language - specification is used within OASIS that implements specific XML transactions by applying the principles of CCTS to typical supply chain transactions such as invoice, purchase order, ship notice and so on

The ebXML architecture is a unique set of concepts; part theoretical and part implemented in the existing ebXML standards work.

1

5.6. EDIFACT EDIFACT is a formal language for machine readable description of electronic business documents. It uses syntax close to delimiter separated files. This syntax was invented in the 1980s to keep files as small as possible. Because of the Internet boom around 2000, XML started to become the most

X




SVEIKATOS APSAUGOS

MINISTERIJA

Eil.

Nr.




widely supported file syntax. But for example, an invoice is still an invoice, containing information about buyer, seller, product, due amount. EDIFACT works perfectly from the content viewpoint, but many software systems struggle to handle its syntax.

5.7. SOA 1.0 SOA provides methods for systems development and integration where systems package functionality as interoperable services. A SOA infrastructure allows different applications to exchange data with one another. Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order that users can combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

1

5.8. ISO 9241 Ergonomics requirements for office work with visual display terminals. Its main purpose is to set up a user-friendly environment for general applications (including e-Health)

?

5.9. ISO/IEC 9075

The standard describing Database query language SQL. SQL (Structured Query Language) is a database computer language designed for managing data in relational database management systems and originally based upon Relational Algebra. Its scope includes data query and update, schema creation and modification, and data access control.

1

SHA-1 [FIPS 180-1]

SHA stands for Secure Hash Algorithm. SHA-1 is the best established of the existing SHA hash functions, and is employed in several widely used security applications and protocols.

1




SVEIKATOS APSAUGOS

MINISTERIJA

Eil.

Nr.




MIME Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of e-mail to support: ｇ Text in character sets other than ASCII ｇ Non-text attachments ｇ Message bodies with multiple parts ｇ Header information in non-ASCII character sets MIME's use, however, has grown beyond describing the content of e-mail to describing content type in general, including for the web (see Internet media type).

1

UTF-8 UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. It is able to represent any character in the Unicode standard, yet is backwards compatible with ASCII. For these reasons, it is steadily becoming the preferred encoding for e-mail, web pages and other places where characters are stored or streamed.

UTF-8 encodes each character (code point) in 1 to 4 octets (8-bit bytes), with the single octet encoding used only for the 128 US-ASCII characters.

1

IEC 8824-1 This standard describes Abstract Systax Notation One. In telecommunications and computer networking, Abstract Syntax Notation One (ASN.1) is a standard and flexible notation that describes data structures for representing, encoding, transmitting, and decoding data. It provides a set of formal rules for describing the structure of objects that are independent of machine-specific encoding techniques and is a precise, formal notation that removes ambiguities.

1

IEC 9834-1 This standard documents Universally Unique Identifiers (UUIDs). UUID is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. Thus, anyone can create a UUID and use it to

1




SVEIKATOS APSAUGOS

MINISTERIJA

Eil.

Nr.




identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labeled with UUIDs can therefore be later combined into a single database without needing to resolve name conflicts.

RFC 3987 On the Internet, the Internationalized Resource Identifier (IRI) is a generalization of the Uniform Resource Identifier (URI), which is in turn a generalization of the Uniform Resource Locator (URL).

1

7.6.7.6.7.6.7.6. Kiti standartaiKiti standartaiKiti standartaiKiti standartai


Trumpas aprašymas Prioretetai

6. Kiti standartai

6.1 E2184-02 Standard Specification for Healthcare Document Formats - Defines requirements for the headings, arrangement, and appearance of sections and subsections when used within healthcare documents.

This specification will facilitate identification and retrieval of health information in a manner that will enhance the quality and efficiency of health services

3

6.2. E2117-00 Standard guide for identification and establishment of a quality assurance program for medical transcription. It establishes a quality assurance program for dictation, medical transcription, and related processes. Quality assurance is necessary to ensure the accuracy of healthcare documentation. This guide establishes essential and desirable elements for quality healthcare documentation, but it is not purported to be an exhaustive list.

3




SVEIKATOS APSAUGOS

MINISTERIJA


Trumpas aprašymas Prioretetai

6. Kiti standartai

6.3. ENV 12443 Healthcare Information Framework (HIF). Creates a basic framework to guide healthcare informatics developers. It is a first step in standardizing the architectures that will support the latest approaches to the delivery of computer systems such as are required to provide the global information.

3

6.4. UCUM The Unified Code for Units of Measure is a code system intended to include all units of measures being contemporarily used in international science, engineering, and business. The purpose is to facilitate unambiguous electronic communication of quantities together with their units. The focus is on electronic communication, as opposed to communication between humans.

1

7.7.7.7.7.7.7.7. Rekomenduojami Rekomenduojami Rekomenduojami Rekomenduojami eSPBIeSPBIeSPBIeSPBI informacinei sistemai taikytini standartaiinformacinei sistemai taikytini standartaiinformacinei sistemai taikytini standartaiinformacinei sistemai taikytini standartai ir reikalavimaiir reikalavimaiir reikalavimaiir reikalavimai

Atlikus e. sveikatos srityje taikytinų standartų apžvalgą ir atsižvelgiant į e. sveikatos esamą pad÷tį bei rekomenduojamą e. sveikatos paslaugų ir bendradarbiavimo infrastruktūros IS architektūrą, aukštas prioritetas skiriams šių standartų ir teis÷s aktų taikymui:

► Elektronin÷s sveikatos istorijos ir klinikinių duomenų struktūrų standartai

• HL7 CDA;

• HL7 EHR;

• IHE XDS.

► Sąveikumo ir duomenų mainų sveikatos priežiūros srityje standartai

• HL7 v3 normatyvinis leidimas;

• HL7 RIM;

• HL7 CMET.

► Sveikatos informacijos saugos standartai ir asmens duomenų tvarkymą reglamentuojantys aktai

• Asmens duomenų teisin÷s apsaugos įstatymas Nr. I-1374

• 95/46/EC

• 13/2/97(5)




SVEIKATOS APSAUGOS

MINISTERIJA

• (EC) 45/2001 Regulation No 45/2001

► Klasifikatoriai, žodynai ir terminologiją aprašantys standartai

• ICPC

• LOINC

• SNOMED CT

• ICD

• HL7 CTS

► Sistemų ir paslaugų standartai, reglamentuojantys e. sveikatos srityje taikomas informacinių technologijų priemones

• TCP/IP v. 4

• IEEE 802

• XML 2.0

• ebXML

• SOA 1.0

• ISO/IEC 9075

• SHA-1 [FIPS 180-1]

• MIME

• UTF-8

• IEC 8824-1

• RFC 3987

► Kiti standartai

• UCUM




SVEIKATOS APSAUGOS

MINISTERIJA

PriedaiPriedaiPriedaiPriedai




SVEIKATOS APSAUGOS

MINISTERIJA

Priedas Nr. Priedas Nr. Priedas Nr. Priedas Nr. 1111 –––– SąsajosSąsajosSąsajosSąsajos

Tiek÷jas Gav÷jas Perduodami duomenys Aprašymas Sąsajos tipas Formatas Technologiškai įgyvendinta

Techninis duomenų pateikimo būdas

Faktiškai naudojama

Naudojimo apimtis

Komentaras

Medicininių duomenų apsikeitimo sąsaja

SPĮ IS NESS Asmens sveikatos priežiūros istorijos įrašų duomenys

Sąsaja medicinin÷s informacijos apsiketimui

Automatinis arba automatinis pagal užklausą

XML formato HL7 V3 pranešimai Paciento sveikatos istorijoje saugomai informacijai struktūrizuoti - CDA strandartas

Dalinai Duomenys perduodami adresuotais arba neadresuotais pranešimais - publikavimas-prenumeravimas.

Ne N÷ra duomenų NESS I apimtyje aprašyti duomenų mainai yra pateikiami NESS I ir SPĮ IS duomenų mainų kataloge. Įgyvendintų pranešimų atitikimas HL7 V3 standartui vertintas nebuvo.

NESS SPĮ IS Asmens sveikatos priežiūros istorijos įrašų duomenys

Sąsaja medicinin÷s informacijos apsikeitimui

Automatinis arba automatinis pagal SPĮ IS užklausą

XML formato HL7 V3 pranešimai Paciento sveikatos istorijoje saugomai informacijai struktūrizuoti - CDA standartas

Dalinai Duomenys perduodami adresuotais arba neadresuotais pranešimais - publikavimas-prenumeravimas.

Ne N÷ra duomenų NESS I apimtyje aprašyti duomenų mainai yra pateikiami NESS I ir SPĮ IS duomenų mainų kataloge. Įgyvendintų pranešimų atitikimas HL7 V3 standartui vertintas nebuvo.

NESS Vaistin÷s IS Informacija apie pacientui priskirtus vaistus

Sąsaja su farmacijos IS N÷ra duomenų N÷ra duomenų Ne N÷ra duomenų Ne N÷ra duomenų Nenagrin÷jama NESS-I etape.

Vaistin÷s IS NESS Informacija apie paciento įsigytus vaistus

Sąsaja su farmacijos IS N÷ra duomenų N÷ra duomenų Ne N÷ra duomenų Ne N÷ra duomenų Nenagrin÷jama NESS-I etape.

Laboratorijos IS NESS Siuntimų laboratoriniams tyrimams informacija

HL7 V2.x sąsaja su laboratorijų IS (remiantis NESS-1 dokumentacija [20])

N÷ra duomenų HL7 V2 pranešimai Ne N÷ra duomenų Ne N÷ra duomenų Integracija su HL7 V2.x pranešimus naudojančiomis sistemomis šiame etape nenagrin÷jama.

NESS Laboratorijos IS Laboratorinių tyrimų rezultatai

HL7 V2.x sqsaja su laboratorijų IS (remiantis NESS-1 dokumentacija [20])

N÷ra duomenų HL7 V2 pranešimai Ne N÷ra duomenų Ne N÷ra duomenų Integracija su HL7 V2.x pranešimus naudojančiomis sistemomis šiame etape nenagrin÷jama.

Registrų ir klasifikatorių informacijos gavimo sąsaja

LR Gyventojų registras NESS Demografiniai fizinių asmenų duomenys

Sąsaja skirta procesų, kuriuose naudojama asmens informacija efektyvumui užtikrinti, sugriežtinti įvedamų duomenų kontrolę bei palengvinti tapatyb÷s nustatymą

Automatinis pagal užklausą - įgyvendintas per SVEIDRA IS

Nustatomas LR Gyventojų registro, tačiau NESS I įgyvendintas per SVEIDRA IS

Įgyvendintas per SVEIDRA IS

Per SVEIDRA IS Per SVEIDRA IS N÷ra duomenų NESS-I etape informacija apie gyventojus bus gaunama iš IS SVEIDRA, į kurią pagal galiojančią sutartį yra pateikiama IS SVEIDRA veikimui reikalinga informacijos dalis iš LR Gyventojų registro.




SVEIKATOS APSAUGOS

MINISTERIJA




Naudojimo apimtis

Komentaras

SVEIDRA NESS Demografiniai fizinių asmenų duomenys

Paciento demografin÷s informacijos pateikimas NESS I etape buvo realizuotas SVEIDRA

Automatinis, pagal naudotojo užklausą.

XML Taip Tranzitin÷ DB. Iškviečiama tranzitin÷je DB esanti procedūra (angl. Stored Procedure). Duomenų paieška galima tik pagal asmens kodą. Rezultatai grąžinami kaip XML pranešimas

Ne N÷ra duomenų Ši paslauga naudojama, kai klientin÷s dalies naudotojas (pvz. registratorius) atlieka paciento registraciją ir atlieka paiešką pagal asmens kodą.

Juridinių asmenų registras NESS Juridinio asmens duomenys Sistema teiks Informacija apie licencijuojamą įstaigą

Automatinis, inicijuojamas SPĮ IS

NESS apibr÷žiamas Ne N÷ra duomenų Ne N÷ra duomenų

SVEIDRA IS NESS Kompensuojamųjų vaistų duomenys, kompensuojamų paslaugų duomenys, paslaugų grup÷s, paslaugų kainos, paslaugų tipai

Kompensuojamų paslaugų informacijos perdavimas

Automatinis SQL (duomenys atrenkami SQL'o pagalba iš tranzitin÷s DB, apdorojami ir perkeliami į NESS DB)

Taip Tranzitin÷ DB. Iš šios DB procesas nuskaito duomenis iš lentel÷s skirtos šių duomenų apsikeitimui. Duomenų apdorojimo būsena taip pat išsaugoma šioje tranzitin÷je DB.

Ne N÷ra duomenų Duomenų apsikeitimas vykdomas periodiškai nustatytu laiku, konfigūruojamu webMethods Scheduler pagalba

SVEIDRA IS NESS TLK-10 klasifikatoriaus duomenis

Ligų ir sveikatos problemų klasifikatorius

Rankinis, n÷ra automatinio duomenų atnaujinimo

(Pirminis pakrovimas tikriausiai vykdomas iš suformuotų SQL failų).

Taip - pirmin÷ integracija Tinklin÷s paslaugos Ne N÷ra duomenų Yra tik pirmin÷ duomenų integracija, t.y. duomenys užkraunami pirminio migravimo metu, tačiau n÷ra automatinio duomenų atnaujinimo.

VAISKIS NESS Vaisto forma, Registruojančios institucijos, Gamintojai, Sudedamosios medžiagos, Vaisto registravimo liudijimai Vaistų registravimo liudijimo tur÷tojai, Vaisto pakuot÷s

Vaistų klasifikatorių atnaujinimas

Automatinis XML Taip Tinklin÷s paslaugos Ne N÷ra duomenų Duomenų mainai realiai neveikia, neįmanoma nustatyti kaip ji tur÷tų veikti, nes dokumentacija duomenų apie tai nepateikia. Pavyko aptikti tik aprašytas tinklinių paslaugų sąsajas (wsdl bylos) bei XML pranešimų duomenų apsikeitimui schemas (xsd bylos).




SVEIKATOS APSAUGOS

MINISTERIJA




Naudojimo apimtis

Komentaras

VAISKIS NESS Vaistų duomenys Pradinis vaistų informacijos užkrovimas

Rankinis SQL Taip SQL skriptas, SQL byla nurodoma duomenų importavimo priemonei ir inicijuojama iš komandin÷s eilut÷s.

Ne N÷ra duomenų

SPĮ IS NESS Įstaigos pacientų registras Kiekviena sistema teiks duomenis tik apie savo įstaigos pacientus, taip išvengiant duomenų, ateinančių iš kitų analogiškų sistemų, dubliavimo.

Automatinis XML formato HL7 V3 pranešimai

Taip Tinklin÷s paslaugos Ne N÷ra duomenų Kauno Medicinos Universiteto Klinikos pacientų registras; Vilniaus Universiteto Santariškių ligonin÷s pacientų registracija; Centro poliklinika; Realiai pacientų katalogas pildomas, kai registratoriai naudodamiesi NESS klientine programa registruoja pacientus.

SPĮ IS NESS Gydytojų darbo grafikai Darbo grafikų integravimo sąsaja

N÷ra duomenų N÷ra duomenų Ne N÷ra duomenų Ne N÷ra duomenų Nenagrin÷jama NESS-I etape.

Farmacijos departamento IS

NESS Kompensuojamųjų vaistų kainynas

Gaunamas Farmacijos departamento sudarytas kompensuojamų vaistų kainynas

Automatinis NESS apibr÷žiamas Ne N÷ra duomenų Ne N÷ra duomenų

EMEA NESS Europos bendrijoje registruojamų vaistų registras

Iš šios sistemos gaunama informacija apie registravimą tų vaistų, kuriems būtina registracija Europos sąjungos mastu.

Automatinis Nustatomas EMEA Ne N÷ra duomenų Ne N÷ra duomenų Nenagrin÷jama NESS-I etape.

SPĮ veiklos palaikymo IS - SPĮ administravimo IS

NESS Informacija apie licencijų tur÷tojų įdarbinimus ir atleidimus

NESS iš šių sistemų gaus informaciją apie licencijos tur÷tojo įdarbinimus įstaigose ir atleidimus iš jų, informaciją apie darbo kokybę. Ši informacija įgalins sekti blogos praktikos atvejus.

N÷ra duomenų NESS apibr÷žiamas Ne N÷ra duomenų Ne N÷ra duomenų Nenagrin÷jama NESS-I etape.

SPĮ veiklos palaikymo IS -Farmacijos įstaigų administravimo IS

NESS Informacija apie licencijų tur÷tojų įdarbinimus ir atleidimus

NESS iš šių sistemų gaus informaciją apie licencijos tur÷tojo įdarbinimus įstaigose ir atleidimus iš jų, informaciją apie darbo kokybę. Ši informacija įgalins sekti blogos praktikos atvejus.

N÷ra duomenų NESS apibr÷žiamas Ne N÷ra duomenų Ne N÷ra duomenų Nenagrin÷jama NESS-I etape.




SVEIKATOS APSAUGOS

MINISTERIJA




Naudojimo apimtis

Komentaras

SPĮ veiklos palaikymo IS - Mokymo įstaigų IS

NESS Pagrindinių, specialiųjų, tęstinių studijų ar jas atitinkančių kursų, programų baigimo pažym÷jimų ir dokumentų, patvirtinančių profesinį tobulinimą ar papildomą pasirengimą, duomenys

Informacija apie licencijų tur÷tojų išsilavinimą patvirtinančius sertifikatus

Automatinis, inicijuojamas SPĮ IS

NESS apibr÷žiamas Ne N÷ra duomenų Ne N÷ra duomenų Nenagrin÷jama NESS-I etape.

Registrų ir klasifikatorių duomenų teikimo sąsaja

Dokumentacijoje teigiama, kad bus pateikta visoms suinteresuotoms sistemoms, tačiau konkrečių realizacijų nepateikima

- - - - - - - - - -

Paslaugų gavimo sąsaja

NESS SVEIDRA 025aLK formos duomenys Konsultacinio įrašo duomenis Automatinis XML Taip Pastaba: sąsaja realizuota tik NESS pus÷je – sąsaja neveikia, nes NESS sistemoje n÷ra visų būtinų duomenų, kurių reikia IS SVEIDRA.

Tranzitin÷ DB. Duomenys išsaugomi tranzitin÷je DB kaip XML pranešimas. Web methods integracin÷je platformoje realizuotos funkcijos, kurios iškviečiamos išsaugant konsultacinio įrašo duomenis

Ne N÷ra duomenų Neveikia. NESS sistemoje n÷ra visų būtinų duomenų, kurių reikia IS SVEIDRA.

SVEIDRA NESS Paciento sveikatos draudimo duomenys

Pagal naudotojo užklausą.

XML Taip Tinklin÷s paslaugos, Realizuotas atskira web naudotojo sąsaja, kurioje galima patikrinti paciento sveikatos draudimo būseną. N÷ra galimyb÷s patikrinti duomenis tiesiogiai iš klientin÷s sistemos dalies.

Ne N÷ra duomenų -

Draudimo bendrovių IS NESS Duomenys apie asmens draustumą

Sąsaja gal÷tų būti naudojama asmens draustumo informacijai patiktinti

N÷ra duomenų N÷ra duomenų Ne N÷ra duomenų Ne N÷ra duomenų NESS-I etape šie duomenys bus gaunama tik iš IS SVEIDRA

NESS Draudimo bendrovių IS

Finansin÷, ekonomin÷ su sveikatinimo paslaugų

Sąsaja naudojama finansin÷ms duomenims

N÷ra duomenų N÷ra duomenų Ne N÷ra duomenų Ne N÷ra duomenų NESS-I etape ši informacija bus gaunama




SVEIKATOS APSAUGOS

MINISTERIJA




Naudojimo apimtis

Komentaras

suteikimu susijusi informacija susijusiems su sveikatinimo paslaugų suteikimu pacientui perduoti draudimo bendrovei

tik iš IS SVEIDRA




SVEIKATOS APSAUGOS

MINISTERIJA

Priedas Nr. Priedas Nr. Priedas Nr. Priedas Nr. 2 2 2 2 –––– NESS I apimtyje aprašyti duomenų mainaiNESS I apimtyje aprašyti duomenų mainaiNESS I apimtyje aprašyti duomenų mainaiNESS I apimtyje aprašyti duomenų mainai tarp tarp tarp tarp NESS ir SPĮ ISNESS ir SPĮ ISNESS ir SPĮ ISNESS ir SPĮ IS Teik÷jas Gav÷jas Perduodami duomenys Aprašymas Sąsajos tipas Formatas Technologiškai

įgyvendinta Techninis duomenų pateikimo būdas


Naudojimo apimtis

Komentaras

SPĮ IS NESS Perduodama informacija apie pacientą, priimantį gydytoją, gydymo įstaigą bei planuojamą vizito laiką

Naujo vizito suplanavimas - Naudojamas informuoti NESS apie suplanuotą vizitą. NESS saugos posistem÷ suteikia reikalingas teises paciento pri÷mimą planuojančiam gydytojui.

Automatinis, pagal užklausą

XML formato HL7 V3 pranešimai

Ne Tinklin÷s paslaugos Ne N÷ra duomenų Įgyvendintų pranešimų atitikimas HL7 V3 standartui vertintas nebuvo.

SPĮ IS NESS Suplanuoto vizito duomenys Suplanuoto vizito atšaukimas Perduodama informacija apie pacientą, priimantį gydytoją, gydymo įstaigą bei planuojamą vizito laiką.




SPĮ IS NESS Perduodama informacija apie pacientą, priimantį gydytoją, gydymo įstaigą bei planuojamą vizito laiką

Naujo vizito planavimas, kai naudojamas NESS kalendorius. Tikrinamas gydytojo, nurodyto pranešime, darbo laiką. Jei laikas laisvas, NESS kalendoriuje nurodytas laikas rezervuojamas, susiejant jį su pranešime nurodytu pacientu.




SPĮ IS NESS Užklausoje nurodomi reikalingų duomenų tipai (sveikatos įrašas/ tyrimų rezultatas/ siuntimas ir pan.), konkretūs dokumento atributai (gydytojas, pacientas ir pan.).

Paieška pagal parametrus Automatinis, pagal užklausą



SPĮ IS NESS Duomenys apie paieškos nutraukimą arba papildomi paieškos parametrai

Paieškos pratęsimas. Naudotojas gali nurodyti tęsti, nutraukti užklausą







SVEIKATOS APSAUGOS

MINISTERIJA

Teik÷jas Gav÷jas Perduodami duomenys Aprašymas Sąsajos tipas Formatas Technologiškai įgyvendinta



Naudojimo apimtis

Komentaras

SPĮ IS NESS Paciento duomenys, gydytojo specializacija taip pat nurodoma pranešime. Konkretus pranešimo adresatas (gydytojas) pranešime nenurodomas

Siuntimas konsultacijai Automatinis, pagal užklausą


Taip Tinklin÷s paslaugos Ne N÷ra duomenų Yra užuomazgų, kad buvo įgyvendinta siuntimo specialisto konsultacijai paslauga iš klientin÷s NESS dalies. Pagal pokalbius su VULSK ir KMUK, ši sąsaja buvo testuota iš jų HIS'ų ir ji veik÷. Įgyvendintų pranešimų atitikimas HL7 V3 standartui vertinta

SPĮ IS NESS Siuntimo duomenys Atšaukti siuntimą - Pranešimas siunčiamas siuntimą pateikusio vartotojo. Pranešimas informuoja, kad anksčiau suformuotas siuntimas yra nebegaliojantis ir vizitų planavimas jo pagrindu nebegalimas.



Taip Tinklin÷s paslaugos Ne N÷ra duomenų Įgyvendintų pranešimų atitikimas HL7 V3 standartui vertintas nebuvo. Tai dalis siuntimo konsultacijai

SPĮ IS NESS Paieškos kriterijų reikšm÷s Tinkamų įrašų paieška - Atrenkamos pranešime nurodytus parametrus atitinkančių paciento sveikatos istorijos įrašų antrašt÷s.




SPĮ IS NESS Kokretaus įrašo duomenys Konkretaus įrašo peržiūros užklausa Automatinis, pagal užklausą



SPĮ IS NESS Paciento demografiniai duomenys

Paciento demografinių duomenų keitimas - Registracijos darbuotojų siunčiamas pranešimas, apie pasikeitusius paciento demografinius duomenis




SPĮ IS NESS Gydytojo, paciento, vizito pradžios duomenys

Vizito pradžios pranešimas - naudojamas tęstiniam vizitui prad÷ti. Siunčiamas, kai gydytojas nenori ar negali pateikti vizito duomenų, tačiau nori išsaugoti vizitą NESS. Nebaigtas vizitas naudingas, kai pacientas siunčiamas neilgos trukm÷s procedūroms/ ko







SVEIKATOS APSAUGOS

MINISTERIJA




Naudojimo apimtis

Komentaras

SPĮ IS NESS Prad÷to bet dar neužbaigto vizito duomenys, medicinin÷ informacija

Vizito tęsimas - Pranešimas nekeičia vizito būsenos (jis lieka būsenoje „aktyvus, angl. „in progress“), o tik papildo vizito dokumentą nauja informacija




SPĮ IS NESS Paciento, gydytojo, medicinin÷ informacija

Vizito duomenų registravimas - Vizito rezultatus pateikiantis pranešimas. Gali būti naudojamas atskirai arba kartu su vizito pradžios/ pratęsimo pranešimais




SPĮ IS NESS Prad÷to vizito informacija Vizito nutraukimas- nutraukti aktyvų vizitą, kai jo tęsimas ar užbaigimas yra neįmanomas




SPĮ IS NESS Prad÷to vizito informacija Vizito anuliavimas - Vizito panaikinimas, kai vizitas prad÷tas klaidingai Anuliuojamas vizitas negali tur÷ti susietų dokumentų (vizito pratęsimų, siuntimų)



Ne Ne N÷ra duomenų Įgyvendintų pranešimų atitikimas HL7 V3 standartui vertintas nebuvo.

SPĮ IS NESS Suplanuoto vizito duomenys Pakeisti suplanuoto laiko būseną - Gali būti naudojamas, kai anksčiau suplanuotas vizitas yra atšauktas ir reikia panaikinti laiko rezervaciją.




SPĮ IS NESS Gydytojo, paciento, laborotorinio tyrimo duomenys

Laboratorinio tyrimo užsakymas - Pranešimas, siunčiamas gydytojo į NESS, kuriame užsakomas reikalingas laboratorinis tyrimas pranešime nurodytam pacientui. Pranešimas neadresuojamas konkrečiai laboratorijai



Ne Tinklin÷s paslaugos Ne N÷ra duomenų Įgyvendintų pranešimų atitikimas HL7 V3 standartui vertinas nebuvo.

SPĮ IS NESS Tyrimo siuntimo paieškos kriterijų reikšm÷s (paciento pateikti duomenys)

Surasti tyrimo užsakymą - Pagal paciento pateiktus duomenis surandamas konkretus siuntimas, kurio pagrindu turi būti atliekamas laboratorinis tyrimas.




SPĮ IS NESS Tyrimo metu surinkta informacija, užsakymo identifikatorius

Tyrimo atsakymai - SPĮ siunčiamas pranešimas į NESS informuojantis apie rezultatų pagal užklausą pateikimą.







SVEIKATOS APSAUGOS

MINISTERIJA




Naudojimo apimtis

Komentaras

SPĮ IS NESS Laboratorijos duomenys, siuntimo duomenys, patvritinimo duomenys

Siuntimo laboratoriniam tyrimui pri÷mimas - SPĮ, priimanti pacientą pagal siuntimą, šiuo pranešimu informuoja NESS, kad atsakymas į užsakytą tyrimą pradedamas ruošti. Šis pranešimas turi būti siunčiamas, kai d÷l tam tikrų priežasčių (technologinis procesa




SPĮ IS NESS Tarpiniai tyrimo metu pasiekti rezultatai, siuntimo duomenys

Tarpiniai tyrimo duomenys - SPĮ, pri÷musi siuntimą laboratoriniam tyrimui, šiuo pranešimu gali informuoti NESS apie tarpinius rezultatus, pasiektus tyrimo metu




NESS SPĮ IS Suplanuoto vizito patvirtinimo duomenys

S÷kmingo planavimo patvirtinimas, kai naudojamas NESS kalendorius. Siunčiamas siunt÷jui, kai planuojamas vizitas yra galimas ir planavimo pranešime nurodytas laikas yra s÷kmingai rezervuotas.

Automatinis, pagal kitos SPĮ IS pranešimą



NESS SPĮ IS Atmetimą paaiškinanti informacija

Planavimo atmetimas, kai naudojamas NESS kalendorius. Siunčiamas siunt÷jui, kai vizito su nurodytais parametrais d÷l tam tikrų priežasčių registruoti negalima. Atsakyme pateikiama informacija, paaiškinanti, kod÷l planavimas nepavyko




NESS SPĮ IS Paieškos NESS rezultatai Atsakymas į paiešką pagal parametrus Automatinis, pagal kitos SPĮ IS pranešimą






SVEIKATOS APSAUGOS

MINISTERIJA




Naudojimo apimtis

Komentaras

NESS SPĮ IS Siuntimo pri÷mimo patvirtinimo duomenys, gydytojo, kuris priima vizitą, duomenys

Siuntimo pri÷mimo patvirtinimas. Vizitą pagal siuntimą priimanti sistema siunčia ši pranešimą į NESS apie planuojamą vizitą pagal siuntimą



Taip Tinklin÷s paslaugos Ne N÷ra duomenų Dokumentacijoje pažym÷ta, jog vizito planavimo sąsaja pirminiame etape nenumatoma naudoti Įgyvendintų pranešimų atitikimas HL7 V3 standartui vertintas nebuvo. Dalis siuntimo konsultacijai

NESS SPĮ IS Siuntimo pri÷mimo duomenys Siuntimo pri÷mimo pakeitimas. Pranešimas, siunčiamas, kai reikia pakeisti prieš tai pateiktą siuntimo pri÷mimą. Pranešimas pakeičia siuntimo pri÷mimo dokumento būseną į „pasenusią“ (angl. „obsolete“).




NESS SPĮ IS Paieškos kriterijus atitinkantys įrašai

Tinkamų įrašų paieškos rezultatas - Atsakyme pateikiama parametrus atitinkati santrauka.




NESS SPĮ IS Konkretaus įrašo duomenys Atsakymas į konkretaus įrašo peržiūros užklausą




NESS SPĮ IS Atnaujinti paciento duomenys Kitų IS informavimas apie pasikeitusius duomenis pacientų kataloge.

Automatinis XML formato HL7 V3 pranešimai


NESS SPĮ IS Demografinių duomenų keitimo patvirtinimas

Paciento demografinių duomenų keitimo patvirtinimas




NESS SPĮ IS S÷kmingo pakeitimo informacija Suplanuoto laiko būsenos pakeitimas s÷kmingas




NESS SPĮ IS Užsakyto tyrimo informacija Tyrimo informacijos paieškos rezultatas







SVEIKATOS APSAUGOS

MINISTERIJA

Priedas Nr. Priedas Nr. Priedas Nr. Priedas Nr. 3 3 3 3 –––– Klasifikatoriai ir informacijos katalogaiKlasifikatoriai ir informacijos katalogaiKlasifikatoriai ir informacijos katalogaiKlasifikatoriai ir informacijos katalogai

Duomenų šaltinis NESS branduolio sąsajos Komentarai

Sveikatos priežiūros specialistai

Pirminis duomenų įk÷limas:

► Gydytojų spaudų numeriai iš IS SVEIDRA esamų duomenų ► Licencijos iš licencijuojančių institucijų informacinių sistemų

NESS branduolys teikia gydytojų paieškos sąsają, kuri skirta NESS klientinei daliai. Realiai šia sąsaja gal÷tų naudotis ir kitos sistemos.

N÷ra automatinio duomenų atnaujinimo iš duomenų teik÷jų. Numatytos priemon÷s administruoti klasifikatorių rankiniu būdu. Padid÷ja administravimo sąnaudos, klaidų tikimyb÷.

Sveikatos priežiūros ir farmacijos įstaigos

Duomenų kilm÷ dokumentacijoje nepateikiama NESS branduolys teikia gydymo įstaigų paieškos sąsają, kuri skirta NESS klientinei daliai. Realiai šia sąsaja gal÷tų naudotis ir kitos sistemos.

N÷ra automatinio atnaujinimo ar sinchronizavimo su JAR (Juridinių asmenų registrų). Duomenys neatnaujinami automatiškai pagal „Valstybin÷s akreditavimo sveikatos priežiūros veiklai tarnybos prie Sveikatos apsaugos ministerijos“ turimą informaciją.

Sveikatos priežiūros paslaugų klasifikatorius (licencijuojamos paslaugos ir paslaugos apmokamos iš PSDF)

Pradiniai duomenų apie licencijuojamas paslaugas šaltiniai yra licencijuojančios įstaigos ir jų naudojamos sistemos.

N÷ra. N÷ra automatinio duomenų atnaujinimo.

Pradinis duomenų apie paslaugas, apmokamas iš PSDFB ir jų kainas šaltinis yra IS SVEIDRA. Konvertavimo metu sukuriamos paslaugos, apmokamos iš PSDFB bei jų kainos. Kainų istorija nepakraunama.

N÷ra. Veikia automatinis duomenų atnaujinimas iš IS SVEIDRA

Ligos

Pradinis duomenų šaltinis yra IS SVEIDRA tvarkomas TLK-10 klasifikatorius. NESS branduolys teikia ligų paieškos tinklines paslaugas, skirtas NESS klientinei daliai. Realiai šia sąsaja gal÷tų naudotis ir kitos sistemos.

Yra tik pirmin÷ duomenų integracija, t.y. duomenys užkraunami pirminio migravimo metu, tačiau n÷ra automatinio duomenų atnaujinimo.

Kiti klasifikatoriai

Klasifikatoriai perkeliami iš statinio sąrašo, kuris pateikiamas dokumente „Duomenų konvertavimo strategija ir darbų planas“.

► Dokumentų tipai

► Tyrimų rūšys ir parametrai

► Valstyb÷s

► Savivaldyb÷s

► Licencijuojančios institucijos

► Ekonomin÷s veiklos rūšys

NESS branduolys teikia klasifikatorių paieškos tinklines paslaugas skirtas NESS klientinei daliai. Realiai šia sąsaja gal÷tų naudotis ir kitos sistemos.

Yra sukurtos klasifikatorių administravimo priemon÷s. Tačiau n÷ra sinchronizavimo su pirminiais duomenų šaltiniais (pvz. su registrų centru, iš kurio galima gauti savivaldybių sąrašą).




SVEIKATOS APSAUGOS

MINISTERIJA

Priedas Nr. Priedas Nr. Priedas Nr. Priedas Nr. 4444–––– NESS I projekto rezultatų panaudojimas NESS I projekto rezultatų panaudojimas NESS I projekto rezultatų panaudojimas NESS I projekto rezultatų panaudojimas

Nr.

Aprašymas Nuorodos Datos

Panaudojimas (Žinios,

Produktas, Prototipas)

1. 2006-02-27 galutin÷ Saugos koncepcijos dokumento versija (BZG0179-0044 v0.04 LT e-Health Security Concept Report)

BZG0179-0129 v0.02 LT e-H Acceptance Certificate

2006 m. vasaris Žinios

2. 2006-03-15 pateiktas Kritin÷s sveikatos informacijos dokumentas (kritin÷ sveikatos informacija su TLK10 v.03.doc)

BZG0179-0148 v.0.51 LT e-H Acceptance Certificate

2006 m. kovas Žinios

3. 2006-03-16 pateiktas Bendrosios sveikatos informacijos dokumentas nuo 0.02 iki 0.07 versijos (bendroji sveikatos informacija v.07.doc)



4. 2006-03-27 pateikta tvirtinti galutin÷ Registrų ir klasifikatorių koncepcijos versija (BZG0179-0047 v0.54 LT e-Health Registries Concept Report



5. Pateikta ir aptarta siuntimo konsultuoti informacija (paskiausia versija BZG0179-0154 LT v0.01 Referral to Specialist

BZG0179-0151 v0.02 LT eH Acceptance

2006 m. balandis Žinios




SVEIKATOS APSAUGOS

MINISTERIJA

Certificate 6. Pateikta ir aptarta konsultacijos įrašo informacija (paskiausia versija

BZG0179-0150 LT v0.04 Consultation note) BZG0179-0151 v0.02 LT eH Acceptance Certificate





SVEIKATOS APSAUGOS

MINISTERIJA

Nr.




7. Pateikta ir aptarta vaiko raidos informacija (paskiausia versija BZG0179-0151 LT v0.02 Child development information)

BZG0179-0151 v0.02 LT eH Acceptance Certificate


8. Pateikta vaiko gimimo pranešimo informacija (paskiausia versija BZG0179-0159 LT v0.01 Child birth notification.doc)



9. Pateikta epikriz÷s informacija (paskiausia versija BZG0179-0158 LT v0.02 Epicrisis note v.02.doc)



10. ► BZG0179-0171 v0 50 NESS IT arch requirements.doc ► BZG0179-0276 Sistemos duomenų modelis (REG) v1.0.doc ► BZR0179-0280 Sistemos funkcijų modelis (REG) v1.0.doc ► BZR0179-0276 Modulių projektas (REG) v1.0.doc ► BZG0179-0273 duomenų baz÷s projektas (REG) v1.0.doc ► BZG0179-0283 NESS RD080 Sistemos duomenų modelis (ESIS DNS)

v0.50.doc ► BZG0179-0284 NESS RD090 Sistemos funkcijų modelis (ESIS DNS)

v0.50.doc ► BZR0179-0285 NESS DB010 Loginis duomenų baz÷s projektas (ESIS

DNS) v0.50.doc ► BZR0179-0289 Modulių projektas (ESIS DNS) v0.50.doc ► BZR0179-0296 Fizinis duomenų baz÷s projektas (ESIS DNS) v0.50.doc

BZG0179-0307 v1.00 LT NEWS

2006 m. rugs÷jo 29 d.

Žinios




SVEIKATOS APSAUGOS

MINISTERIJA

Nr.




10. ► BZR0179-0287 NESS RD080 Sistemos duomenų modelis (ESIS DS) v0.50.doc

► BZR0179-0288 NESS RD090 Sistemos funkcijų modelis (ESIS DS) v0.50.doc

► BZR0179-0286 NESS DB010 Loginis duomenų baz÷s projektas (ESIS DS) v0.50.doc

► BZR0179-0292 Modulių projektas (ESIS DS) v0.50.doc ► BZR0179-0295 Fizinis duomenų baz÷s projektas (ESIS DS) v0.50.doc ► BZG0179-0269 Modulių projektas (GDK) v1.0.doc ► BZG0179-0270 Loginis duomenų baz÷s projektas GDK.doc ► BZG0179-0271 Sistemos duomenų modelis (GDK) v1.0.doc ► BZG0179-0272 Sistemos funkcijų modelis (GDK) v1.0.doc

BZG0179-0307 v1.00 LT NEWS Acceptance.doc

2006 m. rugs÷jo 29 d.

Žinios




SVEIKATOS APSAUGOS

MINISTERIJA

Nr.




11. ► BZG0179-0281 LT v0.01 NESS&VAISKIS INT.doc ► BZG0179-0264 LT v0.050 NESS&SVEIDRA INT TS.doc ► BZG0179-292 LT v0.01 NESS SVEIDRA integracija.doc ► BZG0179-293 LT v0.01 NESS VAISKIS integracija.doc ► BZG0179-301 LT v0.50 WebMethods and Select Access integration

(Security).doc ► BZG0179-0297 LT v0.50 NESS_OV_Naudotojo_Vadovas.doc ► BZG0179-0266 LT v0.50 NESS HL7 OID Methodology.doc ► NESS Web-paslaugų aprašai CD/DVD laikmenoje ► NESS branduolio registrų ir klasifikatorių, pacientų katalogo ir ESIS

išeities tekstai CD/DVD laikmenoje (BZG0179-0305 HER, R&C, DC Source CD.zip)

► Integracin÷s programin÷s įrangos išeities tekstai CD/DVD laikmenoje ► NESS DV išeitiestekstai CD/DVD laikmenoje Pastaba. Visi šioje eilut÷je minimi dokumentai pateikti CD/DVD laikmenose su užrašu „Paslaugos Nr. 10 rezultatai“ ir UAB Hewlett-Packard projekto vadovo parašu bei data.


2006 m. rugs÷jo 29 d.

Prototipas

12. ► BZG0179-0309 v1.00 LT Change Request #2. Deliverables list with explanations.doc

Visi šioje eilut÷je minimi dokumentai pateikti CD/DVD laikmenoje su užrašu „Paslaugos Nr. 18 rezultatai“ ir UAB „Hewlett-Packard“ projekto vadovo parašu bei data.


2006 m. rugs÷jo 29 d.

Prototipas

Nr. Aprašymas Nuorodos Datos Panaudojimas




SVEIKATOS APSAUGOS

MINISTERIJA

(Žinios, Produktas, Prototipas)

13. WebMethods Enterprise Services Platform WebMethods Integration Platform procesoriaus licencija

Į procesoriaus licenciją produkcinei platformai įeina: ► webMethods Integration Server ► webMethods Broker ► webMethods Glue ► webMethods Glue – 1 procesoriaus licencija produkcinei platformai

WebMethods adapteriai – aplikacijų / sistemų / duomenų bazių integravimo priemon÷s (naudojimas priklauso nuo licencijuojamų procesorių skaičiaus). webMethodsJOBC Adapter webMethods Business Process Management webMethods Modeller Papildomos aplinkos

► Kūrimo aplinka (Development Environment) ► Testavimo aplinka (Testing / Staging Environment) ► Licensijuojamų aplinkų kiekis yra lygus aukščiau išvardintų produktų

licencijoms. Programin÷s įrangos laikmena CD laikmena su licencijuojama programine įranga webMethods programin÷s įrangos aptarnavimas ir technin÷ priežiūra Paslaugų paketas apima: ► Pagalbą visais klausimais telefonu, elektroniniu paštu ir internetin÷s

priemon÷s darbo valandomis (9:00-18:00 kliento vietos laiku) išskyus savaitgalius ir visuotinai priimtas šventes.

► Pagalbą telefonu visą parą 7 dienas per savaitę pirmojo ir antrojo

BZG0179-0230 v1.00 LT AC Webmethods

2006 m. rugs÷jo 29 d.

Produktas




SVEIKATOS APSAUGOS

MINISTERIJA

kritiškumo laipsnio problemoms spręsti ► Galimybę visą parą keiptis pagalbos į Advantage support internetinį

puslapį ► Galimybę kreiptis i septynis įgaliotus techninius konsultantus ► Programin÷s įrangos palaikymą ir versijų atnaujinimą ► Galimybę gauti informacinį biuletenį apie naujus programin÷s įrangos

ypatumus, renginius ir straipsnius aktualiais klausimais.

Nr.




14. Parengti koncepcijų projektai: ► Veiklos procesų koncepcija [BZG0179-0042 LT e-Health Concept

Report Processes]; ► Saugos koncepcija [BZG0179-0044 v0.04 LT e-Kealth Security Concept

Report] ► Integracijos ir pranešimų teikimo koncepcija [BZG0179-0089 v0.02

Concept Integration messaging]; ► Registrų ir klasifikatorių koncepcija [BZG0179-0047 v0.51 LT e-Health

Registries Concept Report]; ► E. sveikatos istorijų saugyklos koncepcija [BZG0179-0046 v0.03 LT e-

Health EHR Concept Report]

BZG0179-0089 v0.01 LT eH Acceptance Sertificate

2005 m. sausis Žinios

Nr.







SVEIKATOS APSAUGOS

MINISTERIJA

15. HP OpenView Select Access 100 naudotojų licencija, kai visas naudotojų skaičius yra ne mažesnis kaip 10 000 (Licencija 10 000 naudotojų). Techninis T3257AA produkto aptarnavimas iki 2009.05.01 (sutarties numeris 101421200228, sistemos identifikatorius – SAM-OV-01 HP Select Access 6.2. Laikmena

BZG0179-0232 v1.01 LT AC HP Select Access

2006 m. rugs÷jo 29 d.

Produktas Pastaba: gamintojas jau yra jau nutraukęs šio produkto palaikymą

16. Oracle Server Enterprise Edition 10G licencijos 2 pro: ► Oracle Database 10g Release 2 (10.2.0.1.0) Media Pack v2 for HP-UX

Itanium ► Oracle Enterprise Manager 10g Release 2 Grid Control (10.2.0.1.0) Media

Pack v4 for Linux x86 ► Oracle Warehouse Builder 10g Release 2 (10.2.0.1) Media Pack v2 for HP-

UX Itanium Technin÷ priežiūra iki 2007.10.19

BZG0179 C231 v1.07 LT AC Oracle.doc

2006 m. rugs÷jo 29 d.

Produktas

17. ► Microsoft® Windows® Server Standard 2003.R2 English OPEN No Level

► Agreement Information: MOLP-Z Standard ► Authorization Number: 19913944ZZSO712 ► Indirect Customer Name: Hewlett-Packard UAB ► Licence Number: 41075572 ► Microsoft Invoice Number: 9141075572 ► Reorder/Upgrade End Date: 2007-12-31

BZG0179-0233 v1.D1 LT AC Microsoft

2006.09.29 Produktas




SVEIKATOS APSAUGOS

MINISTERIJA

Nr.




18. „Microsoft Open Licence Purchase Order Cinfirmation“ (Licencijos Nr. 41075572)

BZG0179-0233 v1.D1 LT AC Microsoft


19. Microsoft® Windows® Server Standard 2003.R2 English OPEN No Level BZG0179-0233 v1.D1 LT AC Microsoft





SVEIKATOS APSAUGOS

MINISTERIJA

PriedPriedPriedPriedasasasas Nr. Nr. Nr. Nr. 5555 –––– Susijusių dokumentų ir informacijos šaltiniųSusijusių dokumentų ir informacijos šaltiniųSusijusių dokumentų ir informacijos šaltiniųSusijusių dokumentų ir informacijos šaltinių sąrašassąrašassąrašassąrašas

[1] BZG0179-0297 v2.00 NESS_DV_Naudotojo_Vadovas.doc

[2] BZG0179-0171 v0.52 NESS IT arch requirements.pdf

[3] BZG0179-0290 v.02 User Access Administration _Security_.pdf

[4] BZG0179-0327 v0.50 NEHS IT Admin Roles_LT.pdf

[5] BZG0179-0329 NESS_DV_Tutorial.pdf

[6] BZG0179-0290 v.02 User Access Administration (Security).doc

[7] BZG0179-0301 v0.50 WebMethods and SelectAccess integration (.doc

[8] BZG0179-292 LT v1.00 NESS SVEIDRA Integracija.doc

[9] BZG0179-293 LT v1.00 NESS Vaistu informacijos atnaujinimas.doc

[10] BZG0179-0322 Instaliavimo planas (REG GDK) v2.0.doc

[11] Branduolio funkcijos.htm - NESS branduolio funkcijų aprašymas tinklinių paslaugų deklaracijų failuose

[12] Oracle Forms 10g 2 (10.1.2.x) leidimas: Kliento platformos palaikymas http://www.oracle.com/technology/products/forms/htdocs/10gR2/clientsod_forms10gR2.html

[13] BZG0179-0216 Duomenu konvertavimo strategija ir Darbu planas.doc

[14] Duomenu pakrovimo instrukcija.doc

[15] Programin÷s įrangos JInitiator parsisiuntimas http://www.oracle.com/technology/software/products/developer/htdocs/jinit.htm

[16] Oracle 11g taikomosios programin÷s įrangos aprašymas: http://www.orafaq.com/wiki/Oracle_11g

[17] Apache atviro kodo program÷s įrangos versijavimo taisykl÷s http://apr.apache.org/versioning.html

[18] openLDAP versijų istorija http://en.wikipedia.org/wiki/OpenLDAP

[19] Oracle Identity Federation 11g Frequently Asked Questions http://www.oracle.com/technology/products/id_mgmt/coreid_fed/pdf/identity_federation_faq.pdf

[20] BZG0179-0089 v1.01 Integracijos koncepcija

[21] E. sveikatos sistemos 2009–2015 metų pl÷tros programos projektas

[22] E. sveikatos sistemos 2009–2015 metų pl÷tros programos priemonių plano projektas

Toliau šiame dokumente nuoroda į susijusį dokumentą yra pateikiama taip „[X]“, kur X – dokumento nuorodos numeris.