Особливості в проектуванні та практичній розробці медичної інформаційної системи.
Гусєв А.В., член-кор. РАМН Дуданов І.П., Романов Ф.А., Дмитрієв А.Г., Карельський науково-медичний центр СЗО РАМН, Петрозаводськ
Однак при глибшому вивченні цього процесу все сильніше виділяється істотна проблема: незважаючи на наявність глибоко опрацьованих програмних рішень, практично відсутня досвід повного переходу на електронний принцип зберігання та обробки інформації в лікувальному закладі [8, 11]. Є ряд серйозних перешкод, через які не можуть переступити навіть сучасно оснащені клініки у своєму прагненні відмовитися від паперових носіїв інформації та підвищити ефективність в організації своєї роботи. Усі вони можуть бути об'єднані у кілька груп.
По-перше, існуюча в Україні правова база не забезпечує належного рівня юридичного захисту медичних працівників, які застосовують інформаційні технології у повсякденній практиці. По-друге, фінансові ресурси більшості закладів охорони здоров'я поки що не можуть дозволити їм придбати достатню кількість комп'ютерної техніки та дорогого програмного забезпечення для комплексної автоматизації. Тому цей процес успішно протікає лише в деяких, найчастіше далеких від медичної спрямованості, розділах роботи ЛПЗ: статистика, бухгалтерія, автоматизація роботи адміністративної ланки і т. д. По-третє, в Україні практично відсутня школа, яка б готувала професіоналів високої рівня в галузі розробки та впровадження саме комплексних медичних інформаційних систем, людей з визначення працюючих на стику найскладніших наук – медицини та прикладної математики. Для становлення вітчизняної школи у цій галузі творчим колективам необхіднообмінюватися спостереженнями та думками у розробці програмних продуктів, накопичуючи тим самим спеціальні знання та формуючи потенційно вигідні напрямки у пошуку ефективних рішень розробки та впровадження комплексних МІС.
По-перше, однією з найсуттєвіших причин збільшення вартості МІС ми вважаємо високу вартість самої розробки. Вивчивши причини цього явища, ми дійшли висновку, що не останню роль у цьому відіграла традиція створення медичних інформаційних систем на основі так званих АРМ-ів (автоматизованих робочих місць). Причому найчастіше під АРМ розуміється саме клієнтське програмне забезпечення, хоча спочатку цей термін мав ширше тлумачення [10]. Найчастіше розробка АРМ-ів ведеться за такою методикою: розробники обирають деяке загальне завдання (наприклад, створення електронної історії хвороби для стаціонару), проектують структуру бази даних, розробляють додаток до роботи з нею. Нерідко ця програма виконується у вигляді кількох версій - АРМ головного лікаря, АРМ реєстратора, АРМ лаборанта і т. д. Розробка систем у 65% випадків ведеться на Borland Delphi. При цьому навіть на випуск сирої версії АРМа витрачається 4-8 місяців. Потім стільки часу йде на обкат-ку. Разом з тим, за нашими оцінками, розробнику доводиться 10-20% часу витрачати створення специфічного для медичної області коду. Решта, причому найбільш трудомістка і відповідальна, припадає на розробку механізмів, що забезпечують цілісність даних, підсистему безпеки та адміністрування МІС, зв'язок з периферійним медичним обладнанням і т. д.
Однак, не викликає сумнівів, що ці рішення значно поступаються промисловим рішенням для корпоративного ринку, над якими працюють кращі фахівці і якіпройшли багаторічну перевірку. У зв'язку з цим викликають подив подібні спроби "винайти велосипед". На наш погляд, розробка МІС не повинна здійснюватися створенням та подальшою інтеграцією окремих АРМів. Для створення МІС необхідно застосовувати готові програмні платформи для групової роботи, які вже мають у своєму арсеналі потужні засоби для мультиплатформної розробки програми, готові технології для розгортання та управління підсистемою безпеки. У своїй роботі ми вибрали пакет групової роботи Lotus Notes / Domino, що розробляється в даний час корпорацією IBM. Ця платформа є за кордоном стандартом "де факто" для створення потужних інформаційних систем, орієнтованих на обробку електронних документів і ми вважаємо, що вона найбільше підходить для створення медичних інформаційних систем.
Другим важливим рішенням стала відмова від проектування бази даних МІС за функціональним призначенням, коли для окремого завдання (наприклад, підсистема лабораторії, функціональної діагностики, консультаційна і т. д.) створювалася своя база даних. Хоча такий підхід має ряд переваг, головним з якого є зниження вимог до апаратної потужності сервера за рахунок поділу потоків запитів користувача до окремих БД. Однак було обрано проектування БД МІС у такий спосіб, що вся інформація збиралася навколо пацієнта та зберігалася фізично в одній БД.
Однак кількість таких БД у МІС є варіабельною і залежить від кількості функціональних груп користувачів, що є в ЛПЗ. Так, у стаціонарі це може бути виділена БД для кожного відділення чи корпусу. Для поліклініки - це може бути БД, розділені на ділянках обслуговування. Крім того, в цих БД спеціальним чином зберігається тільки актуальна інформація, адані, що не використовуються, містяться в БД архіву. Для вирішення низки завдань може бути прийнята або пов'язана з об'єктно-орієнтованим ядром реляційна БД, або спеціальним чином сконструйовані уявлення, які ми називаємо регістрами (рис. 1).
Мал. 1. Укрупнена схема об'єктно-реляційної бази даних медичної інформаційної системи
Проектування структури БД, таким чином, дозволяє досягти стабільно малого обсягу БД МІС протягом практично всього терміну її експлуатації, а тим самим забезпечити максимально можливу продуктивність роботи МІС. Так, починаючи з 1999 року, база даних історій хвороби пацієнтів, які проходять реабілітацію в медичному центрі, має об'єм 26-29 Мбайт. При цьому всю інформацію за час роботи центру збережено, а швидкість роботи залишається стабільно високою. Складністю зазначеної методики є те, що програмне забезпечення інформаційної системи має підтримувати будь-яку кількість фізичних баз даних у ядрі системи, об'єднаних в одну логічну структуру.
Таким чином, необхідно розробити алгоритми всіх програм МІС так, щоб вони могли коректно працювати з базою даних поточних документів, що складається з однієї або кількох частин. Це викликано тим, що у деяких випадках програмам необхідно обробляти дані як окремої частини бази даних, а й у всієї наявної у ній інформації. У зв'язку з цим перед кожним зверненням до сервера необхідно виконувати ряд послідовних кроків:
визначити, скільки фізичних баз даних та його імен відповідно установлено на сервері;
визначити можливість доступу до кожної бази даних окремо;
обробити та запам'ятати отриману відповідь;
повторити кроки 2-4 кожної бази даних;
скластинакопичені відповіді та обробити їх, як єдиний пакет інформації.
Використання однотипного програмного коду у різних підсистемах МІС
">