CC BY
80
УДК 681.3.06(075.8)
М.В. КОНОНОВ, О.О. СУДАКОВ
АРХІТЕКТУРА РОЗПОДІЛЕНОЇ ІНФОРМАЦІЙНОЇ СИСТЕМИ МЕДИЧНОГО ПРИЗНАЧЕННЯ ДЛЯ РОБОТИ В УМОВАХ НЕНАДІЙНОГО ЗВ’ЯЗКУ
Abstract: Architecture of distributed information system for telemedical consultations is proposed. The system is oriented on usage of slow and unstable communication channels. The primary usage of proposed system is telemedical care of population from distant regions and for screening people suffered from Chernobyl Accident. Protocols for information storage and transfer is described, block-schema of algorithms for data consistency and crash recovery is considered, database structure is presented.
Key words: телемедицина, телеконсультации, распределенная система, база данных.
Анотація: Запропонована архітектура розподіленої інформаційної системи телемедичних консультацій, яка орієнтована на використання повільних та ненадійних каналів передачі інформації. Система призначена для телемедичного забезпечення населення, що проживає у віддалених районах, а також для скрінінгового обстеження людей, постраждалих від аварії на Чорнобильській АЕС. Наведено опис форматів збереження та протоколів передачі інформації, блок-схеми алгоритмів забезпечення цілісності інформації та відновлення в результаті збоїв і опис структури бази даних.
Ключові слова: телемедицина, телеконсультації, розподілена система, база даних.
Аннотация: Предложена архитектура распределенной информационной системы телемедицинских консультаций, которая ориентирована на использование медленных и ненадежных каналов передачи информации. Система предназначена для телемдицинского обеспечения населения, проживающего в отдаленных районах, а также для скрининговых обследований людей, которые пострадали вследствие аварии на чернобыльской АЭС. Приведены описания форматов хранения и протоколов передачи информации, блок-схемы алгоритмов обеспечения целостности информации и восстановления в результате сбоев в работе, описания структуры базы данных.
Ключевые слова: телемедицина, телеконсультации, распределенная система, база данных.
1. Вступ
Розробка й впровадження телемедичних технологій у клінічну практику є актуальною задачею для підвищення рівня медичної допомоги населенню [1], раціонального використання інфраструктури медичних установ різного відомчого підпорядкування, взаємодії з телемедичними службами інших країн, розвитку виробництва засобів телемедицини.
Одним з найактуальніших напрямків застосування телемедичних технологій є телеконсультації типу лікар-лікар. Ці системи дозволяють лікарям отримувати консультації інших спеціалістів, які знаходяться на значній відстані. Такі системи, наприклад, знайшли застосування для збільшення ефективності і зручності телемедичної допомоги різних рівнів, консультативної допомоги для віддалених та різнопрофільних медичних установ (в тому числі закордонних), медичної допомоги при надзвичайних ситуаціях та катастрофах, медичної освіти та підвищення кваліфікації. Всі системи такого типу містять у собі інформаційні та телекомунікаційні засоби.
Головними вимогами до подібних систем є стабільність роботи, швидке відновлення в результаті збоїв програмного та апаратного забезпечення, робота в умовах повільних каналів зв'язку. Ці вимоги особливо ускладнюються у випадку необхідності проведення консультацій в режимі реального часу та при застосуванні графічної інформації.
Найпоширенішим підходом до розробки таких систем сьогодні є застосування стандартних засобів WWW-технологій. Проте такий підхід має значний недолік, пов'язаний з тим, що всі ці засоби, насамперед, орієнтовані на збереження даних з серверного боку, а також не дозволяють працювати при відсутності або поганій якості зв'язку.
У даній роботі запропонована архітектура системи телеконсультацій, яка розрахована на
проведення консультацій та ведення бази даних обстежень у випадках, коли робочі місця лікарів знаходяться в умовах відсутності або поганої якості зв'язку. Архітектура системи включає в себе протоколи передачі даних, алгоритми проведення консультацій та алгоритми відновлення в результаті збоїв каналів зв'язку і апаратного та програмного забезпечення. Запропонована система може бути легко інтегрована з іншими засобами телеконсультацій та ведення баз даних, зокрема, з тими, що орієнтовані на WWW-технології та SQL-системи керування базами даних (СКБД).
Запропонована в роботі архітектура використана для створення системи скрінінгових обстежень населення, що проживає в зоні відчуження в результаті катастрофи на Чорнобильській АЕС.
2. Засоби телемедичних консультацій
Узагальнюючи різні точки зору на телемедицину, можна визначити основні напрямки сучасної телемедицини для підвищення ефективності діагностики, лікування і профілактики, за якими можна очікувати найшвидшого прогресу в найближчі часи:
а) впровадження баз даних і систем пошуку діагностичної та іншої медичної інформації для широкого вжитку. Інформаційні сервери;
б) засоби розвиненої обробки інформації. Застосування потужних віддалених систем обробки;
в) застосування віддалених консультацій спеціалістів (як у відкладеному, так і в інтерактивному режимі);
г) застосування мобільних систем вимірювання і лікування при терапії;
д) застосування засобів телеметрії для фахових груп з підвищеним ризиком;
є) віддалена хірургія;
ж) системи тренування і підвищення кваліфікації медичного персоналу.
Для реалізації більшості з названих служб [1, 2] можуть використовуватись централізовані або розподілені ІС. Централізовані системи є зручними для надання інформаційних послуг, орієнтованих на асиметричний трафік, тобто відносно невеликі за обсягом запити зі зворотнім відправленням результатів пошуку у БД при умові відсутності частих корекцій умов пошуку. Такий режим доступу до інформації добре забезпечується web-технологіями з використанням універсальних браузерів. Обмежено такі системи можуть використовуватись і для накопичення та систематизації інформації при відносно нескладних структурах вхідної інформації.
Слабо централізовані розподілені системи більше підходять для формування мереж отримання діагностичної інформації, оскільки у цьому випадку накопичення у базу інформації виконується безпосередньо в діагностичних центрах, які між собою взаємодіють, виходячи з вимог передачі даних на конкретних пацієнтів.
Системи консультування реалізуються, як правило, незалежним чином для підтримки відкладеного та інтерактивного режимів. Відкладені консультації традиційно реалізуються off-line методами доставки інформації, наприклад, електронною поштою або через web-інтерфейс методами заповнення та обробки форм (в останньому випадку відповідь відправляється також засобами пошти). Для інтерактивних консультацій часто використовують універсальні програмно-апаратні засоби мультимедійних телекомунікацій. Такі методи добре працюють у випадку
консультативної хірургії, коли на перший план виходить вимога якісної передачі динамічного зображення реального часу, що вимагає утворення спеціалізованих консультативних вузлів, оснащених швидкими каналами. Однак така ідеологія не охоплює найбільш широкий сегмент потреб у віддаленому консультуванні.
Найбільш зацікавленими, з точки зору надання медичних послуг, є регіони з послабленою відносно середнього рівня розвитку технічною базою, а, відповідно, і з погіршеними телекомунікаційними можливостями [2]. Зазначимо, що ця особливість є характерною навіть для країн з максимально високим на поточний момент рівнем розвитку технічної інфраструктури. До цього можна додати також умови експедицій, віддалених місць роботи і проживання невеликих груп населення, для яких важко забезпечити як достатність медичної допомоги, так і відповідний рівень телекомунікаційного сервісу. Ще одним застосуванням телемедицини є зони ліквідації стихійних лих та техногенних катастроф, при яких значно порушується телекомунікаційна інфраструктура.
Таким чином, телеконсультативні системи значним чином повинні орієнтуватись на умови ненадійного або повільного зв'язку та відповідно на високий рівень буферування інформації, якісні методи стиснення, оптимізовані для роботи з специфічними для медицини типами інформаційних потоків.
Інформаційна система, яка береться як основа телеконсультативної служби, повинна забезпечувати проведення віддалених медичних консультацій з використанням графічної діагностичної інформації. Одночасно з цим повинні бути забезпечені зручні методи роботи з іншими типами діагностичної інформації, а також деякою супутньою інформацією, наприклад, оверлейними графічними об'єктами на діагностичних зображеннях, які виконують функцію визначення області інтересу, службових поміток, сегментації зображень з діагностичною метою (виділення поверхонь органів, пухлин тощо).
З точки зору роботи з текстово-цифровою інформацією, найбільш вживаною на поточний момент, є SQL-технологія [3], яка базується на використанні централізованого ядра (серверу) БД з інтерфейсом взаємодії з клієнтами на основі спеціальної мови SQL. Такі принципи будови ІС дозволяють забезпечити певну стабільність інтерфейсів, уніфікацію звернень, відносно якісну мінімізацію навантаження на канали інформаційної мережі при умові використання тільки текстово-цифрової інформації. З іншого боку, пряма взаємодія клієнтського процесу з ядром ІС за SQL-інтерфейсом вимагає достатньо надійного з'єднання, викликає потребу повторної передачі відносно великої кількості інформації при зміні умов фільтрації, навіть незначної. Така проблема знижує ефективність реалізації електронної історії хвороби при винесенні подібних систем на рівень вище клінічного закладу, тобто при переході з каналів локальної мережі на рівень глобальної мережі та особливо на комутовані канали. Особливі затримки можуть виникати при використанні БД для збереження зв'язаної з таблицями ресурсоємної інформації.
Альтернативою традиційних технологій централізованих баз даних є PACS-системи, орієнтовані на роботу саме з діагностичною графічною інформацією, однак вони також погано пристосовані до роботи в умовах ускладненого зв'язку. Сама розробка ідеології таких систем орієнтувалась скоріше на умови розвиненої у технічному плані клініки або об'єднання клінічних закладів при наявності надійного швидкого з'єднання. Таким чином, є потреба знайти компроміс між подібними реалізаціями ІС медичного призначення і доповнити їх методами роботи для оптимізації
використання в ускладнених умовах, характерних для традиційних сфер застосування телемедицини.
Використання найбільш вживаних web-технологій (протокол HTTP, універсальні браузери) для реалізації подібних ІС в більшості випадків не забезпечує умови мінімального навантаження на мережу через надзвичайно високий рівень повторного пересилання інформації при динамічній генерації відповідних інформаційних сторінок. Таким чином, є потреба розробки спеціалізованого протоколу прикладного рівня.
Виходячи з потреб використання для потреб комунікації каналів глобальних мереж та враховуючи сучасні тенденції узгодження методів використання каналів, слід орієнтуватись на стек протоколів TCP/IP. Відповідно є дві основні можливості реалізації транспортного сервісу - потоковий режим, який забезпечує протокол TCP, та дейтаграмний на основі використання протоколу UDP [4].
Ще однією складною проблемою при розробці ІС медичного призначення є складність формалізації медичної інформації. На відміну, наприклад, від бухгалтерського обліку та віддалених фінансових операцій, де можливі практично 100% формалізація і забезпечення цілісності інформації за рахунок використання транзакцій (об'єднання необхідної кількості елементарних операцій в одну макрооперацію, яка переводить БД у новий сталий стан, а при невиконанні частини транзакції виконуються повернення у попередній стан), значна кількість медичних даних погано формалізується. Навіть утворення міжнародних довідників та класифікаторів (номенклатури медичних термінів SNOMED, система клінічних кодів Ріда RCC, міжнародної класифікації хвороб) [5] не розв'язують цю проблему повністю, оскільки вимагають частих корекцій і доповнень, мають складну ієрархічну структуру, що ускладнює їх використання.
Навіть при роботі з текстово-цифровою інформацією у медицині спостерігається певна неоднозначність формалізації, деяка неузгодженість окремих стандартів. Як приклад можна навести велику кількість непарних (нестандартизованих) тегів у файлах діагностичних приладів. Ще складнішою є ситуація при використанні приладової діагностичної інформації, особливо графічної. Таким чином, класифікація медичної інформації вимагає гнучких методів додаткового настроювання ІС, в тому числі зі зміною формату таблиць і внутрішніх зв'язків БД у процесі експлуатації, використання складних методів обробки і пошуку, які не вкладаються в обмеження SQL-запитів.
Зауважимо, що такі особливості ІС медичного застосування, а також потреба інтеграції з програмним забезпеченням, яке безпосередньо працює з діагностичним та лікувальним обладнанням, вимагають орієнтуватись саме на ієрархічні розподілені системи.
3. Архітектура розподіленої системи телеконсультацій
Запропонована розподілена система [6, 7] розроблялась з урахуванням розглянутих вище вимог та недоліків, що притаманні стандартним рішенням. Вона основана на клієнт-серверній ідеології з використанням максимально можливої кількості стандартних рішень - SQL-сервер для збереження даних на ядрі, WWW-сервер для надання доступу на перегляд даних, стек протоколів TCP/IP для забезпечення телекомунікаційних потреб. Передбачений також імпорт даних зі стандарту DICOM. Схема системи показана на рис. 1.
Лікар - віддалений клієнт Лікар-віддалений клієнт Консультант-віддале ний клієнт
Рис. 1. Схема системи телеконсультацій Як видно з рис. 1, система складається з серверної та багатьох клієнтських компонент. Серверна частина включає в себе систему керування SQL-базою даних, WWW-сервер, файловий сервер та ядро системи. Всі ці компоненти є окремими підсистемами і можуть фізично працювати як на одній, так і на різних машинах. У будь-якому випадку для забезпечення швидкості та ефективності роботи ці системи повинні бути з'єднані швидкими каналами зв'язку. Основною компонентою системи є ядро. Ця підсистема відповідає за синхронізацію роботи всіх компонент системи, а також за синхронізацію з клієнтами. Віддалені клієнти можуть працювати з системою тільки через ядро. Ще однією функцією ядра є підтримка консультацій реального часу. Файловий сервер застосовується для збереження даних телемедичних обстежень, таких як зображення, та іншої інформації. В базі даних зберігається пошукова інформація, зв'язана з обстеженнями. Сервер WWW служить для доступу до інформації обстежень через систему WWW. Через цей сервер за допомогою WWW браузера здійснюється доступ до обстежень в режимі "тільки читання".
Клієнтські підсистеми орієнтовані на роботу як з локальної мережі, так і з використанням повільних та ненадійних каналів зв'язку. Алгоритми роботи клієнтів відповідають за відновлення в результаті збоїв апаратного та програмного забезпечення. Клієнтські підсистеми розраховані на роботу в режимі консультанта - лікаря, що дає консультацію, та в режимі лікарі, який бажає отримати консультацію. Ці режими відрізняються налаштуванням програмного забезпечення. Спрощений алгоритм функціонування ядра системи показаний на рис. 2.
Клієнт встановлює з'єднання з сервером за допомогою протоколу, орієнтованого на гарантовану доставку повідомлень, наприклад, ТСР [4]. При з'єднанні запускається завдання, що обслуговує даного клієнта, виконує аутентифікацію і авторизацію клієнта та розпізнає тип служби, яка необхідна клієнту. Після цього, у відповідності з типом служби передачі даних, запускається завдання обробки клієнтських команд, передачі файлів чи телеконференції. Кожен тип завдання у відповідності зі своїм призначенням отримує команди від клієнта, обробляє їх і відправляє відповідь. Одночасно з сервером може працювати велика кількість клієнтів.
_Обмн даним-і
Рис. 2. Схема функціонування ядра телемедичної системи Завдання клієнтських команд зв'язано з каналом керування, який по можливості підтримується у з'єднаному стані. Через цей канал надходять команди керування сервером та відповіді на запити клієнтів. Команди керування пов'язані з запитами до бази даних, запуском телеконференції чи ініціації сеансу передачі файлів. Завдання передачі файлів відповідає за стійку передачу файлів обстежень і відновлення цієї передачі в результаті збоїв. Передача файлів здійснюється паралельно до командного каналу. Завдання телеконференції відповідає за конференцію реального часу. Це завдання відповідає за обмін повідомленнями між учасниками конференції та за ведення протоколу конференції.
Елементи синхронізації роботи відповідають за доступ до спільних ресурсів даних і відправку повідомлень клієнтам про те, що відбулись певні події, наприклад, запущено телеконференцію.
Схему роботи клієнта показано на рис. 3. Клієнтське програмне забезпечення встановлено з боку всіх консультантів та користувачів системи. В задачу клієнта входять функції інтерфейсу користувача, забезпечення роботи в умовах відсутності та поганої якості зв'язку, відновлення в результаті збоїв апаратного та програмного забезпечення, підтримка цілісності інформації.
Клієнт складається з інтерфейсу користувача, системи ведення локальної бази даних клієнта і мережевого агента. Інтерфейс користувача забезпечує функції роботи користувача з системою, такі як перегляд та редагування графічної інформації, створення запитів на телеконсультацію. Система керування локальною базою даних забезпечує буфер інформації з боку клієнта. Інформація в локальній базі даних є копією частини інформації і в основній базі даних сервера. При відсутності зв'язку з сервером всі обстеження можуть записуватись в базу даних клієнта. Коли зв'язок відновлюється, клієнтська інформація синхронізується з сервером.
З’єднання З’єднання з сервером
Обмін даними
Інтерфейс користувача
Обмін даними-
-Обмін даними-
-► Спул директорія <4-
-Обмін даними-
Рис. 3. Схема роботи клієнта Мережевий агент забезпечує функції передачі інформації, відновлення зв'язку у випадку
збоїв каналу передачі, обробку команд користувача, передачу файлів обстежень з сервера та на
сервер і ведення телеконференції. Обмін інформацією, яка є критичною, що до втрати під час збоїв
апаратного та програмного забезпечення відбувається через спул-директорію, де всі повідомлення
зберігаються у вигляді файлів. Це інформація, що синхронізується між базами даних клієнта та
сервера, файли обстежень, файли запитів до бази даних на сервері, файли відповідей сервера.
Інформація, яка не критична до збоїв, наприклад, повідомлення телеконференції передається через
пам'ять спільного доступу. При перезавантаженні клієнта всі файли в спул-директорії зберігаються.
Коли ці файли стають непотрібними, вони видаляються. Мережевий клієнт, файловий клієнт та
клієнт телеконференції забезпечують передачу команд користувача, файлів та повідомлень
телеконференції. Одночасно може працювати один канал команд та багато каналів передачі файлів
і телеконференцій. Система обробки команд користувача забезпечує обробку всіх даних, які
проходять через мережевий агент, і реакцію на відповідні команди та події.
3. Розподілена база даних обстежень
Структура бази даних з боку клієнтів та сервера однакова. Серверна база даних зберігає всю інформацію в цілісному вигляді. З боку клієнтів в базі даних зберігається лише частина серверної бази, необхідна на даному робочому місці. При додаванні на клієнті нової інформації вона заноситься в локальну базу даних клієнта і відправляється на сервер. Структура бази даних виконана таким чином, що забезпечує повну незалежність структури бази даних від типу медичного обстеження.
Структурно база даних складається з таких таблиць: пацієнти, лікарі, псевдоніми, обстеження, форми. Таблиці пацієнтів та лікарів містять всю необхідну персональну інформацію та цілочисельні ключі, які дозволяють посилатись на записи таблиць. Таблиця псевдонімів складається з двох полів: ключа та текстових даних, які з цим ключем пов'язані. В таблиці псевдонімів зберігаються назви, що часто зустрічаються: назви вулиць, міст, лікарських препаратів, діагнозів і т.д.
Для збереження інформації обстежень застосовується 10 таблиць сторінок форми. Кожна
таблиця сторінок форми містить 20 цілочисельних полів та інформацію про обстеження, таку, як номер обстеження та його статус. Крім цього, передбачене поле для текстової інформації. Цілочисельні поля є пошуковими. Для інтерпретації змісту кожного цілочисельного поля застосовується поле форми, яке містить посилання на опис форми обстеження. Описи форм обстежень зберігаються в таблиці форм у вигляді текстового рядка. Таким чином, для доступу до даних обстеження, пошуку за обстеженням тощо необхідно провести пошук по таблиці обстежень, а для інтерпретації даних таблиці необхідно один раз звернутись до таблиці форм. Така структура даних дозволяє зробити базу даних незалежною від типу обстеження, а також забезпечити можливість виконання складних операцій з обстеженнями (пошук, відстеження зв'язків між обстеженнями і т.д.) швидко, оскільки при цьому в основному застосовуються операції з цілими числами, а кількість операцій пошуку за рядками символів зведена до мінімуму. Різні таблиці сторінок зв'язані між собою за допомогою ключа — номера обстеження
Для забезпечення функціонування розподіленої бази даних кожна таблиця має поле статусу. Статус кожного запису таблиці містить інформацію про час оновлення цього елемента. Якщо з клієнта надходить новіша інформація, ніж є на сервері, то інформація в базі даних замінюється на нову. При цьому всі інші клієнти періодично надсилають запит про перевірку надходжень до бази даних нової інформації. При наявності нових даних всі вони передаються клієнтам і відбувається оновлення бази даних клієнтів.
4. Структура і таговий формат даних обстежень
Крім інформації, по якій проводиться пошук і яка зберігається в базі даних, медичні обстеження містять інформацію, яку в базі даних зберігати не доцільно, як, наприклад, діагностичні зображення, кардіограми та ін. Вся ця інформація зберігається у файлах, в'язаних з даними обстеження, що зберігаються в базі даних. Оскільки файл обстеження може містити довільну інформацію, то формат даних повинен бути незалежним від типу інформації. Існують стандартні формати, які мають такі властивості, наприклад, РІООМ. Формат РІООМ є послідовністю тагів. Кожен таг є окремою порцією даних, яка містить розмір даних і опис типу інформації, що несуть ці дані. Дані тагу також можуть бути послідовністю тагів. Таким чином. є можливість в одному файлі зберігати ієрархію даних різних типів. Незважаючи на всі переваги, формат РІООМ також має ряд недоліків, зокрема, він не розрахований на застосування складних типів стиснення даних і не дозволяє відновити втрачений потік у результаті збоїв.
Для запропонованої системи було створено формат даних, який за структурою подібний до формату РІООМ, але додатково дозволяє застосовувати розвинені методи стиснення інформації та відновлювати потік даних у результаті збоїв у роботі.
Файл обстеження складається з набору (потоку) тагів. Кожен таг має однакову структуру і складається з заголовка (рис. 4) і необов'язкового поля даних тагу. Першим елементом тагу є біти наявності необов'язкових полів. Якщо відповідний біт встановлено, таг має відповідне необов'язкове поле. Далі слідує довжина тагу разом з заголовком, після якого йде магічний номер, що дозволяє ідентифікувати заголовок. Потім ідуть необов'язкові поля, такі, як ідентифікатори джерела та приймача, час створення та номер в послідовності, на наявність яких вказує відповідний біт першого поля. Наступний елемент - тип даних, які містить таг. Поля опції стану тагу та розширення
заголовку є зарезервованими для подальшого використання. За заголовком слідують дані тагу.
-Необов’язкові поля-
гНеобов’язкові пол;
& Б
* о -8- З-
я
Рис. 4. Структура тагів
Інформація тагових заголовків має фіксовану довжину, при цьому в заголовок додаються лише необхідні поля. Мінімальна довжина тагу сягає 6 байт. Для найменших тагів, що переносять
інформацію, ефективність використання каналу, яка визначається як 1-
Т„л
дааіеіаеа
сягає близько
60%, де Т
дааіеіаеа
— довжина заголовка, Тдааа — довжина всього тага. Для великих тагів
ефективність сягає майже 100%.
Запропонована структура дає можливість під час зчитування заголовка приймати рішення про те, як інтерпретувати дані, тобто формат є потоковим і може бути використаний як для роботи з файлами, так і для передачі по мережі, швидкого пошуку даних у пам'яті тощо. Структура заголовку дає можливість відновлювати потік тагів в результаті збоїв. Магічний номер завжди знаходиться на одному місці і завжди має одне й те ж значення, що у випадку пошкодження даних, дозволяє відновити потік. Поле типу даних дозволяє інтерпретувати дані тагу. Це поле має ту ж саму структуру, що і для формату РІООМ, тобто група і номер, що дають можливість легко експортувати обстеження у формат РІООМ. Список деяких груп тагів подано в табл. 1.
Таблиця 1. Групи команд телемедичної системи
№ Номер групи тагів Опис групи тагів
1 0x0001 Команди інтерфейсу користувача
2 0x0003 Команди, пов’язані з графічними примітивами
3 0x0005 Команди, пов’язані з контурами
4 0x0007 Команди, пов’язані з мережевим протоколом
5 0x0009 Команди, пов’язані з базою даних
6 0x00ff Службові команди, такі, як керування потоком і т.д.
7 0x0101 Команди роботи із зображеннями
Максимальний розмір тагу обмежений (1 Мбайт), що необхідно для ефективного відновлення в результаті втрати даних. При необхідності передавати дані великого розміру, при записі у файл вони розбиваються на таги меншого розміру, а при зчитуванні знову об'єднуються. Для контролю правильності даних передбачено введення в потік контрольної суми, яка передається за допомогою спеціального тагу.
Обстеження записується в файл у режимі журналювання. При створенні обстеження створюється файл журналу. Кожна дія користувача, як то додавання зображень, графічних примітивів, тощо є командою, яка записується у файл журналу за допомогою відповідного тагу. Тип даних визначає команду, а дані — параметр команди. У випадку збоїв у роботі файл журналу залишається і незаписане обстеження з нього може бути відновлене. Навіть у випадку пошкодження
частини даних зіпсованим виявляється лише один таг, а вся інформація буде відновлена.
При відновленні використовується буферизація інформації з потоку, оскільки повернення в потік і повторне вилучення даних з потоку не завжди можливе, як, наприклад, у випадку передачі по мережі. Максимальний розмір буфера £ дорівнює £ = N * Т, де N — кількість послідовних тагів, Т — максимальний розмір тагу. У зв'язку з цим розмір буфера може бути дуже великим при великому N , тому N було обмежене числом 3.
5. Мережевий протокол передачі
Для передачі по мережі застосовується протокол транспортного рівня, що гарантує надійність доставки, проте для гарантії цілісності даних обстеження потрібен протокол прикладного рівня. Крім забезпечення цілісності обстежень, при розробці протоколу передачі також ставилась задача відновлення в результаті збоїв зв'язку, недоступності серверів та клієнтів, а також робота при повільних каналах зв'язку. Стійка робота в умовах повільних та ненадійних каналів зв'язку забезпечується такими особливостями: тагова структура повідомлень, наявність алгоритму відновлення потоку при втраті даних, можливість рестарту передачі/прийому даних, компактність інформації.
В результаті було розроблено три протоколи передачі.
Кожен клієнт взаємодіє з сервером за допомогою декількох каналів передачі даних: одного каналу команд, декількох каналів передачі файлів та декількох каналів телеконференції (рис. 3). Дані по всіх каналах можуть передаватись паралельно. Для кожного каналу застосовується свій протокол передачі. Незважаючи не це, всі дані передаються за допомогою розглянутого вище тагового формату даних. Одиницею передачі є таг, який вважається прийнятим, лише коли прийнята вся інформація тагу. Поле тип тагу визначає команду чи дані, які надійшли каналом передачі.
Рис. 5. Блок-схема алгоритму роботи командного каналу За допомогою каналу команд клієнти керують функціями серверу, такими як доступ до бази даних, відправка та прийом запитів на телеконсультацію. Вся інформація, яка передається командним каналом, поступає до клієнта зі спул-директорії. Після відправки команди на сервер дані в спул-директорії зберігаються, доки сервер не пришло підтвердження про виконання команди або
помилку, після цього повідомлення видаляється зі спул-директорії. Таким чином, командний канал автоматично відновлюється при збоях в роботі. Спрощений алгоритм роботи каналу показано на рис. 5.
Канал передачі файлів орієнтований на гарантовану та швидку доставку файлів обстежень. Основна відмінність алгоритмів серверу та клієнта в тому, що ініціатором передачі даних завжди є клієнт, а це дає можливість клієнтам працювати за брандмауером. Файли також передаються з використанням спул-директорії. У випадку збоїв протокол передачі передбачає визначення, яка частина файлу була передана раніше і "докачування" тієї частини, якої не вистачає. Передавач завжди має авторитетну інформацію, що дає можливість вирішувати конфлікти, пов'язані з неспівпадінням переданих частин файлу. Спільний алгоритм прийому файлу показано на рис. 6.
Отримати таг________________
0x0007 | 0x0005 ~~|
про успішний прийом, виконати необхідні
Дії
Рис. 6. Блок-схема спільного алгоритму прийому файлів
Сторона, яка передає файл, отримує інформацію про рестарт, оцінює коректність такої інформації і передає дані файла разом з інформацією про рестарт. Аналогічним є спільний алгоритм прийому файлу. Відмінність між клієнтським та серверними алгоритмами полягає в тому, що клієнт завжди передає першим запит на прийом та передачу, при цьому передається тип сервісу - передача, чи прийом файлів і інформація про авторизацію.
Режим телеконференції повністю відповідає режиму передачі файлів, проте він орієнтований на передачу повідомлень в реальному часі від одного до всіх учасників конференції. Кожен учасник веде журнал конференції по аналогії з журналом обстеження. Такий самий журнал ведеться на сервері. Кожен учасник передає дані на сервер, після чого сервер зберігає їх у журналі і передає всім іншим учасникам. Новий учасник аналогічним чином отримує журнал конференції.
Крім підтримки розподіленої бази даних обстежень, протокол розрахований на проведення телемедичних консультацій на основі цих обстежень. Телеконсультація включає відправку запиту на консультацію користувачем, отримання запиту консультантом, створення та відправку відповіді консультантом, отримання відповіді користувачем.
Відправка й отримання запитів та відповідей телеконсультацій у відкладеному режимі відбувається так само, як і у випадку запитів до бази даних. Запит і відповідь є звичайними обстеженнями, проте поле статус для цих обстежень має спеціальне значення, яке дозволяє відрізнити запити та відповіді. Кожен запит може містити посилання на інші обстеження, які при необхідності імпортуються в локальну базу даних клієнтів.
6. Висновки
Запропонована в даній роботі архітектура системи телемедичних консультацій дозволяє вирішити проблему створення розподіленої бази даних обстежень і проведення телеконсультацій в режимі повільних та ненадійних каналів зв'язку, що досягається шляхом буферизації даних з боку клієнтів, застосуванням алгоритмів стиснення даних, журналювання всіх критичних операцій та використання тагових форматів даних з алгоритмами відновлення потоку.
Запропонована архітектура була практично реалізована і відтестована. Результати тестування показали високі технічні характеристики системи, яку можна рекомендувати для експериментального застосування в клінічних умовах.
Особливості реалізації та тестування системи є предметом для іншої статті.
Подяка
Робота виконувалась в рамках гранта УНТЦ NN40.
СПИСОК ЛІТЕРАТУРИ
1. Казаков В.Н., Климовицкий В.Г., Владзимирский А.В. Телемедицина. - Донецк: Типография ООО “Норд”, 2QQ2. - 1Q с.
2. Allely E.B. Synchronous and Asynchronous Telemedicine // J.of Medical Systems. - 1995. - Vol. 19, N 3. - P. 2Q7-212.
3. Ягер Р.Дж., Риз Дж., Кинг Т. MysSQL и mSQL. Базы данных для небольших предприятий и Интернета. -СПб.: Символ-Плюс, 2QQQ. - 56Q с.
4. Олифер В.Н., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы. - СПб.: Питер, 2QQQ. -б72 с.
5. Стэггерс Н., Бэгли Томпсон Ч., Снайдер-Халперн Р. Історія і тенденції розвитку медичних інформаційних систем у США / (російський переклад). - Journal of Nursing Scholarship. - 2QQ1. - № 33. - С. 75-81.
6. Палагин А.В., Опанасенко В.Н., Сахарин В.Г. Вычислительные системы с реконфигурируемой (программируемой) архитектурой // Проблеми інформатизації та управління: Зб. наук. праць. - 2QQ4. - № 1Q. -С. 5-14.
7. Коваль В.Н., Савяк В.В., Сергиенко И.В. Тенденции развития современных высокопроизводительных систем // Управляющие системы и машины. - 2QQ4. - № б. - С. 31-44.
