Documentul de Proiectare a Solu iei Aplica iei Software

(Software Design Document)

Version 1.0 29 September, 2009

Platform de gestiune a datelor medicale electronice

Echipa de Cercetare n Ingineria Programrii, Facultatea de Automatic i Calculatoare, Universitatea Politehnica, Bucureti

Cuprins
Cuprins..................................................................................................................................................... 2 1. Scopul documentului ....................................................................................................................... 3 2. Con inutul documentului ................................................................................................................. 3 3. Modelul datelor................................................................................................................................ 3 3.1. Structuri de date globale .......................................................................................................... 3 3.2. Structuri de date de legtur .................................................................................................... 3 3.3. Structuri de date temporare ...................................................................................................... 4 3.4. Formatul fiierelor utilizate...................................................................................................... 4 3.5. Descrierea bazei de date........................................................................................................... 4 3.5.1. Diagrama schemei bazei de date...................................................................................... 4 3.5.2. Descrierea tabelelor ......................................................................................................... 5 4. Modelul arhitectural i modelul componentelor .............................................................................. 7 4.1. Arhitectura sistemului.............................................................................................................. 7 abloane arhitecturale folosite......................................................................................... 7 4.1.1. 4.1.2. Diagrama de arhitectur................................................................................................... 7 4.2. Descrierea componentelor ....................................................................................................... 8 4.3. Restric iile de implementare .................................................................................................... 9 4.4. Interac iunea dintre componente.............................................................................................. 9 5. Modelul interfe ei cu utilizatorul ....................................................................................................11 5.1. Succesiunea interfe elor ..........................................................................................................11 5.2. Ferestrele aplica iei ................................................................................................................ 12 5.2.1. Fereastra Intro ................................................................................................................ 12 5.2.2. Fereastra CDAHeader.................................................................................................... 13 5.2.3. Fereastra CDAHeaderParticipants ................................................................................. 14 5.2.4. Fereastra CDAContact ................................................................................................... 15 5.2.5. Ferestra CDABody......................................................................................................... 16 6. Elemente de testare ........................................................................................................................ 18 6.1. Componente critice ................................................................................................................ 18 6.2. Alternative.............................................................................................................................. 18

1. Scopul documentului
Acest document are rolul de a descrie acurat i complet solu ia proiectat pentru sistemul software Platform de gestiune a datelor medicale n format electronic. Documentul servete drept ghid unic de construire a solu iei pentru echipa de dezvoltare a proiectului.

2. Con inutul documentului

Documentul este format din patru sec iuni esen iale: Modelul datelor prezint principalele structuri de date folosite, precum i schema bazei de date Modelul arhitectural i modelul componentelor prezint abloanele arhitecturale folosite, arhitectura sistemului i descrie componentele arhitecturii Modelul interfe ei cu utilizatorul prezint interfa a cu utilizatorul i succesiunea ferestrelor acesteia Elemente de testare prezint componentele critice i alternative de proiectare a acestora.

3. Modelul datelor
3.1. Structuri de date globale
Structura de date global folosit este o instan a clasei Main (clasa core a aplica iei), ce are identificatorul logic. Cu ajutorul acestei structuri de date globale cu rol de intermediar, clasele diferitelor module i pot accesa reciproc structurile de date interne.

3.2. Structuri de date de legtur

Pentru componenta client a aplica iei, modulul GUI comunic cu modulul Baze de date prin intermediul argumentelor de genul identificatori de cadre medicale, de pacien i, de institu ii medicale, etc. Astfel, modulul GUI comand ac iuni de tipul CRUD modulului de Baze de date trimi ndu-i valori ale cheilor primare din schema bazei (identificatorii de cadre medicale, pacien i, institu ii medicale, etc.). Modulul GUI comunic cu modulul de Procesare XML transmi ndu-i numele documentului medical (fiierul XML) de procesat. Modulul GUI comunic cu modulul Re ea transmi ndu-i ca argumente informa iile necesare (precum identificatorii cadrelor medicale, ale pacien ilor, ale institu iilor medicale, ale medicamentelor; scheme de tratament) aflate n cmpurile ferestrelor aplica iei. Pentru componenta server, modulul Re ea i transmite modulului de Raportare informa iile medicale primite. Modulul de Raportare i comand modulului de Baze de date opera ii de interogare transmi ndu-i ca argumente criteriile raportului de generat (precum oraul de monitorizat n privin a evolu iei obezit ii n rndul popula iei, pacientul al crui istoric medical se dorete, etc.). Modulul de 3

Re ea i transmite modulului de Procesare XML informa ii medicale n vederea validrii acestora. Modulul de Procesare XML i transmite modulului de Baze de date informa iile medicale de adugat / editat n tabelele bazei de date.

3.3. Structuri de date temporare

Nu se utilizeaz structuri de date temporare cu rol important sau presupunnd un consum semnificativ de resurse de memorie.

3.4. Formatul fiierelor utilizate

Aplica ia folosete fiiere XML ca mod de intrare a datelor medicale n sistem. Aceste fiiere XML, n plus, respect regulile de validare din fiierul schem XSD medical_standards_schema.xsd (aflat pe site-ul Ministerului Snt ii vezi aici).

3.5. Descrierea bazei de date

3.5.1. Diagrama schemei bazei de date Modelul bazei de date este format din urmtoarele tabele inter-rela ionate ca n figura de mai jos:

3.5.2. Descrierea tabelelor Schema bazei de date cuprinde urmtoarele tabele: Countries re ine rile din adresele persoanelor / institu iilor men ionate n documentele medicale. Are urmtoarele coloane: o id identificatorul numeric al rii o name numele rii. Cities re ine oraele din adresele persoanelor / institu iilor men ionate n documentele medicale. Are urmtoarele coloane: o id identificatorul numeric al oraului o name numele oraului o country referin ctre identificatorul rii din care face parte acest ora (din tabela Countries). Entities re ine institu iile medicale / aplica iile software implicate n documentele medicale. Are urmtoarele coloane: o id identificatorul unic al entit ii o name numele entit ii o streetAddressLine adresa strzii entit ii o city referin ctre identificatorul oraului entit ii o postalCode codul potal al entit ii o telecom numrul de telefon al entit ii o type tipul entit ii, anume: 0 nseamn Institu ie medical i 1 Aplica ie software. Pacients re ine pacien ii men iona i n documentele medicale. Are urmtoarele coloane: o id identificatorul unic al pacientului o name numele pacientului o streetAddressLine adresa strzii pacientului o city referin ctre identificatorul oraului pacientului (tabela Cities) o postalCode codul potal al pacientului o telecom numrul de telefon al pacientului o admGenderCode sexul pacientului o birthTime data de natere a pacientului. Physicians re ine doctorii men iona i n documentele medicale. Are urmtoarele coloane: o id identificatorul unic al cadrului medical o name numele cadrului medical o streetAddressLine adresa strzii cadrului medical o city referin ctre identificatorul oraului cadrului medical (tabela Cities) o postalCode codul potal al cadrului medical o telecom numrul de telefon al cadrului medical o code referin ctre identificatorul codului profesional al cadrului medical (tabela Codes) o representedOrganization referin ctre identificatorul organiza iei n care cadrul medical i desfoar activitatea (tabela Entities). 5

Codes re ine codurile specifice aplica iilor medicale. Are urmtoarele coloane: o id identificatorul unic al codului o code numrul codului o codeSystem identificatorul sistemului de coduri din care face parte acest cod o codeSystemName numele sistemului de coduri din care face parte acest cod o displayName numele codului. Languages re ine limbile n care sunt redactate documentele medicale. Are urmtoarele coloane: o id identificatorul limbii o languageCode codul ataat limbii. ClinicalDocuments re ine informa iile din documentele medicale. Are urmtoarele coloane: o id identificatorul documentului medical o code referin ctre codul tipului documentului medical (din tabela Codes) o title titlul documentului medical o effectiveTime amprenta de timp la care a fost redactat documentul medical o languageCode referin ctre identificatorul limbii n care a fost redactat documentul medical (tabela Codes) o setId identificatorul setului din care face parte documentul medical o versionNumber numrul versiunii documentului medical o inFulfillmentOf identificatorul ordinului de plat aferent procedurii medicale descrise de documentul medical o pacient referin ctre pacientul acestui document medical (tabela Pacients) o custodian referin ctre custodele documentului medical (tabela Entities) o legalAuthenticator referin ctre medicul care a semnat documentul medical (tabela Physicians) o performerId referin ctre medicul care a realizat acest procedeu medical (tabela Physicians) o responsiblePhysician referin ctre doctorul care a creat contextul acestui procedeu medical; de exemplu, doctorul care a prescris spitalizarea, investiga ia medical (tabela Physicians) DocumentRelations re ine rela iile dintre documentele medicale. Are urmtoarele coloane: o CDADocId referin ctre identificatorul documentului medical copil (tabela ClinicalDocuments) o parentDocId referin ctre identificatorul documentului medical printe (tabela ClinicalDocuments) o relation rela ia dintre documentele medicale copil i printe; poate lua valorile: 1 Replace, 2 Append, 3 Transform.

4. Modelul arhitectural i modelul componentelor

4.1. Arhitectura sistemului
4.1.1. abloane arhitecturale folosite Solu ia software actual a fost proiectat dup modelul de arhitectur client-server. n acelai timp, interfa a cu utilizatorul se bazeaz pe ablonul event-driven architecture. Componenta server ofer servicii de exploatare a con inutului documentelor medicale n raport cu standardele medicale, fiind deci o platform de procesare. n plus, componenta server nglobeaz i serverul de baze de date (database tier), asigurnd astfel o platform de stocare. Componenta server comunic pe re ea (prin intermediul socke ilor) cu aplica iile client. Astfel, clientul i transmite serverului documentele medicale, iar serverul, n urma procesrii acestora, va transmite feedback-ul su. Aplica ia client ofer utilizatorului posibilitatea de a vizualiza con inutul documentelor medicale, de a crea documente medicale noi, de a edita documente medicale existente i de a solicita procesarea i stocarea informa iilor medicale, precum i generarea de rapoarte pe baza informa iilor medicale stocate de server. 4.1.2. Diagrama de arhitectur Diagrama de arhitectur de mai jos descrie componentele arhitecturii aplica iei i rela iile de interac iune dintre acestea.

4.2. Descrierea componentelor

Aplica ia const din urmtoarele module interconectate: o Modulul GUI (Graphical User Interface) Este responsabil cu desenarea i randarea optim a interfe elor grafice ale aplica iei. 8

o Modulul de Logic (Logica de business din standardele medicale) Este responsabil de coordonarea celorlalte module astfel nct rezultatele rulrii lor s reflecte logica de business din standardele medicale. o Modulul de Baze de date Este responsabil de interac iunile cu serverul de baze de date, de realizare a conectrii, a opera iilor de tip CRUD (Create, Update, Delete) i de rulare a procedurilor stocate. o Modulul de Procesare XML Este responsabil de opera iile ce vizeaz direct fiierele XML, precum opera ii de validare, parsare, creare i editare de fiiere XML. o Modulul de Re ea Este responsabil de asigurarea dialogului dintre client i server n special, de transmiterea informa iilor medicale ntre client i server. o Modulul de Raportare Este responsabil cu exploatarea informa iilor medicale stocate n baza de date n vederea generrii de statistici, analize i predic ii medicale.

4.3. Restric iile de implementare

Modulele aplica iei trebuie s acopere urmtoarele restric ii de implementare: Modulul de Baze de date va fi dezvoltat pentru serverul de baze de date Oracle Database 9i Modulul de Procesare XML va fi dezvoltat spre a suporta urmtoarele tehnologii XML: XSL i XSD Modulul de Raportare va fi dezvoltat pentru a genera fiiere PDF n urma interogrii bazei de date Toate modulele aplica iei vor fi dezvoltate utiliznd limbajul de programare Java Standard Edition Versiunea 6.

4.4. Interac iunea dintre componente

Pentru componenta Client, atunci cnd utilizatorul porne te aplica ia, se va lansa n execu ie clasa Main din modulul de Logic. Aceasta va interac iona cu modulul de Baze de date pentru a ob ine datele necesare ini ializrii interfe ei grafice. Ulterior, va lansa fereastra de start a aplica iei Intro din cadrul modulului GUI. Pa ii urmtori depind de comanda aleas de utilizator din fereastra Intro, declan nd lansarea n execu ie, fie a modulului de Procesare XML, fie a modulului de Re ea, fie a modulului de Raportare. La sfr itul procesrilor cerute de utilizator, controlul se va ntoarce ctre modulul GUI si, ulterior, ctre modulul de Logica. Pentru componenta Server, modulul de Re ea este cel responsabil de recep ionarea informa iilor medicale transmise de componentele client prin re ea. Apoi, n func ie de tipul mesajului recep ionat, se va lansa n execu ie, fie modulul de Procesare XML (care va lucra sub coordonarea 9

direct a modulului de Logica), fie modulul de Raportare. La sfr itul procesrilor, se va pasa comanda modulului de Baze de date spre a realiza, fie interogarea bazei, fie stocarea datelor procesate n baz. La final, controlul se va ntoarce ctre modulul de Re ea, care va transmite feedback aplica iei Client.

10

5. Modelul interfe ei cu utilizatorul

5.1. Succesiunea interfe elor
n cadrul modulului GUI, ferestrele aplica iei sunt afi ate respectnd un flux stabilit n conformitate cu standardele medicale. Acest flux este descris grafic n figura de mai jos:

Astfel, pentru opera iile de creare / editare documente medicale, din fereastra Intro se poate trece n fereastra CDAHeader cu ajutorul butonului Next i, n continuare, se poate trece prin fereastra CDAHeaderParticipant i, n final, prin CDABody. De asemenea, cu ajutorul butonului Back, utilizatorul se poate ntoarce la fereastra precedent conform fluxului ilustrat mai sus. Butoanele Cancel l intorc pe utilizatorul la fereastra Intro, anulnd orice date introduse anterior. Din Intro, utilizatorul poate deschide un document medical n browser cu ajutorul butonului View n browser. Din ferestrele de creare / editare de documente medicale (CDAHeader, CDAHeaderParticipants i CDABody) se poate lansa fereastra CDAContact. 11

5.2. Ferestrele aplica iei

5.2.1. Fereastra Intro Fereastra principal a aplica iei corespunde clasei Intro.java i arat astfel:

Aceast fereastr este panoul de comand al utilizatorului n sensul c, de aici, utilizatorul alege ce ac iune dore te, determinnd n felul acesta executarea unui flux specific. n chenarul din stnga sunt cuprinse butoanele legate de editarea i vizualizarea documentelor medicale, adic butoanele Creare document medicale (New), Deschidere document medical (Open) i Vizualizare n browser (View in browser). n chenarul central sunt cuprinse butoanele destinate validrii documentelor medicale (butonul Valideaz - Validate) i persisten ei (butonul Stocheaz Date Store Data) datelor extrase din documentele medicale pe serverul de baze de date. n chenarul din dreapta se afl butonul de generare a rapoartelor Generate Reports.

12

5.2.2. Fereastra CDAHeader Aceasta este fereastra aplica iei care corespunde completrii / editrii datelor din antetul documentului medical i arat ca n figura de mai jos.

Fereastra Antet con ine: chenarul din dreapta sus (Sistemul Medical de Versionare Medical Versioning System) cu informa iile de identificare a documentului CDA, adic: Document ID, Version i Date. Chenarul din stnga sus General Information cuprinde cmpuri cu informa ii generale despre documentul clinic, precum: Title, In fulfillment of, Custodian, Language. Chenarul din stnga jos Clinical Procedure Information cuprinde cmpuri cu informa ii despre serviciul medical oferit pacientului, precum: ID, Performer ID, Performer Name. Chenarul din dreapta sus Related Documents reprezint interfa a de editare a rela iilor documentului medical curent cu alte documente (numite documente printe) i cuprinde: Parent Document ID, Relationship. Chenarul din dreapta jos Encounter Information cuprinde cmpuri cu informa ii despre circumstan ele efecturii acestui procedeu medical, precum: ID, Responsible Physician.ID, Responsible Physician.Name, Responsible Physician.Type. La crearea unui document nou, se vor completa automat: toate cmpurile din chenarul Medical Versioning System cu valori sugerate de aplica ie n urma consultrii bazei de date. 13

Lista de selec ie pentru custode Custodian cu organiza iile autorizate n acest sens din baza de date Lista de selec ie pentru limba documentului Language cu valorile din nomenclatorul de limbi din baza de date Lista de selec ie pentru Performer ID cu identificatorii cadrelor medicale nregistrate n baza de date Lista de selec ie pentru Responsible Physician ID cu identificatorii cadrelor medicale nregistrate n baza de date.

n plus, cmpurile restric ionate de standard sunt prevzute cu validatori (verificarea se face cu ajutorul expresiilor regulate pe baza recomandrilor standardelor medicale). Pentru a putea trece la fereastra urmtoare (CDAHeaderParticipants), utilizatorul este obligat s completeze cmpurile marcate cu asterisc (mandatory fields), adic: Document ID, Version, Title, Custodian, Performer ID i ID-ul procedurii medicale (din chenarul Clinical Procedure Information). 5.2.3. Fereastra CDAHeaderParticipants Aceast fereastr corespunde completrii / editrii informa iilor despre participan ii la procedeul medical, men iona i n antetul documentului medical. Fereastra con ine trei taburi, specializate pe anumite tipuri de participan i. Primul tab, tab-ul despre pacient i destinatarii acestui document medical Pacient & Document Recipients arat ca n figura de mai jos. Acest tab nglobeaz informa iile a doua tipuri de participan i specificate n standardele medicale: Pacient i Destinatar Document Medical Information Recipient. Chenarul de sus, Pacient, cuprinde datele specifice pacientului, precum: ID, Name , Gender, Date of Birth. Chenarul de jos, Information Recipients, cuprinde datele specifice destinatarilor documentului medical. Deoarece standardul prevede faptul ca pot exista mai mul i destinatari, am organizat informa iilor lor sub forma tabelara, n raport cu urmtoarele coloane: ID, Name, Type.

14

5.2.4. Fereastra CDAContact Aceast fereastr corespunde completrii / editrii datelor de contact (adresa i telefon) ale participan ilor din antetul documentului medical. Completarea / editarea acestor informa ii este op ional. Se pot completa / edita urmtoarele informa ii de contact : ara Country, ora ul City, adresa strzii Address, codul potal Postal code, telefonul. 15

5.2.5. Ferestra CDABody Aceast fereastr corespunde completrii / editrii informa iilor din sec iunile corpului documentului medical. Fereastra con ine zece taburi, specializate pe sec iuni. Tab-ul Vital Signs con ine cmpuri specializate pentru introducerea valorilor indicatorilor de sntate ai pacientului, clasifica i n doua chenare (Body Measurements i Health Indicators) precum: o height (nl ime n cm) o weight (greutatea n kg) o BMI (Body Mass Index, adic Indicele Masei Corporale n kg/m2) o BSA (Body Surface Area, adic Suprafa a Corporala n m2) o Temperature (temperatura n oC) o Pulse (pulsul n bti / minut) o Rhythm (ritmul text con innd constatarea medical) o Respirations (respira ii n respira ii / minut) o Systolic (sistolic n mmHg) o Diastolic (diastolic n mmHg).

16

n plus, acest tab ofera posibilitatea de a fi nregistra i n documentul medical i al i indicatori de sntate specializa i prin introducerea manual a numelui, valorii i unit ii de msur a indicatorilor (chenarul Add Other Health Indicators). Valorile indicatorilor generali aminti i mai sus se vor completa automat dac pacientul respectiv de ine informa ii de acest tip (documente medicale mai vechi) stocate n baza de date.

17

6. Elemente de testare
6.1. Componente critice
Performan a modulului de Procesare XML are o influen decisiv asupra performan ei globale a aplica iei, alturi de performan a modulului de Re ea. Altfel spus, viteza de procesare a documentelor medicale i de transmitere a informa iilor necesare din documentele medicale prin re ea ctre componenta server sunt principalele piste de influen are a performan ei globale a solu iei software.

6.2. Alternative
n vederea creterii vitezei de procesare a documentelor medicale, se poate folosi / integra n aplica ie un parser de documente medicale specializat, dezvoltat de un furnizor third-party. n vederea scderii timpilor de re ea, se pot utiliza algoritmi eficien i de comprimare a informa iilor medicale transmise pe re ea.

18