Interfatare pe Dispozitive Mobile Pentru Medici In Cadrul Interactiunii cu Pacientii In Spital

1. Introducere

1.1 Motivația

În ultimii ani, dezvoltarea rapidă atât a dispozitivelor mobile, cât și a aplicațiilor ce pot fi create pentru acestea au dus la necesitatea integrării acestor dispozitive la un nivel mai înalt de cel al consumului personal. La momentul actual, există suficiente domenii unde acestea au fost integrate cu succes (telefonie mobilă, vânzări, transporturi,etc), însă aceste domenii nu sunt suficiente și de aceea există în continuare o nevoie de a adapta și a crea aplicații și în alte domenii de interes (cum ar fi instituțiile publice, medicină, învățământ, etc) pentru a oferi mai multă flexibilitate în realizarea sarcinilor zilnice.

Cea mai mare problemă cu aceste aplicații ar fi faptul că în fiecare domeniu există nevoi și cerințe specifice și de aceea nu putem crea aplicații mult prea generale. De asemenea, trebuie să luăm în calcul și caracteristicile resurselor de care dispunem (telefon, tabletă), ce sunt diferite de cele alea unui PC, mai ales în ceea ce privește dimensiunea ecranului și lipsa butoanelor fizice, ce este compensată de cele mai multe ori de un ecran tactil. În plus, chiar în cadrul aceluiași domeniu pot există diagrame diferite ale activităților, rezultând de aici nevoia de a particulariza aceste aplicații pentru un subdomeniu anume.

Dintre cele menționate mai sus, medicina ar fi domeniul care ar avea destul de multă nevoie de integrarea activităților în aplicații mobile întrucât acesta este un domeniu foarte dinamic, în care medicii sunt în continuă mișcare și nu dependenți de un birou așa cum se întâmplă în alte domenii, având în același timp nevoie de informații clare și precise în momentele cheie.

Potrivit unui studiu, realizat în 2013 de Black Book Rantings în S.U.A, 89% dintre medici folosesc un smartphone pentru a comunica cu ceilalți membri ai personalului medical și pentru a căuta mai repede informații de specialitate, prescripții de medicamente. De asemenea, 51% dintre aceștia dețin o tabletă (cu sistem de operare Android sau iPad) pe care o folosesc tot în scopul informării și comunicării. Conform aceluiași studiu, 83% dintre cei care au participat la sondaj au spus că ar folosi dispozitivele mobile, pe care aceștia le dețin pentru a accesa sistemul medical informatic, existent doar pe PC-uri în acest moment. Majoritatea au declarat că își doresc ca aplicațiile existente în lumea medicală pentru desktop să fie simplificate sau adaptate pentru ecranele mai mici ale tabletelor și smartphone-urilor, ce sunt prevăzute cu ecrane tactile, pentru ca aplicațiile să fie ușor accesibile atunci când medicii sunt în mișcare prin spital ("The Year of the Big EHR Switch", 2013).

În țara noastră, în ceea ce privește utilizarea dispozitivelor mobile în lumea medicală, majoritatea clinicilor private au integrat în sistemul lor asemenea aplicații menite să îi ajute atât pe medici, cât și pe pacienți să afle informații utile, cum ar fi rezultatele unor analize sau programul consultațiilor dintr-o zi, într-un timp mai scurt. Din păcate, sistemul sanitar de stat nu beneficiază de pe urma unor asemenea aplicații, ce ar fi extrem de utile, mai ales că în acest caz medicii au în grija foarte mulți pacienți și pentru ei fiecare moment de timp contează. De asemenea, în sistemul de stat trebuie completate destul de multe fișe și documente oficiale, ce sunt transmise mai departe în sistem, ceea ce poate duce la reducerea timpului acordat îngrijirii pacienților.

În cazul de față o aplicație mobilă ar putea veni în ajutorul medicului și a celorlalți membri ai personalului medical, întrucât multe dintre informațiile ce sunt completate în documentele oficiale pot deveni redundante sau de interes mic pentru medicii din anumite specialități, ce au nevoie de informații personalizate pentru domeniul lor de interes. De exemplu, un medic din specialitatea chirurgie cardio-vasculară va avea nevoie de mai multe informații în ceea ce privește sistemul cardio-vascular al pacientului, dar fișele oficiale nu vor avea nevoie de aceste detalii. Astfel, ar fi bine să fie găsită o soluție care să vină în ajutorul personalului medical și care să se adapteze la nevoile acestora,

ținând cont de timpul limitat pentru fiecare pacient de care dispun și de faptul că aceștia sunt în continuă mișcare și nu pot sta mereu la un birou în fața unui calculator.

Atunci când vrem să realizăm o aplicație mobilă pentru domeniul medical primul lucru ce trebuie luat în considerare este faptul că fiecare specializare în parte are specificațiile ei și poate nu este recomandat să realizăm o interfațare generală pentru sistemul medical, ci orientată pe anumite arii și specialități, pentru ca medicii respectivi să poată beneficia din plin de avantajele dispozitivelor mobile. Mai ales, dacă aplicația este folosită într-un sistem de stat, putem lua în calcul faptul că medicii vor completa și anumite documente oficiale, pe lângă datele medicale ale fiecărui pacient. De cele mai multe ori, documente oficiale conțin informații standard pentru fiecare rubrica în parte, indiferent de specializarea pentru care sunt completate, medicii având nevoie să completeze alte fișe ce conțin informații suplimentare, dar relevante pentru activitățile desfășurate în cadrul unei specializări(cardio-vascular, neuro-chirurgie, oncologie, chirurgie generală,etc).

1.2 Introducere în aplicație

Pentru a ușura munca unui medic și a salva timp prețios pentru fiecare pacient ce va fi tratat în cadrul unei secții, o aplicație mobilă ar fi extrem de utilă din mai multe puncte de vedere. În primul rând medicul are acces rapid la toate informațiile referitoare la un pacient, chiar și atunci când nu se află în cabinetul lui, putând accesa rapid informațiile de pe un dispozitiv mobil chiar și atunci când este vorba de o urgență. În al doilea rând, cu ajutorul unei aplicații datele pot fi centralizate într-un singur dispozitiv, ele putând fi ușor prelucrate mai târziu pentru a obține informațiile necesare pentru diagnosticarea și tratarea unui pacient, dar și pentru a genera fișele necesare cerute de alte instituții ale statului.

Astfel, scopul acestei lucrări este acela de a realiza o aplicație mobilă cu o interfață care să ofere un grad de satistfacție în utilizare cât mai mare pentru medicul ce o va folosi în activitățile zilnice. În particular, voi realiza o aplicație pentru o anumite specialitate, și anume, cea de chirurgie cardio-vasculară, care potrivit unui studiu realizat de Community Tracking Survey în S.U.A., se află pe locul întâi la numărul de ore lucrate (Leigh, Tancredi, Jerant, & Kravitz, 2011). Întrucât timpul este în acest caz un factor destul de important, o aplicație ce ajută la completarea datelor referitoare la un pacient și în același timp la consultarea lor rapidă ar fi utilă pentru un medic specialist în chirurgie cardio-vasculară.

O aplicație importantă ce se poate realiza este cea care ar înlocui foaia de observație clinică generală, ce conține informații destul de importante pentru un medic, cum ar fi afecțiunile de care a suferit un bolnav în trecut, antecedentele din familie, parametrii măsurați la internare sau la consultare și cel mai important pentru această specialitatea caracteristici și parametrii pentru aparatul cardio-vascular. În momentul de față, aceste informații sunt completate fizic, pe anumite formulare tipizate, care în cele mai multe cazuri sunt schimbate destul de des și necesită un timp mai mare pentru completarea sau chiar regăsirea informațiilor.

Pentru a rezolva aceste probleme și pentru a eficientiza procesele ce au loc într-un spital de stat, va fi creată o aplicație care să ofere medicului aceste informații necesare pe un dispozitiv mobil, pe care evident îl poate folosi atunci când este în afara cabinetului său. Pentru a asigura faptul că aplicația va răspunde nevoilor unui medic și îi va asigura un comfort mai mare în desfășurarea activității trebuie să ținem cont de anumite aspecte ce implică dezvoltarea unei astfel de interfețe. În primul rând, trebuie să observâm cu atenție procesele ce au loc într-un spital și felul cum acestea interacționează între ele, cum ar fi cine completează anumite câmpuri din acea fișă de observație și la ce momente de timp. De asemenea, ar fi bine să ținem cont de principiile dezvoltării unei aplicații pe o tabletă sau alt dispozitiv mobil ce va fi utilizat pentru a lua deciziile de design corecte și pentru a asigura ergonomia aplicației dezvoltate. În ultimul rând, trebuie să ținem cont și de constrângerile și activitățile importante specialității pentru care vom dezvolta interfața întrucât medicina este domeniul unde un grad de generalitate prea mare nu va răspunde nevoilor utilizatorilor.

Când facem referire la procesele dintr-un spital, fie că este din România sau dintr-o altă țară, trebuie să ne gândim în primul rând la rolurile personalului medical din acea unitate, de exemplu în ce procese va fi implicat medicul sau ce sarcini va executa asistenta acelui medic. De asemenea, trebuie să ținem cont și de modul în care are loc schimbul de informații între aceștia, astfel putem să luăm în considerare realizare unei comunicări asincrone, dar fără să neglijăm partea de colaborare și schimbul de informații între diferitele specializări.

După ce au fost cunoscute procesele și modul de interacțiune între diversele entități, o parte importantă este aceea de a asigura în primul rând ergonomia interfeței create prin respectarea unor anumite principii, cum ar fi coerența în prezentarea datelor, conciziunea (aici putem alege abrevieri cunoscute în lumea medicală pentru ușurința interpretării), flexibilitatea (de exemplu, putem alege să validăm datele introduse, însă nu vom împiedica completarea întregului formular din cauza unei validări nereușite) și oferirea unei ghidări a utilizatorului prin asigurarea feedback-ului în urma acțiunilor importante sau prin structurarea activităților astfel încât să fie asigurată starea de flux, de control asupra interfeței. Astfel, pentru a implementa principiile descrise mai sus, trebuie să ținem cont de caracteristicile dispozitivului pe care vom rula aplicația, cum ar fi dimensiunea ecranului sau ecranul tactil, fără butoane fizice. De asemenea, aplicația trebuie să respecte principiul coerenței și de aceea trebuie să fie integrată cu ușurință pe platforma pe care este dezvoltată astfel încât să fie coerentă cu celelalte aplicații existente pe acea platformă.

1.3 Testarea aplicației

Pe lângă modul de dezvoltare al aplicației, se pune problema realizării evaluării în acest caz, întrucât trebuie luate în considerare mai multe metrici pentru testare. Astfel, putem să evaluăm în mai multe moduri o aplicație pentru un dispozitiv mobil, în particular pentru un sistem electronic medical, cum ar fi o evaluare calitativă și o evaluare cantitativă. De asemenea, putem lua în calcul diverse metrici pentru a evalua gradul de utilizare și ergonomie a aplicației măsurând eficacitatea, eficiența și satisfacția utilizatorului atunci când realizeaza diverse sarcini în aplicație.

Pentru aplicația ce va fi dezvoltată, o evaluare calitativă ar putea fi realizată pe parcursul dezvoltării aplicației, testând doar anumite activități din structură într-un mod mai rapid, putând astfel fi corectate erori ce apar în această etapă de dezvoltare. De asemenea, se poate realiza o evaluare cantitativă, după ce a fost dezvoltată aplicația pentru a verifica experiența utilizatorului la modul general. Pe lângă aceste modalități de testare, putem să folosim și evaluarea după anumite metrici semnificative, cum ar fi eficacitatea aplicației, adică dacă utilizatorul reușește să realizeze sarcinile în aplicație fără apariția unor erori. Alte metrici ar fi eficiența, unde se măsoară timpul în care au fost completate anumite sarcini și satisfacția, unde este evaluată opinia utilizatorului asupra gradului de ergonomie și utilizabilitate a aplicației.

Pentru a evalua aplicația medicală, ce va ajuta la menținerea foilor de observație clinică generală, ultimele metrici prezentate vor oferi o evaluare destul de bună a interfeței dezvoltate. Din acest punct de vedere putem evalua timpul câștigat de medic prin folosirea unei astfel de aplicației, precum și impactul aplicației în desfășurarea sarcinilor zilnice, toate acestea putând fi evaluate corect prin realizarea unor planuri de testare bine puse la punct. Din acest punct de vedere, pentru un test trebuie să stabilim din ce perspectivă vrem să evaluăm(metrica), ce parte din aplicație vrem să evaluăm, modul și metoda de evaluare, precum și mediul în care vom evalua aplicația.

2. Interfațare pe dispozitive mobile ( Android )

2.1 Principii de design pentru aplicatii mobile

În ultimii ani, evoluția tehnologică a dispozitivelor mobile a făcut ca acestea să fie din ce în ce mai răspândite în toate domeniile datorită flexibilității și potențialului pe care acestea îl dețin. Un element ce a contribuit la răspândirea dispozitivelor mobile pe piața de consum a fost faptul că acestea au devenit din în ce mai accesibile, iar ca urmare oferta pe piața cuprinde foarte multe modele, utilizatorii putând alege ceea ce este mai potrivit pentru ei.

Astfel, popularitatea dispozitivelor mobile a determinat creșterea interesului pentru dezvoltarea aplicațiilor mobile ce folosesc funcționalitățile puse la dispoziție de tablete și smartphone-uri și chiar adaptarea site-urilor web pentru a fi navigabile de pe aceste dispozitive. De exemplu, multe dintre magazinele online populare (Amazon, eBay) au încercat să dezvolte aplicații separate pentru sistemele de operare mobile cunoscute (cum ar fi Android, iOS sau Windows Mobile) pentru a încerca să ofere funcționalități asemenătoare celor din aplicațiile desktop pe dispozitivele mobile (Budiu, &Nielsen, 2011).

Cu toate acestea, rezultatul nu a fost cel așteptat de companii, întrucât utilizatorii nu au fost mulțumiți cu funcționalitățile și modul de interacționare cu noile aplicații create. De asemenea, primele dispozitive mobile nu aveau un ecran suficient de mare și adaptat pentru aplicațiile create, iar tastatura, fie fizică sau virtuală, nu era adaptată pentru introducerea unui anumit tip de date (numeric, text, email). Pentru a găsi eventuale probleme și nemulțumiri din partea utilizatorilor din acel moment, cei de la Nielsen Norman Group au folosit mai multe metode de testare pentru a vedea gradul de satisfacție al utilizatorilor de dispozitive mobile cu privire la utilizarea aplicațiilor existente. Concluziile nu au fost cele mai bune întrucât utilizatorii au găsit probleme acolo unde ar fi trebuit ca dispozitivele mobile să asigure un grad mai mare de ergonomie. De exemplu, o bună parte dintre aceștia s-au plâns de ecranele mici, ce nu pot să afișeze suficiente informații, de tastatura greu de utilizat pentru a completa anumite câmpuri (de exemplu, căutare într-un website) și de viteza de download care împreună cu ecranul mic îngreuna navigarea într-un website sau într-o pagină web (Nielsen, 2009).

Totuși, din anul 2009, când a fost făcut acest studiu, producătorii de dispozitive mobile au încercat să preîntâmpine probleme legate de design și să creeze dispozitive cu capacități hardware din ce în ce mai performante. De exemplu, s-au creat dispozitive cu ecranul mult mai mare, cu capacități senzitive superioare pentru un răspuns mai rapid la comenzile utilizatorului și nu în ultimul rând cu procesoare destul de performante, ce asigură o experiență, din punct de vedere al vitezei de navigare, asemănătoare cu cea a aplicațiilor desktop. De asemenea, nici operatorii de telefonie mobilă nu au stagnat, ci au continuat să îmbunătățească calitatea serviciilor 3G/4G oferite pentru a ajuta regăsirea mult mai rapidă a informațiilor.

Odată cu aceste îmbunătățiri aduse dispozitivelor mobile au început să se detașeze două mari categorii, smartphone-urile și tabletele. În cazul primelor dispozitive, acestea au un caracter personal bine conturat și pot fi folosite pentru sarcini simplu de realizat, rapide și poate urgente. În schimb, o tabletă poate oferi mai multe funcționalități apropiate de cele ale unui desktop, însă aceasta are și dimensiuni mai mari față de un telefon, ceea ce ar putea fi un inconvienent pentru gradul de mobilitate. În urma unui studiu realizat pe utilizatorii de iPad, s-a dovedit că aceștia folosesc de cele mai multe ori tableta pentru a se juca sau pentru a naviga pe diverse website-uri, folosind-o de cele mai multe ori atunci când sunt acasă, ca un înlocuitor pentru laptop. De asemenea, o parte din utilizatori au spus ca preferă să folosească tableta atunci când au de așteptat undeva mai mult timp sau au un drum mai lung de făcut. Din acest motiv, putem trage concluzia că tableta este un dispozitiv mai puțin personal, întrucât oamenii au tendința de a se autentifica cu conturile personale doar pe telefon (smartphone), tableta fiind folosită de mai mulți membri ai familiei sau prieteni (Budiu, & Nielsen, 2011).

Deși dezvoltarea dispozitivelor mobile de tip tabletă a avut un impact destul de mare asupra utilizatorilor, care au fost interesați să își cumpere o tabletă, acest lucru a creat în același timp confuzie în rândul dezvoltatorilor de aplicații. Prin urmare, au apărut o serie de erori de design ce i-au nemulțumit pe utilizatori și ce au determinat scăderea ergonomiei aplicațiilor dezvoltate pentru tabletă. Potrivit unui articol despre utilizabilitatea pe o tabletă, scris de Jakob Nielsen, principalele probleme cu care se confruntă aplicațiile dezvoltate pentru tabletă sunt designul mult prea minimalist și redimensionarea interfețelor create pentru ecranele telefoanelor mobile cu scopul de a fi afișate corespunzător pe tabletă. Alte probleme se referă la folosirea de gesturi pentru ecranul tactil necorespunzătoare și neadaptarea sarcinilor utilizatorilor la caracteristicile ecranului unei tablete (Nielsen, 2013).

În ceea ce privește problema designului minimalist, mulți dezvoltatori aleg să folosească aceleași elemente grafice de interfață pentru toate platformele pe care dezvoltă o aplicație (desktop, mobile), ceea ce ar asigura o anumită consistență, dar de cele mai multe ori nu se poate generaliza până la acest nivel. De exemplu, fiecare platformă mobilă (iOS, Android, Windows Phone) are principii specifice de design, pentru ca aplicațiile să fie integrate cu succes și să fie consistente cu celelalte aplicații dezvoltate pentru acel mediu. Prin urmare, este foarte important ca dezvoltatorii să țină cont de cerințele și modul de utilizare a fiecărei platforme pentru a asigura un echilibru între consistența aplicației atât cu mediul de dezvoltare, cât și cu scopul pentru care a fost creată.

O altă mare problemă în dezvoltarea aplicațiilor pentru tabletă este aceea că dezvoltatorii au tendința de a adapta aplicațiile mobile existente doar prin redimensionarea elementelor grafice pentru a putea fi vizualizate cu succes pe un dispozitiv cu un ecran mai mare. De cele mai multe ori această metodă rezultă în pierderea potențialului pe care l-ar avea un ecran mai mare și duce la nemulțumiri din partea clienților, întrucât aplicația nu aduce îmbunătățiri față de cea de pe un telefon cu ecran mai mic. Astfel, recomandarea actuală este de a construi aplicații doar dacă acestea aduc îmbunătățiri și funcționalitate mai mare față de o aplicație web existentă. Un exemplu de neadaptare la o platformă mobilă ar fi în cazul aplicației celor de la Sears (website pentru comerț online din S.U.A.), unde aplicația creată pentru utilizatorii de iPad nu oferea funcționalități suplimentare și nu era adaptată pentru ecranul unei tablete. În principiu, așezarea în pagină era asemănătoare cu cea a aplicației web, însă lipseau multe detalii, cum ar fi descrierea completă a produselor, filtrarea în cazul căutării de produse sau lipsa posibilității de evaluare a acestora. Astfel, utilizatorii au preferat să folosească în continuare aplicația web, unde puteau regăsi mult mai multe detalii față de aplicația mobilă (Budiu, & Nielsen, 2011).

Pentru a evita problemele mai sus mențioante, din ce în ce mai mulți dezvoltatori au început să învețe din greșelile din trecut și să acorde mult mai multă importanță dezvoltării unei aplicații pentru o anumită platformă. Astfel, atunci când vrem să dezvoltăm o aplicație pe o platformă mobilă, fie că este o aplicație nouă sau o adaptare a unei aplicații web existente, ar fi bine să ținem cont de câteva aspecte esențiale. În primul rând, înainte de a începe lucrul la structura aplicației și la interfața grafică, ar fi bine să acordăm atenție diferențelor dintre sistemele desktop și sistemele mobile. În acest fel, putem să analizâm modul de interacțiune în cadrul unei aplicații mobile, ce funcționalități pot fi implementate cu ajutorul resurselor de care dispunem, care sunt cerințele minimale pe care utilizatorul le dorește de la aplicație și nu în ultimul rând, cum putem diferenția aplicația noastră de cele existente pe piața platformei alese.

Un alt aspect important, pe care trebuie să îl luăm în considerare înainte de a începe dezvoltarea aplicației este tipul și comportamentul utilizatorilor cărora ne adresăm. Această analiza ne va ajuta să modelăm fluxul de sarcini cel mai potrivit pentru viitorii utilizatori ai aplicației pe care o dezvoltăm și să adaptăm interfața pentru nevoile reale ale acestora. Conform articolului ”The 10 principles of mobile interface design”, s-a dovedit că există trei categorii mari de utilizatori, și anume, cei plictisiți, ce vor căuta într-o aplicație un mod de a se relaxa și de a-și ocupa timpul liber (de exemplu, utilizatorii de aplicații pentru rețele sociale, de jocuri, de navigatoare web), cei ocupați, care vor dori să regăsească informațiile cât mai rapid și să câștige cât mai mult timp (de exemplu, utilizatorii de aplicații business, de tip calendar, de tip email) și cei care nu cunosc mediul în care se află (de exemplu turiștii) și ar avea nevoie de aplicații de tip hartă, tripadvisor sau foursquare pentru a regăsi mai ușor locurile din jurul lor (”The 10 principles of mobile interface design”, 2012).

După ce am aflat căror tipuri de utilizatori ne adresăm, ce anume vrem să transpunem în aplicația mobilă pe care o dezvoltăm și în ce mediu se vor afla utilizatorii atunci când interacționează cu aplicația, trebuie să ținem cont de modul fizic în care folosește utilizatorul aplicația. O regulă importantă în acest caz este rapiditatea cu care aceasta răspunde acțiunilor întreprinse de cel ce o folosește pentru a-i asigura utilizatorului senzația că el controlează aplicația. De asemenea, un aspect important al realizării interfeței îl reprezintă mărimea butoanelor și a elementelor ce controlează aplicația întrucât acestea trebuie să țină cont de mărimea medie a degetului mare al utilizatorului, ceea ce ar însemna că un buton ar trebui să acopere cam 44 de pixeli, indiferent de mărimea ecranului (Budiu, & Nielsen, 2011). Ulterior, după ce am ținut cont de acest aspect al interacțiunii prin intermendiul ecranului senzitiv, putem lua în considerare modul în care vom poziționa butoanele de control pentru aplicație, astfel încât să fie la îndemâna oricui. Spre deosebire de aplicațiile desktop, unde butoanele de control sunt așezate în partea de sus a ecranului, în cazul unei tablete trebuie să ținem cont de faptul că nu interacționăm cu un mouse (pointer-ul aici este aproape invizibil), ci cu degetele și de aceea este recomandat să poziționăm partea de control a interfeței în zona inferioară a ecranului pentru a avea conținutul vizibil în orice moment.

Pe lângă aceste principii de design, prezentate mai sus, putem ține cont și de alte aspecte referitoare la interfațarea pe dispozitive mobile, cum ar fi modul de organizare al paginilor, aici putând avea mai multe posibilități, cum ar fi organizarea paginilor cu ajutorul tab-urile, dar doar pentru cel mult șase-șapte pagini. Dacă avem mai multe pagini, putem apela la submeniuri organizate sub formă de listă, de unde utilizatorul își poate alege pagina dorită. De asemenea, platformele mobile oferă posibilitatea personalizării și adaptării tastaturii virtuale în funcție de tipul conținutului ce urmează să fie introdus, astfel putem opta pentru o tastatură exclusiv numerică sau o tastatură pentru completarea adresei de email, aceasta având butoane specifice.

Nu în ultimul rând, ar fi bine să alegem gesturile pe care utilizatorul le folosește în interacțiunea cu aplicația astfel încât acestea să fie cunoscute și folosite în alte aplicații ale platformei mobile pentru a asigura coerența acesteia și pentru ca utilizatorul să nu fie nevoit să învețe gesturi noi. De asemenea, este important să evităm gesturile ce folosesc ambele mâini întrucât, așa cum am menționat mai sus putem să avem un utilizator în mișcare ce folosește doar o singură mâna pentru a interacționa cu tableta. Pe lângă aceste lucruri, este important să nu uităm să asigurăm un feedback corespunzător fiecărei acțiuni importante făcute de utilizator în aplicație, folosind elementele grafice puse la dispoziție de platforma pe care dezvoltăm și chiar notificări sau alerte pentru a anunța eventuale schimbări de stare ale aplicației către utilizator. În final, după ce am ținut cont de aceste principii în realizarea aplicației noastre, putem să luăm în considerare un ultim aspect, și anume, prima interacțiune a utilizatorului cu aplicația, ce se întâmplă imediat după instalare, când putem să îi asigurăm un mic ghid al aplicației astfel încât acesta să poată regăsi mai ușor și mai repede funcționalitățile.

2.2 Caracteristici ale tabletelor

De-a lungul anilor 2000, odată cu dezvoltarea dispozitivelor mobile cu ecran senzitiv, au existat destul de multe încercări de prototipizare a unui dispozitiv mobil ce poate înlocui din funcționalitatea unui desktop. După mai multe încercări de a crea dispozitive cu o funcționalitate și o mobilitate cât mai mare, în anul 2010 a avut loc o evoluție spectaculoasă datorită avansului tehnologic din acel moment, ce a permis crearea unor dispozitive performante ce pot fi cumpărate de oricine își dorește acest lucru.

Din punct de vedere hardware, o tabletă oferă destul de multe funcționalități, majoritatea dintre acestea având procesoare capabile din familia ARM Cortex, ce pot susține mai multe aplicații, inclusiv navigarea în condiții optime pe internet folosind navigatoare web adaptate pentru acest tip de dispozitiv mobil. De asemenea, un mare atu al acestor dispozitive îl reprezintă lipsa butoanelor fizice, ce sunt compensate prin ecranul senzitiv (rezistiv sau capacitiv) care aduce experiența utilizatorului la alt nivel, unul mai personal unde comunicarea cu dispozitivul este mai naturală pentru om, întrucât nu folosește elemente de legătură impersonale, cum ar fi mouse-ul sau tastatura.

De obicei, ecranele dispozitivelor mobile de tip tabletă pot avea dimensiuni de 7 sau de 10 inch, cu diferite rezoluții ce pot asigura o calitatea mai bună și mai multă funcționalitate în comparație cu un smartphone cu ecran senzitiv. Tocmai de aceea, tabletele au fost create pentru a rezolva problema ecranelor mici și uneori greu de adaptat ale telefoanelor cu ecran senzitiv, dar pentru a păstra gradul mare de mobilitate și flexibilitate a unui dispozitiv mobil în comparație cu un notebook sau chiar netbook.

Principala caracteristică a acestui tip de dispozitiv îl reprezintă ecranul senzitiv de dimensiuni considerabile ce poate asigura utilizatorului un confort mult mai mare la navigare. El asigură legătura între comenzile utilizatorului și comportamentul aplicațiilor, aici click-ul obișnuit al mouse-ului fiind înlocuit de atingerea ecranului senzitiv. De asemenea, pot fi recunoscute numeroase gesturi făcute de utilizator pentru a simula diverse acțiuni pentru aplicațiile software, iar aceste gesturi au fost extinse până la sisteme complexe de recunoaștere a scrisului de mână cu suport pentru caractere din cât mai multe limbi.

Pe lângă cele menționate mai sus, un dispozitiv de tip tabletă conține suport hardware pentru conectivitate la internet, fie prin intermediul WiFi, fie prin intermediul conexiunilor mobile de tip 3G. De asemenea, durata de viața a bateriei este considerabil mai bună în comparație cu un dispozitiv de tip netbook, deoarece procesorul este adaptat pentru asemenea dispozitive și nu consumă mult din baterie. Alte caracteristici se referă la posibilitatea de stocare a datelor locală sau folosind un sistem de tip cloud, la modul de interconectare cu alte dispozitive, majoritatea tabletelor având suport pentru conectarea de tip USB sau pentru conectarea utilizând o conexiune de tip bluetooth și desigur la diferiți senzori, cum ar fi accelerometrul sau senzori de proximitate, ce pot adăuga un plus de funcționalitate aplicațiilor dezvoltate pe tabletă.

Acum că am prezentat principalele caracteristici fizice ale tabletelor, putem să enumerăm problemele ce pot apărea din cauza lor în partea de dezvoltarea software, dar și modalități de a le evita. Întrucât orice sistem ce este implementat în viața reală nu este utilizat în cazul ideal, una dintre principalele probleme în utilizarea unei tablete o reprezintă atingerea accidentală a unui buton de control, ce poate genera o nouă stare a unei aplicații. În acest caz, este recomandat să existe întotdeauna o soluție pentru ca aplicația să revină la starea în care a fost.

Un alt punct sensibil ar fi gesturile pe care utilizatorul le va face pentru a interacționa cu aplicația, întrucât acestea pot ajunge să fie mult prea complicate și să îngreuneze navigarea în aplicație. Din cauza faptului că utilizatorilor le va fi mult mai greu să învețe gesturi complicate pentru ecranele senzitive, este recomandat să folosim doar gesturi simple ce pot fi efectuate cu o singură mână. De asemenea, de multe ori gesturi utilizatorilor nu sunt așa vizibile întrucât acestea sunt foarte rapide și ei nu își dau seama de ele, de aceea este important să asigurăm un feedback al acțiunilor prin intermediul interfeței grafice.

În final, nu ar trebui să uităm de spațiul suficient pus la dispoziție de o tabletă (7 sau 10 inch) și să încercăm să îl utilizăm într-o modalitate cât mai eficientă. Potrivit articolului ”Utilize Available Screen Space” a lui Jakob Nielsen, utilizatorii preferă mai multe informații afișate pe ecran, ce pot fi regăsite din cât mai puține acțiuni, în detrimentul unor interfețe grafice spectaculoase, ce oferă prea multe pop-uri și nivele de organizare în aplicație (Nielsen, 2011). Astfel, utilizatorii vor opta pentru design mai simplu, dar care afișează cât mai multe informații vizibile la o singură privire.

2.3 Sistemul de operare Android pentru dispozitive mobile

2.3.1 Dezvoltarea sistemului de operare Android

Odată cu dezvoltarea pieței dispozitivelor mobile și a lansării a cât mai multor modele de tablete și telefoane cu ecran senzitiv, s-au evidențiat și sistemele de operare ce rulau pe aceste dispozitive, acestea influențând modul de dezvoltare al aplicațiilor de către programatori. Printre cele mai populare sisteme de operare cu care vin dispozitivele cele mai vândute se numără Android OS, iOS și Windows. Cu toate acestea, conform celor de la Statista, piața este dominată clar de dispozitivele mobile (inclusiv tablete, smartphone-uri și alte dispozitive hibride) ce rulează sistemul Android, iar tendința în următorii ani este de detașare clară a acestui tip de sistem de operare (Yarow, 2014). O componentă importantă a unei platforme mobile o reprezintă și magazinul de aplicații ce sunt create special pentru acel sistem de operare, aici Google Play(Android) depășind numărul de aplicații al principalului competitor, App Store(Apple) în anul 2013, conform celor de la phoneArena (Victor, 2013).

Firma ce a dezvoltat pentru prima dată sistemul de operare Android a fost înființată în anul 2003, în Palo Alto, în dorința de a crea un sistem de operare pentru telefoanele mobile cu ecran tactil, ce poate să știe mai multe informații despre utilizatori, cum ar fi locația sa, preferințe și astfel să poată fi personalizat la un nivel destul de ridicat. După mai multe dificultăți financiare ale firmei, aceasta a fost preluată de cei de la Google în anul 2005 și a fost înființată și organizația ”Open Handset Alliance”, din care făceau parte producători de dispozitive mobile(HTC, Samsung), dezvoltatori de procesoare(Qualcomm, Texas Instruments) și firme de telefonie mobilă(T-Mobile), cu ajutorul cărora urma să fie dezvoltat sistemul de operare Android. Astfel, în anul 2008 a fost lansat primul produs ce rula Android, HTC Dream. Din acel moment, au fost lansate din ce în ce mai multe telefoane mobile ce rulează sistemul de operare Android, acestea fiind realizate în colaborare cu mai mulți producători de dispozitive mobile, oferind o posibilitate de răspândire foarte mare a sistemului de operare.

Sistemul de operare Android se bazează pe un kernel de Linux 2.6 modificat special pentru a putea rula fără prea mari dificultăți pe un dispozitiv mobil cu un procesor mai puțin performant față de cel al unui sistem desktop. Pentru ca acesta să ruleze cât mai eficient pe dispozitivele mobile existente, comunitatea open-source a acestui proiect a hotărât să implementeze o librarie proprie în C (Bionic) și o mașină virtuală, ce să ruleze Java, specifică Android (DVM – Dalvik Virtual Machine). Tocmai caracterului open-source al acestui sistem de operare a dus la popularitatea lui pe foarte multe dispozitive mobile, întrucât producătorii pot alege să particularizeze până la un nivel destul de ridicat acest sistem de operare și pot găsi în permanență îmbunătățiri prin contribuția celorlalți membri ai comunității.

Un alt aspect ce a contribuit la popularitatea acestui sistem de operare pentru dispozitive mobile a fost faptul că aplicațiile dezvoltate special pentru Android și puse la dispoziția utilizatorilor prin intermediul magazinului Google Play au fost și sunt mult mai accesibile față de celelalte aplicații ale principalilor competitori. Majoritatea sunt dezvoltate folosind strategia freemium, unde utilizatorul are acces gratuit la o variantă de baza a unei aplicații, fie chiar un joc, urmând să plătească doar dacă dorește funcționalități suplimentare. Potrivit unui studiu făcut în anul 2013, pe aproximativ 6.000 de dezvoltatori de aplicații, 71% din aceștia folosesc platforma Android pentru a dezvolta aplicații, aceasta fiind mult mai răspândită și mai accesibilă față de celelalte platforme mobile (Developer Economics Q3, 2013).

Cu toate că sistemul de operare Android a avut un succes destul de mare în rândul utilizatorilor de smartphone, acesta fiind adoptat cu succes în cazul acestui tip de dispozitiv, nu același lucru s-a putut spune despre dispozitivele de tip tabletă. Atunci când a avut loc o creștere semnificativă a pieței pentru asemenea dispozitive, în anul 2010, tabletele ce rulau Android nu au avut un așa mare succes spre deosebire de ceilalți mari competitori. Principalul motiv a fost faptul că interfața grafică a utilizatorului nu era adaptată pentru un ecran mai mare, ca cel al tabletei, iar dezvoltatorii de aplicații nu acordaseră importanță adaptării design-ului pentru ecranul unei tablete. Pentru a putea atinge performanța Apple, ce se bucurau deja de succes cu produsul lor iPad, cei de la Google au lansat în 2012 tableta Nexus, ce avea să rezolve o parte din probleme existente cu adaptarea aplicațiilor și să ofere astfel un exemplu bun celorlalți dezvoltatori de aplicații specifice tabletelor cu platformă Android.

2.3.2 Platforma de dezvoltatori Android

Odată cu dezvoltarea și răspândirea Android pe diverse dispozitive mobile, a fost creată și o platformă web pentru dezvoltatorii de aplicații, unde sunt oferite anumite puncte de reper pentru cei ce vor să înceapă dezvoltarea unei aplicații ce poate va rula pe mai multe dispozitive cu Android. Există recomandări atât pentru dispozitivele de tip smartphone, unde sunt specificate dimensiunile și rezoluțiile posibile, ce trebuie luate în calcul, cât și pentru dispozitivele mai mari, de tip tabletă. La modul general, cei de la Android propun și ei o serie de criterii ce sunt strâns legate de regulile de design abordate în secțiunile anterioare ale acestui capitol.

În primul rând, sunt stabilite niște reguli clare cu privire la partea grafică, ce este strâns legată de funcționalitatățile implementate odată cu sistemul de operare Android. De exemplu, este specificat faptul că aplicațiile nu au voie să suprascrie sau să adauge funcționalități butonului de întoarcere sau butonului de acasă. Acestea au funcționalități clare, cunoscute tuturor utilizatorilor de dispozitiv cu sistem Android, și de aceea schimbarea acțiunilor realizate de aceste butoane ar crea confuzie în rândul utilizatorilor. Alte recomandări se referă la modul de interacțiune cu utilizatorul, mai exact la modul în care sunt realizate notificările, și anume, este recomandat să afișăm o notificare doar dacă avem ceva de comunicat utilizatorului, în sensul că vrem să anunțăm un eveniment legat de aplicație. De asemenea, notificările multiple vor fi grupate într-un singur obiect, pentru a fi afișate sub formă de sublistă.

Mai mult, o altă serie de recomandări face referire la cum se realizează funcționalitatea aplicației ținând cont de instrumentele puse la dispoziție de sistemul de operare Android. Este știut că fiecare aplicație poate să acceseze funcționalități sau servicii ale unui dispozitiv de tip smartphone sau tabletă, cum ar fi camera foto, conectivitatea la internet sau folosirea memoriei pentru a stoca diverse elemente. Însă, este recomandat ca atunci când dezvoltăm o aplicație să folosim numărul minim de permisiuni posibile, iar dacă acestea implică costuri din partea utilizatorului (sms, apel telefonic), acesta să fie anunțat în aplicație.

Nu în cele din urmă se face referire și la stabilitatea și performanța aplicației ce vrem să o dezvoltăm, două aspecte ce vor contribui semnificativ la impresia pe care utilizatorul și-o va face despre aplicație. Un aspect fundamental pentru o aplicație Android, așa cum este descris în documentația creată pentru dezvoltatori, este ca această să funcționeze fără niciun fel de întreruperi și fără blocarea completă a aplicației, astfel să putem capta erorile ce pot apărea în utilizarea aplicației și să putem afișa simple mesaje de eroare, fără ca utilizatorul să piardă controlul aplicației. O altă recomandare fundamentală, ce ține de calitatea aplicației, este folosirea de imagini corespunzătoare pentru dimensiunile ecranelor dispozitivelor astfel încât să evităm pixelarea sau imagini neclare, dar și alinierea corespunzătoare a părților de text astfel încât acestea să fie vizibile și să existe suficient spațiu față de celelalte elemente înconjurătoare.

2.4 Particularități ale aplicațiilor Android pentru tabletă

În secțiunile anterioare am menționat că dezvoltarea aplicațiilor pe tabletă, din punct de vedere al interfeței grafice, poate fi ușor diferită față de cea pe un smartphone, principalul motiv fiind dimensiunile diferite ale ecranelor. Tocmai din această cauză, este recomandat să luăm în considerare două variante de dezvoltare ale unei aplicații mobile, una pentru smartphone și una pentru dispozitive cu ecran mai mare, de tip tabletă. Având în vedere faptul că sistemul de operare mobil Android nu a avut un succes atât de mare pentru tablete la începutul perioadei de creștere a acestor dispozitive pe piața, cei de la Google au inclus în documentația pentru dezvoltatori câteva recomandări de adaptare a aplicațiilor mobile existente pe smartphone-uri la dimensiunile unei tablete. În principiu, recomandările urmăresc evitarea principalelor nemulțumiri ale utilizatorilor de tabletă, nemulțumiri ce sunt evidențiate în articolele celor de la ”Nielsen Norman Group” cu privire la gradul de utilizabilitatea al aplicațiilor existente pentru tabletă (Nielsen, 2013).

Recomandările referitoare la dezvoltarea aplicațiilor, astfel încât acestea să poată fi accesate la același potențial și de pe un dispozitiv de tip tabletă, reprezintă o completare a principiilor și recomandărilor generale de dezvoltare prezentate în secțiunea anterioară, referitoare la sistemul de operare Android. În acest fel, una dintre recomandările principale face referire la principala diferență dintre un smartphone și o tabletă, și anume, dimensiunea ecranului. Pentru această, ar trebui să analizăm modul de așezare a elementelor în pagină pe un ecran de 7 sau 10 inch și să încercăm să ajustăm lățimea elementelor pentru a asigura un comfort mai mare utilizatorului, dat fiind faptul că liniile foarte lungi de text pot fi greu de urmărit, recomandarea fiind undeva între 50 și 75 de caractere per linie. De asemenea, trebuie să avem grijă la așezarea butoanelor de control astfel încât să fie accesibile de către utilizator atunci când vor folosi tableta și să nu neglijăm ajustarea spațiilor libere dintre elemente astfel încât să fie proporționale cu dimensiunile ecranului.

În dezvoltarea și adaptarea aplicațiilor pentru a fi rulate pe tabletă, o recomandarea destul de importantă, menționată și în capitolele anterioare este aceea de a folosi cât mai bine spațiul pus la dispoziție de un ecran de asemenea dimensiuni. În acest scop, cei de la Android vin în ajutorul dezvoltatorilor prin punerea la dispoziție a unor soluții de software ce permit reutilizarea codului într-o manieră eficientă. Astfel, putem reorganiza elementele aplicației ce va fi adaptată pentru tabletă astfel încât să poată afișa într-un singur ecran elemente din mai multe pagini (activități) existente în aplicație pentru un dispozitiv de tip smartphone. În aceeași manieră putem reorganiza afișarea elementelor principale ale unei pagini la tranziția orientării ecranului, de la portret la vedere și invers.

Tot în cadrul recomandărilor făcute pentru dezvoltatorii de aplicații se menționează faptul că este preferabil să avem un singur executabil (.apk) pentru toate tipurile de dispozitive atunci când vrem să lansăm o aplicație în magazinul Google Play. În aceste condiții, ar trebui să acordăm o importanță mare elementelor grafice, ce vor fi incluse în aplicație (iconuri, imagini, etc) întrucât acestea trebuie să aibă rezoluția potrivită pentru fiecare dimensiune de ecran de dispozitiv pentru care vrem să dezvoltăm aplicația. În aces scop, suportul pentru dezvoltarea de aplicații de la Android oferă posibilitatea de a include același element grafic sub mai multe rezoluții, grupate în funcție de dimensiunile ecranelor.

Așa cum am spus mai devreme, atunci când vrem să integrăm o aplicație existentă pe smartphone și pe o tabletă trebuie să ținem cont de diferențele dintre cele două tipuri de dispozitive. Pe lângă diferențele de dimensiune, ar trebui să ținem cont de caracteristicile hardware ale celor două tipuri de dispozitive, cum ar fi faptul că unele tablete nu au posibilitate de efectuare a unui apel telefonic sau nu conțin două camere foto, așa cum se întâmplă la multe dintre smartphone-uri. Toate aceste diferențe pot afecta funcționalități ale aplicației atunci când ea va fi folosită pe diverse tipuri de dispozitive și de aceea o recomandare este aceea de a evalua toate funcționalitățile aplicației și de a le omite pe cele ce nu pot funcționa pe tabletă, motivul fiind neconcordanțele hardware. O alternativă la omiterea funcționalităților ar fi înlocuirea lor cu unele ce pot rezolva aceeași problemă, dar folosesc resursele hardware puse la dispoziție de tabletele existente pe piață.

Fig 1, Tipuri de tastatură personalizate pentru conținutul introdus (propoziții text, numeric)

O ultimă recomandare ar fi ca să menționăm în fișierul manifest, ce însoțește aplicația și oferă informații despre serviciile pe care le folosește și versiunile de software compatibile, suportul pentru dispozitivele cu ecran foarte mare (referire la 7 și 10 inch). Astfel, vom asigura deschiderea către toate dispozitivele de tip tabletă, informând utilizatorii din magazinul de aplicații de faptul că aplicația dezvoltată este adaptată cu funcționalități speciale pentru tabletă. Tot în acest fișier va trebui să specificăm dependențele de funcțiile hardware ale dispozitivului pe care va rula aplicația, cum ar fi folosirea camerei foto, a apelurilor telefonice, dar așa cum am menționat mai devreme unele funcționalități pot lipsi în cadrul unui dispozitiv de tip tabletă, și de aceea aceste servicii va trebuie să le declarăm ca nefiind obligatorii pentru aplicație.

Toate acestea fiind zise, recomandările pentru dezvoltatorii de Android țin cont atât de principiile generale ale dezvoltării unei aplicații pe un dispozitiv mobil, luând în calcul dimensiunile ecranului, partea de interacțiune tactilă și limitările impuse de procesor și modul de conectare la internet, cât și de funcționalitățile oferite de sistemul de operare Android împreună cu instrumentele de dezvoltare puse la dispoziția utilizatorului. În ultima parte a acestui capitol, voi prezenta câteva exemple concrete de aplicații ce au avut succes și au fost foarte apreciate de utilizatori împreună cu principiile de design pe care acestea le-au respectat.

2.5 Exemple de aplicații Android populare

Până în acest moment am prezentat evoluția pe piața ultimilor ani a dispozitivelor mobile, în special cele de tip tabletă și modul în care au fost dezvoltate aplicații pentru acest tip de dispozitiv. Cu toate că piața aplicațiilor Android pentru tabletă nu este așa de bine dezvoltată ca cea a aplicațiilor pentru smartphone-uri și încă este nevoie de o adaptare a multor aplicații pentru a putea fi utilizate la potențialul lor maxim de către utilizatori, există câțiva dezvoltatori de aplicații care au înțeles oportunitatea oferită de recomandările enumerate mai sus și au decis să pună în aplicare aceste sfaturi pentru aplicațiile lor. În cele ce urmează voi prezenta câteva exemple de aplicații adaptate pentru tabletă, prin care dezvoltatorii au reușit să câștige mai mulți utilizatori și să îmbunătățească utilizabilitatea aplicațiilor lor pe o gamă largă de dispozitive mobile.

Un exemplu foarte bun îl reprezintă aplicația pentru administrarea finanțelor personale, Mint.com Personal Fianance, unde dezvoltatorii vroiau să ofere o experiență mai bună utilizatorilor prin introducerea de noi funcționalități pentru rapoarte, folosind elemente grafice avansate. Cu toate acestea, integrarea acestor funcționalități noi era mai dificilă de realizat din punct de vedere al ergonomiei și comfortului utilizatorului ce va folosi aplicația, dar totodată aplicația ce era afișată pe tabletă nu putea să fie o copie simplă a celei de pe smartphone. Cu această ocazie, dezvoltatorii au hotărât să păstreze grafica aplicației de pe smartphone și să aducă funcționalități suplimentare pentru versiunea dezvoltată special pentru tabletă. Astfel, aceștia au decis să adauge elemente de vizualizare a datelor introduse mai avansate pentru a profita de spațiul mai mare al ecranului unei tablete. Ca rezultat, timpul mediu petrecut de un utilizator per sesiune a crescut la mai mult de cinci minute, conturându-se astfel un comportament clar al unui utilizator, aceșta folosind telefonul pentru a introduce cheltuieli sau venituri în aplicație, iar pentru vizualizarea istoricului financiar și pentru analiza datelor folosesc, în timpul serii, tableta.

O altă aplicație, ce adaptarea la dispozitivele de tip tableta i-au crescut considerabil numărul de descărcări, este Remember The Milk, de tipul listă de sarcini (en. to do list). Așa cum povestesc pe platforma de dezvoltatori Android, cei de la Remember The Milk aveau în minte să adapteze pentru tabletă facilitățile oferite în aplicație, printre care și un widget pentru ecranul principal cu sarcinile completate de utilizator, dar nu aveau idee cum puteau face acest lucru în mod eficient. Odată cu apariția recomandărilor de adaptare a aplicațiilor pentru dispozitivele tabletă de cei de la Google, aceștia au reușit să dezvolte adaptarea aplicației pentru tabletă, modificând modalitatea de afișare a listelor pe tot ecranul (profitând de spațiul pus la dispoziție) și aducând mai multe tipuri de personalizări widget-ului inclus în aplicație. Odată cu aceste modificări, dezvoltatorii au reușit să creeze astfel un singur fișier instalabil, atât pentru smartphone, cât și pentru tablete, reușind să crească cu 83% număr de instalări ale aplicației pe dispozitive de tip tabletă.

Pe lângă aceste aplicații putem să menționăm și altele ce au reușit să realizeze aplicații adaptate pentru ecrane mai mari și să aibă un succes mare printre utilizatori.Un exemplu ar fi aplicația celor de la Flipboard, ce a avut un succes enorm pe platforma celor de la Apple (iPad) și a reușit să fie adaptată cu succes și pe tabletele ce rulează sistemul de operare Android. Aplicația reunește în principiu titlurile de mare interes din presă, dar și poveștile de succes ce apar pe rețelele sociale, cum ar fi Facebook, Twitter sau YouTube, utilizatorul putând chiar să salveze știrile pe care ar vrea să le citească mai târziu, pentru a nu fi necesară o nouă conexiune la internet. În anul 2012, când a fost lansată versiunea optimizată a aplicației pentru tabletele ce rulează Android, utilizatorii au fost extrem de încântați de experiența îmbunătățită, comparabilă cu cea de pe un iPad, lăsând deoparte varianta redimensionată a aplicației adaptată doar pentru smartphone-uri.

Un alt potențial mare pentru optimizare l-au avut aplicațiile de jocuri pentru dispozitivele mobile, dezvoltatorii fiind conștienți de avantajele și de oportunitățile de dezvoltare în cazul unui dispozitiv cu un ecran senzitiv mai mare. Astfel, un exemplu de succes este TinyCo, ce au folosit ca platformă principală de dezvoltare Android și au văzut oportunitatea imensă adusă de adaptarea jocurilor pentru tabletă. De cele mai multe ori, un ecran mai mare poate aduce un grad ridicat de comfort utilizatorilor și pot asigura o experiența a jocului mult mai bogată, ecranul mai mare oferind posibilitatea de a crea un joc cu multe detalii și de a asigura mai mult control prin gesturi din partea jucătorilor. În urma optimizării jocurilor pentru dispozitive de tip tabletă, cei de la TinyCo au ramarcat o creștere atât a numărului de descărcări în cazul utilizatorilor de tablete, cât și a timpului petrecut de aceștia într-o sesiune de joc.

3. Aplicații existente în domeniul medical

3.1 Procesele de lucru în domeniu medical

3.1.1 Descriere generală a proceselor de lucru

În capitolul anterior, am acordat o mare parte din atenție modului de dezvoltarea a unei aplicații pe dispozitive mobile, în mod particular pe un dispozitiv de tip tabletă, rezultând mai multe moduri prin care putem evita greșelile de design și putem construi o aplicație ce poate oferi un grad mare de utilizabilitate utilizatorilor ei. Însă, scopul acestei lucrări este de a dezvolta o aplicație mobilă pentru tabletă în domeniul medical și de aceea, în capitolul ce urmează mă voi ocupa de prezentarea proceselor ce au loc în acest domeniu și cum pot fi modelate în mod particular pe un dispozitiv mobil de tip tabletă. De asemenea, voi face referire la aplicațiile existente, atât cele mobile cât și cele existente în varianta desktop pentru a putea extrage părțile pozitive, ce pot ajuta la viitoarea dezvoltare a aplicației mobile.

Procesele din domeniul medical, în particular cele ce se desfășoară în cadrul unui spital, pot fi destul de complexe, din cauza specializărilor existente, dar pot să se desfășoare pe mai multe planuri paralele, rezultat a mai multor acțiuni ce trebuie efectuate de personalul medical în îngrijirea pacienților (intervievarea acestora, completarea istoricului unui pacient, recomandarea medicației, efectuarea analizelor de laborator,etc). La un nivel de generalizare ridicat putem să folosim modelul unor procese din industrie în domeniul medical, întrucât au în comun următoarele elemente: o ordine anume a sarcinilor de executat, logistica administrării personalului și a diverselor elemente auxiliare (medicație, mobilier, aparatură medicală, consumabile) și planificarea sarcinilor pentru fiecare angajat în parte. Totuși, la un nivel mai mic de generalizare sistemul medical are anumite particularități ce definesc caracterul complex al sarcinilor ce trebuiesc îndeplinite în acest mediu. De exemplu, un pacient trece prin mai multe procese complexe ce pot varia foarte mult în funcția de starea sa de sănătate (analize complexe, tratament, intervenții chirurgicale, recuperare post-operatorie), există foarte mulți angajați în sistemul medical și fiecare are roluri cât mai diverse, stare de sănătate a unui pacient nu este atât de previzibile și există o probabilitate mare să apară schimbări și nu în ultimul rând existe foarte multe departamente ce trebuie să comunice rapid între ele.

Pentru a reuși să dezvoltăm un sistem medical electronic eficient și cu grad mare de utilizabilitate pentru personalul medical este foarte important să studiem cu atenție procesele ce au loc într-un spital, modul în care medicii și ceilalți angajați își desfășoară activitățile și modul de interacționare între aceste procese. Astfel, înainte de a porni dezvoltarea efectivă a funcționalității unui produs software pentru sistemul medical este foarte important să găsim instrumentele potrivite pentru a putea analiza diagramele de flux de lucru și a modela un sistem în care datele circulă corect. În mod obișnuit, pentru a modela aceste diagrame se folosesc diverse sisteme cunoscute în lumea dezvoltatorilor de aplicații pentru afaceri, cum ar fi diagramele UML (Unified Modeling Language), în special partea de modelare a modului de interacțiune cu aplicația sau modul de comunicare între diverse părți componente sau rețelele Petri, ce oferă un exemplu matematic riguros, modelând procesele și intercațiunile dintre acestea prin intermediul unui graf orientat bipartit. La toate acestea putem adăuga și modelul BPM (Business Process Management) ce va ajuta la monitorizarea modelelor create și îmbunătățirea lor permanentă.

3.1.2 Tehnici de modelare a proceselor în domeniul medical

În cazul sistemelor electronice medicale, alegerea unui tip particular de instrument pentru a modela procesele din aplicație împreună cu interacțiune între acestea poate să fie ineficientă și de aceea este recomandat pentru sisteme complex, cum e și cazul celui medical, să fie folosite mai multe abordări hibride, ce reunesc mai multe tipuri de instrumente, unde modele sunt transformate pentru a putea fi transferate între instrumente. Așa cum este precizat în articolul ”A Modeling and Simulation Framework for Health Care Systems” ( Systems, Man, and Cybernetics: Systems, IEEE Transactions on, 2014), există trei tipuri mari de abordări pentru a modela un sistem complex de sarcini, și anume, un tip ce se bazează foarte mult pe partea de modelare a arhitecturii sistemului și a proceselor de business (BPM), însă acest model pierde din vedere interacțiunea umană cu aplicația. Cea de-a doua abordare se bazează pe partea de instrumente UML pentru a putea modela și a simula în același timp un model generic pentru o aplicație medicală, iar cea de-a treia abordare este cea mai complexă dintre toate cele trei, având o abordare mult mai complexă a modelării și simulării proceselor din aplicație, punând accent și pe partea de interacțiune atât a utilizatorilor cu aplicația, cât și între utilizatori.

În articolul menționat mai sus, autorii propun o nouă metodă de modelare a proceselor și fluxului de date dintr-un spital, numită MedPRO. Aceasta folosește două instrumente de modelare cu rol diferit, UML și rețele Petri, astfel acoperind mult mai multe aspecte legate de analiza proceselor și a interacțiunii umane în cadrul sistemului medical. Astfel, modelul presupune analiza domeniului în care vom dori să dezvoltăm aplicația prin intervievarea personalului medical și analiza sarcinilor realizate de aceștia în timpul de lucru, ce va fi transpus ulterior într-o diagrama UML ce modelează în special partea de interacțiune umană destul de complex între angajații sistemului medical. Ulterior, după mai multe iterații în scopul validării modelului UML creat, dacă acesta este satisfăcător, atunci se va trece la următoarea etapă, aceea de transformare din modelul UML în modelul rețelei Petri cu scopul de validare formală și corectă a sistemului de procese creat. De aici, folosind modelul rețelei Petri sunt generate modulele prin care sunt planificate acțiunile ce trebuie executate în sistemul medical analizat și sunt generate simulări ale evenimentele în scopul verificării modelului.

Fig2, Modelul MEDPro propus

Particularitatea lucrului în sistemul medical este aceea că mediul prezintă un risc destul de ridicat prin faptul că interacțiunea se face prin intermediul oamenilor, iar cazurile cu care se confruntă un medic pot fi foarte riscante. Așa cum spun și cei de la NIST (National Institute of Standards and Technology) în lucrarea lor cu privire la integrarea sistemelor electronice medicale în sistemul de lucru al unui spital, asigurarea unui flux de date și model corect de interacționare între sarcini este esențial pentru sistemul medical, întrucât în acest caz orice eroare sau neînțelegere a utilizării sistemului poate avea consecințe grave asupra activității personalului medical și mai ales asupra modului în care sunt tratați pacienții. Astfel, s-au identificat anumite nemulțumiri ale personalului medical ca rezultat al unei implementări ineficiente ale proceselor de lucru cum ar fi faptul că folosesc prea mult tastatura pentru a introduce date despre un pacient, că trebuie să se autentifice de mai multe ori în sistem sau că numele pacienților nu apar pe ecran în permanența pentru a ști pentru cine completează datele. Pe lângă toate aceste lipsuri de desgin, se adaugă tendința personalului medical de a încerca să folosească necorespunzător sistemul, nerespectând astfel pașii din fluxul de sarcini al aplicației, existând riscul de interpretare eronată a datelor ce pot duce la dezechilibre majore în sistemul medical electronic (Lowry, Ramaiah, Patterson, Brick, Gurses, Ozok, & Simmons, 2014).

Pentru a putea preîntâmpina aceste practici, o etapă importantă a procesului de dezvoltare a aplicației medicale și în special al modelului sarcinilor este testarea și evaluarea corectitudinii fluxului de sarcini, atât de către dezvoltatori, cât și de către personalul medical. Astfel, pentru a putea lua în considerarea toate elementele ce apar în cadrul proceselor de lucru din domeniul medical și pentru a putea modela un flux de sarcini adecvat, cei de la ” Systems Engineering Initiative for Patient Safety” propun ca viitorul model al sarcinilor să ia în considerare următoarele elemente: oamenii implicați în sistem (în particular medicii, asistenții medicali, pacienții, însoțitorii pacienților), caracteristici ale mediului în care se desfășoară activitatea (mediu aglomerat, cu multă gălăgie și foarte dinamic), instrumentele puse la dispoziție (sisteme electronice, fișele medicale în format fizic), sarcinile ce trebuie îndeplinite (completarea datelor despre un pacient, prescripții medicale, recomandarea analizelor de laborator) și nu în ultimul rând caracteristicile organizației pentru care dezvoltăm aplicația (procedurile medicale, legislația privind asigurările de sănătate din țara în care dezvoltăm aplicația, cultura și obiceiurile specifice). Dacă vom modela corect procesele și interacțiunea dintre aceste elemente vom reuși să obținem un sistem de procese corect, atât din punct de vedere al corectitudinii aplicației, cât și din punct de vedere al factorului uman (Lowry, Ramaiah, Patterson, Brick, Gurses, Ozok, & Simmons, 2014, p. 2).

3.2 Motivația dezvoltării sistemelor electronice medicale

În ceea ce privește motivația implementării unor astfel de sisteme electronice medicale, implicările sunt destul de mari întrucât interesul nu este doar din partea sistemului medical, ci și din partea companiilor mari de software, ce văd aici un potențial de business foarte mare, dar și din partea guvernului, mai ales în S.U.A. unde se urmărește eficientizarea sistemului. Din partea personalului medical, motivele adoptării unui sistem electronic pot varia în funcție de specialitate, de țară, însă conform statisticilor făcute în special de guvernul american, majoritatea angajaților din domeniul medical își doresc adoptarea unui sistem electronic tocmai pentru a putea eficientiza modul de îngrijire a pacienților, de a simplifica și automatiza modul de organizare a cheltuielilor din spital în ceea ce privește asigurarea medicală și de a putea eficientiza procesele ce au loc într-un spital din punct de vedere al timpului. Totuși, unii medici rămân încă reticenți la adoptarea unui astfel de sistem, tocmai din cauza greșelilor de design a aplicațiilor anterioare, ce s-au dovedit ineficiente pentru sistemul medical.

Cu toate că satisfacția cu privire la adoptarea sistemelor medicale electronice nu este așa mare, există o tendință de creștere a utilizării lor în marile centre medicale, conform statisticilor făcute în Statele Unite ale Americii. Acestea arată că 78% din medicii ce au și un cabinet au adoptat un sistem electronic medical de gestionare a pacienților și a proceselor ce au loc în fiecare zi, față de 18%, cât era procentul în 2001. Privind în ansamblu, aceste numere reprezintă o creștere spectaculoasă a sistemelor medicale electronice ca urmare a evoluției tehnologiei în domeniul software medical. Cu toate aceste cifre, procentul de medici ce sunt mulțumiți de sistemul medical electronic este mult mai mic, și doar 48% cred că aplicația medicală folosită îndeplinește sarcinile de bază așa cum trebuie (Hsiao, & Hing, 2014) .

O explicația a faptului că tehnicienii din domeniul medical nu sunt pe deplin mulțumiți de aplicațiile existente este faptul că acestea au foarte multe lipsuri în ceea ce privește utilizabilitatea, un motiv fiind neînțelegerea pe deplin a proceselor dintr-un spital de către dezvoltatorii de software, astfel sistemul electronic complică procesele din spital, în loc să simplifice munca medicilor. Din această cauza, încrederea în astfel de sisteme este destul de mică întrucât o aplicație care nu interacționează cu utilizatorul creează impresia că datele vor fi pierdute, de asemenea medicii s-au plâns și de alte probleme cum ar fi navigarea în aplicație. La nivel mai înalt, problemele legate de adoptare ar fi în principal de ordin financiar și de timp, întrucât un sistem electronic medical este destul de complex, cuprinde mai multe module și trebuie particularizat pentru fiecare unitate în care este implementat.

Printre dificultățile mari întâmpinate la implementarea unui astfel de sistem se numără faptul că personalul medical dispune de un timp limitat pentru a explica cerințele lor cu privire la o aplicație software medicală și pentru a contribui la modelarea proceselor interumane sau faptul că aceștia nu au timp pentru instruire în ceea ce privește utilizarea unor astfel de programe. Un alt motiv se referă la timpul necesar pentru a implementa un asemenea sistem într-o clinică întrucât modelul este unul complex, ce necesită multe iterații pentru a ajunge la o variantă optimă. De asemenea, un alt motiv se referă la securitatea datelor din aplicații și la politici ce țin de confidențialitatea datelor unui pacient, întrucât de cele mai multe ori acestea nu reies din descrierea aplicațiilor și de aici rezultă neîncrederea într-un astfel de sistem. Și nu în ultimul rând, o problemă ar fi și în modul în care aceste aplicații își merită banii și cum este amortizată investiția într-un asemenea sistem întrucât aici se discută de unități ce primesc finanțare din partea guvernului și a contribuțiilor pacienților.

Singura metodă prin care putem să menținem interesul și motivația pentru dezvoltarea de aplicații în domeniul medical este asigurarea permanentă a unui model de dezvoltare ce să preîntâmpine problemele menționate mai sus. Pentru acest lucru, în lucrarea ” NIST Guide to the Processes Approach for Improving the Usability of Electronic Health Records”, se menționează aceste probleme și se pune accent pe faptul că designul unor astfel de aplicații ar trebui să se centreze pe utilizator pentru a se adapta mai bine nevoilor personalului medical și pentru a evita reticența acestora.

3.3 Principii de dezvoltare a aplicațiilor în domeniul medical

3.3.1 Principii critice în dezvoltarea unei aplicații medicale

Înainte de a începe modelarea fluxului de sarcini și a structurii aplicației medicale pe care vrem să o implementăm este foarte important să luăm în considerare anumite cerințe critice ale interacțiunii personalului medical cu sistemul software pentru a putea acorda atenție sporită acestora și a mări astfel gradul de utilizabilitate. Pentru a evita probleme grave legate de siguranța pacienților și tratarea lor în condiții de siguranță, în cele ce urmează voi prezenta câteva aspecte critice în dezvoltarea unei aplicații medicale, ce sunt în incluse în lucrarea celor de la m_acadamian, ”Developing Successful Healthcare Software:10 Critical Lessons” (Thizy, 2010).

În primul rând, un principiu esențial pentru dezvoltarea de aplicații în domeniul medical este acela de a adapta cerințele utilizatorului la specialitatea din care face parte personalul medical ce va folosi aplicația. De exemplu, există multe sisteme electronice medicale folosit în medicina generală, ce conțin foarte multe detalii despre pacienți și consultațiile lor, de care un medic dintr-o anumită specialitate nu are nevoie. De cele mai multe ori, aceștia au nevoie de o parte specializată a aplicației doar pe domeniul lor de interes și pentru activitățile pe care le execută în cadrul specialității pe care o practică. O soluție propusă pentru această problemă ar fi ca medicilor să le fie prezentat un exemplu de utilizare bazat pe un scenariu, și nu pe diagrama UML, ce sunt puțin impersonale, iar dezvoltatorii de software medical să profite la maximum de timpul acordat de către medici pentru expunerea cerințelor legate de aplicație.

În al doilea rând, un aspect foarte important al unei aplicații medicale este încadrarea ei în normele juridice legate de confidențialitatea datelor unui pacient, fără a afecta funcționalitățile oferite de sistemul electronic. În acest caz, pentru a putea să respectăm cele două criterii menționate anterior, cel mai bine ar fi să modelăm un sistem de autentificare bazat pe roluri ce poate controla aplicația la diferite nivele, cum ar fi la nivelului unei pagini din aplicație, la nivelul sesiunii unui utilizator sau la nivelul unui singur pacient, aici doar personalul medical implicat având acces la datele acestuia. Totuși, o problemă ar putea apărea în cadrul urgențelor medicale, când nu va mai conta cine anume se ocupă de pacient, ci acordarea îngrijilor medicale cât mai repede, caz în care se poate face o excepție de la sistemul bazat pe roluri. Pentru a asigura consistența legală a acțiunilor întreprinse de un angajat putem să păstrăm fișiere, unde vom monitoriza activitatea fiecărui utilizator și ce anume, când și cum a modificat în baza de date a aplicației.

Un alt principiu important ce trebuie respectat atunci când dezvoltăm o aplicație pentru sistemul medical este acela al timpului petrecut în aplicație, deoarece acesta este o componentă critică a activității unui medic, iar din această cauza personalul medical va renunța rapid la o aplicație ce nu le economisește timpul. Pentru a putea să evaluăm această componentă este necesar să ținem cont de anumiți indicatori cum ar fi, cât timp este ocupat de operațiile blocante (transfer către baza de date, transferul informațiilor din alte module), cum este afișat progresul în aplicație cu privire la procentul datelor completate, dacă există șansă de recuperare a datelor în cazul unui transfer eșuat sau câte operații au loc în fundal și dacă utilizatorul este conștient de acestea. Rezolvarea acestor indicatori poate să îmbunătățească timpul petrecut de un utilizator al aplicației într-o sesiune.

Profilul majorității aplicațiilor medicale includ completarea datelor despre un pacient, cum ar fi analize, istoricul bolii, caracteristici ale anumitor măsurători ce s-au făcut la internare sau la consultație, dar și date personale ale pacientului ce vor ajunge la casa de asigurări medicale. Având în vedere faptul că în acest domeniu datele medicale sunt cele mai importante, putem să păstrăm un minim de câmpuri obligatorii ce trebuie completate în fiecare secțiune, dând posibilitatea utilizatorului să revină ulterior pentru a le completa. De exemplu, la internare se completează anumite date despre pacient, ce includ atât partea de date personale prin care poate fi identificat ca asigurat, cât și date despre starea sa de sănătate actuală (valori ale tensiunii arteriale, valori ale analizelor de sânge,etc), astfel nu putem condiția completarea câmpurilor de număr de asigurat social pentru a completa câmpurile legate de starea pacientului, întrucât datele medicale și îngrijirea pacientului au o prioritate mai mare față de partea de decontare a serviciilor medicale. Totodată, legat de validarea câmpurilor trebuie să existe o documentare destul de bine pusă la punct în ceea ce privește valorile posibile ale unui câmp, de exemplu tensiunea arterială poată să fie completată și cu alte valori în afara celor numerice.

Un principiu important de design al aplicațiilor de tip medical îl reprezintă modul de interacțiune între utilizatorii aplicației și cum anume colaborează ei în cadrul procesului de muncă. În scopul de a trata pacienții, fiecare angajat va avea rolul lui în clinica, însă resursele (datele despre pacient și modalitatea de tratarea) vor fi partajabile și de aceea în acest caz comunicarea va avea un puternic caracter asincron. De asemenea, așa cum am mai spus mediul în care lucrează medicii este unul foarte dinamic, în care aceștia sunt adesea întrerupți dintr-o activitate pentru a prelua altă sarcină mai urgentă și astfel este critic să îi lăsăm medicului posibilitatea de a completa datele la momente diferite de timp, fără a fi constrâns de a finaliza o sesiune în aplicație. De exemplu, un flux de lucru poate să fie modelat astfel, un angajat va programa pacienții pentru consultații sau analiza, apoi pacienții vor efectua analiza la un anumit laborator, unde un angajat de aici va completa rezultatele analizelor la un anumit moment de timp. Apoi, în altă zi sau chiar în aceeași zi medicul va verifica rezultatele analizelor în prezența pacientului și va întocmi un raport în acest caz și pacientul va fi informat de către doctor sau alt angajat al spitalului (de exemplu, asistent medical).

Alte aspecte critice ce ar fi bine să le luăm în considerare fac referire la organizarea datelor din punct de vedere fizic (baza de date) și cum sunt transferate datele între diferite standarde. Astfel, o parte importantă a unui sistem electronic medical îl reprezintă modul de organizare al bazei de date, întrucât avem de-a face cu un volum mare de date, ce trebuie organizate în mod eficient astfel încât să nu fie afectate (din punct de vedere al codului) de reglementări ale legislației și ale cerințelor în mediul de lucru din spital.Nu în ultimul rând, trebuie să acordăm atenție standardelor folosite pentru a putea asigura compatibilitatea datelor și fluxul acestora în aplicație. Pentru acest lucru trebuie să luăm în calcul că date diferite sunt reprezentate în formate diferite, dar aceste standarde trebuie integrate cu aplicația noastra pentru a asigura comunicare între diverse module, cum ar fi datele unui pacient ce sunt reprezentate într-un format (exemplu RxNorm) sau rapoartele referitoare la diagnosticul unui pacient (exemplu format ICD10).

3.3.2 Principii ce se aplică în cazul aplicațiilor medicale mobile

În ceea ce privește dezvoltarea de aplicații mobile pentru sistemul medical, se observă două abordări, una ce se referă la implementarea unei interfețe mobile independente de alt sistem, ce va rezolva o parte din sarcinile personalului medical și o alta ce se referă la adaptarea aplicațiilor desktop pentru domeniul medical la o platformă mobilă. Deși cele două abordări pot avea implicații diferite din punct de vedere al design-ului, al informațiilor prezente în aplicație, al proceselor modelate sau al modului de interacțiune cu utilizatorul, la bază se vor afla câteva principii comune de design ce vor face referire atât la caracteristicile unui dispozitiv mobil, cât și la mediul în care aplicația va fi folosită (domeniul medical).

Cei de la HIMSS (Health Information Management Systems Society) propun în câteva prezentări și articole, principii de design pentru aplicațiile mobile general valabile ce sunt totuși critice într-un sistem medical electronic dezvoltat pentru dispozitive mobile. Astfel, un principiu simplu de design, dar ce este foarte important într-o aplicație medicală este acela de simplitate, naturalețe și consistență a aplicației dezvoltate. Având în vedere caracteristicile mediului pentru care se dezvoltă aplicația (clinică sau spital), acesta nu va avea timp să studieze cu atenție aplicația și să învețe elemente noi, astfel este necesar să fie folosite elemente de design cunoscute, inspirate din viața reală, păstrând în același timp consistența elementelor vizuale ale interfeței la schimbarea paginilor din aplicație.

Având în vedere că sistemul medical electronic va opera cu multe informații, de o importanță foarte mare pentru desfășurarea fluxului de lucru al unui medic, dar că în același timp experiența utilizatorului în aplicație se va petrece în continuă mișcare și într-un timp foarte scurt, este important să implementăm metode de recuperare a datelor în caz de eroare în utilizarea aplicației. De asemenea, un aspect important în acest caz este de a asigura un feedback rapid acțiunilor întreprinse de medic în aplicație, pentru a asigura încrederea acestuia în corectitudinea aplicației. În final, aplicația trebuie să ii asigure utilizatorului control asupra acțiunilor făcute, dar să reducă din complexitatea cu care sunt accesate sarcinile, lucru care se poate face prin micșorarea numărului de pași și de gesturi necesare pentru a executa o sarcină și prin adăugare de scurtături pentru acțiunile importante.

Alte recomandări se referă la modul de prezentare a informației către utilizator astfel încât acesta să poată reacționa destul de repede și să înțeleagă în timp util ce anume trebuie să facă în aplicație. Pentru a realiza aceste lucruri, putem să ținem cont de mai multe aspcte, cum ar fi să încercăm să nu avem chiar atât de multe ferestre de dialog în aplicație pentru a nu întrerupe fluxul aplicației și a crea confuzie pentru utilizator. De asemenea, ar trebui să folosim fonturile și culorile diferite în mod corespunzător astfel încât să fie evidențiată funcția acelui element din interfață (de exemplu putem folosi culoarea roșie a textului pentru a sublinia urgențele medicale).

O ultimă problemă ce apare în cazul variantei mobile a unei aplicații, în mod particular pentru sistemul medical este aceea a păstrării datelor într-un loc sigur având în vederea dimensiunea datelor întrucât un spital poate trata foarte mulți pacienți de-a lungul timpului. În acest caz, dispozitivele mobile nu dispun de memorie foarte mare pentru a reține date pe termen lung și de aceea este nevoie să acordăm atenție implementării unui sistem de sincronizare a datelor către un server central cât mai eficient și care să fie în același timp și foarte sigur. În final, trebuie să avem în vedere implementarea unei sincronizări bilaterale, întrucât personalul medical va completa date, dar vor cere și informații despre un pacient din arhivă și să nu uităm să asigurăm mecanisme de recuperarea a datelor în cazul în care este pierdută conexiunea și de rezolvare a conflictelor de date întrucât este vorba de un sistem de date partajat.

3.4 Utilizabilitatea aplicațiilor în domeniul medical

3.4.1 Ce înseamnă utilizabilitate?

De-a lungul istoriei dezvoltării produselor software, indiferent de domeniul pentru care au fost făcute, o preocupare destul de mare a fost și aceea de a evalua calitatea lor din punct de vedere al scopului pentru care au fost create. Astfel, nu este suficient ca o aplicație software să îndeplinească strict cerințele de sistem, ci este nevoie și de o evaluare din punct de vedere a factorului uman întrucât un astfel de program va fi folosit tot de oameni într-un anumit mediu și într-un anumit context. Pentru a evalua calitatea unui produs software dezvoltat în cadrul mediului în care este folosit folosim un termen destul de întâlnit în ultima perioadă, și anume, utilizabilitatea. Conform standardului ISO 9241-11, utilizabilitatea este definită ca eficacitatea, eficiența și satisfacția cu care utilizatorii unui sistem software interacționează cu o aplicație în mediul specific pentru care aceasta a fost creată.

Prin urmare, definiția dată utilizabilității prin standardul ISO 9241-11 stabilește principiile după care poate fi evaluată corect o aplicație software, în contextul în care este utilizată și în același timp oferă suport pentru a măsura corect criteriile de evaluare stabilite, eficacitatea, eficiența și satisfacția. Astfel, utilizabilitatea nu se referă neapărat la respectarea și implementarea tuturor cerințelor aplicației în cadrul proiectului de dezvoltare software, ci se referă la contextul în care este utilizată (mediul utilizatorului), la sarcinile efective pe care acesta le va întreprinde în aplicație și la factorul uman, adică cum interacționează în cazul real utilizatorul cu aplicația. De asemenea, utilizabilitatea nu se rezumă doar la partea de design a interfeței, ce reprezintă doar un strat superficial al aplicației dezvoltate dacă aceasta nu are implementate funcționalitățile de bază sau acestea nu funcționează corect. Tocmai de aceea măsurarea utilizabilității unei aplicații poate detecta probleme de fond ale unui sistem software, ce țin de structura acestuia, modul în care comunică componentele între ele și pe ultimul loc va fi designul (de exemplu, chiar dacă o aplicație are o grafică impresionantă, cu multe animații, culori bine alese, dacă utilizatorii nu reușesc să ducă la bun sfârșit sarcinile ce vroiau să le execute prin intermediul aplicației aceștia nu vor mai folosi acea aplicație).

În contextul dezvoltării unei sistem electronic de tip medical, măsurarea utilizabilității sistemului poate fi un criteriu destul de important ce ajută la evaluarea corectă a aplicației.Având în vedere importanța caracteristicilor mediul (spitale, clinici, etc), ce este unul dinamic și în continuă schimbare, dar și a modului în care își execută sarcinile un medic (acesta este în permanență întrerupt, trebuie să fie atent la multe detalii din jurul său și astfel nu este dedicat în totalitate aplicației), proiectarea unei aplicații și implementarea unor sarcini specifice ei nu sunt suficiente, ci trebuie găsită o metodă prin care să evaluăm modul în care aceasta ajută munca unui angajat al personalului medical.

3.4.2 Elementele componente ale utilizabilității

Așa cum am spus în secțiunea anterioară, utilizabilitatea se referă la trei criterii prin care o aplicație ce are un nivel ridicat de interacționare cu utilizatorul poate fi evaluată corect, și anume eficacitate, eficiență și satisfacție. În primul rând, eficacitatea se referă la numărul de utilizatori ce reușesc să ducă la bun sfârșit sarcinile din aplicație într-un timp măsurat rezonabil. Metricile se pot referi la mai multe tipuri de măsurători cum ar fi numărul de sarcini sau obiective principale ce au fost atinse în timpul unei sesiuni în aplicație, numărul de sarcini executate într-o anumită unitate de timp sau chiar modul sau calea prin care au fost terminate anumite sarcini din aplicație. De exemplu, în cazul unei aplicații medicale poate un medic prescrie medicația unui pacient completând denumirile proprii în câmpurile text și nu folosește sugestiile date de aplicație, astfel medicamentul poate nu este găsit în sistem și nu poate fi procurat pentru pacient.

Un alt criteriu, și anume cel de eficiență se referă strict la măsurarea timpului în care sunt desfășurate și duse la bun sfârșit sarcinile din aplicația dezvoltată. Cu toate aceste, există două abordări din acest punct de vedere, și anume, există o metodă prin care timpul este măsurat în unitățile de măsură corespunzătoare (secunde, minute,etc) sau altă metodă prin care măsurăm timpul prin intermediul comparării cu execuții ale sarcinilor în alte aplicații software asemănătoare sau folosind cu totul alte metode existente. Această metodă este una foarte eficientă pentru măsurarea unei aplicații dezvoltată pentru sistemul medical, întrucât timpul este o componentă critică pentru personalul medical , date fiind caracteristicile mediului de lucru, iar principalul obiectiv la medicilor rămâne reducerea timpului de executare a anumitor sarcini prin implementarea acestor aplicații software.

În ultimul rând, satisfacția este o măsură a utilizabilității ce face referire în principal la factorul uman și cum percepe utilizatorul aplicația în desfășurarea sarcinilor zilnice. În contextul în care este dezvoltată o aplicație software pentru sistemul medical, factorul ce hotărăște folosirea aplicației în activitățile zilnice este personalul medical, întrucât părerea generală despre aplicație și impactul pe care aceasta îl are asupra utilizatorului direct va influența folosirea în continuare a ei. Așa cum s-a constat în urma dezvoltării anterioare de aplicații pentru sistemul medical, folosirea unui astfel de sistem electronic a fost puternic influențată de satisfacția resimțită de medici în utilizarea unei astfel de aplicații și a devenit un factor decisiv în continuarea folosirii ei.

3.4.3 Design centrat pe utilizator

Mai devreme, în secțiunile anterioare am vorbit despre importanța utilizabilității și cum o măsură bună a acesteia poate asigura succesul aplicației pe care vrem să o dezvoltăm. Desigur, există mai multe principii pe care putem să le respectăm pentru a atinge performanțe bune ale aplicației, dar în acest caz al aplicațiilor medical un element esențial îl reprezintă designul aplicației centrat pe utilizator. Acest principiu chiar a fost reglementat printr-un standard ISO, alături de cel al utilizabilității, ISO 9241-210:2010 ”Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems” (” ISO 9241-11:1998.”).

Pentru a respecta principiile de design centrat pe utilizator există o serie de elemente pe care trebuie să le luăm în considerare atunci când vrem să dezvoltăm interfața prin această metodă. Aceasta se aplică foarte bine pentru sistemele medicale întrucât aplicațiile pentru sistemul medical urmăresc ajutarea medicului în desfășurarea activităților zilnice. De exemplu, pentru un sistem medical trebuie să intervievăm cât mai mulți utilizatori pentru a afla atât sarcinile importante zilnice, cum ar fi consultație, prescripție de medicamente, de analize, dar și sarcinile mai mici ce duc la îndeplinirea acestora (de exemplu, alegerea unui medicament, a cantității necesare, a planului de tratament,etc). De asemenea, pentru sistemul medical trebuie să aflăm și mediul în care se desfășoară fiecare sarcină în parte cum ar fi, cabinetul medicului sau pe holurile unei clinici destul de aglomerate.

Un alt aspect important al aplicației centrate pe utilizator este modul în care acesta este implicat în interacțiunea cu aplicația. Pentru a putea găsi o metodă potrivită de implicare a utilizatorului, este important să analizăm cât de des va interacționa utilizatorul cu aplicația, cine anume din personalul medical va executa o anumită sarcină și ce complexitate trebuie adoptată în acest caz. În final, toate aceste informații pe care le vom colecta ne vor ajuta să propunem și să implementăm o interfață potrivită pentru utilizatorii țintă, în cazul nostru personalul medical. Pentru a putea apoi verifica corectitudinea sarcinilor din aplicația modelată de noi, putem să folosim următoarea metodă: stabilim anumite obiective pentru fiecare sarcină în parte, din punct de vedere al celor trei criterii de utilizabilitate descrise în secțiunea anterioară și în funcție de aceste obiective vom îmbunătăți designul sau nu.

Nu în ultimul rând, ar trebui să asigurăm corectitudinea designului centrat pe utilizator prin efectuarea de teste de utilizabilitate în mod iterativ, pe parcursul dezvoltării aplicației. Încă din primele stagii de dezvoltare putem să testăm aplicația pe un grup mic de utilizatori din domeniul medical pentru a putea vedea anumite erori de design si pentru a le putea corecta încă din faze incipiente dezvoltării. Toate aceste etape trebuie repetate până când obiectivele setate din punct de vedere al utilizabilității sunt îndeplinite.Un exemplu de metodologie de design centrat pe utilizator ar fi (NIST, 2010):

Fig 3. Exemplu de metodologie de dezvoltare centrată pe utilizator

3.5 Aplicații existente în domeniul medical

3.5.1 Aplicații desktop în domeniul medical

Una dintre cele mai populare companii ce dezvoltă aplicații medicale, în special pe partea medicală de tip ambulatoriu este eClinicalWorks, ce a implementat în prezent destul de multe aplicații medicale în foarte multe spitale de stat, dar și clinici particulare din Statele Unite ale Americii. În portofoliu lor se află destul de multe aplicații ce oferă soluții atât pentru clinici particulare cu un număr mai mic de pacienți, cât și soluții mobile ca eClinicalTouch pentru tabletă și eClinicalMobile pentru telefon. Datorită metodologiei de dezvoltare au reușit să implementeze produse software ce au grad mare de flexibilitatea și adaptabilitate la o gamă largă de specializări din domeniul medical. De asemenea, la capitolul utilizabilitate stau foarte bine întrucât au ales să se orienteze spre un design centrat pe utilizatori, reușind să dezvolte o interfață prin care poți accesa un pacient cu foarte puține clickuri și poți include rezultate de laborator ale analizelor foarte ușor.Pentru că pacienți sunt și ei uneori utilizatori ai sistemului, în funcție de sarcinile stabilite pentru acea aplicație medicală, a fost creat un sistem special pentru aceștia prin care își pot verifica decontările și facturile pentru spitalizare sau pot vedea rezultatele analizelor și programul consultațiilor viitoare.

La noi în țară a fost lansat de curând (aprilie 2014) un portal web numit ”Dosarul Electronic de Sănătate al Pacientului”, ce își propune să colecteze date de la pacienții din țară ce se prezintă la unitățile de îngrijire medicală pentru consultații, analize și tratament în scopul de a facilita aflarea istoricului bolii unui pacient, intervențiile la care acesta a fost supus sau medicația prescrisă de alți medici pentru acesta. Potrivit unui articol, acest sistem a fost testat până în luna aprilie și până la acel moment 50 de spitale au reușit să se conecteze cu succes la sistem, 3.000 de medici reușind să introducă în sistem 130.000 de dosare electronice (Oprea, 2014). Cu toate aceste cifre, comentariile neoficiale nu sunt cele mai bune, pacienții acuzând modul în care se face autentificarea în sistem, folosind codul numeric personal, ce este de multe ori public și astfel există riscul compromiterii securității datelor și a încrederii în sistem. De asemenea, pentru medicul ce va fi obligat să adauge pacientul în baza de date va fi destul de costisitor din punct de vedere al timpului, deoarece sunt multe informații de completat, cum ar fi date personale, istoricul bolii, prescripții, iar autentificarea unui pacient prezintă o soluție de securitate nu tocmai la îndemână. Din acest punct de vedere, medicul trebuie să listeze o matrice cu coduri de securitate, pe care apoi să le folosească pentru înscrierea unui pacient.

3.5.2 Aplicații mobile în domeniul medical

În cazul aplicațiilor mobile, atenția a fost distribuită mai mult către aplicații independente de sistemul electronic al unității de îngrijire medicală, în care este implementat, dar în același timp tendința dezvoltatorilor este de a integra aplicațiile mobile medicale în cadrul sistemelor electronice prezente în spitale. Toate aceste tendințe sunt susținute și de dorința majorității medicilor de a folosi smartphone-ul personal sau tableta pentru a accesa mai usor datele din sistemul electronic al unității medicale în care lucreează.

Un prim exemplu de aplicație mobile independentă de mediul de lucru al medicului ar fi Eye Emergency Manual, aplicație folosită pentru a detecta urgențele oftalmologice ale pacienților ajunși la urgențe, atunci când nu există un medic oftalmolog prin preajmă și este necesară stabilirea gravității stării oftalmologice a unui pacient. Printre funcționalități, aplicația prezintă un meniu simplu prin care sunt evidențiate principalele urgențe prin intermediul unor poze sugestive, apoi în următorul nivel al aplicației în funcție de starea aleasă sunt prezentate posibile cauze ale acelei răni și tratamente ce trebuie prescrise, cele urgente fiind marcate cu un steag roșu.

O aplicație mobilă implementată cu succes și integrată în sistemul electronic existent este aceea a unui spital din Corea, numită M-UMIS, ce a fost implementată atât pentru dispozitivele mobile cu sistem de operare Android, cât și pentru cele cu iOS. Aceștia au dezvoltat un sistem mobil cu resurse proprii, folosind foarte puțin resursele marilor companii dezvoltatoare de software medical, reușind să realizeze o aplicație ce folosește cu succes autentificarea pe bază de roluri, unde utilizatorii au la dispoziție în ecranul principal sarcinile importante pe care le desfășoară în fiecare zi, cum ar fi pacienții pe care îi au în grijă sau programările din acea zi pentru consultații. De asemenea, în informațiile fiecărui pacient sunt prevăzute și analize efectuate de acesta în spital, poze cu anumite leziuni ce sunt păstrate în baza de date sau comenzi vocale pe care un medic le poate înregistra atunci când nu are posibilitatea de a scrie în aplicație.

4. Structura aplicației

4.1 Implementarea F.O.C.G. în aplicație

F.O.C.G. reprezintă prescurtarea de la Foaia de Observație Clinică Generală, ce este folosită în România pentru a ține evidența pacienților dintr-un spital, fiind trecute date vitale pentru medicii cum ar fi istoricul bolii pacientului, antecendentele acestuia, date despre starea de sănătate actuală, dar și date personale ale acestuia. Astfel, acest document are două roluri, în primul rând prezintă informații importante despre un pacient medicului pentru ca acesta să poată să urmărească corespunzător starea de sănătate, dar reprezintă și un document oficial ce servește ca dovadă pentru deconturile oficiale la Casa Națională de Asigurări de Sănătate și pentru monitorizarea activității instituțiilor publice medicale și ale personalului acestor instituții.

Cu toate că aceste documente ar trebui să servească atât interesele statului, cât și activitățile medicilor din instituțiile medicale de stat, formatul oficial existent, ce este anexat legii este mult prea rigid, întrucât nu poate fi modificat sau particularizat și în același timp nu răspunde nevoilor de informație a unor medici din anumite specializări. De exemplu, medicii ce sunt specializați pe oncologie ar avea nevoie de un spațiu mai mare dedicat tratamentului și schemelor de tratament pentru a putea include detalii ale tratării pacienților vitale în desfășurarea activității lor. Tocmai din această cauză, de multe ori angajații din domeniul medical folosesc un format din acest document particularizat, în sensul că sunt dedicate spații mult mai mari secțiunilor de interes pentru specialitate și pentru diagnosticarea corectă a unui pacient. Totuși această practică duce la crearea unei redundanțe în completarea datelor unui pacient, întrucât pentru formatul oficial vor trebui completate alte tipuri de fișe.

În acest caz, o modelare a problemei din punct de vedere al arhitecturii software s-ar putea face utilizând arhitectura ”Model-view-controller (MVC)”, ce poate astfel să rezolve problema prezentată mai sus prin remodelarea informației primite și transpunerea ei în diverse forme. De exemplu, partea de model reprezintă componenta ce va organiza datele din aplicația și va ține cont în același timp de starea în care se află aceasta, iar partea de view va reprezenta forma de reprezentare a informației din model către utilizator și interacțiunea lui cu aplicația. În cazul particular prezentat mai sus această arhitectură ar fi potrivită pentru implementare întrucât va reduce din redundanța datelor și din necesitatea de a completa de mai multe ori aceeași informație de mână.

În mod particular, aplicația de interfațare medic-pacient pe tabletă ”EHR Chirurgie Cardiovasculară”, modelează procesul de completare a datelor unui pacient în fișa de observație clinică generală, de redarea a acestor date pentru un pacient și în același timp exportarea datelor în formatul cerut de lege. Conform unui studiu realizat în Statele Unite ale Americii, a rezultat că personalul medical implicat în chirurgia cardio-vasculară au cel mai ridicat număr de ore lucrate pe săptămână, astfel realizarea unei aplicații cu grad de utilizabilitate mare și care să aibă un grad ridicat de eficiență din punct de vedere la timpului este foarte important (Leigh, Tancredi, Jerant, & Kravitz, 2011). Însă nu doar aspectul legat de timp și de birocrație este principala preocupare în dezvoltarea acestei aplicații pentru specialitatea medicală de chirurgie cardio-vasculară, dar și modul de reprezentare a informațiilor despre un pacient și a detaliilor legate de starea sa de sănătate astfel încât aplicația să vină în ajutorul medicului pentru a diagnostica și trata corect un pacient.

În primul rând, aplicația EHR este dezvoltată pentru a putea asigura redarea informațiilor necesare atunci când un medic sau un alt angajat din personalul medical nu se află într-un cabinet, ci fie efectuează vizitele zilnice în saloane pentru a vedea starea pacienților sau se confruntă cu o urgență medicală. Din situații reale aflăm că unii medici pot afla informații importante despre un pacient, de exemplu antecedente de boli cardio-vasculare în familie sau prezența unei boli de nutriție, cum e diabetul de tip II, informații ce trebuie completate apoi în fișa pacientului pentru a ține cont de ele la tratarea acestuia. Alegerea dispozitivului de tip tabletă ca suport pentru dezvoltarea aplicației vine să rezolve această problemă și să asigure medicului suficientă mobilitate și flexibilitatea în completarea datelor medicale legate de un pacient, dar și să poată afla destul de ușor și rapid informații deja completate despre acel pacient.

În al doilea rând, când vine vorba de a dezvolta o aplicație mobilă posibilitățile sunt infinit mai mari față de formatul actual, de fișe pe hârtie întrucât putem implementa diferite metode de completare și redare a informațiilor unui pacient în funcție de cerințele de sistem ale personalului medical, dar și în funcție de sarcinile efectuate și modul de interacțiune între ele. De asemenea, pentru a micșora timpul în care este efectuată o sarcină este important să îmbunătățim modul de completare a câmpurilor, astfel pentru cele ce au intrări predefinite sufiecient de puține putem include liste de selecție sau putem folosi un sistem de autocompletare a textului pe baza sugestiilor introduse în aplicație și pe baza primelor litere tastate în câmpul text. La toate acestea se adaugă și o funcționalitatea foarte utilă pentru medici, un sistem de interfață utilizator multimodală, în sensul că pentru un anumit diagnostic există și posibilitatea de a vedea grafic o imagine vectorizată a părții anatomice implicate în diagnostic și de a completa datele din altă perspectivă.

În ultimul rând, există alte aspecte ce țin de dezvoltarea unei aplicații si au fost luate în considerare pentru implementarea funcționalităților au fost lucruri ce țin de dezvoltarea oricărei aplicații, cum ar fi modul de organizare a datelor despre pacienți sau modul de organizare a datelor necesare în aplicație și cum sunt ele salvate pentru a fi redate mai departe în aplicație. În principiu, dispozitivele mobile cu sistem de operare Android oferă suport pentru baze de date cu funcționalități reduse, cum este SQLite, date fiind dimensiunile memoriei și faptul că nu putem gestiona o cantitate mare de informații. Totuși, pentru un volum de date mai mare, mai ales în ceea ce privesc datele despre pacienți acestea pot fi depozitate pe un server central, cel mai bine cu implementare proprie ce asigură astfel un grad mai mare de securitate din punct de vedere al locației. De asemenea, pentru implementarea aplicației s-au urmărit și alte aspecte cum ar fi adaptarea elementelor grafice ale interfeței pentru dispozitive de tip tabletă, urmărind așezarea în pagină a informației, mărimea imaginilor și a simbolurilor grafice pentru a fi accesibile cu modul de interacțiune(degetele) și alegerea potrivită a gesturilor pentru a nu îngreuna experiența utilizatorului. Singurele gesturi folosite au fost cele de apăsare simplă, apăsare lungă pe un element pentru eliminarea lui dintr-o listă (gest destul de cunoscut printre utilizatorii de Android) sau swipe, un gest destul de popular și prezent în magazinul de aplicații Android.

4.2 Arhitectura sistemului

4.2.1 Meniul principal

În urma studierii cerințelor medicilor de aici din sistemul medical românesc, dar și prin analiza structurii aplicațiilor de acest tip existente în alte instituții medicale din lume, am observat tendința medicilor de a avea toate funcționalitățile aplicației în meniul principal al aplicației. De aceea, am hotărât să le grupez într-o vedere de tip panou (GridView pentru Android) în care am grupat următoarele activități pentru utilizatorul aplicației, adăugarea unui pacient nou, căutarea unui pacient existent în sistem, urgențele medicale în sensul pacienților ce au nevoie de îngrijire imediată și generare de documente pentru a putea fi printate și îndosariate în format fizic.

Prima opțiune de meniu aleasă a fost cea de adăugare pacient, întrucât aceasta cea mai frecventă sarcină ce trebuie îndeplinită în aplicație, iar celelalte sarcini depind de accesarea anterioară a acestei funcționalități ce facilitează înregistrarea unui pacient în aplicație. Mai departe, sunt transpuse în aplicație elementele fișei de observație clinică generală, fiecare secțiune având un ecran separat și putând naviga printre acestea fie prin în ordinea din fișele în format fizic sau accesând capitolele dorite. De asemenea, același format de reprezentare a fișei este afișat atunci când sunt editate datele unui pacient în vederea modificării acestora. Voi detalia în secțiunea următoare modul de realizare a acestor două funcționalități.

Tot din meniul principal, medicul are opțiunea de căutare a unui pacient existent, înregistrat anterior în aplicație și apoi să îi acceseze de aici informațiile referitoare la starea de sănătate și/sau motivele internării în unitatea de îngrijire medicală. Pentru a facilita regăsirea unui pacient în timpul cel mai scurt am implementat un sistem de căutare interactiv, ce își adaptează rezultatele căutării pe măsură ce utilizatorul introduce numele acestui în câmpul text folosit pentru căutare. Astfel, sunt filtrate persoanele înscrise în aplicație ce au în componența numelui șirurile tastate de medic în câmpul text pentru căutare. De asemenea, pacienții sunt ordonați în ordinea descrescătoare a înregistrării lor în aplicație, astfel încât utilizatorul să poată regăsi în primele rezultate pacienții înscriși recent pentru care există o șansă mai mare de modificare a datelor acestora.

Nu în ultimul rând, există în meniul principal opțiunea de generare documente, de unde utilizatorul, în cazul nostru un angajat din unitatea medicală unde este implementată aplicația, poate să aleagă să genereze pe rând câte un document în format pdf ce poate fi mai departe transmis pentru printare, fiind astfel disponibil în format fizic. Bineînțeles că în acest caz funcționalitățile aplicației nu pot fi transpuse într-un document pdf, dar scopul acestuia este de a rezolva problema completării documentelor oficiale ce trebuie transmise către Casa Națională de Asigurări de Sănătate aplicând astfel avantajele unei arhitecturi de tip Model-view-controller.

O ultimă opțiune de meniu, dar destul de importantă ar fi cea de urgențe medicale, ce reprezintă o extensie a căutării de pacienți întrucât prezintă aceleași funcționalități de editare, cu excepția faptului că aceștia sunt oameni ce au nevoie de îngrijire de urgență și existența unui astfel de meniu face ca ei să nu se piardă printre ceilalți pacienți. Medicul este cel ce poate să modifice starea de urgență a unui pacient prin bifarea acestei opțiuni din meniul de căutare de pacienți. De asemenea, tot el este cel ce poate să declare urgența rezolvată și poate să scoată un pacient din această listă.În continuare voi prezenta o schema a activităților principale din aplicație organizate în mod ierarhic, împreună cu legăturile dintre acestea.

Fig 4, Diagrama activităților și interacțiunea între ele

4.2.2 Adăugarea și editarea unui pacient

Meniul de adăugare pacient reprezintă principalele funcționalități ale aplicației, întrucât aici sunt reprezentate modalitățile de completare a datelor despre acesta, bazate pe modelul anterior al foii de observație clinică generală. Celelalte funcționalități prezente în aplicație și regăsite în meniul principal au la bază această activitate. Pe lângă informațiile necesare internării ce sunt cerute într-un asemenea document, aplicația își dorește să implementeze un instrument ce poate să ajute medicul în diagnosticarea și tratarea pacienților prin prezentarea informațiilor într-o manieră interactivă, cu elemente vizuale grafice ajutătoare ce vor reduce timpul petrecut în recunoașterea și stabilirea corectă a diagnosticului unui pacient.

Așadar, pentru ca trecerea de la formatul fizic la o aplicație mobilă implementată pe un dispozitiv de tip tabletă să nu fie bruscă și să solicite prea multă atenție și timp de instruire din partea personalului din sistemul medical, am ales să respect în linii mari ordinea secțiunilor din foaia de observație clinică, adăugând funcționalități noi cu ajutorul instrumentelor puse la dispoziție de grupul de dezvoltatori de la Android. În acest scop, aplicația cuprinde șapte secțiuni, ce se regăsesc normal și pe foaia de observație din formatul actual, prin care utilizatorul are mai multe modalități de navigare, cum ar fi prin gestul de swipe dintre paginile componente se poate naviga incremental prin secțiunile implementate sau prin accesarea segmentată din cadrul meniului lateral de tip ”sertar”, specific versiunilor curente de aplicații Android. Prin aceste două metode am urmărit două tipuri de flux de sarcini de lucru, unul în care utilizatorul dorește să completeze toate secțiunile din acest meniu și astfel vrea să păstreze o ordine a parcurgerii și unul în care un medic fie completează ”pe sărite” anumite secțiune, fie vrea să modifice un simptom sau o caracteristică anume dintr-un submeniu.

Fig 5, Schema fragmentelor din activitatea principală, Foaia de Observație Clinică Generală

De asemenea, secțiunea de anamneză cuprinde alte cinci secțiuni mai mici, ce sunt accesibile dintr-un submeniu al secțiunii respective din meniul de navigare din stânga. Cu toate acestea, în varianta de flux de lucru continuu prin intermediul gestului de swipe, aceste secțiuni componente sunt incluse incremental. Ca modalități de reprezentare a informației, fiecare pagină cuprinde elementele secțiunii pe care o reprezintă, având predominant un câmp text editabil de unde se pot adăuga elemente corespunzătoare secțiunii ce vor apărea mai apoi într-o listă ce poate oferi o vedere de ansamblu a elementelor adăugate. De asemenea, pentru câmpurile text, în măsura în care există momentan date disponibile în baza de date a aplicației, la completarea datelor apar sugestii legate de opțiunile ce se pot pune în acel câmp în funcție de șirul de caractere introdus, iar pentru listele de caracteristici (motivele internării, antecedente heredocolaterale, antecedente personale, comportmente,etc) există posibilitatea de a șterge un element prin click lung.

Alte detalii de implementare întâlnite ar fi faptul că sunt folosite ferestre de dialog pentru completarea informațiilor suplimentare legate de starea pacientului și pentru ca medicul să aibă posibilitatea de adăugare a unor detalii fără ca aplicația să își schimbe semnificatic stările. De asemenea, pentru puține opțiuni de completare (trei, patru) ce nu au multe variații de terminologie în lumea medicală sunt folosite liste de selecție pentru a alege mai ușor o caracteristică, fără a fi nevoie de utilizarea tastaturii în acest caz.

Din punct de vedere al salvării datelor, mecanismul este următorul, utilizatorul aplicației va iniția o sesiune nouă de adăugare a unui pacient, timp în care datele completate în acea sesiune vor fi salvate automat pe măsura completării ca aparținând pacientului respectiv. Doar atunci când medicul va părăsi acest meniu sau va apăsa din această activitate butonul de pacient nou, atunci va fi deschisă o sesiune nouă pentru ca să fie completate date diferite pentru altcineva. De asemenea, aplicația oferă posibilitatea de consultare a datelor deja editate și de modificare a lor prin intermediul aceleași interfețe pentru a păstra consistența aplicației și pentru a nu crea un nou submeniu ce poate să complice fluxul de lucru al aplicației.

4.2.3 Modalități de utilizare a aplicației

O problemă ce a fost semnalată în cazul sistemelor electronice medicale a fost folosirea necorespunzătoare a aplicațiilor, acest lucru datorându-se fluxurilor de sarcini mult prea complicate și neglijenței dezvoltatorilor de asemenea aplicații software, ce nu au controlat corespunzător comunicarea între elementele componente ale aplicației. Astfel, în domeniul medical, unde informațiile despre un pacient sunt critice pentru diagnosticarea și tratarea acestuia, o utilizare greșită a aplicației poate avea consecințe grave asupra activității personalului medical.

În acest caz, am încercat să modelez un ciclu de lucru în aplicație fluid, fără prea multe întreruperi ce pot cauza erori ale sistemului electronic medical și păstrând o adâncime mică în organizarea ierarhică a meniurilor, astfel dezvoltând funcționalitățile în lățime. Astfel, principalele activități ale utilizatorului se vor desfășura în activitatea Foaie de Observație Clinică Generală din aplicație, unde sunt prezente principalele funcționalități ale aplicației. Accesând acest meniu, medicul va avea la dispoziție în mod secvențial paginile componente prin care poate completa sau vizualiza starea și datele unui pacient, neavând alte întreruperi sau schimbări de context ce pot activa alte opțiuni din aplicație. De asemenea, o sesiune în acest meniu este rezervată strict unui pacient pentru a nu crea confuzie utilizatorului și pentru a ne asigura că datele completate în aplicație sunt cele corecte pentru pacientul ales.

Așa cum este recomandat în dezvoltarea de aplicații Android, dar și în studiile făcute de cei de la Nielsen Norman Group, unde s-a constatat că utilizatorii de dispozitive mobile din ziua de astăzi au tendința de a căuta informațiile în aplicații și nu au mult timp de petrecut aici întrucât în cazul real ei sunt în mișcare, execută și alte sarcini în paralel, am încercat să introduc în aplicație un sistem simple de căutare dar care să ii ofere utilizatorului control asupra a ceea ce caută. Mai mult, la afișarea listei de rezultate relevante, medicul poate alege să vizualizeze datele pacientului respectiv prin accesarea lui, interfața fiind aceeași ca aceea de la adăugare pacient nou, nefiind nevoit să învețe alte gesturi și sarcini noi în aplicație. De asemenea, după închiderea activității de editare, datele modificate sunt salvate automat, iar activitate revine la starea anterioară, adică în lista de căutare în care se afla medicul.

4.3 Detalii de implementare folosind Android SDK

4.3.1 Navigation Drawer

Acest instrument de interfață grafică propus de dezvoltatorii Android are rolul de a crea un meniu interactiv pentru utilizatori, care să nu ocupe spațiu inutil din ecranul aplicației, dar să fie la îndemână atunci când este nevoie să fie accesată o opțiune din meniu. Această practică s-a răspândit destul de mult printre dezvoltatorii de aplicații, iar utilizatorii au recepționat destul de bine folosirea acestui mod de organizare a informațiilor, prin urmare este recomandat să folosim un astfel de instrument în dezvoltarea aplicației noastre.

Pentru a putea implementa această facilitate de design, dezvoltatorii din comunitatea Android recomandă să includem în această secțiune funcționalitățile principale oferite în aplicație sau în activitatea în care sunt create. Forma de reprezentare a datelor într-un astfel de meniu se recomandă a fi sub formă de listă, unde un element conține o parte text, ce descrie pe scurt rolul acestuia și eventual o imagine reprezentativă de tip icoană. Pentru a implementa fluxul de date descris mai sus, am ales să reprezint lista de navigare sub formă de listă expandabilă Expandable List View ce este derivată din lista simplă denumită ListView.

În cazul în care avem de reprezentat mai multe elemente ce vor avea același format de design, dar având conținut diferit este recomandat să folosim o vedere de tip listă, unde prin intermediul unui fișier .xml putem să stabilim așezarea în pagină a componentelor unui element al listei, stilul respectiv replicându-se către toate elementele listei, chiar și atunci când aceasta este construită dinamic. Având în vedere că secțiunile din foaia de observație clinică generală a pacientului conțin și secțiuni mai mici componente, ocupând mai mult spațiu față de celelalte secțiuni am ales să implementez pentru reprezentarea meniului Expandable List View, unde submeniurile se expandează doar la apăsarea meniului ce le include.

Fig 6, Apariția meniului sertat în stânga ecranului împreună cu lista expandabilă

Așa cum spuneam mai devreme, modul de dezvoltare al aplicațiilor Android se bazează pe arhitectura Model-view-controller, astfel că pentru a implementa Expandable List View, avem de făcut următoarele: vom crea în interfața grafică a activității Android(fișierul xml corespunzător) elementul de tip Expandable List View și îi vom seta atributele de descriere a poziției și a stilului(culori, font-uri), apoi vom implementa o interfață de tip BaseExpandableListAdapter ce va gestiona conținutul listei expandabile și conține metode de redare a numărului de elemente din listă, modul de afișare și gestionare atât a elementelor de tip grup, cât și a celor de tip copil(submeniurile).

Folosirea instrumentului Navigation Drawer este dependentă de prezența altui instrument de dezvoltare Android în aplicație, și anume ActionBar, ce a fost introdus începând cu versiunea Android 3.0. Acest element de află poziționat în partea de sus a activităților și are rolul de a deține controlul unor acțiuni importante pentru aplicație, ce ar fi bine să fie accesate imediat, cum ar fi căutarea, setările, dar și elemente de control al fluxului de lucru, ce includ numele secțiunii din aplicația în care ne aflăm sau sigla aplicației noastre. Din aceste considerente, navigarea în meniul aplicației, unde găsim principalele funcționalități a fost inclusă în acest element, printr-un simbol unic folosit în toate aplicațiile, și anume o imagine cu trei linii orizontale ce va reprezenta modalitatea de control a apariției meniului de tip Navigation Drawer. Desigur, în bara de acțiuni am ales să includ funcționalități ce sunt frecvente în această activitate, cum ar fi buton de adăugare pacient nou sau funcționalități legate de starea aplicației, incluzând titlul fiecărei pagini în care se află utilizatorul pentru a-i oferi acestuia control asupra aplicației.

4.3.2 Swipe Views

Alegerea acestui mod de implementare a tranzițiilor între mai multe pagini din aplicația medicală Android dezvoltată a fost motivată de faptul că aceste pagini prezintă același nivel în ierarhia activităților și în acest caz Swipe Views este chiar recomandarea de șablon de design al platformei de dezvoltatori Android. O alternativă des folosită pâna acum la acest tip de tranziție era folosirea unor butoane de navigare înainte și înapoi, care poate ocupau o mare parte din ecran și nu ofereau o experiență diferită în comparație cu o aplicație desktop.

Întrucât ecranul tactil oferă mult mai multe posibilități față de un calculcator personal, unde principalele gesturi din aplicație sunt realizate cu ajutorul mouse-ului și al tastaturii, este recomandat să folosim cât mai multe gesturi pentru controlul aplicației în detrimentul unor butoane fizice ce pot apărea pe ecranul tabletei și pot să ocupe spațiu util. Cu toate acestea gesturile alese în aplicație trebuie să se potrivească contextului pentru care sunt folosite și cel mai important să fie naturale, eventual inspirate din acțiunile clasice pe care un om le face cu mâna. De exemplu, pentru a acționa un buton de pe ecran sau un alt element de interfață grafică, apăsarea cu degetul pe zona acelui buton reprezintă astăzi gestul cel mai natural pentru utilizatorii de dispozitive mobile, evident cât timp acel buton ocupă aproximativ 44 de pixeli(așa cum am menționat în capitolul 2) pentru ca orice utilizator să poată utiliza degetul cel mare pentru această acțiune.

Fig 7, Modul de realizare a gestului de swipe între paginile aplicației

Pentru tranziția între două pagini diferite ale sistemului de Swipe Views, utilizatorii vor trebui să folosească un gest cunoscut atât pentru dispozitivele mobile, cât și din viața de zi cu zi, gestul de swipe fiind inspirat din gestul prin care răsfoim o carte sau o revistă. Pentru a implementa acest lucru în aplicația medicală, am creat mai întâi câte un fragment pentru fiecare pagină din această activitate, de completare și vizualizare a foii de observație clinică generală. Mai devreme, instrumentul Naviagtion Drawer conținea în partea de interfață grafică descrisă de fișierul xml corecpunzător activității, o parte de conținut a paginii în afara meniuluii din dreapta. Pentru a putea folosi Swipe Views, elementul de interfață grafică inclus în fișierul activity_foaie_observatie.xml corespunzător este android.support.v4.view.ViewPager, unde sunt setate atributele de vizualizare a unei singure pagini.

Așa cum am spus și în secțiunea anterioară, platforma Android respectă arhitectura Model-view-controller, deci pentru a putea controla modul de redare și ordinea paginilor în cadrul instrumentului Swipe View trebuie să implementăm un adaptor pentru acest lucru. Astfel, pentru Swipe Views avem la dispoziție două tipuri de interfețe de tip Adapter, pe care putem să le implementăm, și anume FragmentPagerAdapter, ce se pretează pentru un număr mic și cunoscut de pagini, fără posibilitatea de extindere pe viitor, și FragmentStatePagerAdapter, ce este folosit atunci când nu numărul de pagini este dinamic și există o posibilitate mare de schimbare pe viitor. Astfel, am ales pentru implementare actuală FragmentStatePagerAdapter, întrucât oferă un control mai bun al memoriei telefonului sau tabletei prin faptul că distruge fragmentele pe parcursul navigării spre alte pagini, minimizând astfel consumul de memorie al dispozitivului.

Adaptorul implementat în aplicație, numit PageSliderAdapter, conține implementarea mai multor metode necesare pentru controlul navigării între fragmentele componente, cum ar fi getCount(), ce redă numărul de fragmente din acel moment sau getItem(int position), ce returnează un obiect de tip Fragment, corespunzător poziției iterative din implementarea Swipe Views. De asemenea, obiectelor de tip Fragment li se pot atașa argumente suplimentare în mod particular printr-un obiect de tip Bundle, folosit în cazul aplicației pentru a putea diferenția modul de complatare a unui pacient nou sau modul de editare a unui pacient existent, transmițând și identificatorul pacientului prin această metodă.

4.3.3 Android SQLite Database

Întrucât aplicația ”EHR Chirurgie Cardiovasculară” lucreează cu o cantitate mare de date de tip text, iar pentru un singur pacient trebuie rețiunte nu mai puțin de zece tipuri de informații în ceea ce privește starea lui de sănătate. În acest caz, a trebuit să caut o soluție de organizare a acestor date, chiar și pe partea locală a aplicației pentru a putea realiza funcționalitățile de editare într-un mod coerent, dar care să se poată adapta pentru o viitoare soluție a unui server central pentru un volum mare de date.

Astfel dezvoltatorii Android propun mai multe metode prin care putem păstra datele aplicației pe care o dezvoltăm, în funcție de mărimea datelor, complexitatea legăturilor dintre ele și în funcție de disponibilitatea lor (Content Provider, Shared Preferences, Internal Storage, External Storage,etx). Pentru a păstra datele ce sunt folosite doar într-o singură aplicație ce nu comunică cu alte aplicații instalate pe un dispozitiv Android, este recomandat să folosim o baza de date de tip SQLite întrucât sistemul de operare Android oferă suport pentru toate funcționalitățile acesteia.De asemenea, alegerea acestui tip de bază de date pentru dimensiunile unei aplicației Android este cea mai bună întrucât deși oferă funcționalități reduse față de o bază de date cunoscută, este parte integrantă a procesului aplicației și nu consumă resursele dispozitivului.

Deși nu sunt impuse anumite limitări ce țin de consistența datelor și evitarea redundațelor ce țin de depozitarea datelor în SQLite, este recomandat să folosim o structură de bază de date ce respectă forma normală și mai ales se încurajează folosirea atributului autoincremenet pentru cheia unică a unei intrări dintr-o tabelă. Pentru a putea crea baza de date am folosit o subclasă a SQLiteOpenHelper, ce conține metode de creare a bazei de date dorite, a tabelelor și de actualizare a datelor. De asemenea, odată creată baza de date se pot efectua operațiunile obișnuite pe o bază de date cum ar fi creare, selectare, actualizare și ștergere prin intermediul obiectului de tip SQLiteDatabase. Astfel, se poate face o cerere cătra baza de date folosind SQLiteQueryBuilder, iar rezultatele obținute pot fi parcurse utilizând obiectul de tip Cursor, ce este întors ca urmare a executării cererii de tip SQL.

Pentru a modela datele din aplicație am folosit o schemă de organizare a datelor trunchiată, folosind o tabelă principală unde sunt înregistrate datele personale de bază ale pacientului, cum ar fi nume, prenume, cod numeric personal și alte tabele adiacente, în jurul tabelei pacientului ce vor ține informații despre o anumită caracteristică a foii de observație clinică. Așa cum am spus în capitolul anterior, una din recomandările făcute în cazul dezvoltării unei aplicații medicale electronice este de a crea o structură de bază de date flexibilă, ce poate fi modificată ușor fără schimbări majore de structură și de implementare. În acesr caz, oricând se poate adăuga un tabel nou ce va conține datele unei rubrici noi din foaia de observație clincă generală, fără a afecta tabelele existente.

4.3.4 Autocomplete TextView

Pe parcursul studierii cerințelor pentru aplicație electronică medicală dezvoltată, dar și pe parcursul implementării interfeței grafice pentru dispozitivele de tip tabletă am realizat faptul că multe sarcini ce sunt executate în aplicației au nevoie pe lângă funcționalități de grafică și conținut adaptabil, și de câmpuri text ce pot fi editate. Cu toate că vrem să acordăm medicului libertatea deplină în aplicație pentru ca acesta să aibă sentimentul că se află în control, datele ce sunt furnizate din aplicație sunt de importanță vitală pentru tratarea unui pacient și astfel trebuie să asigurăm mecanisme de protejare a unei introduceri greșite de text. O altă problemă ce apare în general la aplicațiile electronice din domeniul medical este faptul că, la un moment dat, utilizatorul aplicației este nevoit să folosească mult prea mult introducerea textului de la tastatură, fără a avea alte facilități în aplicație.

Pentru a rezolva problemele enumerate mai sus, am hotărât să folosesc pentru unele câmpuri de tip text un sistem de sugestii, ce poate ajuta în același timp atât la corectarea erorilor de complatare a unor date , încă din faze incipiente ale fluxului de lucru, dar și la reducerea timpului de completare prin evitarea utilizării excesive a tastaturii. Un instrument de dezvoltare Android ce poate oferi toate aceste avantaje, inclusiv evitarea unor ferestre suplimentare cu rezultate în aplicație ce pot solicita prea mult atenția utilizatorului este AutoCompleteTextView, o clasă derivată din EditText, instrumentul clasic folosit pentru editarea unor câmpuri de tip text în dezvoltarea Android.

Așadar, pentru implementarea Autocomplete Text View avem nevoie să creem în primul rând un obiect în interfața grafică pentru a reprezenta modul de afișare și detaliile de poziționare a câmpului cu sugestii. După reprezentarea în fișierul xml asignat interfeței grafice, vom implementa modul de redare al conținutului, care conform arhitecturii Model-view-controller, se va face folosind un adaptor. Acest adaptor, de tip ArrayAdapter, va fi implementat, stabilindu-se pentru acesta modul de afișare al elementelor sugerate (un fișier xml descriptiv) și conținutul ce va afișat, care în cazul nostru va fi legat la o bază de date SQLite creată special pentru completarea de sugestii.

Un alt aspect legat de implementarea corectă ce va duce la un grad de utilizabilitate mai mare a aplicației este legat de tipul conținutului unui câmp text. Cum tastatura virtuală aflată pe ecranul unui dispozitiv de tip mobil oferă o mulțime de posibilități de completare ceea ce duce la un timp mai mare de alegere a conținutului corect, dezvoltatorii Android oferă posibilitatea personalizării tipului de tastatură afișat în funcție de conținutul câmpului text. Astfel, pentru câmpurile text ce pot fi editate am folosit următoarele tipuri de conținut oferite de obiectul de tip EditText: number, pentru câmpurile de introducere ale unor valori numerice cum ar fi vârstă, cod numeric personal sau valori ale tensiunii arteriale, textCapSentences, pentru câmpurile de introducere date personale ce au un caracter oficial și trebuie să înceapă cu literă mare și text, pentru câmpurile text normale.

Fig 8, Modalitatea de realizare a Autocomplete Edit Text

4.4 Posibile îmbunătățiri

Desigur că se pot aduce multe îmbunătățiri unei aplicați aflate în acest stadiu de dezvoltare, însă este foarte important ca acestea să nu complice inutil fluxul de sarcini al unui utilizator în aplicație, ci dimpotrivă să îmbunătățească această experiență pentru a crește gradul de utilizabilitate. În momentul actual, o parte importantă a aplicației ce poate fi îmbunătățită este aceea a existenței mai multor date pentru sistemul de completare bazat pe sugestii, potrivite pentru specializarea d chirurgie cardio-vasculară. De asemenea, se află în lucru o baza de date cât mai completă si cât mai detaliată a unui arbore de diagnostice, ce pot oferi medicului detalii cât mai multe despre boala pe care o caută. Momentan este implementat un mecanism de căutare a unui diagnostic, dar pe viitor se poate îmbunătăți prin completarea a cât mai multor atribute după care se va face căutarea, nu doar expresii regulate pentru a putea dovedi utilitatea acestei căutări.

Pentru a putea îmbunătăți și modul de redare a unor interfețe multimodale astfel încât fiecare medic să își poată alege modalitatea cea mai potrivită pentru nevoile lui de a vizualiza și completa datele clinice ale unui pacient, este necesar ca odată cu baza de date a diagnosticelor să fie incluse imagini vectorizate cu părțile anatomice detaliate ce sunt implicate în diagnostic. De asemenea, includerea în aplicația Android este la fel de importantă întrucât utilizabilitatea rămâne elementul primordial când vine vorba de dezvoltarea unei aplicații în domeniul medical, iar pentru aceasta va fi necesar să folosim ferestre de dialog ce vor lăsa să se vadă activitatea anterioară pe care o desfășuram.

Cei de la Google oferă instrumente de dezvoltare destul de avansate și cu setări detaliate cu privire la modul de folosire a aplicației de către utilizatori prin intermediul platformei Google Analitycs. Desigur, aceasta este adaptată și pentru dispozitivele ce rulează sistemul de operare Android și astfel putem să monitorizăm modul în care interacționează utilizatorul cu aplicație, observând astfel și utilizările eronate ce pot afecta activitatea medicală sau momentele în care aplicație aruncă o excepție ce ține de eroarea sistemului de operare.

Un ultim aspect ce este necesar pentru a putea integra aplicația într-o unitate de îngrijire medicală și pentru a asigura scalabilitatea utilizării acesteia ar fi găsirea unei soluții de depozitare centrală a datelor, deși acest lucru nu afectează foarte mult utilizabilitatea aplicației. Un exemplu de server central de date pentru o aplicație Android ar fi Parse, o soluție de tip backend ce este adaptată pentru majoritatea platformelor mobile existente pe piața, ce folosește obiecte pentru transferul datelor astfel asigurând flexibilitate în organizarea datelor. De asemenea, putem să implementăm și un server local în instituția medicală, cum ar fi Tomcat, ce poate asigura funcționalitățile și posibilitățile de stocare de care aplicația medicală de gestiune a foii de observație clinice a pacientului are nevoie.

5. Evaluare și testare

5.1 Evaluarea aplicațiilor electronice medicale

Procesul considerat cel mai important în dezvoltarea unei aplicații electronice medicale (en. EHR – Electronic Health Records) este acela de evaluare și testare al aplicației, dar pentru acest lucru există destul de multe metode și metrici de testare menită să asigure o clasificare ierarhică din anumite puncte de vedere. Cu toate acestea, elementul central, în jurul căruia se învârte întregul proces de testare și evaluare a unei aplicații din domeniul medical, este gradul de utilizabilitate al aplicației.

Totuși, se pune întrebarea de ce este atât de importantă măsurarea utilizabilității unei aplicații medicale și de ce acestă metrică ne va furniza o privire de ansamblu corectă asupra aplicației. Pe lângă faptul că astfel de aplicații au un grad mare de dificultate din punct de vedere al fluxurilor de lucru modelate într-o astfel de aplicației și al datelor ce sunt înregistrate, astfel de aplicații prezintă costuri foarte ridicate dezvoltare, atât pentru producători, cât și pentru beneficiari. Astfel, testarea utilizabilității și concluzii ce se pot trage de pe urma unei astfel de testări sunt importante pentru mai mulți actori implicați în dezvoltarea unor astfel de produse, cum ar fi producătorii de sisteme electronice medicale, ce pot îmbunătăți aplicația în urma unor astfel de teste, utilizatorii de astfel de aplicații care în cazul nostru reprezintă personalul medical, ce pot alege mai ușor aplicația ce se potrivește cel mai bine sau guvernul ce poate fi sigur de aplicarea normelor de siguranță prevăzute în legile din țara respectivă.

Înainte de a enumera metodele recomandate de testare și evaluare a unei aplicații medicale, voi încerca să menționez câteva elemente adiacente ce pot ajuta foarte mult acest proces și de care este important să nu uităm atunci când realizăm testarea. Un lucru esențial al design-ului centrat pe utilizator ar fi acela de a implica personalul medical încă de la fazele incipiente ale dezvoltării produsului software, aceștia având un rol foarte important pentru aplicație, iar prezența lor în toate etapele dezvoltării este esențială. Pentru a putea realiza aceste lucruri va trebui ca pe lângă interviurile cu actorii implicați direct (personalul medical al instituției medicale în care urmează sa fie implementată aplicația), cei ce dezvoltă și integrează produsul software să analizeze sistemele electronice medicale existente pe piață, să identifice aspectele pozitive și negative ale acestora, dar și părerea celorlalți utilizatori despre sistemele existente.

Primul pas în testarea utilizabilității unui sistem electronic medical este de a crea cât mai multe scenarii de utilizare și de test pentru a fi incluse în testarea ce va fi realizat cu personalul medical. Pentru acest lucru este nevoie ca cel puțin un membru al personalului medical să fie direct implicat în realizarea acestor scenarii, iar alte informații despre interacțiunea în cadrul scenariului de test să fie aflate de dezvoltator prin observarea mediului de lucru direct în spitalul în care integrăm aplicația sau în alte spitale în care a fost implementată o aplicație asemănătoare. Înainte de a trece la pasul următor, este important să avem o sesiune de prezentare a funcționalităților oferite de compania dezvoltatoare și apoi o sesiune de întrebări și răspunsuri pentru a clarifica cât mai mult modul de utilizare al aplicației medicale.

Alt pas în testare ar fi stabilirea pentru început a unor sesiuni de testare directă a aplicației cu unul dintre utilizatorii implicați direct, cum ar fi un medic sau o asistentă din specializarea medicală pentru care dezvoltăm aplicația. Este foarte important ca această testare să nu fie de tipul unei demonstrații sau prezentări a utilizării aplicației făcute de unul dintre reprezentanții companiei dezvoltatoare, ci să fie un beneficiar direct al aplicației medicale. În finalul acestor testări practice a aplicației de către un medic sau o asistentă este important pentru evaluare să avem pregătite un set de întrebări sub forma unui chestionar foarte rapid cu răspunsuri scurte și cu metrici simple (de exemplu sistemul de cinci stele) stabilite de comun acord între utilizator și dezvoltator.

În ultimul rând, trebuie să planificăm o sesiune completă de testare a utilizabilității de către un grup din personalul medical ce va folosi pe viitor aplicația și să oferim un mecanism de evaluare pentru fiecare scenariu descris în etapele prezentate anterior. În testarea unui scenariu stabilit, de exemplu pentru aplicația ”EHR Foaia de Observație Clinică Generală” un scenariu ar fi completarea datelor unui pacient ce nu a mai fost niciodată internat în aceea unitate medicală, trebuie să existe un mediator ce va conduce testul de utilizabilitate, urmărind respectarea scenariilor, dar și consemnarea rezultatelor evaluării. Pentru fiecare test, moderatorul va trebui să fie atent la comentariile și observațiile unui utilizator, dar fără să-l întrerupă pe acesta, menționând în rezultate dacă sarcinile au fost executate fără erori ale sistemului și în cât timp acestea au fost executate.

Pe parcursul acestor sesiune de testare a anumitor scenarii din aplicația medicală, o metodă foarte bună de a evalua părerea utilizatorului este aceea de a îi pune pe aceștia să își spună părerile și cum anume execută sarcinile în aplicație cu voce tare pe parcursul testării efective. Această metodă este mult mai eficientă pentru observarea greșelilor și neînțelegerilor la nivel de detaliu al aplicației dezvoltate, testele de la sfârșit oferind o părere mai mult de ansamblu asupra aplicației. Desigur, în tot acest scenariu intervine și problema numărului de utilizatori ce efectuează testarea, în acest caz putând fie opta pentru testare secvențială sau punerea în aplicarea a unui scenariu complex de testare în paralel a aplicației, observând astfel modul de colaborare între actorii implicați.

5.2 Planificarea testării

Când vine vorba de testarea software a unei aplicații complexe, metoda cea mai folosită este aceea a testării unitare pentru a fi testat fiecare modul în parte, astfel pentru testarea utilizabilității unde este implicat și factorul uman testarea nu poate să fie așa de exactă ca cea software, însă se respectă principiul testării unitare în sensul că sunt testate anumite părți ale interfeței. De altfel, atunci când planificăm testarea aplicației pentru utilizabilitate trebuie să ținem cont că sunt două metode de testare, cea formativă și cea sumativă. De obicei, testarea formativă se realizează în stagiile incipiente ale dezvoltării și este o testare ce este menită să ajute la repararea micilor erori de funcționalitate și utilizabiliate. În aceste testări sunt detectate încă din timp posibile erori de mari de utilizabilitate, tocmai prin implicarea utilizatorilor în folosirea versiunilor celor mai incipiente ale aplicației. În schimb, testarea sumativă are loc la sfârșitul dezvoltării aplicației și are rolul de a stabili formal calitatea aplicației prin măsurarea modului de executarea a sarcinilor de către utilizator.

Totuși, indiferent de etapa de testare aleasă sau de stagiul în care realizăm testarea utilizabilității, un pas important în elaborarea planului este acela de fixare a obiectivelor ce sunt urmărite în acest scop. Aceste obiective sunt setate pe baza a ceea ce dezvoltatorii vor să afle de la utilizatorii lor atunci când aceștia sunt într-o sesiune din aplicație, cum ar fi dacă utilizatorii direcți reușesc să ducă la bun sfârșit sarcinile din aplicație și dacă da în cât timp sau cu câte erori. Un alt obiectiv ar fi să cerem utilizatorilor să detecteze principalele greșeli de design ce duc la un nivel scăzut al utilizabilității sau dacă interfața finală rezultată corespunde cu cerințele și cu viziunea utilizatorului asupra aplicației.

Acum că am stabilit punctele de repere pentru alegerea obiectivelor, trebuie să stabilim pentru fiecare obiectiv în parte modalitatea de a obține părerile utilizatorului cu privire strict la un aspect. Astfel, putem să avem un obiectiv prin care vrem să vedem cât de bine înțeleg utilizatorii fluxul de sarcini din aplicație și funcționalitățile disponibile la acel moment. Pentru acest lucru putem să adresăm următoarele întrebări cu referire la aplicația medicală dezvoltată în cadrul acestei lucrări:

Care este modul de navigare între paginile principale din foaia de observație clinică generală implementată în aplicație?

Cum este căutat un pacient în aplicație?

Cum se realizează editarea unui pacient existent?

Care sunt posibilitățile din pagina principală a aplicației?

Un alt obiectiv ce poate fi setat pe parcursul întocmirii planului de testare ar fi acela de a afla punctele slabe ale aplicației și ce anume îî deranjează cel mai tare pe utilizatorii aplicației medicale în navigarea prin aplicației, având următorul set posibil de întrebări:

Ce sarcină nu ați putut realiza sau ați întâmpinat dificultăți în finalizarea ei?

Ce aspect a fost cel mai deranjant în completarea foii de observație clinică a pacientului?

Ce sarcină ați dorit să faceți și nu ați găsit o modalitate pentru finalizarea ei?

După ce am stabilit obiectivele și ce anume urmărim să aflăm de la utilizatorii aplicației dezvoltate putem să stabilim următoarele aspecte ale planificării unei testări. Un detaliu minor, dar important pentru a vedea evoluția utilizabilității aplicației ar fi să stabilim caracteristicile versiunii aplicației pe care o testăm, cum ar fi versiunea ei (1.0, 2.0, etc), caracteristicile sistemului pe care poate rula, cum ar fi sistemul de operare, programe adiționale (browsere specifice) și evident dispozitivul fizic (în cazul de față tabletă de 7 sau 10 inch cu sistem de operare Android, versiunea mai recentă de 4.0 Ice Cream Sandwich). De asemenea, mai există detalii ce trebuie precizate cum ar metricile de testare folosite, pe care putem să le caracterizăm în metrici calitative, cele ce țin de comentariile personale ale utilizatorilor cu privire la experiența în aplicație, sau în metrici cantitative ce fac referire la timpul de execuție a unei sarcini sau la numărul de erori apărute în timpul utilizării, însă aceste aspecte vor fi detaliate în secțiunea următoare.

Nu în ultimul rând, din planul de testare nu trebuie să lipsescă modalitatea de testare efectivă, unde trebuie să descriem numărul exact de utilizatori și experiența lor anterioară cu astfel de sisteme, dar și sarcinile detaliate și modul în care se vor realiza acestea. De exemplu, în cazul aplicației medicale dezvoltate pe tabletă în acest proiect, la o sesiune de testare pot participa unul sau doi medici care poate au experiență anterioară în utilizarea aplicațiilor generale pe o tabletă cu sistem de operare Android. De asemenea, putem menționa sarcinile principale pe care aceștia pot să le facă sau chiar sarcini de detaliu, cum ar fi completarea valorii tensiunii arteriale în aplicație, găsirea potrivirii necesare în sistemul de recomandări pentru un anume diagnostic, adăugarea unui nou pacient prin completarea datelor personale necesare (nume, prenume, cnp) sau găsirea unui pacient existent după nume și prenume.

În final, trebuie să prezentăm detaliile ce țin de mediul în care se va face testarea și cum anume vor fi analizate datele culese în această sesiune. În cazul de față testarea se poate efectua în mai multe medii, în funcție de etapa în care se află dezvoltarea aplicației, astfel putem să testăm aplicația într-un mediu neutru, ce nu este neapărat unitatea medicală țintită sau chiar în spital, unde avem mai multe posibilități, cum ar fi în cabinetul medicului, pe holurile spitalului sau chiar în saloane când sunt efectuate vizitele zilnice.

5.3 Metricile folosite pentru testare

Așa cum am spus în capitolele anterioare, definiția utilizabilității unei aplicații software se referă la trei metrici componente, respectiv la eficacitatea, eficiența și satisfacția cu care un utilizator își duce la final sarcinile din aplicație. Acum vom detalia aceste metrici și cum anume putem ajunge să le măsurăm și să analizăm rezultatele, dar și alte metrici adiacente ce pot fi foarte utile în a evalua utilizabilitatea.

În primul rând, o metrică ce oferă informații mai mult cantitative, dar este utilă în a evalua modul în care sunt desfășurate sarcinile în aplicația medicală este eficiența, ce reprezintă practic viteza cu care un utilizator navighează într-o sesiune de lucru. De obicei, datele pentru a măsura eficiența pot fi colectate folosind instrumente automate, în cazul Android putem să folosim API-ul pus la dispoziție de Google Analytics, iar testele sunt realizate atât de dezvoltatori sau utilizatori necalificați, cât și de către personalul medical pentru care dezvoltăm aplicația. De exemplu, putem măsura în cazul aplicației Android pe tabletă de câte ori s-a oprit neașteptat, de câte ori au fost accesate activitățile componente, numărul de accesări ale tastaturii sau timpul în care a fost adăugat efectiv un nou pacient în aplicația medicală cu toate datele completate.

Totuși, nu este suficient să măsurăm cantitativ modul de interacțiune a aplicație, deși acest lucru ne poate indica primele probleme ale utilizabilității, cât timp mai putem face schimbări fundamentale în ceea ce privește fluxul de lucru și modul de implementare al sarcinilor. Astfel, o măsură importantă a utilizabilității este eficacitatea de utilizare a unei aplicații, ce se referă în principal la modul în care utilizatorul parcurge fluxul de sarcini din aplicație și dacă acesta reușește să termine sarcina cu succes sau cu erori. De asemenea, măsurarea eficacității unui sistem medical electronic este vitală pentru aplicație întrucât prin aceasta putem depista riscurile majore ce pot exista în fluxul de lucru. În funcție de măsura numărului de finalizări ale sarcinilor cu succes sau a finalizării sarcinilor cu erori putem face o analiză topologică a riscurilor ce există în aplicație ca urmare a erorilor produse sau a utilizării unei alte înlănțuiri de sarcini ce duce la un rezultat cu totul diferit față de cel așteptat. De exemplu, în cazul sistemelor medicale electronice depistarea riscurilor este foarte importantă întrucât avem de-a face cu starea de sănătate, chiar viața unor oameni, mai ales când vine vorba de prescripțiile de medicamente și alergiile pe care le are pacientul.

Cu toate că eficacitatea și eficiența sunt măsuri importante și exacte ale utilizabilității, baza acestor testări o reprezintă măsurarea satisfacției utilizatorului cu privire la aplicație folosită. Astfel, deși este o măsură subiectivă, unde nu pot fi anticipate prea ușor rezultatele testării, satisfacția reprezintă elementul central al măsurării utilizabilității. De cele mai multe ori, metodele nu sunt cele mai exacte întrucât acestea presupun exprimarea opiniei personale cu privire la aplicație și la modul în care au fost finalizate sarcinile în aplicație și nu există o recomandare precisă pentru modalitatea de obținere a răspunsurilor. Însă, există și anumite sisteme standard de evaluare cum ar fi stabilirea unor sarcini critice (de exemplu, modul de completare al datelor despre pacient, căutarea unui pacient) și acordarea unor note la 1 la 10 pentru fiecare sau un sistem rapid, dar destul de apreciat ”System Usability Scale”, unde utilizatorul trebuie să acorde o notă de la 1 la 5 (1 – nu este de acord și 5 – este total de acord) pentru zece criterii general valabile pentru orice sistem software, cum ar fi dacă utilizatorului i-ar plăcea să folosească des sistemul sau dacă a avut control total asupra sesiunii din aplicație (Sauro, 2011).

Pe lângă metricile enumerate mai sus am spus mai devreme că putem găsi și alte modalități de a evalua parte din utilizabilitatea unui sistem, cum ar fi măsurarea rapidității cu care un utilizator învață să folosească sistemul software sau evaluarea încărcării cognitive a utilizatorului. Pentru a evalua acest aspect de învățare a utilizării aplicației putem măsura după cât timp un medic învață semnificația elementelor grafice din aplicaței sau timpul pe care utilizatorul l-a petrecut cerând ajutorul dezvoltatorilor sau accesând meniurile de ajutor din aplicație. Din alt punct de vedere, trebuie să evaluăm cumva și încărcarea cognitiva a utilizatorului, ce este foarte importantă pentru utilizabilitatea unei aplicații medicală având în vedere caracteristicile mediului de lucru al personalului medical, descrise anterior în această lucrare. Există metode complexe, ce cuprind metode existente în psihologie cognitivă, ce analizează modul de procesare a informațiilor între momentul unui stimul și cel al unui răspuns, dar putem folosi și metode simplificate ce ne pot oferi o privire de ansamblu asupra aspectului cognitiv cum ar fi NASA-TLX, ce oferă un mic chestionar pentru evaluare și instrucțiuni pentru interpretarea rezultatelor (”NASA TLX Paper/Pencil Version”).

O alternativă la utilizarea acestor metrici și la crearea testelor de către dezvoltatori ar fi folosirea unor instrumente existente pentru evaluarea utilizabilității unei aplicații medicale prin introducerea de capturi de ecran, înregistrări video cu folosirea aplicației sau chiar detalii legate de cazurile de utilizare ale acesteia. Cu toate acestea, intervine o problemă delicată aici, cea de dezvăluire a datelor personale și medicale ale unui pacient prin trimiterea capturilor de ecran către alte instrumente de testare și evaluare independente de sistemul medical.

6. Concluzii

În final, domeniul studierii utilizabilității unei aplicații software, împreună cu dezvoltarea acesteia astfel încât să respecte principiile de eficacitate, eficiență, dar cel mai important de satisfacție a utilizatorului direct, reprezintă o provocare pentru fiecare dezvoltator indiferent de domeniul pentru care este implementat sistemul software. În particular, sistemul medical prezintă o mulțime de puncte sensibile în dezvoltarea unor astfel de produse datorită caracteristicilor mediului, dar și a proceselor complexe ce au loc întrucât interacțiunea se realizează în principal cu oamenii, iar principala problemă o reprezintă starea de sănătate. De aici tragem concluzia că orice greșeală mică de implementare, de interpretare greșită a sarcinilor sau de corelare a datelor poate avea consecințe grave imediate și de aceea este așa importantă studierea utilizabilității sistemelor electronice medicale încă din fazele incipiente ale dezvoltării până în etapa de implementare efectivă.

De altfel, date fiind condițiile în care lucrează un medic și responsabilitatea pe care o implică acțiunile sale, important este să eliminăm cât mai multe erori de funcționare ale aplicației încă din stadiul de dezvoltare. Însă, erorile de funcționare nu se referă strict la starea aplicației, ci și la interpretarea greșită a datelor introduse în sistem de un pacient sau la modul în care se face legătura între datele pacientului ( de exemplu, existența unor alergii în prescripția unor medicamente). Toate aceste lucruri se pot corecta dacă pe lângă testarea de sistem, urmărim modul în care un utilizator execută fluxul de sarcini în aplicație și cum înțelege medicul stările aplicației și acțiunile de aici.

Un alt aspect al dezvoltării unei aplicații medicale din acest moment îl reprezintă existența a multor sisteme electronice medicale pe piața, care încearcă să acopere cât mai multe nevoi ale unui medic. Deși la început s-a crezut că se pot dezvolta ușor astfel de aplicații pentru medici, timpul a dovedit faptul că un produs software medical poate fi respins foarte ușor de către personalul medical dacă acesta nu modelează corect sarcinile și nu le îmbunătățește activitatea zilnică. De aici a început preocuparea pentru dezvoltarea de sisteme software medicale cu un grad de utilizabilitate cât mai mare pentru a putea cuprinde un număr cât mai mare de unități medicale. Cu toate acestea, domeniul medical este unul vast, ce conține o sumedenie de specializări (cardiologie, medicină generală, oncologie, chirurgie, oftalmologie, etc) și dezvoltarea unei aplicații generale, ce poate satisface nevoile acestor specializări nu este posibilă.

Pentru a putea evita problemele de utilizabilitate într-o aplicație generală, marile companii dezvoltatoare de astfel de sisteme software medicale au oferit posibilitatea realizării unor studii preliminare pentru a putea adapta o aplicație la sarcinile existente într-o anumită specializare medicală dintr-un spital anume. Cu toate acestea, oferirea unor astfel de studii au mărit considerabil costurile de integrare pe care trebuie să le suporte o unitate medicală ce dorește să implementeze un sistem medical electronic, ceea ce a dus la o reticență din partea managerilor de spitale pentru adoptarea acestor aplicații. Chiar și pentru companiile dezvoltatoare de software, ce nu au un sistem propriu de evaluare a utilizabilității, ședințele de consultanță la o companie specializată pe testarea utilizabilității poate avea costuri foarte mari (”Nielsen Norman Group”).

Totuși, o alternativă la folosirea unor studii de utilizabilitatea complexe este dezvoltarea unor sisteme proprii de evaluare a aplicației, inspirate din starea actuală a aplicațiilor medicale. Există foarte multe studii de utilizabilitate, ce le-am prezentat în capitolul 5 de Testare și evaluare, prin care putem evalua aplicația dezvoltată, deși poate acest lucru va mări timpul de implementare și integrare a sistemului software în unitatea medicală aleasă. Cu toate acestea, implementarea unei aplicații software medicale pentru o anumită specializare medicală și satisfăcând doar cerințele personalului medical implicat poate să constituie un avantaj în crearea unei aplicații cu un grad de utilizabilitate mare. Este cazul și aplicației dezvoltate în această lucrare, unde dispar poate constrângerile impuse de o companie ce își adaptează un produs software existent pentru anumite sarcini specifice (completarea foii de observație clinică generală).

Nu în ultimul rând, un avantaj al dezvoltării aplicației medicale pentru chirurgie cardio-vasculară l-a reprezentat folosirea platformei de dezvoltare mobilă Android, ce oferă foarte multe posibilități din punct de vedere al desginului, al ușurinței în utilizare și al gradului de mobilitate. În plus, pentru a dezvolta o aplicație adaptată pentru dispozitivele mobile de tip tabletă, cei de la Android oferă mecanisme prin care atenția dezvoltării este îndreptată către nevoile utilizatorului, către mediul în care se află și către modul de interacțiune cu aplicația (gesturi de interacțiune, folosirea tastaturii virtuale, rotirea automată a ecranului). Prin urmare, mediul de lucru din spital este unul foarte dinamic, unde medicii și asistentele sunt în permanentă mișcare și nu stau la birou pe parcursul orelor de lucru și de aceea dezvoltarea unei aplicații pe tabletă le va oferi mobilitatea de care au nevoie și mecanisme de manipulare a datelor mult mai la îndemână.

Pe viitor acest model de aplicație se poate extinde, bineînțeles prin particularizarea cerințelor de sistem și pentru alte specializări din domeniul medical, poate chiar din cadrul aceluiași spital, dacă acest sistem se dovedește eficient și este integrat într-o secție. În final, cea mai bună dovadă a utilizabilității aplicației medicale este implementarea cu succes într-o anumită specialitate, ca apoi aceasta să fie extinsă cu modificările necesare la alte specializări, în afară de cea de chirurgie cardio-vasculară, care poate au la fel de multă nevoie de eficientizarea proceselor de lucru.

BIBLIOGRAFIE

Brown, D. (2013, May 30). "The Year of the Big EHR Switch" Confirms Physicians Favor iPad and Mobile Applications. PRWeb. Retrieved June 3, 2014, from http://www.prweb.com/releases/2013/5/prweb10553455.htm

Leigh, P., Tancredi, D., Jerant, A., & Kravitz, R. (2011, July 11). Annual Work Hours Across Physician Specialties. Retrieved May 10, 2014, from http://archinte.jamanetwork.com/article.aspx?articleid=1105820#ref-ild15019-1

Nielsen, J. (2013, August 15). Tablet Usability. Tablet Usability: Findings from User Research. Retrieved April 20, 2014, from http://www.nngroup.com/articles/tablet-usability/

Budiu, R., & Nielsen, J. (2011, January 1). iPad App and Website Usability. iPad App and Website Usability. Retrieved March 20, 2014, from http://www.nngroup.com/reports/ipad-app-and-website-usability/

Nielsen, J. (2009, July 20). Nielsen Norman Group. Mobile Usability, First Findings. Retrieved June 6, 2014, from http://www.nngroup.com/articles/mobile-usability-first-findings/

The 10 principles of mobile interface design. (2012, April 16). The 10 principles of mobile interface design. Retrieved June 5, 2014, from http://www.creativebloq.com/mobile/10-principles-mobile-interface-design-4122910

Nielsen, J. (2011, May 9). Utilize Available Screen Space. Utilize Available Screen Space. Retrieved June 7, 2014, from http://www.nngroup.com/articles/utilize-available-screen-space/

Tablet computer. (2014, June 28). Wikipedia. Retrieved June 6, 2014, from http://en.wikipedia.org/wiki/Tablet_computer

Yarow, J. (2014, March 28). This Chart Shows Google's Incredible Domination Of The World's Computing Platforms. Business Insider. Retrieved June 7, 2014, from http://www.businessinsider.com/androids-share-of-the-computing-market-2014-3

Victor, H. (2013, July 24). Android's Google Play beats App Store with over 1 million apps, now officially largest. Phone Arena. Retrieved June 7, 2014, from http://www.phonearena.com/news/Androids-Google-Play-beats-App-Store-with-over-1-million-apps-now-officially-largest_id45680

Open Handset Alliance. (n.d.). Open Handset Alliance. Retrieved June 7, 2014, from http://www.openhandsetalliance.com/

Developer Economics Q3 2013 – Developer Economics. (n.d.). Developer Economics. Retrieved June 10, 2014, from http://www.developereconomics.com/reports/q3-2013/

Android (operating system). (2014, June 10). Wikipedia. Retrieved June 10, 2014, from http://en.wikipedia.org/wiki/Android_(operating_system)

Core App Quality. (n.d.). Android Developers. Retrieved June 10, 2014, from http://developer.android.com/distribute/essentials/quality/core.html

Tablet App Quality. (n.d.). Android Developers. Retrieved June 10, 2014, from

http://developer.android.com/distribute/essentials/quality/tablets.html

Developer Stories: The Opportunity of Android Tablets. (n.d.). Android Developers. Retrieved June 10, 2014, from http://developer.android.com/distribute/stories/tablets.html

Sawh, M. (2013, December 24). Best Android Tablet Apps: Top 5 Google Play downloads. – Trusted Reviews. Retrieved June 10, 2014, from http://www.trustedreviews.com/best-android-tablet-apps_round-up

It’s easy to understandwhat’s going on with your money.. (n.d.). Mint. Retrieved June 10, 2014, from https://www.mint.com/

Remember The Milk for Android. (n.d.). Remember The Milk. Retrieved June 10, 2014, from http://www.rememberthemilk.com/services/android/

Flipboard Proves — Again — That Android Tablet Apps Don’t Have to Suck | Gadget Lab | WIRED. (2012, December 19). Wired.com. Retrieved June 11, 2014, from http://www.wired.com/2012/12/flipboard-tablet-optimized-android-app/

Augusto, V., & Xie, X. (). A Modeling and Simulation Framework for Health Care Systems. Systems, Man, and Cybernetics: Systems, IEEE Transactions on.

Unified Modeling Language. (2014, June 25). Wikipedia. Retrieved June 15, 2014, from http://en.wikipedia.org/wiki/Unified_Modeling_Language

Lowry, S.Z., & Ramaiah, M., & Patterson, E.S., & Brick, D., & Gurses, A.P., & Ozok, A., & Simmons, D., & Gibbons, M.C. (2014). Integrating Electronic Health Records into Clinical Workflow: An Application of Human Factors Modeling Methods to Ambulatory Care, National Institute of Standards and Technology.

Hsiao, C., & Hing, E. (2014, January 1). Use and Characteristics of Electronic Health Record Systems Among Office-based Physician Practices: United States, 2001–2013.

Lowry, S.Z., & Schumacher, R.M. (2010). NIST Guide to the Processes Approach for Improving the Usability of Electronic Health Records, National Institute of Standards and Technology.

Thizy, D. (2010, June 2). Healthcare Archives – Macadamian. Macadamian. Retrieved June 15, 2014, from http://www.macadamian.com/category/healthcare/#http%3A%2F%2Fwww.macadamian.com%2F2010%2F06%2F02%2Fdesigning-successful-healthcare-software-10-critical-lessons%2F

(2012, August 7). Selecting a Mobile App: Evaluating the Usability of Medical Applications . Lecture conducted from mHIMSS App Usability Work Group .

HIMSS Enterprise Information Systems Committee. (2012, June). Hospital Mobile Adoption Considerations.Retrieved from http://www.himss.org/files/HIMSSorg/content/files/HospitalMobileAdoptionConsiderations.pdf

ISO 9241-11:1998. (n.d.). ISO 9241-11:1998. Retrieved June 20, 2014, from http://www.iso.org/iso/catalogue_detail.htm?csnumber=16883

ISO 9241-210:2010. (n.d.). ISO 9241-210:2010. Retrieved June 20, 2014, from http://www.iso.org/iso/catalogue_detail.htm?csnumber=52075

eClinicalWorks EMR Software. (n.d.). Software Reviews from the Business Experts at Software Advice. Retrieved June 22, 2014, from http://www.softwareadvice.com/medical/eclinicalworks-profile/

Oprea, M. (2014, April 17). Dosarele electronice de sanatate ale asiguratilor pot fi accesate. Dosarele electronice de sanatate ale asiguratilor pot fi accesate. Retrieved June 22, 2014, from http://www.avocatnet.ro/content/articles/id_32723/Dosarele-electronice-de-sanatate-ale-asiguratilor-pot-fi-accesate.html

Khawar, W. (2014, February 19). Eye Emergency Manual is a free medical app to diagnose ophthalmology emergencies – iMedicalApps. iMedicalApps Eye Emergency Manual is a free medical app to diagnose ophthalmology emergencies Comments. Retrieved June 22, 2014, from http://www.imedicalapps.com/2014/02/eye-emergency-manual-free-app-ophthalmology-emergencies/

Choi, W., Park, M., Hong, E., Kim, S., Ahn, R., Hong, J., et al. (2013, December 31). Abstract. National Center for Biotechnology Information. Retrieved June 22, 2014, from http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3920044/

Model-view-controller. (2014, June 24). Wikipedia. Retrieved June 22, 2014, from http://en.wikipedia.org/wiki/Model-view-controller

Navigation Drawer. (n.d.). Android Developers. Retrieved May 12, 2014, from https://developer.android.com/design/patterns/navigation-drawer.html

Creating a Navigation Drawer. (n.d.). Android Developers. Retrieved May 22, 2014, from https://developer.android.com/training/implementing-navigation/nav-drawer.html

BaseExpandableListAdapter. (n.d.). Android Developers. Retrieved May 20, 2014, from http://developer.android.com/reference/android/widget/BaseExpandableListAdapter.html

List View. (n.d.). Android Developers. Retrieved May 10, 2014, from http://developer.android.com/guide/topics/ui/layout/listview.html

Action Bar. (n.d.). Android Developers. Retrieved May 23, 2014, from http://developer.android.com/guide/topics/ui/actionbar.html

Swipe Views. (n.d.). Android Developers. Retrieved May 10, 2014, from

http://developer.android.com/design/patterns/swipe-views.html

Creating Swipe Views with Tabs. (n.d.). Android Developers. Retrieved May 10, 2014, from http://developer.android.com/training/implementing-navigation/lateral.html

SQLiteOpenHelper. (n.d.). Android Developers. Retrieved May 10, 2014, from http://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html

Storage Options. (n.d.). Android Developers. Retrieved May 10, 2014, from http://developer.android.com/guide/topics/data/data-storage.html

AutoCompleteTextView. (n.d.). Android Developers. Retrieved May 20, 2014, from http://developer.android.com/reference/android/widget/AutoCompleteTextView.html

Google Analytics. (n.d.). SDK v4 for Android. Retrieved May 20, 2014, from https://developers.google.com/analytics/devguides/collection/android/v4/

Android Developer Guide | Parse. (n.d.). Android Developer Guide | Parse. Retrieved June 1, 2014, from https://www.parse.com/docs/android_guide

Sauro, J. (2011, February 2). Measuring Usability with the System Usability Scale (SUS). : Measuring Usability. Retrieved June 29, 2014, from http://www.measuringusability.com/sus

NASA TLX Paper/Pencil Version. (n.d.). NASA TLX Paper/Pencil Version. Retrieved June 13, 2014, from http://humansystems.arc.nasa.gov/groups/tlx/paperpencil.html

HIMSS EHR Usability Task Force. (2009, June). Defining and Testing EMR Usability:  Principles and Proposed Methods of EMR Usability Evaluation and Rating. Retrieved from http://www.himss.org/files/HIMSSorg/content/files/himss_definingandtestingemrusability.pdf

HIMSS EHR Usability Task Force. (2010, August). Selecting an EMR for Your Practice: Evaluating Usability. Retrieved from http://www.himss.org/files/HIMSSorg/content/files/selecting_emr_eval_usability.pdf

Nielsen Norman Group. (n.d.). : UX Research, Training, and Consulting. Retrieved June 21, 2014, from http://www.nngroup.com/consulting/ux-research-usability-testing/