Aplicatie Software Pentru Departamentul de Diabet Zaharat, Nutritie Si Boli Metabolice
Aplicație software pentru departamentul de
Diabet-zaharat, nutriție și boli metabolice
– S.I.M.T.I. –
— Teză de dizertație —
Alexandra MIHĂILĂ
Cuprins
Cuprins 2
Introducere 4
Cap. 1 – Studiu bibliografic 7
1.1. SIUI – Sistem informatic unic integrat al asigurărilor de sănătate din Romania 7
1.2. Hipocrate medical 8
1.3. Concluzie 10
Cap. 2 – Fundamentare teoretică 11
2.1. Aspecte generale despre Visual Studio 11
2.2. Limbajul C# 12
2.2.1. Caracterizare 12
2.2.2. Compilarea unui program C# de tip Windows Store App 12
2.2.3. Structura unui program C# de tip Windows Store App 13
2.3. Microsoft Azure 14
2.3.1. Site-uri web 14
2.3.2. Bază de date SQL 14
2.3.2. Stocare 15
2.4. SQL 15
Cap. 3 – Specificațiile aplicației 18
3.1. Schema bloc a sistemului. Scurtă descriere a aplicației 18
3.2. Funcțiile sistemului 21
3.3. Interfața cu utilizatorul 22
3.3.1 Modulul Utilizator 22
3.3.2. Modulul Administrator 22
3.3.4. Modulul Medic 23
3.3.5. Modulul Asistentă 24
3.4. Structuri de baze de date și fișiere 25
3.5. Tipărirea la imprimantă 26
3.6. Analiza de risc 26
3.7. Planificarea lucrărilor 26
3.7.1. Model de ciclu de viață 26
Cap. 4 – Proiectarea de detaliu 29
4.1. Arhitectura sistemului 29
4.1.1. Interfața cu utilizatorul 29
4.1.2. Programarea vizuală 29
4.2. Descrierea componentelor 32
4.2.1. Interfețe utilizator de tip administrator 33
4.2.2. Interfețe utilizator de tip doctor 36
4.2.3. Interfețe utilizator de tip asistentă 42
4.3. Structuri de baze de date 42
Cap. 5 – Concluzii 49
5.1. Ce sa realizat 49
5.2. Comparație cu alte sisteme 49
5.3. Direcții de dezvoltare 49
Bibliografie 50
Anexa 1: Lucrare știiințifică 52
Anexa 2. Model de declarație de originalitate 56
Introducere
Ideea temei pentru lucrarea de diplomă a apărut în urma proiectului din anul 1, în cadrul căruia, tot anul a trebuit să lucrăm în echipă și să realizăm un sistem eHealth folosind Microsoft Azure. Acel proiect a fost o adevarată aventură, deoarece atunci am observant cu adevarat cât de grea este comunicarea dintre medici si programatori, cât de greu este să realizezi șase aplicații ce trebuie să comunice între ele și toate aplicațiile să fie ușor de utilizat din punctul de vedere al utilizatorilor.
Pornind de la acest sistem ce era format din șase aplicații, m-am gandit că ar fi de ajutor un sistem informatics în cadrul spitalelor. În urma unor cercetri, deoarece un sistem informatic pentru un spital ar fi prea general, m-am hotarât să mă axez pe un sistem informatic pentru un department din cadrul unui spital și anume departamentul de diabet-zaharat, nutritie și boli metabolice.
Am ales aces department deoarece într-o societate într-o continuă schimbare și mișcare, oamenii uită cum să mănânce echilibra, iar bolile metabolice și diabetul- zaharat sunt din ce în ce mai frecvente.
Deoarece doctorii din cadrul spitalelor nu stau toata ziua in cabinet, ci saloane pentru a-și vizita pacienți, acest produs software ar fi folositor dacă ar putea fi accesibil de pe o tabletă. tablet deoarece smartphone-urile având ecranele mici nu foarte practice pentru o asemenea aplicație.
Ca sistem de operare pe care ar putea sa functioneze aplicația am ales Windows 8, adică am ales realizarea unei aplicații de tip windows deoarece este folosit și pe tablete și este compatibil cu Microsoft Azure. O tabletă funcționează exact ca un calculator ce are acest sistem de operare instalat, ceea ce va face utilizarea aplicației mult mai ușoară.
După ce am luat hotărârea ca aplicația să fie de tip window app și să fie atât variant desktop, cât și pe tablet, am cerut și opinia unui medic din cadrul acestui department. Domnul doctor Farcaș Caius a considerat idea mea ca fiind foarte bine primită, iar faptul că va fi pe Windows 8 nu ar fi o problemă doarece medicii lucr cu acest sistem de operare.
În acest domeniu informațiile din carul aplicațiilor trebuie sa respecte anumite standarde, ceea ce mi-a oferit libertate pe partea de design și pe partea de interacționare cu ultilizatorul.
O astfel de aplicație implică anumite costuri de investiție, cum ar fi crearea unui cont pe platforma Microsoft Azure și achiziționarea unei sau mai multor tablete cu sistemul de operare Windows 8, dar avantajele pe care o astfel de aplicație le oferă merită investiția.
Iată o parte din beneficiile utilizări unui astfel de :
Se câștigă timp pentru consultație (primează aspectul clinic și comunicarea medic – pacient);
Acces rapid la informații folositoare atât despre pacient, cât și la articole stiințifice
Posibilitatea de adaugare a programrilor induce disciplină și crește respectful față de medic și de instituție
Ca surse de inspirație am utilizat atât proiectul din anul 1 de facultate, cât si aplicațiile DOCS, MedINS și SIUI (pusă la dispoziție de Casa Națională de Asigurări de Sănătate). De la acestea și de la discuția cu medicul specialist porni prin alcătuirea listei de specificații.
Prin această aplicație îmi propun să țin evidența unui departament de diabet-zaharat, nutritie și boli metabolice. Aceasta presupune existența unei baze de date cu ajutorul căreia să reținem:
Utilizatorii aplicației
Informațiile de la fiecare consultație
Informațiile din fiecare act medical eliberat
Programrile
Lista cu documentele folositoare pentru un medic ( exemplu link-uri înspre articole medicale)
Pe scurt aplicația trebuie să permită înregistrarea fiecărei acțiuni realizate de către medicul specialist pe parcursul fiecărei zile și mai apoi vizualizarea acțiunilor înregistrate anterior și tipărirea listelor de care are nevoie.
Am plecat de la ideea că aplicația poate fi instalată pe un calculator sau o tabletă unde au acces mai mulți medici și asistente (cazul cabinetel unde lucrează mai mulți medici „în schimburi”) și din acestă cauză nu ar fi practic instalarea mai multor versiuni pentru fiecare medic și o versiune pentru fiecare asistentă. A fost nevoie astfel să găsesc o soluție prin care să restricționez accesul la baza de date. O soluție ar fi ca accesul să se facă pe baza unui nume de utilizator și a unei parole, astfel aplicația ar fi particularizată pentru fiecare. E nevoie astfel:
Cont de tip administrator – aceștia se vor ocupa de gestionarea conturilor utilizatorilor
Cont de tip doctor – vor avea acces la informații legate de pacienți și vor putea adăuga date în interiorul aplicației
Cont de tip asistenta – va putea modifica date personale ale unui pacient și va avea acces la programări.
Deoarece această soluție mi se pare cea mai convenabilă am împar aplicația pe trei module: modulul administrator, modulul medic si modulul asistentă, fiecare având alte interfețe.
Numele aplicației l-am ales să fie S.I.M.T.I, ceea ce e prescurtarea de la ,,Sistem informatic medical de tratare si investigare, iar ca siglă am ales să folosesc cercul abastru, ce este simbolul universal pentru diabet și un cursor, deoarece este vorba despre o aplicație.
Figure 0-1 Logo aplicație
Cap. 1 – Studiu bibliografic
Înainte de dezvoltarea unei aplicații informatice care să corespundă cu cerințele utilizatorului, este necesară o analiză a programelor create anterior, studiind îndeplinirea unui set de criterii de bază. Aceste criterii abordează câteva aspecte cum ar fi fiabilitatea, credibilitatea, gestiunea versiunilor, controlul accesului, confidențialitatea, introducerea și afișarea datelor.
SIUI – Sistem informatic unic integrat al asigurărilor de sănătate din Romania
SIUI este pusă la dispoziție de Casa Naționala de Asigurări de Sănătate (CNAS). Sistemul Informatic Unic Integrat al Asigurărilor Sociale de Sănătate din România este un factor cheie în dezvoltarea și perfecționarea serviciilor medicale și farmaceutice, reprezentând o soluție pentru îmbunătățirea gestiunii fondului național unic de asigurări sociale de sănătate și pentru oferirea de servicii medicale și farmaceutice de calitate asiguraților.
Sistemul Informatic Unic Integrat este extrem de important pentru realizarea informatizării în domeniul sănătății, pentru uniformizarea sistemului de raportare și prelucrare a datelor din sănătate, la nivel național și județean. În același timp, SIUI este aliniat la strategia națională de informatizare și se poate alinia ușor la reglementările organismelor internaționale cu care se efectuează schimburi permanente de date.
Pentru ca acest sistem să fie realizat a fost nevoie să lucreze următorul consorțiu:
Hewlett-Packard (HP) în calitate de integrator de sistem și furnizor de infrastructura informatică
Serviciul de Transmisiuni Speciale (STS) pentru servicii de telecomunicații
SIVECO România care asigură proiectarea, dezvoltarea și instalarea aplicațiilor informatice
Figure 1.1-1 Interfață SIUI CLINIC
Sistemul SIUI CLINIC este într-o continuă dezvoltare, ultima actualizare fiind făcută chiar în 11 iunie 2015, și anume, actualizări la aplicațiile de raportare.
Hipocrate medical
Hipocrate Medical este pus la dispoziție de Romanian Soft Company. Această aplicație are ca obiective principale:
Prelucrarea automata si centralizata a informatiilor despre pacienti
Urmarirea electronica a starii de sanatate a pacientului pe parcursul mai multor examinari in cadrul spitalului
Fluidizarea circulatiei informatiei intre cladiri si/sau sectiile spitalului
Cresterea eficientei lucrului in spital
Centralizarea si automatizarea managementului spitalului
Figure 1.2-1 Hipocrate
Ca și beneficii cei de la Romanian Soft Company amintesc următoarele:
Obtinerea datelor in timp real permite managementului stabilizarea functionarii spitalului prin eficientizarea sectiilor subordonate
Automatizarea prelucrarii si transferului de date si imagini
Management clienti si structuri de decontare
Raportari corecte si controlabile catre finantatori
Modificari de raportari, in cel mai scurt timp catre finantatori, in concordanta cu schimbarile legislative de ultima ora
Posibilitati avansate de configurare a aplicatiei
Urmarirea tuturor consumurilor de materiale generate de diverse sectii in timp real (aprovizionare pe termen scurt si eliminare stocurile create in unitate)
Sistem nelimitat extensibil bazat pe tehnologia Internet/Intranet
Securitatea datelor (eliminarea cator mai multe erori umane)
Concluzie
Chiar dacă nici una din aplicațiile studiate nu sunt create special pentru departamentul de Diabet-zaharat, nutriție și boli metabolice, le-am considerat ca fiind exemple relevante. Aceste aplicații ne arată că se pot crea sisteme complexe ce vin în întâmpinarea personalului medical. Ca toate aplicațiile complexe, acestea necesită mentenanță și feedback continuu de la utilizatori.
Cap. 2 – Fundamentare teoretică
Pentru realizarea aplicației s-a folosit mediul de dezvoltare oferit de cei de la Microsoft și anume Visual Studio, versiunea 2013. Din pachetul de limbaje puse la dispoziție s-a ales C#. Pentru datele care trebui reținute în tabele s-a folosit sistemul de gesiune a bazelor de date pus la dispoziție de cei de la Microsoft Azue, și anume SQL Database și Storage, pentru interogarea bazei de date s-a folosit limbajul SQL.
Aspecte generale despre Visual Studio
Visual Studio, vesiunea 2013, a apărut în 26 iunie 2013. Am ales această versiune deoarece permite:
realizarea de aplicații de tip ,,Windows Store appsˮ
se pot creea web service-uri prin care
oferă posibilitatea de a emula diferite tipuri de tablete
debug direct pe dispozitiv ( în cazul meu direct pe o tableă cu Windows 8)
exista versiune gratis, Visual Studio Community 2013
Editorul pus la dispoziție posedă o proprietate destul de interesantă numită IntelliSense care se poate traduce prin punerea la dispoziția programatorului a unei liste care conține variabile și obiecte care se pot folosit. De asemenea pentru fiecare control/obiect folosit afișează lista de proprietăți corespunzătoare lui. Utilizarea acestei proprietăți puse la dispoziție de Visual Studio scutește programatorul de o serie de erori de sintaxă care pot apărea în momentul compilării codului sursă.
Visual Studio suportă diferite tipuri de limbaje cu ajutorul pachetelor specifice. Din categoria limbajelor care pot fi utilizate fără a fi nevoie de instalarea unor pachete speciale fac parte: C/C++ (Visual C++), VB.NET (Visual Basic .NET), C# (Visual C#), F#, XML/XSLT, HTML/XHTML, JavaScript și CSS.
Limbajul C#
2.2.1. Caracterizare
Din familia limbajelor oferite de către Visual Studio, pentru dezvoltarea acestui proiect s-a ales limbalul C#. Acesta este un limbaj de programare orientat-obiect conceput de Microsoft la sfârșitul anilor 90. C# este un derivat al limbajului de programare C++. C# simplifică mult scrierea de programe pentru sistemul de operare Windows.
Limbajul C# a fost dezvoltat de o echipă restrânsă de ingineri de la Microsoft, echipă din care s-a evidențiat Anders Hejlsberg (autorul limbajului Turbo Pascal și membru al echipei care a proiectat Borland Delphi). C# este un limbaj simplu, cu circa 80 de cuvinte cheie și 12 tipuri de date predefinite. El permite programarea structurată, modulară și orientată obiectual, conform perceptelor moderne ale programării profesioniste.
Principiile de bază ale programării orientate pe obiecte (ÎNCAPSULARE, MOȘTENIRE, POLIMORFISM) sunt elemente fundamentale ale programării C#. În mare, limbajul moștenește sintaxa și principiile de programare din C++. Sunt o serie de tipuri noi de date sau funcțiuni diferite ale datelor din C++, iar în spiritul realizării unor secvențe de cod sigure (safe), unele funcțiuni au fost adăugate (de exemplu, interfețe și delegări), diversificate (tipul struct), modificate (tipul string) sau chiar eliminate (moștenirea multiplă și pointerii către funcții). Unele funcțiuni (cum ar fi accesul direct la memorie folosind pointeri) au fost păstrate, dar secvențele de cod corespunzătoare se consideră „nesigure”.
2.2.2. Compilarea unui program C# de tip Windows Store App
Pentru compilarea programului, se selectează Build din meniul principal. În cazul în care sunt erori, acestea sunt afișate în fereastra Error List. Efectuând dublu-clic pe fiecare eroare în parte, cursorul din program se poziționează pe linia conținând eroarea. Rularea programului se poate realiza în mai multe moduri:
rapid fără asistență de depanare (Start Without Debugging Ctrl+F5)
rapid cu asistență de depanare (Start Debugging F5 sau cu butonul din bara de instrumente)
rulare pas cu pas (Step Into F11 și Step Over F10)
rulare rapidă până la linia marcată ca punct de întrerupere (Toggle Breakpoint F9 pe linia respectivă și apoi Start Debugging F6). Încetarea urmăririi pas cu pas (Stop Debugging Shift+F5) permite ieșirea din modul depanare și revenirea la modul normal de lucru. Toate opțiunile și rulare și depanare se găsesc în meniul Debug al mediului de programare.
Pentru aplicațiile de tip Windows 8 depanarea se poate face și cu ajutorul emulatorului sau chiar pe dispozitivul pentru care este creată aplicația.
Pentru a face depanarea pe un dispozitiv gen o tableta trebuie următorii pași:
instalarea programului Remote Tools for Visual Studio 2013 pe dispozitiv
pornim programul
conectam dispozitivul la PC
în Visual Studio selectăm la depanare Remote Machine
selectăm dispozitivul corespunzător
2.2.3. Structura unui program C# de tip Windows Store App
O aplicație C# este formată din una sau mai multe clase, grupate în spații de nume (namespaces). Este obligatoriu ca doar una din aceste clase să conțină un „punct de intrare”(entry point), și anume metoda (funcția) MainPage.
Clasa (class), în termeni simplificați, reprezintă principalul element structural și de organizare în limbajele orientate spre obiecte, grupând date cât și funcții care prelucrează respectivele date.
Spațiul de nume (Namespaces): din rațiuni practice, programele mari, sunt divizate în module, dezvoltate separat, de mai multe persoane. Din acest motiv, există posibilitatea de a apărea identificatori cu același nume. Pentru a evita erori furnizate din acest motiv, în 1955 limbajul C++ introduce noțiunea și cuvântul cheie namespace. Fiecare mulțime de definiții dintr-o librărie sau program este grupată într-un spațiu de nume, existând astfel posibilitatea de a avea într-un program definiții cu nume identic, dar situate în alte spații de nume. În cazul în care, într-o aplicație, unele clase sunt deja definite, ele se pot folosi importând spațiile de nume care conțin definițiile acestora. Mai menționăm faptul că un spațiu de nume poate conține mai multe spații de nume.
În C#, simplificat vorbind, un program poate fi privit ca având mai multe „straturi”: avem cod în interiorul metodelor, care, la rândul lor, se află în interiorul claselor, aflate în interiorul namespaces-urilor.
Microsoft ne ofera guidelines pentru a creea o aplicație de tip Windows 8. Aceste guidelines cuprind sfaturi atât pentru cum să fie codul scris, cât și pentru design, structura paginilor, culorile pe care să le folosim, ghiduri pentru controalele folosite in aplicatie, etc. Toate acestea vin în întâmpinarea programatorului.
Microsoft Azure
Microsoft Azure este o platformă de Cloud deschisă și flexibilă care ne permite să dezvoltăm, să implementăm și să gestionationăm rapid aplicații într-o rețea globală de centre de date gestionate Microsoft.
Aceasta platforma ne ofera mai multe servicii, dar in cazul aplicației S.I.M.T.I. avem nevoie doar de:
Site-uri web
SQL database
Storage ( Stocare)
2.3.1. Site-uri web
Azure Web Sites permite instalarea rapidă a aplicațiilor web pe o structură Cloud scalabilă și de incredere. Cu ajutorul acestui serviciu putem scala resursele sau numărul de noduri, sau putem configura ca sa scaleze automat conform cerințelor aplicației. Acest serviciu am hotărât să îl folosesc pentru a încărca pe el serviciul web de care are nevoie aplicația mea.
2.3.2. Bază de date SQL
Azure SQL Database este un serviciu pentru baze de date relaționare. Limbajul folosit este SQL. Spre deosebire de baze de date bazate pe cloud similare, baze de date SQL de pe platforma Microsoft Azure permite utilizatorilor să facă interogări relaționale cu datele stocate, care pot fi fie structurate sau documente semi-structurate sau nestructurate.
SQL Database folosește o versiune specială a Microsoft SQL Server ca și backend. Acesta expune un subset de funcționalitate completă SQL Server, inclusiv doar un subset de tipuri de date – string, numeric, data și Boolean. Se folosește un format bazat pe XML pentru transferul de date. Ca Microsoft SQL Server. , baze de date SQL foloseste T-SQL ca limbaj de interogare și tabelară a datelor Stream (TDS), ca protocolul pentru a accesa serviciul prin Internet. (produsul nu oferă un API bazat pe REST pentru a accesa serviciul peste HTTP -. Microsoft recomandă utilizarea ADO.NET Data Services în acest scop )
2.3.2. Stocare
Un alt serviciu foarte folositor de la Microsoft Azure este serviciul de stocare. Acesta ofera utilizatorilor spatii de stocare pentry structure de date non-relaționale cum ar fi obiecte sau fișiere binare, tabele simple, cozi sau discuri virtuale.
Pentru această aplicație se va folosi acest serviciu pentru a stoca spre exemplu fișele pacienților.
SQL
Limbajul SQL este abrevierea de la Structured Query Language (limbaj structurat de interogare) și este un limbaj conceput special pentru comunicarea cu bazele de date. Spre deosebire de alte limbaje de programare, SQL se compune din foarte puține cuvinte (instrucțiuni), ceea ce face să fie ușor de învățat și folosit. Toate bazele de date importante acceptă limbajul SQL, așa că învățarea lui este de un real folos. În ciuda aparentei simplități, SQL este un limbaj foarte puternic se pot efectua operații complexe și sofisticate cu bazele de date.
Limbajul SQL este un limbaj neprocedural sau declarativ deoarece nu conține instrucțiuni precum IF, GOTO, WHILE sau altele care să ofere un flux de control; utilizatorul lui descrie numai informațiile pe care vrea să le obțină în urma interogării bazei de date, fără a fi nevoie să stabilească și modalitățile de a ajunge la rezultatele dorite. Există un anumit grad de standardizare a limbajului SQL, mai multe SGBDR recunoscând principalele instrucțiuni ale acestuia. Pe plan mondial, standardul în domeniu este considerat ANSI (American National Standards Institute) SQL care are în vedere atât aspectele de definire, interogare, manipulare a datelor, procesare a tranzacțiilor, cât și caracteristicile complexe privind securitatea informațiilor.[10]
Instrucțiunile SQL se grupează astfel:
Instrucțiuni de definire a datelor;
Instrucțiuni de manipulare a datelor (adăugare, modificare, ștergere);
Instrucțiuni de selecție a datelor (consultare a bazei de date);
Instrucțiuni de procesare a tranzacțiilor.
Principalele instrucțiuni SQL
SELECT – instrucțiunea SQL cea mai utilizată. Se folosește pentru regăsirea (interogarea) datelor din unul sau mau multe tabele sau vederi. Sintaxa este următoarea:
UPDATE – Instrucțiunea UPDATE actualizează una sau mai multe linii dintr-o coloană. Sintaxa este următoarea:
INSERT – Instrucțiunea INSERT adaugă o singură linie într-un tabel. Sintaxa este următoarea:
INSERT SELECT – Instrucțiunea INSERT SELECT inserează rezultatele unei interogări, într-un tabel. Sintaxa este următoarea:
DELETE – Instrucțiunea DELETE șterge una sau mai multe linii dintr-un tabel. Sintaxa este următoarea:
DROP – Instrucțiunea DROP șterge permanent obiecte din bazele de date (tabele, vederi, etc). Sintaxa, pentru ștergerea unui tabel, este următoarea:
CREATE TABLE – Instrucțiunea CREATE TABLE este folosită pentru crearea de noi tabele într-o bază de date. Sintaxa este următoarea:
ALTER TABLE – Instrucțiunea ALTER TABLE este folosită pentru actualizarea schemei unui tabel (adăugare și ștergere de coloane). Sintaxa este următoarea:
CREATE VIEW – Instrucțiunea CREATE VIEW este folosită pentru crearea unei vederi noi a unuia sau mai multor tabele. Sintaxa este următoarea:
Cap. 3 – Specificațiile aplicației
Schema bloc a sistemului. Scurtă descriere a aplicației
a) Schema generală a aplicației
Ȋn figura 3.1. este prezentată schema generală a aplicației. Aplicația software dezvoltat se adresează atât medicilor din centrele de permanență cât și asistentelor. Aplicația este dezvoltată pentru trei tipuri de utilizatori: administrator, medic și asistentă, fiecare dintre module având caracteristici particulare. Aceasta comunică cu o baze de date și poate folosi o imprimantă.
Figure 3-1-1 Schemă generala
La accesarea aplicației cu ajutorul iconiței de pe desktop se va deschide o fereastră în care se vor fi oferite informații generale, și care corespunde utilizatorului obișnuit. După accesarea link-ului de autentificare se va modifica interfața afișată în concordanță cu tipul de utilizator.
Aplicația este structurată pentru trei tipuri de utilizatori, acest lucru nu trebuie să însemne însă că aplicația este constituită din trei module independente puse în același loc și care nu au nici un fel de legătură sau asemănare. Structurarea interfeței trebuie să fie aceeași pentru toate tipurile de utilizatori, partea comună e reprezentată de modulul “pacient”. Informațiile oferite în cadrul acestuia se regăsesc în fiecare din celelalte module, datele particulare vin ca o completare la structura de bază.
Fiecare interfață trebuie să cuprindă:
Logo-ul aplicației
Un buton de înapoi ce va duce tot timpul la pagina anterioară
Numele utilizatorului ce este logat
Opțiunea de a ajunge spre pagina de profil a utilizatorului
La acestă structură se adaugă aspectele particulare pentru fiecare utilizator în parte. Totul trebuie însă adăugat pe acest nucleu, pentru a oferii utilizatorilor o aplicație ușor de folosit. Schema bloc a sistemului este prezentată în figura 3-2.
Figure 3.1-2 – Schema bloc a sistemului
Administrator
Administratorul este persoana responsabilă de gestiunea centrelor din județ, precum și a medicilor care deservesc aceste centre. Introducerea sau ștergerea unui a unui medic se realizează de către administrator. Atribuțiile acestuia sunt:
Introduce un nou utilizator în sistem și îi atribuie un nume de utilizator și o parolă
Modificarea parolei unui utilizator
Schimbarea unui user activ în user inactiv și viceversa
Gestionează mesajele
Pentru un sistem poate exista un singur administrator sau mai mulți. Inițial aplicația va veni însoțită de un singur cont de administrator. Utilizatorul de tip administrator se autentifică pe baza unui nume de utilizator și a unei parole. Rolul de administrator poate fi jucat de un medic din centrele de permanență sau poate fi atribuit unei persoane din exterior deoarece administratorul nu are acces la datele personale ale medicilor, ci doar la datele de logare.
Un administrator nu va putea niciodată să șteargă un cont de tot din sistem, ci doar să il pună pe inactiv. Am ales această soluție deoarece mi sa părut cea mai adegvată pentru a nu se pierde date.
Medic
Medicul reprezintă tipul de utilizator care accesează zilnic programul de gestiune pentru a completa rapoarte sau pentru a modifica date. Autentificarea se face pe baza unui nume de utilizator și a unei parole, acestea sunt primite de la administrator pe email sau prin alt mijloc de comunicare și trebuie modificate după prima autentificare. Tot la prima autentificare un utilizator de tip doctor este obligat să își completeze pagina de profil cu datele personale pentru a putea trece la utilizarea programului. Atribuțiile și drepturile atribuite unui medic:
Modificarea datelor personale și de contact
Vizualizarea fiselor pacientilor aferenți lui
Introducerea medicamentației pentru un pacient deja internat
Introducerea, modificarea și vizualizarea programărilor programărilor
Completarea fișelor de consultație, trimiteri
Gestionare mesaje
Documentarea asupra noilor tendințe în domeniu
Un medic își poate desfășoară activitatea în mai multe centre de permanență.
Asistentă
Asistenta este tipul de utilizator, dintre cei care se autentifică, cu cele mai puține atribuții și drepturi. Aceasta poate modifica doar datele personale și poate introduce diferite tipuri de articole. Autentificarea se face pe baza unui nume de utilizator și a unei parole, acestea sunt primite de la administrator și trebuie modificate după prima autentificare. Atribuțiile și drepturile atribuite unei asistente:
Modificarea datelor personale și de contact
Introducerea, modificarea și vizualizarea programărilor medicului
Introducerea si modificarea datelor pesonale ale unui pacient
Introducerea diferitelor tipuri de informații utile
Administrarea medicamentației și notarea acesteia în aplicație
Gestionare mesaje
Documentarea asupra noilor tendințe în domeniu
O asistentă își desfășoară activitatea în mai multe centre de permanență și la mai mulți medici.
Funcțiile sistemului
Pentru a putea fi îndeplinite cerințele care se impun aplicației de față, sistemul trebuie să îndeplinească următoarele funcții:
Comunicare permanentă cu o baza de date pentru a permite operații de adăugare, ștergere, modificare
Prelucrarea datelor stocate în baza de date în conformitate cu unele criterii introduse de utizator
Vizualizarea datelor stocate în baza de date în funcție de anumite criterii, și în funcție de tipul de utilizator.
Administrarea și configurarea drepturilor de acces pentru utilizatori
Exportarea datelor în format XML și XLS (fișiere Excel)
Asigurarea confidențialității datelor
Interfața trebuie să fie simplă, prietenoasă iar programul să fie ușor de utilizat și explorat
Atribuirea responsabilităților/drepturilor în funcție de tipul de utilizator
Gestionarea mesajelor
Generarea progamărilor
Interfața cu utilizatorul
Aplicația se adresează la trei tipuri de utilizatori, fiecare utilizator având responsabilități și drepturi bine definite. Toate cele trei module au în comun următoarele secțiuni:
Date autentificare – pentru a permite utilizatorilor autorizați accesul la modulul propriu
Căsuța de căutare – prin intermediul căreia se realizează căutări în cadrul aplicației
Meniul principal – elementele principale de meniu, cu opțiunile care sunt puse la dispoziția utilizatorului
Imaginea care reprezintă logo-ul aplicației
Informațiile despre aplicație și adresele utile
3.3.1 Modulul Utilizator
Modulul principal prin intermediul căruia se realizează trecerea la celelalte module. În cadrul acestui modul se regăsește interfața de logare.
Structura interfaței de logare este:
– un buton ,,Autentificaˮ
– un modal ce apare la apasarea butonului ce necesita date completate
– mesaje de validare
3.3.2. Modulul Administrator
Modulul destinat administratorului, persoanei cu ce se ocupă de gestionarea conturilor din sistem. Se ajunge aici după realizarea cu success a unei autentificări pentru un utilizator de tip administrator. Prin intermediul acestuia se adaugă, modifică și șterg date.
Structura meniului:
– Adăugare utilizator
– Ștergere/ Schimbare stare utilizator
– Resetare parola utilizatori
– Suport utilizatori
Meniurile diferă în funcție de tipul de utilizator.
3.3.4. Modulul Medic
Modulul este atribuit medicilor. Se ajunge aici după realizarea cu success a unei autentificări pentru un utilizator de tip medic. Prin intermediul acestuia se adaugă, modifică și șterg date.
Structura meniului principal:
Adăugare pacienți
Vizualizare pacienți
Vizualizare fișă pacient
Modificare fișă pacient
Programări
Adaugare programare consultație
Modificare programare consultație
Sterge programare consultație
Adăugare consultație
Adăugare trimiteri
Adăugare trimitere laborator
Adăugare trimitere medic specialist
Adăugare rețete
Medicamentație pacient
Adăugare medicamentație
Vizualizare dacă a fost administrată
Modificare medicamentație
Mesaje
Vizualizare mesaje
Adăugare mesaje către alt utilizator
Documentare
Vizualizare articole
Adăugare bookmarks
Stergere bookmarks
Administrare
Modificare date personale
Modificare parolă
3.3.5. Modulul Asistentă
Modulul este atribuit asistentelor. Se ajunge aici după realizarea cu success a unei autentificări pentru un utilizator de tip asistentă. Prin intermediul acestuia se adaugă, modifică și șterg date.
Structura meniului derulant:
Structura meniului principal:
Adăugare pacienți
Vizualizare pacienți
Vizualizare fișă pacient
Modificare fișă pacient
Programări
Adaugare programare consultație
Modificare programare consultație
Sterge programare consultație
Medicamentație pacient
Vizualizare medicamentație
Modificare status medicamentație ( a fost sau nu administrată pacientului)
Mesaje
Vizualizare mesaje
Adăugare mesaje către alt utilizator
Documentare
Vizualizare articole
Adăugare bookmarks
Stergere bookmarks
Administrare
Modificare date personale
Modificare parolă
Structuri de baze de date și fișiere
Aplicația comunică cu o bază de date ce se află în Cloud. Această bază de date conține mai multe tabele în care sunt salvate informațiile puse la dispoziția utilizatorilor. Aceste informații au fost împărțite în mai multe tabele în funcție de categoria din care fac parte. E nevoie de utilizarea unor tabele cât mai bine organizate, care să asigure o navigare mul mai ușoară.
Cele mai importantă tabele, este cele ale utilizatorilor și ale datelor acestora personale , practic cu ajutorul acestora se asigură accesul în aplicație a tuturor tipurilor de utilizatori. Fiecare medic și asistentă au conturi unice, astfel încât e nevoie de o tabelă care să rețină informațiile referitoare la medici și una reeritoare la asistente.
Informațiile de interes general puse la dispoziția utilizatorilor, în special a utilizatorului ocazional nu sunt stocate în tabele, ci în fișiere XML. Acest mod de stocare este utilizat datorită tipurilor de date folosite, de regulă este vorba de articole destul de cuprinzătoare, cu mult text și făcând referire la subiecte variate. Un exemplu în acest sens sunt fișierele în care se stochează legislația curentă care face referire la înființarea centrelor de permanență, sau fișierele în care se salvează anexa 21 (cea care face referire la clasificarea urgențelor medico-chirurgicale).
Medicii au de asemenea posibilitatea de a introduce informații pe care le consideră utile, fiecare articol adăugat de aceștia va fi salvat într-un fișier XML, a cărui nume va fi construit din titlul articolului și din data la care a fost adăugat. Căutarea articolelor se va face prin analizarea numelui sub care este salvat un fișier.
Fiecare fișier trebuie să respecte o anumită structură pentru a putea fi interpretat corect de către aplicație, structura va fi construită intern de către program. Fișierele trebuie să conțină:
Data la care au fost create
Numele utilizatorului care le-a creat
Titlul articolului
Conținutul acestuia (dacă conținutul acestuia trebuie redat sub forma unui tabel se va utiliza o segmentare suplimentară)
Alte observații ale autorului
Pe lângă fișierele utilizate pentru completare interfețelor (fișiere de intrare), aplicația de față trebuie să fie capabilă să genereze la rândul ei fișiere necesare utilizatorilor (fișiere de ieșire). Astfel informațiile afișate într-un anumit stadiu pot fi transformate în format PDF, pe care utilizatorul le poate salva cu ușurință pentru o utilizare ulterioară. De asemenea graficele de gărzi, sau rapoartele generate pot fi salvate în fișiere Excel sau PDF.
Tipărirea la imprimantă
Aplicația generează fișiere PDF pe baza informațiilor solicitate de către utilizator. Prin generearea acestor fișiere tipărirea la imprimantă este mult mai ușor de realizat, informațiile fiind structurate într-o formă inteligibilă. Bineînțeles pentru folosirea acestei facilități, este nevoie de o imprimantă conectată la calculatorul pe care rulează aplicația.
Analiza de risc
Produsul software este stocat pe un server, riscurile care pot apărea sunt cele generate de căderile de tensiune sau cele datorate diverselor defecțiuni fizice care pot interveni. Acestea nu pot fi prevăzute de aplicație, deci nu se poate propune o soluție pentru rezolvarea lor, totuși aceste evenimente nu provoacă stricăciuni mari în cadrul aplicației, pot eventual duce la pierderea datelor cu care utilizatorul lucra și care nu au fost salvate înainte.
De asemenea se mai poate vorbi și de pierderea conexiunii la internet a utilizatorilor care accesează această aplicație, nici în acest caz nu pot fi luate măsuri de protecție. Singurul mod prin care se poate diminua efectul nefavorabil generat în acest caz este salvarea periodică de către utilizator a datelor cu care lucrează.
Planificarea lucrărilor
Primul pas pentru realizarea acestui produs software este scrierea specificațiilor. După ce acestea sunt stabilite se începe proiectarea bazei de date cu tabelele necesare, se proiectează interfețele, se adaugă în tabele informații pentru a putea fi realizată testarea, se scrie cod și apoi se realizează teste pentru a verifica funcționalitatea aplicației.
3.7.1. Model de ciclu de viață
Pentru dezvoltarea produsului software s-a ales “Modelul în V”. Acesta este o variantă a modelului cascadă, care pune ín evidență corelarea dintre activitățile de specificare și cele de testare, înlănțuirea în timp a activităților fiind aceeași.
Partea din stanga reprezintă lanțul de specificare a sistemului iar cea din dreapta lanțul de testare. Partea de jos a V-ului reprezintă implementarea. Ȋn acest model exista doua tipuri de dependențe între etape:
cele reprezentate prin liniile care formează V-ul, care corespund înlănțuirii și eventualei iterații din modelul cascada; etapele se derulează deci secvențial, urmând V-ul de la stânga la dreapta;
cele reprezentate prin linii orizontale, care indică faptul ca o parte din rezultatele etapei din care pleacă sageată sunt utilizate direct în etapa țintă. De exemplu, la terminarea etapei de proiectare arhitecturală, cazurile de teste de integrare trebuie să fie complet descrise.
Figure 3.7.1-1 Modelul în V
Modelul punctează cu mai multă claritate separările dintre ceea ce implică participarea utilizatorului, modelul arhitectural și acela al implementării. Utilizatorul este implicat doar în fazele din partea superioară a V-ului. Arhitectura sistemului este surprinsă în partea de mijloc a literei, iar partea inferioară a ei se referă la faza de implementare, care ar putea consta fie din asamblarea componentelor soft, fie din codificarea unor componente. Modelul se pretează și în mediul orientat obiect, deoarece încurajează prototipizarea, reutilizarea unor structuri superioare. El oferă un control puternic asupra sistemului în curs de realizare, prin structurile ierarhice și modulare pe care le promovează, ceea ce îl face utilizabil și în cazul sistemelor complexe.
Cap. 4 – Proiectarea de detaliu
Arhitectura sistemului
Sistemul informatic pentru departamentul de diabet-zaharat, nutriție și boli metabolice dezvoltat este realizat în Visual Studio.NET 2013, folosind limbajul C# pentru crearea unei aplicații de tip Windows Store App și a unui Web Service de tip asmx. Baza de date pe care o folosește această aplicație se află în cloud-ul Microsoft Azure.
Figure 4.1-1 Arhitectura sistemului
4.1.1. Interfața cu utilizatorul
Pentru realizarea aplicației s-a folosit mediul de dezvoltare Visual Studio 2013, astfel că pentru dezvoltarea intefeței s-a beneficiat de modul grafic de programare oferit de acesta. Limbajul de programare folosit a fost C#.
4.1.2. Programarea vizuală
Primul pas a fost crearea unui nou proiect, care a fost numit în cazul de fața App1 (denumirea nu mai necesită alte comentarii), tipul de proiect ales a fost Store App →Windows App, iar la partea de Template s-a ales Blank App. După ce proiectul a fost creat s-a continuat cu introducerea în cadrul acestuia a unui număr de Basic Page egale cu numărul ferestrelor de care era nevoie. Fiecare xaml a fost populat cu controalele necesare și i-au fost stabilite proprietățile în funcție de cerințe.
Pentru realizarea fiecărei ferestre s-au folosit mai multe controale puse la dispoziție de Toolbox-ul aplicației. Pentru fiecare control s-a profitat de proprietățile lui pentru a fi adapta nevoilor ferestrei pe care era folosit. Lista cu controalele utilizate și contextul lor de folosire este cea de mai jos:
AppBarButton – sunt butoane predevinite ce au fost concepute pentru a fi afisate in AppBar
Button – folosit pentru a deschide noi ferestre sau pentru a realiza o serie de operații puse la dispoziția utilizatorului.
Checkbox – control folosit pentru a permite utilizatorului să aleagă prin bifare una sau mai multe opțiuni dintr-o listă pusă la dispoziția sa
Combobox -control folosit pentru o permite utilizatorului să aleagă o valoare dintr-o listă (diferența față de controlul de mai sus constă în modul de alegere dar și în tipul de valori din care se poate alege)
DataPicker – folosit pentru a alege data pentru care doreste să vizualizeze sau adauge informații
Grid – panouri ce dispun in aranjarea elementelor copil in randuri si coloane
Image – folosit pentru a aadauga anumite iconuri sau imagini semnificative pentru aplicație
ListView – – folosit pentru a afisa liste de date
PasswordBox – este la fel ca si un TextBox, dar specializat pe adăugarea de parola
Popup – folosit pentru a afisa modale pe ecran. Acesta este preferat când pasul nu necesita o cantitate mare de informații și pentru ca utilizatorul să rămână pe pagina curentă
RadioButton – utilizat pentru a obliga utilizatorul să aleagă o singură valoare dintr-o listă dată
ScrollViewer – folosit pentru a apărea bara de scroll in listele de tip ListView sau GridView
StackPanel – folosit pentru afisarea elementelor pe o singura linie atât orizontal, cât și vertical
TextBlock – cel mai utilizat control, folosit pentru a eticheta câmpurile care apar pe ecran.
TextBox – este poate controlul de editare cel mai utilizat în cadrul aplicației, folosit pentru a permite utilizatorului să completeze diferite informații, sau doar pentru a vizualiza informațiile introduse anterior (pentru a permite doar vizualizarea datelor înscrise în ele s-a setat proprietatea ReadOnly ca fiind true).
TimePicker – folosit pentru a adăuga ora în anumite instanțe
Tooltip – folosit pentru adăugarea de mesaje la pozitionarea cursorului pe anumite elemente
WebView – folosit pentru a naviga pe internet
Această parte vizuală nu a fost tot timpul realizată cu drag & drop. Am incercat pe cât posibilul să mă bazez pe scris cod direct in xaml. Am ales această metodă deoarece dacă pozitionam elementele cu drag and drop riscam la tablete de diferite dimensiuni să se strice interfața sau pe desktop să apară bine și pe tabletă nu.
Chiar dacă partea de programare vizulă este ușor de realizat și cu efecte spectaculoase de cele mai multe ori ea nu este suficientă pentru dezvoltarea de aplicații. Pentru ca fiecare control așezat pe interfață să poată fi folosit și să realizeze ceva trebuie scris codul din spatele lui.
Funcțiile dezvoltate până în momentul de față sunt:
Comunicare permanentă cu o baza de date pentru a permite operații de adăugare, ștergere, modificare
Prelucrarea datelor stocate în baza de date în conformitate cu unele criterii introduse de utizator
Vizualizarea datelor stocate în baza de date în funcție de anumite criterii, și în funcție de tipul de utilizator.
Administrarea și configurarea drepturilor de acces pentru utilizatori
Interfața trebuie să fie simplă, prietenoasă iar programul să fie ușor de utilizat și explorat
Atribuirea responsabilităților/drepturilor în funcție de tipul de utilizator
Generarea progamărilor
Restul funcțiilor prezentate în specificații for fi dezvoltate în următoarele versiuni.
Descrierea componentelor
Sistemul informatic medical pentru departamentul de diabet-zaharat, nutriție și boli metabolice pornește cu o pagina simplă, în care, exista un buton de autentificare ce deschide un modal unde utilizatorul poate adăuga datele de autentificare, și anume, numele de utilizator și parola.
Figure 4.2-1 Interfață pornire
Un utilizator se poate autentifica doar dacă are un cont creeat și acesta este activ. În cazul în care utilizatorul nu are cont, sau acesta este dezactivat, un utilizator de tip administrator va putea rezolva problema.
Figure 4.2-2 Interfață autentificare
O data logat va apărea interfața aferentă tipului de utilizator.
Interfețe utilizator de tip administrator
După logare apare interfața principală pentru utilizatorii de tip administrator. Această interfață este formată din patru componente:
Adaugare utilizator nou
Schimba starea unui utilizator ( din activ, în inactiv și invers)
Resetarea parolei unui utilizator
Suport utilizatori
Interfața de adăugare a unui utilizator nou este cea selectată automat. Administratorul nu adaugă datele cu caracter personal și nu are acces la acestea. Datele cu caracter personal sunt gestionate de fiecare utilizator în parte. Pentru utilizatorii de tip administrator am considerat că nu sunt necesare asemenea date.
Figure 4.2.1-1 Interfață adăugare urilizator
Pe adresa de email se va trimite automat contul creeat cu utilizatorul și parola. Aplicația oferă și mesaje de confirmare sau eroare pentru operațiile făcute, spre exemplu în cazul adăugării unui nou utilizator, vom primi trei tipuri de mesaje:
Datele au fost adăugate cu succes și emailul a fost trimis.
Datele au fost adăugate cu succes, dar emailul nu a fost trimis.
Datele nu au fost adăugate.
În cadrul interfeței de schimbare a stării unui utilizator, putem doar activa sau dezactiva un cont. Această interfață este practică deoarece, în cazul în care un medic sau o asistentă pleacă în concediu, nu există riscul ca altcineva să intre în cont.
Figure 4.2.1-2 Interfață activare/dezactivare cont
Figure 4.2.1-3 Interfață activare/dezactivare cont – utilizator selectat
Interfața de resetare parolă este utilizată în cazul în care un utilizator si-a pierdut parola. Administratorul poate adăuga o parolă manual, sau poate genera automat o parolă de șase caractere. Această parolă va fi trimisă pe email utilizatorului. Am ales ca doar administratorul să poată să facă resetare de parolă din motive de securitate, restul utilizatorilor pot doar să își schimbe parola de pe pagina de profil.
Figure 4.2.1-4 Interfață resetare parolă
Ultimul buton ,,Suport utilizatoriˮ este utilizat pentru a merge pe pagina cu mesaje trimise de pe conturi spre administrator. Am considerat că în această aplicație administratorul are și cunoștiințe de baze de date.
Interfețe utilizator de tip doctor
Interfața prncipală atunci când ești logat ca și medic arată ca și în figura de mai jos. Aceasta conține butoanele aferente fiecărui modul. Pentru a interacționa cu aplicația trebuie să selectați pasul următor.
Figure 4.2.2-1 Interfață principală utilizator de tip medic
Medicul specialist nu are tot timpul fișa completă a pacientului. Dacă apare un pacient nou acesta îl adaugă în registru cu date minime. În această aplicație se oferă posibilitatea de a adăuga fișe mai complexe,dar medicul nu este obligat să aibe această fișă completată pentru a consulta un pacient.
Figure 4.2.2-2 Interfață editare fișă pacient
Programările sunt un mod bun de a organiza o zi de lucru. Un pacient nu este obligat să își fi făcut programare ca să poată fi consultat. În modulul de programri întâlnim următoarele funcții:
Adaugă programare
Șterge programare
Vizualizează programare
Figure 4.2.2-3 Interfață vizualizare programare
Modulul de consultații este foarte important deoarece nici o trimitere sau rețetă nu se scrie, în general fără ca pacientul să fie consultat în prealabil.
Acest modul conține câteva date personale ale pacientului și datele referitoare la consultație. Ca și diagnostice am folosit codurile ICD10 de la capitolul ,,Boli endocrine, de nutritie si metabolism (E00-E89)ˮ. Pe viitor pot fi adăugate toate codurile.
Figure 4.2.2-4 Interfață adăugare consultație
Pentru a adăuga o rețetă sau o trimitere trebuie doar să alegem sau să avem ales un pacient și să adăugăm datele corespunzătoare fiecărui modul. După completarea câmpurilor se apasă butonul de salvare și ar trebui să se genereze documentul PDF pentru printat. În prototip această funționalitate nu este implementată, iar la apăsarea butonului de salvare se va afișa un mesaj.
Figure 4.2.2-5 Interfață adăugare trimitere
Figure 4.2.2-6 Interfață adăugare rețetă
Putem vizualiza în aplicație istoricul unui pacient. Acest istoric poate fi pentru consultații, pentru rețete prescrise și pentru trimiteri. Un exemplu de interfață este cel din figura de mai jos. Toate interfețele sunt compartimentate în 2 rânduri. În primul se vor găsi datele personale ale pacientului de bază, iar în al doilea rând lista cu datele în care sa făcut o consultație, sa prescris o rețetă sau sa făcut o trimitere. După ce se selectează o dată, lângă această listă apare documentul dorit.
Figure 4.2.2-7 Interfață istoric consultație
Modulul de documentare a fost gândit pentru a ajuta personalul medical să țină pasul cu ceea ce este nou în domeniu. Acesta este ca un browser doar legat de aplicație. Poți adăuga, modifica sau sterge linkurile salvate.
Figure 4.2.2-8 Interfață documentare
Figure 4.2.2-9 Interfață documentare – sterge link salvat
Există și site-uri salvate ca fiind implicite.
Figure 4.2.2-10 Interfață documentare – vizualizare linkuri salvate
Sistemele prezentate la studiul bibliografic nu conțin un asemenea modul, iar acesta ar fi foarte folositor deoarece știința evoluează. Actualmente complexitatea lui din aplicația S.I.M.T.I. este minimă, iar pe viitor poate fi îmbunătățită în funcție de feedback-ul primit.
Interfețe utilizator de tip asistentă
Interfețele pentru utilizatorii de tip asistente sunt asemănătoare cu cele de la doctor, diferențele fiind în faptul ca acești utilizatori nu au drepturile de editare doar pentru programări, fise pacienti,documentare și medicamentația de pe saloane. Din acest motiv butoanele nerelevante le-am scos și interfața principală va fi ca în figura de mai jos.
Figure 4.2.3-1 Interfață principala utilizator asistentă
În modulul de programări diferența față de utilizatorul de tip medic este faptul că nu se poate decat adăuga, vizualiza și modifica programări, iar butoanele de adăugare consultație,rețetă, trimitere nu se mai afișează.
Am mai considerat că acest tip de utilizator poate adăuga fise de pacient pentru a micsora timpul pe care medicul trebuie să îl piardă cu acest task. Datele fiind personale se pot adăuga în prezența pacientului și doar confirma cu medicul.
Modulul de documentare și mesaje sunt exact ca și pe contul de tip medic.
Structuri de baze de date
Deoarece avem de-a face cu o aplicație care comunică cu o bază de date aflată în Cloud, încă de la prima ferestră care apare, o dată cu lansarea în execuție a aplicație, trebuie definit în primul rând modul în care aplicația se conectează la baza de date. Aplicațiile de tip Store App nu permit conectarea în mod direct la Cloud, ci doar printrun Web Service. După ce Web Service-ul a fost creat, în aplicație doar se face referință la el și la funcțiile acestuia.
Pentru a putea defini conexiunea in Web Service trebuie să includem în proiect o clasă care conține obiecte specifice acestui tip de acțiune, clasa de care avem nevoie este inclusă prin următoarea linie de cod: using System.Data.OleDb; acest cod trebuie scris în fiecare asmx al Web Service-ului care comunică cu baza de date. Ultimul termen din secvența de cod scrisă desemnează tehnologia folosită pentru conectarea la baza de date, aceasta se numește OleDB.
Obiectele care trebuie folosite din acestă clasă se declară o singură dată în cadrul formului unde sunt prima dată referite, în acest caz în cadrul formului care reprezintă interfața de autentificare. Obiectele care sunt necesare pentru realizarea acestei operații sunt cele prezentate în codul din figura 3.1.
Figure 4.3-1 Declararea obiectelor care se folosesc la conectarea la baza de date
Toate sunt declarate având specificatorul de acces public static, s-a ales acestă metodă de declarare pentru a putea folosite aceste obiecte și în celelalte formulare ale aplicației. Semnificația obiectelor declarate mai sus este următoarea:
Obiectul de tip OleDbConnection, permite conectarea la baza de date prin intermediul string-ului de conectare
Obiectul de tip OleDbCommand, permite editarea unei interogări asupra bazei de date, dar și executarea unor comenzi sql NonQuery cum ar fi insert, update, delete, etc:
Un DataSet reprezintă o copie în memorie a datelor extrase dintr-o sursă de date. Un DataSet constă dintr-o colecție de tabele:
OleDbAdapter reprezintă o punte între un DataSet și o sursă de date (cum ar fi o tabelă a unei baze de date) pentru extragerea datelor și salvarea lor.
Un OleDbCommandBuilder generează automat comenzile necesare pentru ca schimbările făcute într-un tabel dintr-un DataSet să se reflecte și în baza de date din care a fost încărcat DataSet-ul.
Obiectul de tip DataReader realizează citirea datelor din baza de date, fiecare înregistrare pe rând, conform comenzii SQL.
Stringul strSQL reprezintă de fapt comanda dată bazei de date.
Conexiunea cu baza de date se deschide în momentul rulării aplicației și se închide o dată cu închiderea acesteia, deci acest cod se scrie o singură dată în cadrul aplicației. Codul care realizează stabilirea conexiunii este cel din figura 3.2.
Figure 4.3-2 Conectarea la baza de date
Stringul din paranteză reprezintă stringul de conectare la baza de date și trebuie să conțină:
Provider – se completează în funcție de tehnologia de comunicare folosită și în funcție de baza de date utilizată.
Password, User Id – se completează cu datele cu ajutorul cărora se realizează procesul de autentificare în SQL Plus
DataSource – se completează cu numele bazei de date folosite
Deoarece obiectele folosite sunt de tipul referință declararea lor nu rezervă automat spațiu în memorie astfel că acest lucru se face în mod explicit prin utilizarea termenului new.
Din motive de securitate am ales ca stringul de conectare să fie adăugat în web.config. Web.config este fișierul în care se găsesc setările principale și configurare pentru o aplicatie web ASP.NET. Fișierul este un document XML care definește informații de configurare privind stochează fișiere pe web application.. Fișierul web.config conține informații care controlează modul de încărcare, de configurare de securitate, configurare stat sesiune, și limba de aplicare și setările compilare.
Acesta se poate considera ca fiind un constructor, care realizează operația de instanțiere a unei noi variabile. După ce conexiunea a fost stabilită cu succes se trece la interogarea bazei de date în vederea realizării operației de autentificare. Interogarea acesteia se realizează utilizând stringul strSQL care reprezintă comanda pe care o dăm bazei de date, în acest caz este vorba de un SELECT. Codul complet pentru interogarea bazei de date pentru a vedea dacă datele introduse de utilizator corespund cu cele din baza de date este cel din figura 3.3.
Figure 4.3-4 Interogarea unei tabele din baza de date
Prima linie de cod din figura 3.3 reprezintă stringul de conectare. Acesta, după cum am precizat și mai sus se găsește în fișierul web.config, iar in aplicație doar este apelat. În această secvență de cod se apelează două tabele medic_tab, ce conține datele personale utilizatorilor de tip medic și users_tab ce conține datele de logare a tuturor utilizatorilor. În aceast query se dorește substragerea datelor personale ale unui medic, dacă medicul are contul creeat deja, iar dacă această tabelă nu conține datele personale va returna fals și va însemna ca în aplicație după logare va trebui să apară interfața pentru adăugarea datelor personale.
Alte interogări din cadrul Web Service-ului returnează ,,trueˮ sau ,,falseˮ. În aceste cazuri în cadrul aplicației se vor afișa mesaje de eroare în interfață cu ajutorul unui Textblock, cum se întâmplă pe interfața de logare sau într-un messageDialog cum se întâmpla in figura 3.4.
Figure 4.3-5 Afișare messageDialog
La prima rularea a aplicației trebuie create tabelele ce urmează a fi folosite, crearea se face după ce conectarea la baza de date a fost realizată.
Fiind vorba de informați care se extrag din mai multe tabele era nevoie de existența unui câmp de legătură pentru a realiza corespondența de exemplu între datele cu caracter personal ale unui medic și datele acestuia de logare. Legătura dintre cele doua tabele se face prin câmpul ce contine id-ul utilizatorului și anume, în cazul de față, user_id și id-ul intrării din tabela cu datele personale (doctor_id). Câmpul de legătură în user_id din tabela users_tab este definit în tabela considerată ca fiind principală și Primary Key și apoi este referit în tabele considerate ca fiind secundare.Legătura dintre înregistrările din tabele se verifică astfel:
users_tab.user_id = doctor_tab.medic_id
Fișele pacienților, trimiterile și rețetele am considerat că ar fi bine sa fie salvate ca și xml-uri, deoarece acestea sunt voluminoase și nu au tot timpul acelasi format, de exemplu o rețetă poate să conțină un singur medicament sau cinci. Am considerat ca ar fi greu de gestionat daca datele ar fi salvate în tabele.
Baza de date ar pentru aceasta aplicație ar trebui sa conțină următoarele tabele:
tabelă date de autentificare
tabelă date personale doctori
tabelă date personale asistente
tabelă date personale pacienti
tabelă date consultatii
tabelă programări
tabelă mesaje
tabelă documentație
tabelă medicamentație pe saloan
Pe lângă aceste tabele în storage vor exista trei containere în care se vor adăuga xmluri cu trimiteri, rețete și fișele pacienților.
Figure 4.3-6 Componență baze de date S.I.M.T.I.
O primă legătură de unde pornește toată structura este cea între tabela cu datele de autentificare și tabela cu datele medicilor, respectiv tabela cu datele asitentelor, iar câmpul de legătură care face acest lucru posibil este câmpul id din tabela autentificare.
În schema următoare este prezentat modul de relaționare a tabelelor. Cu Storage am adăugat doar legătura între tabela date personale pacienți și fișele pacienților deoarece aici se găseste o legătură directă. În tabela exista un câmp în care se completează numele xmlului. Pentru trimiteri și rețete nu am ales această abordare. Pentru a recunoaște care sunt documentele fiecărui pacient am ales să denumesc xml-urile sub forma: cnp-pacient_id.xml, unde id-ul este unic și are valori începând cu 1 și crește.
Figure 4.3-7 Legături baze de date S.I.M.T.I.
În baza de date din Microsoft Azure am stocat și codurile ICD10 pentru boli, deoarece sunt mai ușor de gestionat și actualizat.
Cap. 5 – Concluzii
Ce sa realizat
Lucrarea prezintă cercetarea și realizarea informatizării în departamentul de diabet-zaharat, nutriție și boli metabolice și asigurarea monitorizării pacienților. Prin realizarea acestei aplicații, medicul poate urmării evoluția stării de sănătate și intervenii atunci când este nevoie.. Proiectarea interfețelor utilizator este un subiect care preocupă tot mai mult dezvoltatorii de software. Deoarece aplicația realizată este adresată unui grup țintă, și anume medicilor de diabet-zaharat, nutriție și boli metabolice, cu o anumită pregătire profesională și culturală nevoia de interfață potrivită și centrată pe utilizator (sau client) este stringentă. O interfață potrivită face ca aplicația să fie ușor de utilizat și învățarea funcțiilor. Interfaț trebuie să fie responsive, să arate la fel de bine pe tabletă, cât și pe desktop.
Pe lângă partea teoretică și interfețele aferente am realizat un prototip pentru aplicația S.I.M.T.I. Deoarece este un prototip, acesta nu conține toate funcțiile prezentate în specificații, dar am înglobat toate interfețele aferente funcțiilor.
Comparație cu alte sisteme
Sistemele informatice prezentate în capitolul 1 nu sunt specifice departamentului de diabet-zaharat, nutriție și boli metabolice, ci sisteme complexe dexvoltate pentru consultații și monitorizare, având posibilitatea de a comunica cu alte sisteme. Sistemul informatic dezoltat poate este specializat pe un singur departament.
Direcții de dezvoltare
plicația realizată un prototip se mai poate dezvolta în primul rând cu funcțiile neimplementate, iar în al doilea rând, pe viitor, ar putea comunica cu alte sisteme cum ar fi un site pentru pacienti, în care fiecare pacient să poată să își vizualizeze fișa personală, să își monitorizeze glicemia sau diabetul.
Bibliografie
[1] Window 8 Design and coding guidelines go.microsoft.com/fwlink/p/?linkid=258743
[2] Windows 8.1 Design templates https://dev.windows.com/en-us/design/assets
[3] Run Windows Store apps on a remote machine from Visual Studio https://msdn.microsoft.com/en-us/library/windows/apps/hh441469.aspx#BKMK_DirectConnect
[4] Microsoft Academy – cursuri C#/XAML http://www.microsoftvirtualacademy.com/training-topics/c-app-development
[5] Windows Dev Center https://dev.windows.com/en-us/windows-apps
[6] Microsoft Azure http://azure.microsoft.com/en-us/
[7] Fundamentals Introduction to Azure, http://azure.microsoft.com/enus/documentation/articles/fundamentals-introduction-to-azure/
[8] Channel 9 – Tutoriale Microsoft Azure http://channel9.msdn.com/Series/Windows-Azure-Cloud-Services-Tutorials/
[9] Coduri Loinc http://loinc.org/
[10] ICD10 http://www.cdc.gov/nchs/icd/icd10cm.htm
[11] SCURT GHID DE UTILIZARE DES DIN SIUI-MF http://siui.casan.ro/cnas/siui_4.0/siui-mf/manuals/Ghid-DES.pdf
[12] Dosar electronic de sănătate http://www.des-cnas.ro/pub/
[13] Portal CNAS-SIUI http://siui.casan.ro/cnas/
[14] Manual de utilizare SIUI http://siui.casan.ro/cnas/files/tutorial_99/Manual%20de%20utilizare.pdf
[15] Prezentare Hipocrate Medical http://www.hosptm.ro/files/Hipocrate%20Prezentare.pps
[16] Icon-uri aplicație https://icons8.com
[17] Icon-uri aplicație https://www.iconfinder.com
Anexa 1: Lucrare știiințifică
Anexa 2. Model de declarație de originalitate
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Aplicatie Software Pentru Departamentul de Diabet Zaharat, Nutritie Si Boli Metabolice (ID: 109946)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.
