Telemedicină şi e-Sănătate

CURS 3 - Prof. dr. ing. Hariton Costin

I. Specificaţii de proiectare pentru organizarea unui centru

regional de telemedicină

II. Specificaţiile de proiectare software pentru organizarea

unui centru local de telemedicină şi telemonitorizare

1
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

Figura 1. Arhitectura generala a unui sistem integrat de telemedicină

2
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

Figura 2. Arhitectura de tip SOA (Service Oriented Architecture ) a sistemului

central (TELEMON)

3
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

1. Serviciile oferite pacientilor si personalului medical:

• crearea fişei pacientului (EHR- e-Health Record)

• managementul profilului utilizatorului
• accesarea informaţiilor despre pacienţi (de exemplu un istoric al
bolilor)
• personalul medical poate să acceseze informaţii (de urgenţă) de la
subsistemul local, dar are acces şi la informaţii complete prin
accesarea sistemului central
• accesarea informaţiilor despre cazuri similare
• căutarea celui mai apropiat centru de urgenţă
• receptarea şi redirectarea diferitelor alarme legate de starea
pacienţilor
• procesarea diferitelor biosemnale
• localizarea pe hartă a pacientului, pentru cazuri de urgenţă
• diverse statistici necesare medicului specialist şi sistemelor de
îngrijire a sănătăţii.

4
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

(a) SOA nu este o tehnologie, ci o metodologie a cărei scop este proiectarea unui
sistem format dinr-un set de servicii, acestea putând fi refolosite pentru diferite
situatii.
(b) Într-o platforma SOA, serviciile respecta niste caracteristici importante:
• serviciile sunt autonome
• serviciile sunt slab conectate (loosely coupled). Beneficiile oferite de aceasta
caracteristica sunt: flexibilitatea, scalabilitatea, posibilitatea inlocuirii rapide,
toleranta la erori
• serviciile pot fi compuse pentru crearea altor servicii (composability). Aceasta
caracteristica permite reutilizarea functionalitatilor deja exitente.
• serviciile participa in cadrul diferitelor “workflow”-uri. O operatie realizata de un
serviciu va depinde de mesajul care a fost receptat (service choreography)
• serviciile pot fi cu usurinta descoperite (discoverability), eventual in mod
automat. Pentru aceasta, serviciile trebuie sa faca publice diferite elemente
(interfaţa, protocoalele suportate, diferite politici de acces etc.)
• Alte caracteristici: limbajul de programare, platforma pe care ruleaza serviciile
• SOA este un stil arhitectural iar serviciile Web pot fi privite ca tehnologia care
asigura implementarea efectivă

5
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

• Specificaţiile - cheie folosite de servicile Web sunt:

• XML (eXtensible Markup Language): un meta-limbaj care a devenit o

paradigmă omniprezentă pentru interschimbul de informatii
(semi)structurate
• SOAP (Simple Object Access Protocol): un protocol bazat pe XML care
permite schimbul de informaţii structurate (cererea şi răspunsul unui
serviciu) într-un mediu distribuit şi descentralizat
• WSDL (Web Services Description Language): un limbaj bazat pe XML
folosit pentru descrierea servicilor Web (atributele serviciilor, interfaţa
serviciilor şi alte proprietăţi)
• XML, SOAP şi WSDL sunt standarde, acest fapt permiţând integrarea
sistemului în unul sau mai multe meta-sisteme de e-Health existente pe
piaţă
• Arhitectura SOA permite adăugarea cu usurinţă de noi facilitati, bazate pe
serviciile deja construite. Reutilizarea codului – program este maximă şi
deci timpul de dezvoltare şi testare este minim

6
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

2. Specificaţii generale pentru bazele de date folosite într-

un SITM (Telemon) (nivelul Database din Fig. 2)
Figura 2: Telemon are doua tipuri de baze de date:
• baze de date pentru subsistemele locale
• baza de data pentru sistemul central

(a) Baza de date pentru subsistemele locale contine informatii despre:

• medicii care activează în diferite instituţii medicale aparţinând zonei
respective;
• pacienţii abonaţi ai acestui subsistem local;
• consultaţiile realizate pentru pacienţii abonaţi;
• procedurile medicale realizate / tratamente;
• diagnosticele medicale.

(b) Baza de date pentru sistemul central conţine toate informaţiile

existente în toate bazele de date asociate subsistemelor locale;
tot aici se ţin o serie de date suplimentare (de exemplu lista tuturor
subsistemelor locale).
7
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

• Structura şi caracteristicile unui SITM

• SITM se compune din trei subsisteme mari:
(a) Aparatele pentru prelevarea parametrilor medicali vitali
ai persoanelor monitorizate. Probleme: stabilirea
semnalelor monitorizate precum şi a aparatelor care
vor fi utilizate.
(b) Reţeaua radio personală (WPAN), destinată colectării
şi transmisiei parametrilor monitorizaţi către reţeaua de
arie largă (WWAN). Stabilirea caracteristicilor acestor
reţele.
(c) Reţeaua de arie extinsă (WWAN) care poate fi o reţea
Wi-Fi ad hoc, Internet, telefonie mobilă sau fixa.
• Observatie: practic toate legăturile se fac prin sisteme
radio, singurele în măsură să asigure comunicaţiile în
orice condiţii de poziţie şi/sau mobilitate atât a
pacienţilor cât şi a asistenţei medicale.
8
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

“In spital”

Dispecerat
control
monitorizare
Monitorizare “la
pacient”
filă date
pacient
Telealarmă
WPAN generare,
pacient control
WPAN pe pacient
“în deplasare”
transfer imagine
prin radio “Acasă”

Staţie de bază GSM

Asistenţă ambulatorie
WPAN pe pacient
mobil “In maşină”

Figura 3. SITM pentru activităţi în spitale, în ambulator şi în teren

9
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

Figura 4. Arhitectura sistemului central SOA – module

10
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

• Modulele sistemului central (Fig. 4) sunt similare celor de

la subsistemele locale, diferenţele regăsindu-se în
principal la nivelul bazei de date.
• Interacţiunea cu utilizatorul: când un utilizator doreşte să
invoce un serviciu generic, se execută următorii paşi:
• autentificarea si autorizarea, realizate de modulul de
gestionare a identitatilor
• cererea utilizatorului este directionata (prin intermediul
modulului de rutare) catre modului de gestionare a
serviciilor
• uneori sunt necesare un numar de transformari pentru a
schimba date dintr-un format in altul suportat de catre
sistem. Acesta este rolul modulului de transformare a
datelor.

11
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

• Pentru a optimiza traficul de date sunt proiectate doua tipuri de

actualizari ale depozitului de date: actualizari instantanee si actualizari
periodice.
• Actualizările periodice se executa in mod regulat, la perioade pre-fixate
de timp si se aplica tuturor tipurilor de date. Actualizările instantanee
depind de un prag de urgenta, care cuantifica gravitatea starii
pacientului. Daca gravitatea starii pacientului este deasupra pragului de
urgenta, atunci se declanseaza o actualizare instantanee in baza de
date. Într-un caz de urgenta doctorul poate consulta specialistii care
sunt logati in sistemul central in acel moment şi pot interveni in
tratamentul pacientului respectiv direct în subsistemul local din care
acesta face parte.
• Informatiile privitoare la la tratament se sincronizeaza cu sistemul
central prin intermediul actualizarilor periodice sau instantanee. Mai
mult, atunci cand a avut loc in trecut un caz de aceeasi gravitate in alt
subsistem local, doctorul care este logat in acel subsistem consulta
depozitul de date pentru a obtine tratamentul aplicat anterior care l-ar
putea asista in luarea deciziilor privitoare la tratamentul curent.

12
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

Figura 5. Interacţiune generală (subsisteme locale cu cel central) 13

 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

II. Specificaţia pentru aplicaţiile software necesare

funcţionării unui centru local de telemedicină

În arhitectura subsistemelor locale apar urmatoarele

module (Figura 6):
• modulul front-end
• modulul de gestionare a identităţilor
• modulul de gestionare a serviciilor
• modulul de rutare
• modulul de baze de date
• modulul de gestiune a aplicaţiilor
• modulul de gestiune a depozitului de date.

14
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

Figura 6. Arhitectura software a subsistemului local

15
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

• Modulul front-end garanteaza interactiunea utilizatorului cu sistemul, la nivelul

de interactiune cu utilizatorul.
• Modulul de gestiune a identitatilor asigura autentificarea si autorizarea
utilizatorilor.
• Modului de gestionare a serviciilor este o componenta care asigura accesul la
serviciile disponibile.
• Modulul de rutare garanteaza faptul ca cererea ajunge la modulul de servicii.
• Modulul de baze de date asigura accesul transparent la bazele de date locale.
• Modulul de gestiune a aplicatiilor asigura accesul la operatii care nu sunt
accesibile utilizatorilor obisnuiti, precum pacientii sau personalul medical.
• Modului de gestiune a depozitului de date asigura accesul transparent la
depozitul de date central. Acest modul interactioneaza folosind servicii speciale
cu modulele de management al bazelor de date din fiecare subsistem local. De
aceea, in depozitul de date vom gasi date consistente din orice sub-sistem local.
• Aceste date provin din servicii de consumator (“consumer services”), care pot fi
servicii de actualizare sau cereri specifice de date. Sistemul asigura transferul
datelor de la subsistemele locale la cel central.

16
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

17
Figura 7. Structura bazei de date existente in subistemele locale
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

În Fig. 7 se identifică urmatoarele tabele:

• Tabelul PACIENTI (id#, nume, prenume, data_nastere, sex, cnp, adresa,

telefon_fix, telefon_mobil, email, grupa_sanguina, rh,
cod_casa_asigurari, cod_medic_familie, info_speciale) contine informatii
generale despre pacientii telecentrului medical.

• Tabelul CASA_ASIGURARI (cod_casa_asig, nume_casa_asig) contine

lista caselor de asigurari din Romania.
• Atributele au urmatoarea semnificatie:
• cod_casa_asig reprezinta codul casei de asigurari;
• nume_casa_asig reprezinta denumirea casei de asigurari.
• Cheia primara a acestui tabel este atributul cod_casa_asig.

• Datorita particularitatilor modelului, au fost considerate doua entitati

diferite, corespunzatoare celor doua categorii: medici de familie si medici
specialisti.

18
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

• Tabelul MEDIC_FAMILIE (cod_parafa#, nume, prenume,

data_nastere, cnp, telefon_fix, telefon_mobil, email, adresa_cabinet,
cod_casa_asig) contine informatii generale despre medicii de familie
din judetul corespunzator telecentrului medical.

• Atributele au urmatoarea semnificatie:

• cod_parafa reprezinta identificatorul medicului de familie;
• nume, prenume, data_nastere reprezinta numele, prenumele si data
nasterii medicului de familie;
• cnp reprezinta codul numeric personal;
• telefon_fix, telefon_mobil, email reprezinta informatiile de contact ale
medicului;
• adresa_cabinet reprezinta localizarea cabinetului medical;
• cod_casa_asig reprezinta codul casei de asigurari la care este afiliat
medicul.
• Cheia primara a acestui tabel este atributul cod_parafa. Atributul
cod_casa_asig este cheie externa relativa la campul cod_casa_asig
din tabelul CASA_ASIGURARI.

19
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

• Tabelul MEDIC_SPECIALIST (cod_parafa#, nume, prenume, data_nastere, cnp,

telefon_fix, telefon_mobil, email, cod_specialitate, grad, titlu_academic,
cod_institutie, cod_sectie) contine informatii generale despre medicii specialisti
din judetul corespunzator telecentrului medical. Entitatea medic specialist contine
atat medicii specialisti din spitale, policlinici, laboratoare afiliate telecentrului, cat
si medicii specialisti care lucreaza efectiv in cadrul telecentrului medical.

• Atributele au urmatoarea semnificatie:

• cod_parafa reprezinta identificatorul medicului specialist;
• nume, prenume, data_nastere reprezinta numele, prenumele si data nasterii
medicului specialist;
• cnp reprezinta codul numeric personal al medicului;
• telefon_fix, telefon_mobil, email reprezinta informatiile de contact ale medicului;
• cod_specialitate reprezinta codul specialitatii sale medicale;
• grad, titlu_academic reprezinta titlurile medicului specialist;
• cod_institutie reprezinta codul institutiei medicale in care lucreaza medicul
specialist;
• cod_sectie reprezinta codul sectiei in care activeaza medicul respectiv.
• Cheia primara a tabelului MEDIC_SPECIALIST este atributul cod_parafa.

20
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

• Tabelul TIPURI_SENZORI (id#, denumire) contine informatii despre

tipurile de senzorii care for fi folositi pentru preluarea informatiilor
legate de starea de sanatate a pacientilor.

• Atributele au urmatoarea semnificatie:

• id reprezinta identificatorul tipului de sensor si este generat
automat;
• denumire – reprezinta numele senzorului.
• Tabelul DATE_SENZOR (id#, id_pacient, id_tip_senzor,
time_stamp) contine informatii despre transmisiile de date.
• Atributele au urmatoarea semnificatie:
• id – reprezinta identificatorul unic al unei transmisii si este generat
automat;
• id_pacient – reprezinta identificatorul pacientului
• id_tip_senzor - reprezinta identificatorul senzorului
• time-stamp – reprezinta momentul de timp la care s-au primit
masuratorile

21
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

• Tabelul PARAMETRI (id#, id_tip_senzor, denumire, tip)

• Atributele au urmatoarea semnificatie:

• Id# – reprezinta identificatorul unic al unei transmisii si este generat automat;
• id_tip_senzor - reprezinta identificatorul senzorului
• denumire – reprezinta denumirea parametrului
• tip – tipul de date folosit pentru stocare (de exemplu: numeric, textual)

• Tabelul VALORI_PARAMETRI (id_date_senzor#, id_parametru#, valoare)

• id_date_senzor - reprezinta identificatorul pacientului
• id_parametru - reprezinta identificatorul senzorului
• valoare – reprezinta datele care vor fi trasmise de senzor
• Cheia primara a acestui tabel este compusa din atributele id_date_senzor si
id_parametru.

22
 Telemedicină şi e-Sănătate
CURS 3 - Prof. dr. ing. Hariton Costin

• Tabelul TIPURI_EVENIMENTE (id#, denumire)

• Id# – reprezinta identificatorul unic al unei transmisii si este generat
automat;
• denumire – reprezinta denumirea evenimentelor medicale

• Tabelul EVENIMENTE(id#, id_tip_eveniment, id_pacient,

timp_start, timp_sfirsit)
• Id# – reprezinta identificatorul unic al unei transmisii si este generat
automat;
• Urmatoarele atribute reprezinta cheile externe ale tabelului
EVENIMENTE:
• id_tip_eveniment este cheie externa relativa la campul id din tabelul
TIPURI_EVENIMENTE;
• id_pacient este cheie externa relativa la campul id din tabelul
PACIENTI.

23