Monitorizarea echipamentelor medicale
Yüklə 53,75 Kb.
|
- Bu səhifədəki naviqasiya:
- Protocolul SNMP. Descriere generala Primitivele
- Setul de standarde ISO/IEEE 11073
- Analiza comparativa a celor doua protocoale
- Implementari ale ISO 11073 -10xxx
- O critică a standardelor 11073-10xxx
- Arhitectura unui sistem de monitorizare
|
MONITORIZAREA ECHIPAMENTELOR MEDICALE Cresterea continua a numarului si complexitatii echipamentelor de monitorizare utilizate in medicina ne-a facut sa luam in considerare necesitatea realizarii de puncte de centralizare a informatiilor. Acestea ar urma sa centralizeze atat informatii de stare cat si sa receptioneze alerte pe care sa le distribuie intr-un mod convenabil ( avertizare sonora, SMS, e-mail etc ) catre destinatari prestabiliti Modelul principial care s-a luat in calcul a fost protocolul SNMP folosit pe scara larga in monitorizarea sistemelor de calcul. Aceasta abordare doreste sa valorifice atat infrastructura existenta ( retele ethernet, Wi-Fi deja instalate) cat si experienta si instrumentele software de uz general deja existente intr-o integrare originala.
Protocolul SNMP este un protocol Internet la nivel aplicatie care a cunoscut pana acum trei versiuni succesive ( v1, v2c si SNMPv3) Ultima dintre implementari este descrisa in RFC 3411 [1.1] si RFC 3418 [1.2] si va fi folosita mai departe in text ca baza de discutie, in cazul in care nu va fi specificat altfel, fiind versiunea considerata curenta. Totusi, versiunea 3 nu difera principial de versiunea 2 decat prin adaugarea elementelor de securitate a informatiei, ceea ce face ca descrierea principiala sa fie valabila si pentru v2 SNMP este in principiu un protocol de tip master-slave, in care master-ul transmite request-uri iar slave-ul raspunsuri. SNMP implementeaza un set restrans de primitive: GetRequest SetRequest GetNextRequest GetBulkRequest (implementat din v2) Toate aceste mesaje sunt transmise de catre master, care va primi un mesaj de tip “response” de la slave. In afara de acestea insa, “slave”-urile au posibilitatea de a trimite alerte, numite “trap-uri” Trap-urile sunt folosite in principal in scopul de a informa asupra aparitiei unui eveniment Pentru confirmarea receptionarii “trap-ului” si nu numai in v2 s-a introdus primitiva Informrequest MIB Informatia transmisa de catre “slave” nu este specificata prin campuri fixe. In schimb, acestea sunt definite prin “MIB”-uri (Management Information Base) care descriu intr-o structura ierarhica o descriere a obiectului de monitorizat. Informatia este interpretata de manager pe baza bibliotecii de MIB-uri. Concret, sistemul de monitorizare tipic cuprinde fisiere de tip MIB pentru fiecare din echipamentele monitorizate, pe baza carora interpreteaza informatiile. In lipsa fisierelor .mib, informatia poate fi “parsata” dar nu poate fi interpretata. Totusi, exista cateva campuri relativ standard “de facto” : denumirea, persoana de contact, locatia etc pe care de regula orice sistem de monitorizare le poate interpreta. Structura MIB-urilor este definita in RFC 2578 [1.3] In esenta, MIB-urile sunt compuse din liste de “identificatori de obiecte” (OID, object identifiers) OID-urile sunt atribuite de catre IANA , root-ul acestora fiind 1.3.6.1. ( deci toate OID-urile incep cu acest grup de cifre) Dintre ramurile acestuia, mgmt mgmt OBJECT IDENTIFIER ::= { internet 2 } se refera la obiectele standard, existand insa si ramurile “experimental”, “enterprise” si “private”. SMI ( Structure of management information) cuprinde, cf rfc-ului citat module, obiecte si notificari Modulele sunt folosite pentru a circumscrie un modul de informatie, de regula un echipament monitorizat, obiectele reprezinta descrierea acestui modul, iar notificarile descriu mesajele nesolicitate reprezentand informatii de management ( in mod tipic evenimente monitorizate, precum depasirea unui prag, defectarea unui subansamblu etc) Obiectele de tip MIB sunt descrise in mod formal folosind ASN.1 ( Abstract syntax notation one) definit de OSI. Un extras dintr-un fisier MIB reprezentand un host ( server sau statie de lucru) se poate regasi in exemplul de mai jos: -------------------------------------------------------------------------------------------------------------------------
Extrasul face parte din pachetul SNMP de pe un sistem desktop de tip Linux Se observa definirea componentelor ca ramuri ale obiectului initial ( host) si descrierea acestora folosind ASN.1
Tipic, protocolul SNMP este implementat peste UDP, avand asignat portul 161 . Trnsmiterea “trap-urilor” foloseste portul 162. UDP este un protocol de comunicatie fara confirmare care nu asigura integritatea mesajelor si nici ordinea corecta a pachetelor. Monitorizarea de tip SNMP este “sessionless” asigurand o incarcare mica a retelei dar si o fiabilitate scazuta Setul de standarde ISO/IEEE 11073 Pentru monitorizarea aparaturii medicale de monitorizare personala ISO/IEE a publicat in 2008 un set de standarde sub numarul 11073, care cuprinde standarde de comunicatie intre dspozitive de sanatate personala si un “manager”
Acestea “calchiaza” modelul SNMP folosind o arhitectura bazata pe un manager si agenti ( in esenta tot master-slave) si o descriere ierarhica a parametrilor monitorizati compatibila cu MIB. Sunt insa definiti parametri specifici domeniului medical, ceea ce permite interconectarea intre echipamente de provenienta heterogena. Definirea parametrilor urmeaza un model orientat spre obiecte format din “handle” si atribute. Fiind un standard ISO/IEEE, definitiile sunt mult mai stricte decat in cazul protocoalelor Internet, intregul document avand 208 paginii Spre deosebire de SNMP insa standardele 11073 folosesc o abordare bazata pe conexiune. Modelul sistemului in ISO 11073 este impartit in trei mari sectiuni: DIM (“domain information model”) , modelul serviciului ( “service model”) si modelul de comunicatie (“communication model”) DIM se refera la informatiile pe care agentul le furnizeaza ( datele, vazute ca set de obiecte asociate dispozitivului) “Service model” se refera la primitivele folosite pentru accesarea acestor informatii “Communication model” se refera la componenta referitoare la comunicatie ( asociere/deasociere) si topologia globala a sistemului. Protocolul este structurat pe doua “servicii” cel de comunicare ( “association service”) si cel de acces la date (“Object access service”) Agentii pot fi in starea “asociat” sau “neasociat” la manager. Asocierea se realizeaza prin primitivele “Association request” si Association response” Dezasocierea foloseste primitivele “ release request” si “release response” In caz de probleme de comunicatie se foloseste primitiva “Abort” Pentru accesul la date se folosesc primitivele “Get” , “Set” , “Action” si “Event Report” . Din acestea primele trei sunt initiate de manager, iar ultima de catre agent. Necesitatea ca agentul sa poata semnala anumite evenimente catre manager incalca modelul strict master-slave , ca si in cazul SNMP , relevand limitele modelului in cazul de fata. In principiu, datele sunt preluate cu comanda “GET” iar comanda “Action” va invoca metode specifice dispozitivului monitorizat. Standardul stabileste reguli privind nomenclatorul de produse si codarea acestora , tabela de stari referitoare la asociere si deasociere a agentului de la manager, informatiile de stare referitoare la timp ( clock-ul managerului , clock-ul device-ului, informatiile referitoare la ajustarea timpului) , modalitatea de transmitere a datelor cu caracter periodic, factorul de scala etc. Analiza comparativa a celor doua protocoale Ne-am propus sa analizam cele doua protocoale de mai sus din punct de vedere al adecvarii la folosirea in monitorizarea echipamentelor medicale. SNMP este un protocol matur, folosit de multa vreme si pe scara larga pentru monitorizarea echipamentelor IT. Din punct de vedere al comunicatiei, SNMP este definit peste un singur tip de transport : “Internet Protocol”. Aceasta este o prima limitare, legata de faptul ca echipamentele vor trebui sa poată implementa stiva TCP/IP ( sau să comunice in alt mod cu un echipament capabil IP) Un contraargument ar fi ca la ora actuală cablări de rețele IP există pretutindeni, deci ar beneficia de infrastructura existenta. Protocolul definit sub ISO/IEEE 11073 nu precizeaza tipul de transport, impunand doar niste cerinte generice, ca atare se preteaza la implementare peste orice tip de conexiune de date. Totusi, exista o limitare intrinseca, legata de definirea acestuia ca protocol orientat pe sesiune. Protocolul necesita ca nivelul de comunicatie ( communication layer) sa poata comunica nivelului aplicatie situatia de deconectare sau terminare a conexiunii “ n) The communications layers should provide a mechanism to indicate to the application layer when a connection is terminated or disconnected.” ( 1.9 pag 56 paragraf 8.3.3) Aceasta este adevarata de exemplu pentru conexiunile USB, insa pentru conexiuni de tip IP ar fi necesar un serviciu suplimentar de tip heart-beat care sa monitorizeze starea conexiunii. In mod concret, un dispozitiv comunicand, de exemplu pe IP nu va avea o modalitate de a comunica “managerului” starea de deconectare, acesta aparand conectat pana , de exemplu, va incerca o citire de tip “get” care eventual va returna eroare. Pentru scopul nostru cel putin, folosirea unui protocol bazat pe sesiune nu aduce nici un fel de avantaj. In mod tipic, monitorizarea ar insemna apelarea periodica a unor metode de tip Get sau extensii ale acestora si receptionarea de semnale de tip “trap” sau “event” in functie de terminologia fiecarui protocol. Este de asteptat sa fie mai profitabil atat din punct de vedere al benzii consumate cat si din punct de vedere al fiabilitatii globale implementarea unui sistem de tip heart-beat folosind metode “get” sau “trap-uri” transmise la intervale prestabilite decat folosirea unui protocol bazat pe sesiune. Managerul ar considera automat un dispozitiv ca fiind deconectat in momentul in care o metoda de tip “get” esueaza sau un “trap” nu soseste in intervalul prestabilit. Din acest punct de vedere, folosirea unui protocol orientat pe sesiune peste IP este redundanta, deoarece ar necesita oricum implementarea unui sistem care sa semnalizeze starea de “deconectat” a unui dispozitiv. Din punctul de vedere al datelor utile, protocolul SNMP nu defineste concret marimile de masurat. Producatorii de echipamente IT de regula furnizeaza si fisiere MIB pentru integrarea acestora intr-un sistem de monitorizare, insa pentru echipamentele medicale, OID-urile ar trebui definite pentru a se putea folosi. ISO11073 defineste tot nomenclatorul pentru echipamentele cuprinse in standard precum si posibilitati de extindere a acestuia. De aemenea ia in calcul si principalele situatii concrete referitoare la natura datelor ( lucrul cu factori de scala, sincronizarea timpului etc) punand la dispozitia implementatorului obiecte si metode specifice. Un punct de discutat in legatura cu ISO11073 este ca acesta nu defineste nimic referitor la comunicatia “managerului” cu alte dispozitive decât cele medicale. O arhitectura uzuala in monitorizarea sistemelor ar fi una de tip arbore, cu puncte de monitorizare ( manageri) locali care sa raporteze la randul lor catre managerul central. Arhitectura de tip arbore este destinata sa reduca atat incarcarea managerului central cat si traficul in retea. O astfel de arhitectura este greu de implementat folosind ISO11073 deoarece acesta nu defineste comunicatia de tip manager-manager. De asemenea este dificil de implementat o arhitectura in care managerul local sa actioneze ca un agent pentru managerul central, deoarece am avea la dispozitie doua abordari: fie pentru fiecare device ( sau functie a device-urilor) managerul local ar implementa cate un agent, ceea ce ar anula reducerea de complexitate dorita ( practic managerul central ar avea atatia agenti cati ar avea si daca nu ar exista manageri locali) fie managerul local ar implementa un singur agent dar avand metode pentru toate seturile de date masurate, ceea ce in final s-ar traduce tot prin complexitate sporita la nivelul managerului. S-ar putea imagina inclusiv o arhitectura hibrida, care sa foloseasca manageri locali comunicand prin suita de protocoale ISO11073 cu dispozitivele, beneficiind de faptul ca in acest caz nu e necesar protocolul IP la nivel de dispozitiv , iar comunicatia manager local – manager central sa se faca prin SNMP, peste IP. In stadiul actual, nu se poate trage o concluzie clara referitoare la avantajul uneia din solutii fata de celelalte. O solutie ar trebui sa ia in considerare atat caracteristicile concrete ale dispozitivelor ( protocoale deja implementate, conectivitate, putere de calcul etc) cat si un set de specificatii mai restrans pentru definirea solutiei. Implementari ale ISO 11073 -10xxx In momentul de față sunt cunoscute cateva implementari Open Source ale serviciului de manager al standardului respectiv. Ne-am concentrat asupra acestora pentru că, având acces la codul sursă se poate verifica stadiul implementării și se poate urmări tehnologia folosită. Pentru sistemele cu Android există o implementare a funcției de manager , openHealth Manager, scrisă in Java. De asemenea, pentru Linux exista un set de biblioteci si programe cu numele de Antidote, care implementeaza functiile de manager si agent folosind comunicatia pe bluetooth. Am analizat acest pachet mai indeaproape pentru a-l folosi pentru teste, însă în acest moment e limitat la comunicația bluetooth, este necesară implementarea transportului peste TCP/IP Ideea care a stat la baza elaborarii standardului a fost ca producatorii de echipamente de monitorizare medicală personală să implementeze funcția de agent pe echipamentele comercializate , acestea putând fi apoi monitorizate de un echipament – smartphone, notebook sau computer desktop cu aplicații produse de ei sau de terțe părți. Din acest motiv eforturile producătorilor de software sunt concentrate spre realizarea funcției de manager, care să primească informații de la agenți. Implementarea funcției de agent este de obicei sarcina producătorului echipamentului, care alege și tipul de conectivitate. In mod obișnuit, producătorul este oarcum limitat la conectivitatea Bluetooth sau IP ( wireless sau ethernet) dacă dorește interfațarea cu echipamentele mobile sau USB, pentru dispozitive conectate direct la un calculator. Totuși, cel puțin pachetul Antidote cuprinde și o implementare a funcției de agent, extrem de utilă pentru teste.
Modelul de la care s-a plecat în elaborarea familiei de standarde discutate a fost acela al unui dispozitiv de monitorizare – în mod tipic PC la care se conectează un număr de echipamente de monitorizare personală. Aceste echipamente ar trebui să fie de preferință autonome ( alimentate pe baterii și fără cabluri de interconectare) , ușoare (portabile ) și dacă se poate, ieftine. După cum se observă și în [2.3] , implementarea serviciului pe mai multe niveluri (layers) este dificilă în arhitecturi cu microcontrolere, ale căror resurse sunt limitate. Incapsularea bazată pe niveluri necesită în general apeluri de funcții specializate consumând inutil memorie și putere de calcul. Din acest motiv, în documentul citat s-a eliminat încapsularea la nivelul funcției de agent. Aceleași considerații sunt valabile și în ceea ce privește abordarea orientată pe obiecte. Totuși, deși standardul folosește o asemenea abordare, aceasta nu este obligatorie în implementare. Adițional față de observațiile citate mai sus, e ușor să observăm că În anumite condiții payload-ul adăugat informației utile devine extrem de mare, exprimat procentual. Dacă luăm, de exemplu, cazul termometrului digital, vom vedea ca domeniul de temperatură necesar este, grosso-modo, de aproximativ 10 grade, iar o precizie de 0,1 grade e suficienta. În acest caz, informația utilă se poate exprima printr-un singur octet. Totuși, datorită obligației de a introduce un timestamp, precum și a parametrilor suplimentari, pachetul final trimis ca răspuns de către device va avea aproximativ 14 octeți. De asemenea problema timestamp-ului este delicată, deoarece presupune ca: 1. device-ul respectiv să aibă un clock propriu 2. Ceasul device-ului să poată fi sincronizat sau măcar citit, printr-o metodă externă sau de către manager. Această cerință este de fapt prezentă în standard, dar modalitatea de implementare nu este definită. Tot în [2.3] se observă că lungimea pachetului, în cazul bluetooth DH5 este de doar 341 octeți de informație, ceea ce ar necesita o modalitate de fragmentare /defragmentare în cazul pachetelor de date mai mari, pentru a le adapta la lațimea canalului. Setul de standarde nu prevede o metodă de asociere a datelor personale achiziționate cu un profil personal. Probabil ar fi posibilă asocierea acestora de către manager într-un obiect DICOM, dar aceasta nu este prevăzută în nici un fel. În același timp, datele transmise de echipamentele de monitorizare nu conțin informații referitoare la persoana de monitorizat. Aceasta poate constitui o problemă în diverse situații; fie când același manager monitorizează mai mulți agenți provenind de la persoane diferite, fie, mai rău, în cazul în care un echipament de monitorizare se conectează accidental la alt manager (cazul sălilor de gimnastică, de exemplu, în care posibilitatea de a exista mai multe echipamente în aria de acoperire e mare, iar eventualitatea unor conexiuni wireless sau bluetooth deschise nu e de neglijat) . În această situație pot să apară atât rezultate eronate cât și acces neautorizat la date personale- acest din urmă caz favorizat, e drept, de neglijență. Limitarea intenției standardului la echipamentele de monitorizare personală este de asemenea discutabilă. Pe de o parte există echipamente de uz general care pot fi folosite cu succes atât în aplicații de monitorizare personală cât și în mediu profesional ( termometre, cântare etc) iar pe de altă parte existența a unor standarde separate pentru aparatura profesională ar fi nejustificată, atâta timp cât standardul este extensibil și nu are limitări principiale în ceea ce privește volumul de date, rezoluție sau viteză de transmisie. Dealtfel, există lucrări care propun extinderea standardului în domeniul clinic, precum [2.5] Nu vedem nici un obstacol în a extinde folosirea standardului în domeniul clinic sau la aparatură profesională, mai ales că la echipamentele din această categorie de obicei implementarea funcției de agent este mai ușor de implementat, acestea folosind de regulă procesoare mai puternice. Arhitectura unui sistem de monitorizare Pentru verificarea în practică a diverselor scenarii de conectare a dispozitivelor de monitorizare, s-a elaborat o schemă bloc a unui sistem de test, care să permită o comparație între diverse moduri de interconectare. Schema bloc din figura 1 conține un software de management central care va comunica atât cu dispozitive care au implementată functia de agent conform 11073 cât și cu dispozitive de monitorizare pe SNMP, de exemplu echipamente de monitorizare ambientală .  Cu s1 – s5 sunt definite dispozitivele efective de masurare. Se va avea în vedere studierea implementării unui concentrator pentru a prelua datele de la senzorii care nu sunt x73 -capabili prin alte protocoale de nivel mai scăzut ( i2c, x10), în figură s1-s3 . Acesta va implementa funcția de agent pentru fiecare mărime de măsurat. Pe schema bloc mai apare un dispozitiv analizor de date. Acesta va fi un modul separat, care va comunica printr-un protocol IP cu unitatea de management. Rolul lui va fi acela de a analiza datele monitorizate cu ajutorul unor algoritmi inteligenți, pentru a genera alerte sau în alte scopuri definite de către operator. Bibliografie generală 1.1. Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. 1.2. McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1.3. Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009. 1.4. Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 1.5. Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. 1.6.Tanenbaum, Andrew S. ; Wetherall, David J. - Computer networks [Text tipărit] / Andrew S. Tanenbaum, David J. Wetherall . - Boston ; Columbus ; Indianapolis [etc.]:Pearson Education, 2011 . - 951 p. : fig., tab. ; 23 cm
1.7. Liţă, Ioan ;Bănică, Logica-Protocoale de comunicaţie în Internet / Ioan Liţă, Logica Bănică . - Bucureşti : Matrix Rom, 2007 . - 156 p. : fig., tab. ; 24 cm 1.8. Peterson, Larry L. ; Davie, Bruce S. - Computer networks [Text tipărit] : a systems approach / Larry L. Peterson and Bruce S. Davie . - Amsterdam ; Boston ; Heidelberg [etc.] : Morgan Kaufmann, c2012 . - XXXI, 884 p. : fig. ; 24 cm 1.9. ISO/IEEE 11073 Committee. Available at: http://www.ieee1073.org. Bibliografie specifică 2.1. Lasierra, N, Alesanco, A,Garcia, J. (2012). An SNMP-based solution to enable remote ISO/IEEE 11073 technical management. IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, 16(4), 709-719. doi:10.1109/TITB.2012.2193409 2.2. Kermes, K. M., & Moorman, B. A. (2010). IEEE 11073 standards address remote monitoring market. Biomedical Instrumentation & Technology, 44(4), 339-45. 2.3. Yao J, Warren S. Applying the ISO/IEEE 11073 standards to wearable home health monitoring systems.J Clin Monit Comput 2005; 19: 427–436 i Yüklə 53,75 Kb. Dostları ilə paylaş:
|