Приложение на CORBA



Начало
Общи сведения за CORBA
OMG и архитектура на CORBA
Обектен модел на CORBA
Езикът IDL
Проект BioStandards
Приложение на CORBA в пациентските регистри
  • Общи данни
  • Методи за реализация
  • Резултати
  • Приложение на CORBA в телероботиката
     
     

    2. Методи


    2.1. Заявка чрез CORBA базиран двигател.

        За обмена на данни за пациенти между множеството бази данни и институти посредством интернет, трябва да има двигател за заявка, който да приеме или създаде заявка към базата данни, да предаде заявката към определената база данни, да я изпълни в определената база данни и да върне резултата от заявката. Тъй като CORBA е подход за работа с разпределени обекти за стандартизиране на мрежово-разпределени софтуерни компоненти, в който един или повече от компонентите са заключени в сървъра на базите данни, а други компоненти са разпределени в workstations, то има много предимства от изграждането на двигател за заявки в такава среда. Създаден бе базиран на CORBA двигател за заявки, който съдържа клиентска, сървърска и обслужваща част и използва или булев достъп (потребителите формулират своите заявки като комбинация от ключови думи) или базиран на hypertext достъп (заявките се създават автоматично, в зависимост от клиничния контекст). Клиентската част е предназначена за приемането на заявки от потребители или автоматичното създаване на заявки според клиничния контекст и служи за показването на резултати в потребителския интерфейс. Сървърската част служи за получаване на заявки, минали през Посредника при запитвания за обекти (Object Request Broker, ORB) и за изпълнението на заявките в подходяща клинична база данни. Обслужващата част е за обработването на информация, свързана със заявката, осигурява някои общи функции и поддържа контрола на съобщенията. Модела на заявката се базира на създадения от OMG IDL и се състои основно от име (на данните), ID на пациент, временна информация, ID на болницата, искаща заявката и ID на болницата – цел. Създаден бе компонент, наречен Domain Quiry Proxi, който служи за комуникационен център за изпълняваните заявки. Докато съществува нужда от обмен на данни между една и друга система или между две институции трябва да има и стандарти за обмен на данни. Ето защо CORBA съобщенията за двигателя за заявки трябва да бъдат стандартизирани. За ЕКГ данните съобщенията бяха създадени в съответствие със Standard Communication Protocol за компютърнa електрокардио-графия (SCP-ECG). За клиничните данни бяха временно дефинирани техните CORBA съобщения според принципа на проблемно–ориентираните медицински записи, т.к. текущо се използва опитна база данни и все още не са на разположение моделите за информация на CORBA съобщенията в съответствие с Health Level Seven (HL7). Друга важна цел, нуждаеща се от стандартизация е местното време. Когато данните за пациентите се съхраняват в база данни, повечето системи съхраняват тези данни с местното си време. Времето на CORBA съобщенията на временните данни на Universal Coordinated Time (UCT) бе унифицирано. Общите термини като ECG, EKG и електрокардиодрама бяха стандартизирани с Unified Medical Language System (UMLS).

    2.2. Mapping на пациентските ID – та чрез сравнение на атрибутите на пациентите и компютърно-базирана проверка.

        За да бъде създаден механизъм за mapping между различните ID – та на пациенти между множество системи и институциии и за да бъде възможно стандартизирането им за в бъдеще бе използвана CORBA средата и бе създаден обектен модел на предаване на ID – та на пациенти. Този модел включва Транслатор на пациентски ID - та и някои сървъри с атрибути на пациентите (фиг.1). Сървърът, съхраняващ атрибути на пациентите, разположен във всяка болница може да достига до данните за пациентите, регистрирани в базата данни за регистрирани пациенти, както и до други данни (кръвна група, навици, семейна история, история на предишни заболявания и т.н.), които се съхраняват в клиничните бази данни. Когато Domain Query Proxy получи заявка от определена болница, той предава ID – то на пациента, ID – то на болницата, която подава заявката и това на болницата, към която е изпратена тази заявка към транслатора на пациентски ID – та. Последният свързва IDL интерфейсите на сървърите с пациентските данни на двете болници (тази, която прави заявката и тази, към която е отправена) в реално време или алтернетивно достига до база данни за търсене по ID, в която предварително са съхранени записи с цел да транслира пациентски ID – та, използвани в болницата, която подава заявката към тези, използвани в болницата, към която е отправена съответната заявка. След това Domain Query Proxy използва транслираните пациентски ID – та, за да получи данните за пациенти от болницата, към която е отправено запитването.

    Фигура 1. Описание на модел на транзакции на ID-та на пациенти

        При модела за транслации на пациентски ID – та една от най-важните задачи е да бъде елиминирана двусмислеността на съществуващите пациентски идентификатори. Вероятностния алгоритъм на свързване е един от най-полезните методи за намаляването и елиминирането на двусмислията, но за този метод има някои съмнения по отношение на употребата му за идентифицирането на пациентите в клиничната практика, като напр. ”Какво в същност означава да се каже, че някой е 97% като друг?”. Това се дължи главно на реалната ситуация при идентифицирането на пациенти в клиничната практика. Лекарите биха искали определянето на това дали двама пациенти са идентични да е абсолютно точно. Тази ситуация налага намесата на известна човешка преценка. Поради тези причини се смята, че компютърно-базираната проверка от човек, използваща технология на взаимодействие човек-компютър е оправдана и осъществима за елиминирането на двусмислия при сравнението на пациентски данни в клиничната практика. Важни атрибути на пациентите като име и пол и дата на раждане, застрахователна информация или други специфични идентификатори като SSN в САЩ се сравняват първо автоматично. Ако тези данни за пациенти съвпадат напълно, то всички данни за пациента директно се получават от всички институции и се показват в потребителски графичен интерфейс (таблица), където са на разположение за справки от потребителите. Резултатът се съхранява в база данни за търсене по ID, от където може да бъде използвана отново. Този вид сравнение може да бъде направено в реално време от лекарите в кабинетите за консултации и/или да бъде осъществен предварително от определени групи от болничния персонал. Проверката в реално време обикновено е приемлива за лекарите и пациентите, т.к. трябва да бъдат сравнени краен брой пациенти, чиито имена, пол и дата на раждане или застрахователен номер (или SSN в САЩ) са подобни на тези на текущия пациент и не се налага повторна проверка от човек след като резултатът бъде съхранен в базата данни за търсене по ID. Компютърно –базираната проверка от човек в CORBA средата не се влияе от качеството на компютърната система, т.к. тя е различна от проверката от човек на данните на хартиен носител, при която обработката е основно ръчна.

        Коректността на сравнението на атрибутите на пациентите плюс компютърната обработка от човек е напълно надеждна. Ако има достатъчно данни, коректността на човешката преценка за това дали два пациента са идентични следва да е 100%. Обикновено данните за пациента, съхранявани във всяка институция могат да потвърдят неговата самоличност, въпреки че регистрацията на данни за пациенти все още не е стандартизирана. Изследванията на регистрации на данни в голям брой японски здравни институции показват, че всички включени в проучването болници пазят информация за името на пациента, пол, дата на раждане, адрес, домашен телефонен номер и застрахователна информация. Повечето от тях регистрират и възраст, пощенски код и занимание, някои регистрират и адрес и телефон за спешен случай, а други пазят информация за местораждане, организация и служебен телефонен номер. Общата регистрационна информация, както и някои други данни за пациента като кръвна група , навици, семейна история и история на минали заболявания, които се съхраняват в клиничните бази данни служат за основа на човешката преценка. Ако някои данни за пациентите (адрес, занимание и др.) липсват или се различават, то лекарите, пациентите или някой друг могат да преценят на базата на своите знания. След като при човешката проверка за данните за даден пациент се използват данните от всяка институция директно в CORBA средата и с подходящ графичен интерфейс, то за потребителите е по-лесно да формират коректна преценка.

    2.3. Свързване на данни чрез временен mapping.

        В медицинските записи подобни пациентски данни могат да бъдат свързани едни с други чрез временен mapping, т.к. всички пациентски събития се случват по време, от което лекарите зависят за записването на данни, поставянето на диагноза и назначаването на лечение. От гледна точка на mapping –а на случаите има основно три типа на временна информация. Първият тип имаме когато например: “На пациента е направено 12-то ECG на 12.01.05”, при този тип временната информация се отнася към времето на ЕCG случаите, без значение на това какви клинични събития настъпват. Вторият тип е непряка временна информация, като например “ На пациента е направено ECG изследване през миналата година”. При него временната информация първо се отнася към времето на клиничните събития за определяне на границите на mapping и тогава се отнася към един от ECG случаите. Третият тип е липсата на временна информация, когато например лекарят отбелязва в забележки: “Да се извършат ECG изследвания”. В този случай mapping –а към ECG събитията изцяло зависи от клиничните събития. От друга страна това колко ECG събития ще се map - ват зависи от грануларността на временната информация. Ако времевата гранулация е достатъчно добра, то съответното ECG събитие може да бъде map –нато директно. Ако се осигури по-груба грануларност, то е възможно да се map –нат странични ECG случаи. Възможно е също така никой ECG случай да не бъде map –нат по причина на записването на приблизителна или неточна временна информация, напр. ако пациентът си припомни приблизителната дата на последното си посещение в друга болница или когато лекарят по някаква причина промени времето за планиран следващ преглед и не го коригира в забележката.

        Пациентскте ID –та и временната информация за динамично свързване бяха използвани и приложени във временен съждителен метод за интегрирането на клиничната информация. Бяха разработени и различни временни съждителни функции за работа с различни типове данни и различни грануларности на временната информация. Бяха създадени също така и редица временни mapping – и за сравнение на данните на случаи между различните хетерогенни бази данни. Примери за временен метод са първоначален и вторичен mapping, контекстуален mapping, разширен mapping, следващ и предходен mapping– всички те формират основите на метода за динамично свързване. Всички свързвания започват с първоначален mapping, базиран на съждения за долните и горни граници за mapping. Този mapping има три възможни резултата : съществуват една, много или нула данни между горната и долната граница. Резултатът от първата възможност е проста връзка и ефективността е подобна на тази на предефинирана връзка. Втората възможност е разширена и многопосочна връзка и контекстуален mapping (използва се времето на получаване на данните за изследвания в рамките на долната и горната граница на дадена временна информация, за да бъде сравнено и се показва информация за съответния клиничен кантекст), както и вторичен mapping – те са необходими за достигането на целевите данни. Третата възможност може да се случи в някои много редки случаи и не означава, че свързването е провалено. Въпреки, че текущите горни и долни граници не покриват съответните данни, те осигуряват белег за търсенето на целевите данни. Една от ролите на разширения mapping (сравнение на данните чрез разширяване на долната и горната граница на временнта информация) и mapping –а на предходни и следващи на текущия случай е изпълнението на този тип процес.

        По чувствителност и специфичност на динамичното свързване само по себе си то е еднакво на предефинираното свързване. Ако изразяваме връзка към ECG запис, който е направен на 1996/08/06 в 10:10:20 за пациент с ID : 1000413502 и е записан с ECG ID като 12345 в SQL (Struktured Query Language) изразите за предефинирана връзка (а) и за динамична връзка (б) ще бъдат:

     а)  SELECT ECG FROM ECG_DB
    	  WHERE ECG_ID=’12345’;
    
     б)  SELECT ECG FROM ECG_DB
    	WHERE Patient_ID= 
     	 ‘1000413502’ AND 
    	Aquisition Time >=
    		“1996/08/06 10:10:20” AND 
    	Aquisition Time <=
    		“1996/08/06 10:10:20”. 
    

        Резултатите от тези два израза са еднакви както в термините на релационните бази данни, така и на оебктно-ориентираните бази данни, т.к. посочването на специфичен запис за пациентско ECG с време на придобиването му при първата грaнуларност (1996/08/06 10:10:20) в базата данни има същата чувствителност и специфичност, както и употребата на ECG ID (12345). Връщането на друг запис за ECG не може да се осъществи при клиничните информационни системи. Трябва да бъдат взети предвид единствено предимствата и недостатъците на методите. Предефинираните връзки например могат да бъдат с предимство при прости връзки, понеже те са достатъчно уникални и обикновено са по-бързи при запитвания за единични записи от бази данни, но презумцията е, че това лице или група от лица, чиито ID се използват в търсенето, трябва да бъдат получени предварително. Това се отнася за ситуация, при която ID –та на единични данни са лесно транслирани. В кличничните информационни технологии това дефиниране има предимство при назначаването на преглед, или оценка на мултимедийни данни; така например системните дизайнери обикновено избират този метод когато свързват оценките от ECG данни със съответния ECG запис. В този случай ID –то на ECG може да бъде отнесено към оценката на автоматичния или ръчен ECG запис.

        Метода на динамичното свързване има много предимства пред предефинираното свързване. Той може да замени предефинираното свързване с проста връзка. Долната и горната граници на временната информация могат да бъдат разширени чрез даването на по-груба грануларност с цел повече данни да могат да бъдат сравнявани. Временната информация, използвана в свързванията може да е осгиурена както чрез компютърно, така и чрез човешко действие и по тази причина записването на клиничните данни заедно с хипертекстови връзки има голямо предимство. Когато лекарите записват клинични данни, особено такива като история на заболяването, забележки и указания, свързани с различни медицински обекти като ECG, рентгенови снимки и т.н., те могат да посочат временна информация в някаква степен на грануларност (понякога пропускат да го правят), ако клиничният контекст може да определи времето; те имат възможността да дават ID –та на тези данни директно. В клиничната практика даването на по-груба грануларност понякога е необходима за данни за пациенти които са в клиничен период и понякога по причина на някакви клинични особености.

        Ако от една връзка се извлекат много данни за един пациент, това не означава, че част от тези данни са некоректни. Така например, ако лекарят провери ECG в частта данни от “На пациента бе извършен ECG преглед през октомври 1996 г.” при първия mapping ще се върне за всички времена, по които са направени записи за ECG през м. октомври 1996г., за да се види колко ECG записа са направени през този период и какъв е техният клиничен контекст. Само по себе си динамичното свързване никога не пропада, ако информацията, асоциирана с него е коректна. То позволява на лекарите да получат целевите данни, ако граниларността й е достатъчно добра за идентифицирането й от останалите. Динамичното свързване може да бъде използвано и за разрешаването на проблеми, касаещи некоректна временна информация, която е била записана случайно.