Проблеми збереження та обробки медичних даних в
регіональної телемедичної інформаційній системі ХМАО
А.Л. Царегородцев, Югорський
науково-дослідний інститут
інформаційних технологій, м. Ханти-Мансійськ
Проблема
підвищення якості медичної допомоги є пріоритетним завданням нашого
суспільства і займає одне з центральних місць у політиці Російської держави.
Особливе значення має можливість інтеграції інформаційних систем і систем
телекомунікацій як засобу підвищення ефективності медицини за рахунок більш
інтенсивного розвитку телемедичних технологій, що забезпечують медику
віддалений доступ до сучасних медичних ресурсів, в тому числі,
міжнародним.
Основними
причинами, що перешкоджають очним медичним консультацій в окружних і
федеральних центрах є: важкий стан здоров'я пацієнта, висока
вартість проїзду та проживання, неможливість тривалого відсутності на роботі,
відсутність транспортного сполучення і т.д. З тих же причин обмежені
можливості в отриманні різних видів високоспеціалізованої
консультативної медичної допомоги у жителів найбільш віддалених районів, навіть
якщо такі консультації можуть бути надані в регіональних медичних центрах.
Одним
з головних достоїнств телемедицини є можливість наблизити
висококваліфіковану і спеціалізовану допомогу працівників провідних
медичних центрів до віддалених районах і, тим самим, суттєво заощадити
витрати пацієнтів. Все вище сказане обумовлює актуальність проведення
досліджень і розробок регіональних телемедичних інформаційних систем.
Регіональна
Телемедична Інформаційна Система Ханти-Мансійського автономного округу
(РТІС ХМАО) - це територіально розподілений програмно-технічний
комплекс, що дозволяє проводити телеконсультації медичних відеозображень і
супровідної інформації про пацієнта в режимі відстрочених телеконсультацій допомогою
електронної пошти.
Комплекс
складається з серверної і клієнтської частини. Серверна частина забезпечує роботу по
організації взаємодії між консультантами і консультуються. Вона
включає в себе СУБД «Oracle», www-сервер, поштовий модуль «Оброблювач пошти»,
сервер оновлень, АРМ «Адміністратор», а також web-програми: АРМ
«Координатор», АРМ «Консультант On-line» і АРМ «Статистика». Клієнтська частина
включає в себе АРМ «Консультант/консультованого», підсистему «Перинатальний
аудит »і апаратну частину, комплектуемую залежно від потреб
консультованого лікаря. Вона може містити мікроскоп, відеокамеру, комп'ютер з
платою відеозахоплення, сканер, фотоапарат і т.д.
Традиційний
підхід до розробки бази даних РТІС спирається на реляційну модель
представлення даних. Однак, як відомо, реляційна модель передбачає
точне знання структури збережених даних. При використанні реляційної моделі
всі рядки в будь-якій таблиці бази завжди мають однаковий набір полів, крім
того, заголовки стовпців, первинні ключі в таблицях і т.д. повинні бути
визначено заздалегідь. З появою даних з новою структурою, не зустрічалася в
реляційної базі до цього моменту, в схему бази необхідно вносити зміни
або навіть повністю перебудовувати всю її структуру.
Інша
характерна особливість РТІС полягає в тому, що вона є розподіленою
системою, у зв'язку з чим, виникає задача інтеграції розподілених даних.
Проблема полягає в тому, що навіть при об'єднанні джерел, дані яких
добре структуровані, не завжди вдається створити жорстку структуру для
отриманих сумарних даних.
Таким
чином, для організації зберігання та обробки медичних даних потрібна
вирішити дві проблеми:
§
проблему управління медичними даними, що мають нечітку, «розмиту»
структуру;
§
проблему інтеграції медичних даних з різних джерел.
Розглянемо
основні особливості медичних даних.
1.Неправільная
структура. У різних джерелах даних одні й ті самі сутності реального світу
можуть моделюватися за допомогою різних структур і типів даних. Так, наприклад,
запис в медичній карті для одного пацієнта може містити перелік
щеплень, для іншого - показники росту і ваги, для третіх - операції,
який йому зробили. Інший приклад, технічні характеристики медичних
приладів описуються параметрами, якісно відрізняються у різних моделей.
При об'єднанні різнорідних джерел можна спробувати сконструювати нову
структуру, що включає в себе всі різнорідні дані. Однак при великій кількості
джерел створення такої єдиної структури може натрапити на нездоланні
технічні труднощі, або ця структура виявиться настільки складною, що її
використання стане неефективним. Якщо відмовитися від спроб створення
структури, загальною для всіх даних, то інтегровані дані будуть мати
неправильну структуру.
2.Неявная
структура. Значна кількість медичних даних, хоча і має деяку
структуру, але ця структура неявна. Наприклад, медичні дані підсистеми
«Перинатальний аудит» РТІС ХМАО включають в себе дуже велику кількість різних
показників, класифікація яких не розроблена. Крім того, медичні
дані іноді мають невідому структуру, прикладом чого можуть служити
мультимедійні дані або документи з структурованим текстом.
3.Частічная
структурованість. У ряді випадків більша частина медичних даних, роботу з
якими необхідно автоматизувати, мають чітку структуру. Для зберігання цієї
частини даних використовують традиційні системи керування базами даних і
розробляють методи зв'язку структурованих даних з даними, що залишилися,
які не вдалося структурувати і які доводиться зберігати не в базі
даних, а в інших системах, наприклад, у файловій системі.
4.Частое
зміна структури. Структура медичних даних часто змінюється. Прикладом
можуть служити медичні звіти, в яких кожен рік одні показники
додаються, а інші зникають.
5.Апостеріорная
структура медичних даних. Як відомо, традиційні СУБД використовують жорстко
фіксовану структуру даних. У таких СУБД спочатку описується структура бази
даних і тільки потім база наповнюється даними. На наш погляд, при роботі з
медичними даними доцільно застосовувати зворотний підхід: спочатку
заповнюється база даних, і в процесі заповнення визначається її структура.
Системи, що працюють за останнім принципом, називають системами з апостеріорного
схемою. Використання такого підходу, дає більшу гнучкість при формуванні
бази і надає можливість вільно змінювати її структуру.
Проведений
аналіз характерних особливостей структури медичних даних і попереднє
планування бази даних РТІС ХМАО з використанням функціональних діаграм і
діаграм потоків даних дозволяє зробити висновок про те, що медичні дані
слід розглядати як полуструктурірованние дані, які здатні
динамічно змінювати свою структуру, свій склад і тип.
Відомо,
що полуструктурірованние дані складно зберігати в реляційної бази даних,
оскільки в цьому випадку виникає або багато різних таблиць, або
проектується єдина таблиця з безліччю порожніх колонок. І те, і інше
негативно позначається на тривалості часу пошуку даних і підтримки їх
цілісності в базі. «Полуструктурірованние дані дуже легко зберігати як XML,
і вони чудово підходять для XML-баз даних »[1].
В
зв'язку з цим база даних РТІС ХМАО розроблялася нами не як реляційна, а
як XML-база даних. Даний підхід заснований на технології XML (eXtensible Markup
Language - розширювана мова розмітки), яка, по суті, є синтаксисом,
що дозволяє створювати мови розмітки (схеми), що описують дані.
«Використання
XML-контейнерів для зберігання різних медичних параметрів призводить до
різкого скорочення числа таблиць, відпадає необхідність у глибокій ієрархії
даних, що, у свою чергу, призводить до збільшення швидкості доступу до бази
даних. У цілому, при виконанні запитів над ієрархічними даними, в яких
з'єднання потрібні тільки для відтворення ієрархії, XML-СУБД є
ефективніше реляційних »[1].
В
закінчення хотілося б навести приклад, - діагноз пацієнта, що знаходився в
реляційної базі в декількох десятках таблиць, при використанні
XML-контейнерів прийняв такий вигляд:
<(8D4FA29A-F9D9-4C6B-99E4-D8728C8AE715)
Version = "1.0">
Всі
XML-контейнери будуються за спільною ознакою. У перші декларації вказується тип
документа - XML - і наводиться додаткова інформація про нього. Спочатку
вказується версія XML-документа, після версії документа вказується кодування.
Оголошення кодування вказує набір символів документа. За замовчуванням
вважається, що документ XML має кодування UTF-8 (8-розрядний Unicode) або
UTF-16 (16-розрядний Unicode). Якщо у документа один з названих кодувань,
цей атрибут можна не задавати. Атрибут «encoding» повинен знаходитися в самому
початку документа. Як і весь документ, оголошення чутливе до регістру
символів [2].
Друга
декларація - це ідентифікатор GUID (Глобальний Унікальний Ідентифікатор), він
створюється ядром у такий спосіб, щоб гарантувати унікальність в часі і
просторі. Остання декларація - це теж унікальний ідентифікатор GUID
XML-документа, що показує, що опис діагнозу закінчено. Між другим і
останньою декларацією вказані безпосередньо дані по діагнозу пацієнта.
Таким
чином, застосування полуструктурірованного підходу з використанням
XML-контейнерів для зберігання різних медичних параметрів дозволяє:
§
спростити структуру бази даних і, як наслідок, збільшити швидкість доступу до
базі даних;
§
зменшити час пошуку даних в базі за рахунок відсутності глибокої ієрархії
даних;
§
отримати можливість гнучкого зміни структури бази даних;
§
спростити приведення медичних даних до загальній структурі при спробі
інтеграції їх з різнорідних джерел даних.
Список літератури
1. Ronald Bourret, XML and
Databases, http://www.rpbourret.com/xml/XMLAndDatabases.htm.
2.
Тревіс Б. XML і SOAP: программирование для серверів BizTalk. Найновіші
технології/Пер. з англ. - М.: Видавничо-торговий дім «Російська редакція",
2001. - 496 c.
Для
підготовки даної роботи були використані матеріали з сайту http://www.techno.edu.ru
