База даних MySQLДля запису, вибірки та обробки даних, що зберігаються в комп'ютерній базі даних, необхідна система управління базою даних, якою і є програмне забеспечення (ПЗ) MySQL. База даних MySQL - реляційна база даних. У реляційній базі даних дані зберігаються не всі скопом, а в окремих таблицях, завдяки чому досягається виграш у швидкості та гнучкості. Таблиці зв'язуються між собою за допомогою відносин, завдяки чому забезпечується можливість об'єднувати при виконанні запиту дані з декількох таблиць. SQL як частина системи MySQL можна охарактеризувати як мова структурованих запитів плюс найбільш поширений стандартний мову, що використовується для доступу до баз даних [9]. СУБД MySQL є системою клієнт-сервер, яка містить багато-поточний SQL-сервер, що забезпечує підтримку різних обчислювальних машин баз даних, а також кілька різних клієнтських програм і бібліотек, засоби адміністрування і широкий спектр програмних інтерфейсів (API). Сервер MySQL постійно працює на комп'ютері. Клієнтські програми (наприклад, скрипти PHP) посилають серверу MySQL SQL-запити через механізм сокетів (тобто за допомогою мережевих засобів), сервер їх обробляє і запам'ятовує результат. Тобто скрипт (клієнт) вказує, яку інформацію він хоче отримати від сервера баз даних. Потім сервер баз даних посилає відповідь (результат) клієнтові (скрипту). Структура MySQL трирівнева: а) бази даних; б) таблиці; в) записи. Логічно - таблиця являє собою сукупність записів. А записи - це сукупність полів різного типу. Ім'я бази даних MySQL унікально в межах системи, а таблиці - в межах бази даних, поля – в межах таблиці. Один сервер MySQL може підтримувати відразу декілька баз даних, доступ до яких може розмежовуватися логіном і паролем. Знаючи ці логін і пароль, можна працювати з конкретною базою даних. Наприклад, можна створити або видалити в ній таблицю, додати записи і т. д. Зазвичай ім'я-ідентифікатор та пароль призначаються хостинг провайдерами, які і забезпечують підтримку MySQL для своїх користувачів. ПЗ MySQL, є додатком з відкритим кодом. Кожен користувач може вивчити вихідний код і змінити його у відповідності зі своїми потребами. Основні достоїнства пакету MySQL [9]: ‒ багатопоточність. Підтримка декількох одночасних запитів; ‒ оптимізація зв'язків з приєднанням багатьох даних за один прохід; ‒ записи фіксованої і змінної довжини; ‒ ОDBC драйвер в комплекті з вихідним текстом; ‒ гнучка система привілеїв і паролів; ‒ до 16 ключів в таблиці. Кожен ключ може мати до 15 полів; ‒ заснована на потоках, швидка система пам'яті; ‒ всі операції роботи з рядками не звертають уваги на регістр символів в оброблюваних рядках. 3.2 Телеконсультація Телемедичне консультування - процес дистанційного обговорення конкретного клінічного випадку з метою підтримки в прийнятті якісногоі оптимального клінічного рішення для надання невідкладної або планової медичної допомоги. Телемедичне консультування це найбільш древня, а нині – основна теле-медична процедура. Щодня в усьому світі проводяться тисячі телеконсультацій за допомогою самих різних телекомунікаційних технологій по всіх клінічних дисциплінами. Саме телемедичне консультування забезпечує наближення кваліфікованої та спеціалізованої допомоги в точку необхідності,взаємодія між рівнями медико-санітарної допомоги, швидку підтримку ефективних клінічних рішень. Основною метою телемедичного консультування є надання якісної медичної допомоги (від першої долікарської до спеціалізованої та кваліфікованої) в точці необхідності. Слабо централізовані розподілені системи більше підходять для формування мереж отримання діагностичної інформації, оскільки у цьому випадку накопичення у базу інформації виконується безпосередньо в діагностичних центрах, які між собою взаємодіють, виходячи з вимог пере-дачі даних на конкретних пацієнтів. Системи консультування реалізуються, як правило, незалежним чином для підтримки відкладеного та інтерактивного режимів. Відкладені консультації традиційно реалізуються off-line методами доставки інформа-ції, наприклад, електронною поштою або через web-інтерфейс методами заповнення та обробки форм (в останньому випадку відповідь відправляється також засобами пошти). Для інтерактивних консультацій часто використовують універсальні програмно-апартні засоби мульти-медійних телекомунікацій. Такі методи добре працюють у випадку консультативної хірургії, коли на перший план виходить вимога якісної передачі динамічного зображення реального часу, що вимагає утворення спеціалізованих консультативних вузлів, оснащених швидкими каналами. Однак така ідеологія не охоплює найбільш широкий сегмент потреб у відда-леному консультуванні. Найбільш зацікавленими, з точки зору надання медичних послуг, є ре-гіони з послабленою відносно середнього рівня розвитку технічною ба-зою, а, відповідно, і з погіршеними телекомунікаційними можливо-стями [10]. Зазначимо, що ця особливість є характерною навіть для країн з максимально високим на поточний момент рівнем розвитку технічної інфраструктури. До цього можна додати також умови експедицій, віддалених місць роботи і проживання невеликих групп населення, для яких важко забезпечити як достатність медичної допомоги, так і відповідний рівень телекомунікаційного сервісу. Ще одним застосуванням телемедицини є зони ліквідації стихійних лих та техногенних катастроф, при яких значно порушується телекомунікаційна інфраструктура. Таким чином, телеконсультативні системи значним чином повинні орієнтуватись на умови ненадійного або повільного зв’язку та відповідно на високий рівень буферування інформації, якісні методи стиснення, оптимізовані для роботи з специфічними для медицини типами інформаційних потоків. Інформаційна система, яка береться як основа телеконсультативної служби, повинна забезпечувати проведення віддалених медичних консультацій з використанням графічної діагностичної інформації. Одночасно з цим повинні бути забезпечені зручні методи роботи з іншими ти-пами діагностичної інформації, а також деякою супутньою інформацією, наприклад, оверлейними графічними об’єктами на діагностичних зображеннях, які виконують функцію визначення області інтересу, службових поміток, сегментації зображень з діагностичною метою (виділення поверхонь органів, пухлин тощо). З точки зору роботи з текстово-цифровою інформацією, найбільш вживаною на поточний момент, є SQL-технологія [10], яка базується на використанні централізованого ядра (серверу) БД з інтерфейсом взаємодії з клієнтами на основі спеціальної мови SQL. Такі принципи будови ІС до-зволяють забезпечити певну стабільність інтерфейсів, уніфікацію звернень, відносно якісну мінімізацію навантаження на канали інформаційної мережі при умові використання тільки текстово-цифрової інформації. З іншого боку, пряма взаємодія клієнтського процесу з ядром ІС за SQL-інтерфейсом вимагає достатньо надійного з’єднання, викликає потребу повторної передачі відносно великої кількості інформації при зміні умов фільтрації, навіть незначної. Така проблема знижує ефективність реалізації електронної історії хвороби при винесенні подібних систем на рівень вище клінічного закладу, тобто при переході з каналів локальної мережі на рівень глобальної мережі та особливо на комутовані канали. Особливі затримки можуть виникати при використанні БД для збереження зв’язаної з таблицями ресурсоємної інформації. Альтернативою традиційних технологій централізованих баз даних є PACS-системи, орієнтовані на роботу саме з діагностичною графічною інформацією, однак вони також погано пристосовані до роботи в умовах ускладненого зв’язку. Сама розробка ідеології таких систем орієнтувалась скоріше на умови розвиненої у технічному плані клініки або об’єднання клінічних закладів при наявності надійного швидкого з’єднання. Таким чином, є потреба знайти компроміс між подібними реалізаціями ІС медичного призначення і доповнити їх методами роботи для оптимізації використання в ускладнених умовах, характерних для традиційних сфер засто-сування телемедицини. Використання найбільш вживаних web-технологій (протокол HTTP, універсальні браузери) для реалізації подібних ІС в більшості випадків не забезпечує умови мінімального навантаження на мережу через надзвичайно високий рівень повторного пересилання інформації при динамічній генерації відповідних інформаційних сторінок. Таким чином, є потреба розробки спеціалізованого протоколу прикладного рівня. Виходячи з потреб використання для потреб комунікації каналів глобальних мереж та враховуючи сучасні тенденції узгодження методів використання каналів, слід орієнтуватись на стек протоколів TCP/IP. Відповідно є дві основні можливості реалізації транспортного сервісу – потоковий режим, який забезпечує протокол TCP, та дейтаграмний на основі використання протоколу UDP [11]. Ще однією складною проблемою при розробці ІС медичного призначення є складність формалізації медичної інформації. На відміну, наприклад, від бухгалтерського обліку та віддалених фінансових операцій, де можливі практично 100% формалізація і забезпечення цілісності інформації за рахунок використання транзакцій (об’єднання необхідної кількості елементарних операцій в одну макрооперацію, яка переводить БД у новий сталий стан, а при невиконанні частини транзакції виконуються повернення у попередній стан), значна кількість медичних даних погано формалізується. Навіть утворення міжнародних довідників та класифікаторів (номенклатури медичних термінів SNOMED, система клінічних кодів Ріда RCC, міжнародної класифікації хвороб) [12] не розв’язують цю проблему повністю, оскільки вимагають частих корекцій і доповнень, мають складну ієрархічну структуру, що ускладнює їх використання. Навіть при роботі з текстово-цифровою інформацією у медицині спостерігається певна неоднозначність формалізації, деяка неузгодженість окремих стандартів. Як приклад можна навести велику кількість непарних (нестандартизованих) тегів у файлах діагностичних приладів. Ще скла-днішою є ситуація при використанні приладової діагностичної інформації, особливо графічної. Таким чином, класифікація медичної інформації вимагає гнучких методів додаткового настроювання ІС, в тому числі зі зміною формату таблиць і внутрішніх зв’язків БД у процесі експлуатації, використання складних методів обробки і пошуку, які не вкладаються в обмеження SQL-запитів.
3.2.1 Архітектура розподіленої системи телеконсультацій
Архітектура основана на клієнт-серверній ідеології з використанням максимально можливої кількості стандартних рішень – SQL-сервер для збереження даних на ядрі, WWW-сервер для надання доступу на перегляд даних, стек протоколів TCP/IP для забезпечення телекомунікаційних потреб. Передбачений також імпорт даних зі стандарту DICOM [13,14]. Схема системи зображено на рис.3.1 [14].
Рисунок 3.1 – Схема системи телеконсультацій
Як видно з рис.3.1, система складається з серверної та багатьох клієнтських компонент. Серверна частина включає в себе систему керування SQL-базою даних, WWW-сервер, файловий сервер та ядро системи. Всі ці компоненти є окремими підсистемами і можуть фізично працювати як на одній, так і на різних машинах. У будь-якому випадку для забезпечення швидкості та ефективності роботи ці системи повинні бути з’єднані швидкими каналами зв’язку. Основною компонентою системи є ядро. Ця підсистема відповідає за синхронізацію роботи всіх компонент системи, а також за синхронізацію з клієнтами. Віддалені клієнти можуть працювати з системою тільки через ядро. Ще однією функцією ядра є підтримка консультацій реального часу. Файловий сервер застосовується для збереження даних телемедичних обстежень, таких як зображення, та іншої інформації. В базі даних зберігається я пошукова інформація, зв’язана з обстеженнями. Сервер WWW служить для доступу до інформації обстежень через систему WWW. Через цей сервер за допомогою WWW браузера здійснюється доступ до обстежень в режимі "тільки читання". Клієнтські підсистеми орієнтовані на роботу як з локальної мережі, так і з використанням повільних та ненадійних каналів зв’язку. Алгоритми роботи клієнтів відповідають за відновлення в результаті збоїв апаратного та програмного забезпечення. Клієнтські підсистеми розраховані на роботу в режимі консультанта – лікаря, що дає консультацію, та в режимі лікарі, який бажає отримати консультацію. Ці режими відрізняються налаштуванням програмного забезпечення. Спрощений алгоритм функціонування ядра системи показаний на рис.3.2 [15]. Клієнт встановлює з’єднання з сервером за допомогою протоколу, орієнтованого на гарантовану доставку повідомлень, наприклад, TCP [12]. При з’єднанні запускається завдання, що обслуговує даного клієнта, виконує аутентифікацію і авторизацію клієнта та розпізнає тип служби, яка необхідна клієнту. Після цього, у відповідності з типом служби передачі даних, запускається завдання обробки клієнтських команд, передачі файлів чи телеконференції. Кожен тип завдання у відповідності зі своїм призначенням отримує команди від клієнта, обробляє їх і відправляє відповідь. Одночасно з сервером може працювати велика кількість клієнтів.
Рисунок 3.2 – Схема функціонування ядра телемедичної системи
Завдання клієнтських команд зв’язано з каналом керування, який по можливості підтримується у з’єднаному стані. Через цей канал надходять команди керування сервером та відповіді на запити клієнтів. Команди керування пов’язані з запитами до бази даних, запуском теле-конференції чи ініціації сеансу передачі файлів. Завдання передачі файлів відповідає за стійку передачу файлів обстежень і відновлення цієї передачі в результаті збоїв. Передача файлів здійснюється паралельно до командного каналу. Завдання телеконференції відповідає за конференцію реального часу. Це завдання відповідає за обмін повідомленнями між учасниками конференції та за ведення протоколу конференції. Елементи синхронізації роботи відповідають за доступ до спільних ресурсів даних і відправку повідомлень клієнтам про те, що відбулись певні події, наприклад, запущено телеконференцію. Схему роботи клієнта показано на рис. 3.3 [14]. Клієнтське програмне забе-зпечення встановлено з боку всіх консультантів та користувачів системи. В задачу клієнта входять функції інтерфейсу користувача, забезпечення роботи в умовах відсутності та поганої якості зв’язку, відновлення в результаті збоїв апаратного та програмного забезпечення, підтримка цілісності інформації. Клієнт складається з інтерфейсу користувача, системи ведення локальної бази даних клієнта і мережевого агента. Інтерфейс користувача забезпечує функції роботи користувача з системою, такі як перегляд та редагування графічної інформації, створення запитів на телеконсультацію. Система керу-вання локальною базою даних забезпечує буфер інформації з боку клієнта. Інформація в локальній базі даних є копією частини інформації і в основній базі даних сервера. При відсутності зв’язку з сервером усі обстеження мо-жуть записуватись в базу даних клієнта. Коли зв’язок відновлюється, клі-єнтська інформація синхронізується з сервером. Мережевий агент забезпечує функції передачі інформації, відновлення зв’язку у випадку збоїв каналу передачі, обробку команд користувача, передачу файлів обстежень з сервера та на сервер і ведення телеконференції. Обмін інформацією, яка є критичною, що до втрати під час збоїв апаратного та програмного забезпечення відбувається через спул-директорію, де всі пові-домлення зберігаються у вигляді файлів.
Рисунок 3.3 – Схема роботи клієнта Це інформація, що синхронізується між базами даних клієнта та сервера, файли обстежень, файли запитів до бази даних на сервері, файли відповідей сервера. Інформація, яка не критична до збоїв, наприклад, повідомлення телеконференції передається через пам’ять спільного доступу. При перезавантаженні клієнта всі файли в спул-директорії зберігаються. Коли ці файли стають непотрібними, вони видаляються. Мережевий клієнт, фа-йловий клієнт та клієнт телеконференції забезпечують передачу команд користувача, файлів та повідомлень телеконференції. Одночасно може пра-цювати один канал команд та багато каналів передачі файлів і телеконференцій. Система обробки команд користувача забезпечує обробку всіх даних, які проходять через мережевий агент, і реакцію на відповідні команди та події.
3.2.2 Розподілена база даних обстежень
Структура бази даних з боку клієнтів та сервера однакова. Серверна база даних зберігає всю інформацію в цілісному вигляді. З боку клієнтів в базі даних зберігається лише частина серверної бази, необхідна на даному робочому місці. При додаванні на клієнті нової інформації вона зано-ситься в локальну базу даних клієнта і відправляється на сервер. Структура бази даних виконана таким чином, що забезпечує повну незалежність структури бази даних від типу медичного обстеження. Структурно база даних складається з таких таблиць: пацієнти, лікарі, псевдоніми,обстеження, форми. Таблиці пацієнтів та лікарів містять всю необхідну персональну інформацію та цілочисельні ключі, які дозволяють посилатись на записи таблиць. Таблиця псевдонімів складаєтьсяз двох полів: ключа та текстових даних, які з цим ключем пов’язані. Для збереження інформації обстежень застосовується 10 таблиць сторінок форми. Кожна таблиця сторінок форми містить 20 цілочисельних полів та інформацію про обстеження, таку, як номер обстеження та його статус. Крім цього, передбачене поле для текстової інформації. Цілочисельні поля є пошуковими. Для інтерпретації змісту кожного цілочисельного поля застосовується поле форми, яке містить посилання на опис форми обстеження. Описи форм обстежень зберігаються в таблиці форм у вигляді текстового рядка. Таким чином, для доступу до даних обстеження, пошуку за обстеженням тощо необхідно провести пошук по таблиці обстежень, а для інтерпретації даних таблиці необхідно один раз звернутись до таблиці форм. Така структура даних дозволяє зробити базу даних незалежною від типу обстеження, а також забезпечити можливість виконання складних операцій з обстеженнями (пошук, відстеження зв’язків обстеженнями і т.д.) швидко, оскільки при цьому в основному засосовуються операції з цілими числами, а кількість операцій пошуку за рядками символів зведена до мінімуму. Різні таблиці сторінок зв’язані між собою за допомогою ключа — номера обстеження. Для забезпечення функціонування розподіленої бази даних кожна таблиця має поле статусу. Статус кожного запису таблиці містить інформацію про час оновлення цього елемента. Якщо з клієнта надходить новіша інформація, ніж є на сервері, то інформація в базі даних замінюється на нову. При цьому всі інші клієнти періодично надсилають запит про перевірку надходжень до бази даних нової інформації. При наявності нових даних всі вони передаються клієнтам і відбувається оновлення бази даних клієнтів. 3.2.3 Структура і таговий формат даних обстежень Крім інформації, по якій проводиться пошук і яка зберігається в базі даних, медичні обстеження містять інформацію, яку в базі даних зберігати не доцільно, як, наприклад, діагностичні зображення, кардіограми та ін. Вся ця інформація зберігається у файлах, в’язаних з даними обстеження, що збе-рігаються в базі даних. Оскільки файл обстеження може містити довільну інформацію, то формат даних повинен бути незалежним від типу інформації. Існують стандартні формати, які мають такі властивості, наприклад, DICOM. Формат DICOM є послідовністю тагів. Кожен таг є окремою порцією даних, яка містить розмір даних і опис типу інформації, що несуть ці дані. Дані тагу також можуть бути послідовністю тагів. Таким чином. є можливість в одному файлі зберігати ієрархію даних різних типів. Незважаючи на всі переваги, формат DICOM також має ряд недоліків, зокрема, він не розрахований на застосування складних типів стиснення даних і не дозволяє відновити втрачений потік у результаті збоїв. Для запропонованої системи було створено формат даних, який за структурою подібний до формату DICOM, але додатково дозволяє застосовувати розвинені методи стиснення інформації та відновлювати потік даних у результаті збоїв у роботі. Файл обстеження складається з набору (потоку) тагів. Кожен таг має однакову структуру і складається з заголовка (рис. 3.4) [13] і необов’язкового поля даних тагу. Першим елементом тагу є біти наявності необов’язкових полів. Якщо відповідний біт встановлено, таг має відповідне необов’язкове поле. Далі слідує довжина тагу разом з заголовком, після якого йде магічний номер, що дозволяє ідентифікувати заголовок. Потім ідуть необов’язкові поля, такі, як ідентифікатори джерела та приймача, час створення та номер в послідовності, на наявність яких вказує відповідний біт першого поля. Наступний елемент – тип даних, які містить таг. Поля опції стану тагу та розширення заголовку є зарезервованими для подальшого використання. За заголовком сліжують дані тагу.
Рисунок 3.4 – Структура тагів Інформація тагових заголовків має фіксовану довжину, при цьому в заголовок додаються лише необхідні поля. Мінімальна довжина тагу сягає 6 байт. Для найменших тагів, що переносять нформацію, ефективність використання каналу, яка визначається як:
Ефективність сягає близько 60%, де Тз –– довжина заголовка, ТT ––довжина всього тага. Для великих тагі ефективність сягає майже 100%. Запропонована структура дає можливість під час зчитування заголовка приймати рішення про те, як інтерпретувати дані, тобто формат є потоковим і може бути використаний як для роботи з файлами, так і для передачі по мережі, швидкого пошуку даних у пам’яті тощо. Структура заголовку дає можливість відновлювати потік тагів в результаті збоїв. Магічний номер завжди знаходиться на одному місці і завжди має одне й те ж значення, що у випадку пошкодження даних, дозволяє відновити потік. Поле типу даних дозволяє інтерпретувати дані тагу. Це поле має ту ж саму структуру, що і для формату DICOM, тобто група і номер, що дають можливість легко експортувати обстеження у формат DICOM. Список деяких груп тагів подано в табл. 3.1. Таблиця 3.1 – Групи команд телемедичної системи
Максимальний розмір тагу обмежений (1 Мбайт), що необхідно для ефективного відновлення в результаті втрати даних. При необхідності пере-давати дані великого розміру, при записі у файл вони розбиваються на таги меншого розміру, а при зчитуванні знову об’єднуються. Для контролю пра-вильності даних передбачено введення в потік контрольної суми, яка передається за допомогою спеціального тагу. Обстеження записується в файл у режимі журналювання. При створенні обстеження створюється файл журналу. Кожна дія користувача, як то додавання зображень, графічних примітивів, тощо є командою, яка записується у файл журналу за допомогою відповідного тагу. Тип даних визначає команду, а дані — параметр команди. У випадку збоїв у роботі файл журналу залишається і незаписане обстеження з нього може бути відновлене. Навіть у випадку пошкодження частини даних зіпсованим виявляється лише один таг, а вся інформація буде відновлена. При відновленні використовується буферизація інформації з потоку, оскільки повернення в потік і повторне вилучення даних з потоку не завжди можливе, як, наприклад, у випадку передачі по мережі. Максимальний розмір буфера S дорівнює:
де, N –– кількість послідовних тагів T –– максимальний розмір тагу. У зв’язку з цим розмір буфера може бути дуже великим при великому N, тому N було обмежене числом 3.
3.2.4 Мережевий протокол передачі Для передачі по мережі застосовується протокол транспортного рівня, що гарантує надійність доставки, проте для гарантії цілісності даних обстеження потрібен протокол прикладного рівня. Крім забезпечення цілісності обстежень, при розробці протоколу передачі також ставилась задача відновлення в результаті збоїв зв’язку, недоступності серверів та клієнтів, а також робота при повільних каналах зв’язку. Стійка робота в умовах повільних та ненадійних каналів зв’язку забезпечується такими особливостями: тагова структура повідомлень, наявність алгоритму відновлення потоку при втраті даних, можливість рестарту передачі/прийому даних, компактність інформації [14]. В результаті було розроблено три протоколи передачі. Кожен клієнт взаємодіє з сервером за допомогою декількох каналів передачі даних: одного каналу команд, декількох каналів передачі файлів та декількох каналів телеконференції (рис. 3.5) [14]. Дані по всіх каналах можуть передаватись паралельно. Для кожного каналу застосовується свій протокол передачі. Незважаючи не це, всі дані передаються за допомогою розгля-нутого вище тагового формату даних. Одиницею передачі є таг, який вважається прийнятим, лише коли прийнята вся інформація тагу. Поле тип тагу визначає команду чи дані, які надійшли каналом передачі. За допомогою каналу команд клієнти керують функціями серверу, такими як доступ до бази даних, відправка та прийом запитів на телеко-нсультацію. Вся інформація, яка передається командним каналом, поступає до клієнта зі спул-директорії. Після відправки команди на сервер дані в спул-директорії зберігаються, доки сервер не пришло підтвердження про виконання команди або помилку, після цього повідомлення видаляється зі спул-директорії. Таким чином, командний канал автоматично відновлюється при збоях в роботі.
Рисунок 3.6 – Блок схема алгоритму роботи командного каналу
Канал передачі орієнтований на гарантовану та швидку доставку файлів обстежень. Основна відмінність алгоритму серверу, та клієнту в тому, що ініціатором передачі даних завжди є клієнт, а це дає можливість клієнтам працювати за брандмауером. Файли також передаються з використанням спул-директорії. У випадку збоїв протокол передбачає визначення, яка частина файлу була передана раніше і докачування тієї частини, якої не вистачає. Передавач завжди має авторитетну інформацію, що дає можливість вирішувати конфлікти, пов’язані з неспівпадінням переданих частин файлу. Спільний алгоритм прийому файлу показаний на рис. 3.6 [14]. Сторона, яка передає файл, отримує інформацію про рестарт, оцінює коректність такої інформації і передає дані файла разом з інформацією про рестарт. Аналогічним є спільний алгоритм прийому файлу. Відмінність між клієнтським та серверними алгоритмами полягає в тому, що клієнт завжди передає першим запит на прийом та передачу, при цьому передається тип сервісу – передача, чи прийом файлів і інформація про авторизацію.
Рисунок 3.6 – Блок-схема спільного прийому файлів Режим телеконференції повністю відповідає режиму передачі файлів, проте він орієнтований на передачу повідомлень в реальному часі від одного до всіх учасників конференції. Кожен учасник веде журнал конференції по аналогії з журналом обстеження. Такий самий журнал ведеться на сервері. Кожен учасник передає дані на сервер, після чого сервер зберігає їх у журналі і передає всім іншим учасникам. Новий учасник аналогічним чином отримує журнал конференції. Крім підтримки розподіленої бази даних обстежень, протокол розрахований на проведення телемедичних консультацій на основі цих обстежень. Телеконсультація включає відправку запиту на консультацію користувачем, отримання запиту консультантом, створення та відправку відповіді консультантом, отримання відповіді користувачем. Відправка й отримання запитів та відповідей телеконсультацій у відкладеному режимі відбувається так само, як і у випадку запитів до бази даних. Запит і відповідь є звичайними обстеженнями, проте поле статус для цих обстежень має спеціальне значення, яке дозволяє відрізнити запити та відповіді. Кожен запит може містити посилання на інші обстеження, які при необхідності імпортуються в локальну базу даних клієнтів. Інший режим телеконсультації — режим реального часу на основі протоколу телеконференції.
|
(3.1)
(3.2)
