Підсистема обміну даними для оперативної взаємодії між різними медичними інформаційними системами

Миронець, Валерія

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6644

Title:	Підсистема обміну даними для оперативної взаємодії між різними медичними інформаційними системами
Authors:	Бабенко, Віра Миронець, Валерія
Issue Date:	2025
Abstract:	Випускна кваліфікаційна робота магістра складається зі вступу, чотирьох розділів, висновків, списку використаних джерел та додатків. Загальний обсяг роботи становить 72сторінок основного тексту. Робота містить 7 рисунків, 2 таблиці та 3 додатки. Список використаних джерел –26 найменувань. Актуальність роботи. Сучасна цифрова трансформація охорони здоров’я та впровадження eHealth створюють виклики, пов'язані з інтеграцією гетерогенних медичних інформаційних систем (HIS, LIS, RIS). Ключовою проблемою є відсутність ефективної інтероперабельності між застарілими системами, що використовують стандарт HL7 v2.x, та новітніми платформами, орієнтованими на HL7 FHIR. Це призводить до фрагментації даних та ризиків лікарських помилок. Розробка спеціалізованої підсистеми обміну даними, що виступає мостом між різними технологічними поколіннями, є актуальним завданням для створення єдиного медичного інформаційного простору. Метою роботи є підвищення ефективності та надійності інформаційної взаємодії в медичних закладах шляхом розробки підсистеми, що забезпечує оперативну обробку, валідацію та трансформацію повідомлень між різнорідними системами. Об’єктом дослідження є процес обміну клінічно значущою інформацією між різнорідними медичними інформаційними системами. Предметом дослідження є методи, архітектурні патерни та інструментальні засоби для побудови підсистеми обміну даними. Методи дослідження. У роботі використано методи системного аналізу, об’єктно-орієнтованого проектування, патерни мікросервісної архітектури, методи декларативного програмування та експериментального навантажувального тестування. У першому розділі проведено аналіз теоретичних засад інтероперабельності та огляд існуючих стандартів (HL7 v2, FHIR, DICOM). Обґрунтовано вибір технологічного стека (Java Enterprise, Spring Boot, HAPI) та мікросервісного підходу для реалізації підсистеми. У другому розділі здійснено проектування архітектури системи. Сформульовано вимоги до надійності, безпеки та оперативності. Розроблено логічну модель даних та схему взаємодії компонентів, що забезпечує ізоляцію збоїв та незалежне масштабування. У третьому розділі описано програмну реалізацію модулів підсистеми. Основну увагу приділено розробці декларативного рушія мапінгу повідомлень, реалізації механізмів безпеки (аутентифікація, захист від витоку даних у логи) та забезпеченню семантичної сумісності між HL7 v2 та FHIR. У четвертому розділі наведено результати експериментальних досліджень ефективності розробленої підсистеми обміну повідомлення. Стрес-тестування підтвердило високу пропускну здатність та стійкість рішення до пікових навантажень, характерних для реальних медичних закладів. Наукова новизна результатів полягає в удосконаленні архітектурного підходу щодо інтеграції медичних систем на базі легковагової мікросервісної REST-архітектури, а також у подальшому розвитку декларативного методу трансформації даних (Configuration-Driven Engine) з використанням YAML- шаблонів. Практична цінність роботи полягає у створенні підсистеми обміну даними для оперативної взаємодії між медичними інформаційними системами шляхом впровадження програмного рішення, яке дозволяє інтегрувати застаріле медичне обладнання із сучасними інформаційними системами, знижуючи операційні витрати та мінімізуючи ризик помилок ручного введення даних.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/6644
Appears in Collections:	123 Комп’ютерна інженерія (Комп'ютерні системи та мережі)

Files in This Item:

File	Description	Size	Format
РОБОТА_МИРОНЕЦЬ-merged.pdf Restricted Access		856.23 kB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНОЇ БЕЗПЕКИ ТА КОМП’ЮТЕРНОЇ ІНЖЕНЕРІЇ
Пояснювальна записка
до кваліфікаційної роботи магістра
на тему: «Підсистема обміну даними для
оперативної взаємодії між різними медичними
інформаційними системами»
ЧДТУ.252467.005 ПЗ
Виконала: студентка 2 курсу, групи МКМ-2405
спеціальності 123 – Комп’ютерна інженерія
за освітньою програмою – Комп’ютерні системи
та мережі
Валерія МИРОНЕЦЬ
Керівник
д.т.н., професор Віра БАБЕНКО
Н. контроль
Світлана ГРЕСЬКО
Рецензент
доцент кафедри інженерної та аварійно-
рятувальної техніки ННІ оперативно-
рятувальних сил НУЦЗ України, к.т.н., с.н.с.
Ольга МЕЛЬНИК
«ЗАХИСТ ДОЗВОЛЯЮ»
Завідувач кафедри ІБ та КІ
к.т.н., доцент______Артем ЛАВДАНСЬКИЙ
Черкаси 2025 року
Форма № Н-9.01
Черкаський державний технологічний університет
Факультет інформаційних технологій і систем
Кафедра інформаційної безпеки та комп‘ютерної інженерії
Освітньо-кваліфікаційний рівень Магістр
Спеціальність 123 Комп’ютерна інженерія
Освітня програма Комп’ютерні системи та мережі
«ЗАТВЕРДЖУЮ»
Завідувач кафедри _____ АртемЛАВДАНСЬКИЙ
«___» ___________ 2025 року
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Миронець Валерії Олександрівні
(прізвище, ім‘я, по батькові)
1. Тема роботи Підсистема обміну даними для оперативної взаємодії між
різними медичними інформаційними системами
Керівник роботи Бабенко Віра Григорівна,д.т.н., проф.
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «07» жовтня 2025 р. № 307/03-03
2. Строк подання студентом роботи
3. Вихідні дані до роботи: Архітектура програмного застосунку –мікросервісна;
Засоби розробки: платформа JavaEnterprise та фреймворк SpringBoot; RESTAPI;
ддееккллааррататиивнвинйомгоетмоедттодраунтсрфаонрсмфацоірї мдаанциіхї (дCаoнnиfiхgu(rCatoionnf-iDgurirvaetniEonng-Dineri)vзeвnиEкоnрgиiсnтe)анзням
YвиAMкоLр-шисатбалноніяв;ммYедAичMниLй-сштаабнлдоарнтівHL7; стрес-тестування.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
Розділ 1.Аналіз методів організації обміну даними між медичними інформаційними
системами
Розділ 2.Проектування архітектури підсистеми обміну даними
Розділ 3.Практична реалізація модулів підсистеми та тестування
Розділ 4.Оцінка ефективності та апробація підсистеми обміну даними
Висновки
Перелік умовних позначень, скорочень, термінів
Список використаних джерел
Додатки
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів):
Додаток А. Специфікація
Додаток Б. Текст програми
Додаток В. Інструкція користувача
6. Консультанти розділів роботи
Підпис, дата
Прізвище, ініціали
Розділ та
посадаконсультант завдання видав завдання прийняв
а
7. Дата видачі завдання
КАЛЕНДАРНИЙ ПЛАН
Строк
№ з/п Назва етапів кваліфікаційної роботи магістра виконання Примітка
етапів роботи
1. Вибір теми кваліфікаційної роботи магістра 1.10-7.10.2025 виконано
2. Збір матеріалу 08.10 – 19.10 виконано
3. Обробка матеріалу 20.10 – 25.10 виконано
4. Обґрунтування актуальності виконання
досліджень 26.10 - 31.10 виконано
5. Оцінка стану проблеми, виокремлення виконано
дослідницьких задач, постановка задачі 01.11 – 07.11
дослідження
6. Викладення сутності і результатів дослідження 08.11 - 18.11 виконано
7. Практичне застосування результатів виконано
дослідження. Реалізація та впровадження. 19.11 – 27.11
8. Оформлення результатів в пояснювальну записку 28.11 - 01.12 виконано
9. Подання роботи на відгук та рецензування 02.12 - 04.12 виконано
Студент-магістрант ____________________________ Валерія МИРОНЕЦЬ
(підпис)
Керівник роботи _____________________________ Віра БАБЕНКО
(підпис)
АНОТАЦІЯ
Випускна кваліфікаційна робота магістра складається зі вступу,
чотирьох розділів, висновків, списку використаних джерел та додатків.
Загальний обсяг роботи становить 72сторінок основного тексту. Робота
містить 7 рисунків, 2 таблиці та 3 додатки. Список використаних джерел
–26 найменувань.
Актуальність роботи. Сучасна цифрова трансформація охорони
здоров’я та впровадження eHealth створюють виклики, пов'язані з
інтеграцією гетерогенних медичних інформаційних систем (HIS, LIS, RIS).
Ключовою проблемою є відсутність ефективної інтероперабельності між
застарілими системами, що використовують стандарт HL7 v2.x, та новітніми
платформами, орієнтованими на HL7 FHIR. Це призводить до фрагментації
даних та ризиків лікарських помилок. Розробка спеціалізованої підсистеми
обміну даними, що виступає мостом між різними технологічними
поколіннями, є актуальним завданням для створення єдиного медичного
інформаційного простору.
Метою роботи є підвищення ефективності та надійності інформаційної
взаємодії в медичних закладах шляхом розробки підсистеми, що забезпечує
оперативну обробку, валідацію та трансформацію повідомлень між
різнорідними системами.
Об’єктом дослідження є процес обміну клінічно значущою
інформацією між різнорідними медичними інформаційними системами.
Предметом дослідження є методи, архітектурні патерни та
інструментальні засоби для побудови підсистеми обміну даними.
Методи дослідження. У роботі використано методи системного
аналізу, об’єктно-орієнтованого проектування, патерни мікросервісної
архітектури, методи декларативного програмування та експериментального
навантажувального тестування.
У першому розділі проведено аналіз теоретичних засад
інтероперабельності та огляд існуючих стандартів (HL7 v2, FHIR, DICOM).
Обґрунтовано вибір технологічного стека (Java Enterprise, Spring Boot, HAPI)
та мікросервісного підходу для реалізації підсистеми.
У другому розділі здійснено проектування архітектури системи.
Сформульовано вимоги до надійності, безпеки та оперативності. Розроблено
логічну модель даних та схему взаємодії компонентів, що забезпечує
ізоляцію збоїв та незалежне масштабування.
У третьому розділі описано програмну реалізацію модулів підсистеми.
Основну увагу приділено розробці декларативного рушія мапінгу
повідомлень, реалізації механізмів безпеки (аутентифікація, захист від витоку
даних у логи) та забезпеченню семантичної сумісності між HL7 v2 та FHIR.
У четвертому розділі наведено результати експериментальних
досліджень ефективності розробленої підсистеми обміну повідомлення.
Стрес-тестування підтвердило високу пропускну здатність та стійкість
рішення до пікових навантажень, характерних для реальних медичних
закладів.
Наукова новизна результатів полягає в удосконаленні архітектурного
підходу щодо інтеграції медичних систем на базі легковагової мікросервісної
REST-архітектури, а також у подальшому розвитку декларативного методу
трансформації даних (Configuration-Driven Engine) з використанням YAML-
шаблонів.
Практична цінність роботи полягає у створенні підсистеми обміну
даними для оперативної взаємодії між медичними інформаційними
системами шляхом впровадження програмного рішення, яке дозволяє
інтегрувати застаріле медичне обладнання із сучасними інформаційними
системами, знижуючи операційні витрати та мінімізуючи ризик помилок
ручного введення даних.
Ключові слова: МЕДИЧНА ІНФОРМАЦІЙНА СИСТЕМА,
ІНТЕРОПЕРАБЕЛЬНІСТЬ, HL7, FHIR, МІКРОСЕРВІСНА АРХІТЕКТУРА,
JAVA SPRING BOOT, ОБМІН ДАНИМИ, REST API, ТРАНСФОРМАЦІЯ
ДАНИХ
ANNOTATION
The master's thesis consists of an introduction, four chapters, conclusions, a
list of used sources and appendices. The total volume of the work is 72 pages of
the main text. The work contains 7 figures, 2 tables and 3 appendices. The list of
used sources is 26 items.
Relevance of the work. The modern digital transformation of healthcare and
the implementation of eHealth create challenges related to the integration of
heterogeneous medical information systems (HIS, LIS, RIS). The key problem is
the lack of effective interoperability between legacy systems using the HL7 v2.x
standard and the latest platforms focused on HL7 FHIR. This leads to data
fragmentation and risks of medical errors. The development of a specialized data
exchange subsystem, which acts as a bridge between different technological
generations, is a relevant task for creating a single medical information space.
The aim of the work is to increase the efficiency and reliability of
information interaction in medical institutions by developing a subsystem that
provides operational processing, validation and transformation of messages
between heterogeneous systems.
The object of the study is the process of exchanging clinically significant
information between heterogeneous medical information systems.
The subject of the study is methods, architectural patterns and tools for
building a data exchange subsystem.
Research methods. The work uses methods of system analysis, object-
oriented design, microservice architecture patterns, declarative programming
methods and experimental load testing.
The first section analyzes the theoretical foundations of interoperability and
reviews existing standards (HL7 v2, FHIR, DICOM). The choice of a technology
stack (Java Enterprise, Spring Boot, HAPI) and a microservice approach for
implementing the subsystem is justified.
The second section designs the system architecture. Requirements for
reliability, security and operability are formulated. A logical data model and a
component interaction scheme have been developed, which provides fault isolation
and independent scaling.
The third section describes the software implementation of the subsystem
modules. The main attention is paid to the development of a declarative message
mapping engine, the implementation of security mechanisms (authentication,
protection against data leakage to logs) and ensuring semantic compatibility
between HL7 v2 and FHIR.
The fourth section presents the results of experimental studies of the
effectiveness of the developed messaging subsystem. Stress testing confirmed the
high throughput and stability of the solution to peak loads typical of real medical
institutions.
The scientific novelty of the results lies in the improvement of the
architectural approach to the integration of medical systems based on a lightweight
microservice REST architecture, as well as in the further development of the
declarative data transformation method (Configuration-Driven Engine) using
YAML templates.
The practical value of the work lies in the creation of a data exchange
subsystem for operational interaction between medical information systems by
implementing a software solution that allows integrating outdated medical
equipment with modern information systems, reducing operating costs and
minimizing the risk of manual data entry errors.
Key words: MEDICAL INFORMATION SYSTEM,
INTEROPERABILITY, HL7, FHIR, MICROSERVICE ARCHITECTURE,
JAVA SPRING BOOT, DATA EXCHANGE, REST API, DATA
TRANSFORMATION
2
ЗМІСТ
ВСТУП..................................................................................................................... 4
РОЗДІЛ 1АНАЛІЗ МЕТОДІВ ОРГАНІЗАЦІЇ ОБМІНУ ДАНИМИ МІЖ
МЕДИЧНИМИ ІНФОРМАЦІЙНИМИ СИСТЕМАМИ......................................9
1.1.Огляд медичних інформаційних систем та вимог до їх взаємодії.........9
1.2.Аналіз існуючих стандартів та протоколів обміну медичними даними
(HL7, FHIR, DICOM)...................................................................................... 15
1.3.Обґрунтування вибору технологічної основи для розробки підсистеми
обміну даними.................................................................................................20
1.4.Висновки до першого розділу.................................................................28
РОЗДІЛ 2ПРОЕКТУВАННЯ АРХІТЕКТУРИ ПІДСИСТЕМИ ОБМІНУ
ДАНИМИ...............................................................................................................31
2.1.Вимоги до функціональності та надійності підсистеми обміну
даними..............................................................................................................31
2.2.Розробка загальної архітектури інтеграційної підсистеми...................39
2.3.Проектування логічної моделі даних та інтерфейсів взаємодії. ..........41
2.4.Висновки до другого розділу...................................................................44
РОЗДІЛ 3ПРАКТИЧНА РЕАЛІЗАЦІЯ МОДУЛІВ ПІДСИСТЕМИ ТА
ТЕСТУВАННЯ......................................................................................................46
3.1.Опис інструментальних засобів та технологій реалізації підсистеми.46
3.2.Розробка модуля перетворення та мапінгу медичних повідомлень....48
3.3.Реалізація механізмів безпеки та журналювання операцій обміну
даними..............................................................................................................50
3.4.Висновки до третього розділу.................................................................52
РОЗДІЛ 4ОЦІНКА ЕФЕКТИВНОСТІ ТА АПРОБАЦІЯ ПІДСИСТЕМИ
ОБМІНУ ДАНИМИ..............................................................................................54
4.1.Методика проведення експериментальних досліджень........................54
4.2.Аналіз результатів тестування продуктивності підсистеми.................56
4.3.Обговорення практичної цінності та перспектив впровадження.........60
3
4.4.Висновки до четвертого розділу .............................................................62
ВИСНОВКИ...........................................................................................................64
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СКОРОЧЕНЬ, ТЕРМІНІВ................... 67
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ.............................................................70
ДОДАТОК А – 482.ЧДТУ.52467-01 Підсистема обміну даними для
оперативної взаємодії між різними медичними інформаційними
системами
4
ВСТУП
Актуальність теми.
Сучасна парадигма розвитку глобальної та вітчизняної системи
охорони здоров’я характеризується фундаментальними змінами,
зумовленими стрімкою цифровою трансформацією. Перехід до концепції
електронної охорони здоров’я (eHealth) та повсюдна імплементація
електронних медичних записів (EHR/ЕМЗ)[2, 4], перетворили медичну
інформацію на ключовий актив, від якості та доступності якого
безпосередньо залежить ефективність лікувально-діагностичного процесу.
На сьогоднішній день інформаційна інфраструктура більшості
медичних закладів являє собою складний, історично сформований
конгломерат програмного забезпечення. Цей гетерогенний ландшафт
включає госпітальні інформаційні системи (HIS) для адміністративного
управління, спеціалізовані лабораторні системи (LIS) для обробки аналізів,
радіологічні системи (RIS/PACS) для роботи з діагностичними
зображеннями, а також низку вузькопрофільних додатків. Однак,
незважаючи на високий рівень автоматизації окремих клінічних процесів,
ключовою системною проблемою галузі залишається відсутність ефективної
інтероперабельності[17, 19]‒ здатності різнорідних інформаційних систем
безперешкодно обмінюватися даними та однозначно інтерпретувати їхній
зміст.
Ситуація ускладнюється технологічним дуалізмом, притаманним
медичній ІТ-сфері. Більшість базових систем, що функціонують у лікарнях,
побудовані на основі технологій попередніх поколінь (legacysystems) і
використовують для обміну даними стандарт HL7 v2.x[6]. Цей стандарт, хоча
і є надійним, базується на подієво-орієнтованій моделі та текстових
повідомленнях, що ускладнює його інтеграцію з сучасними веб-рішеннями.
Водночас, новітні розробки, мобільні додатки для пацієнтів та аналітичні
5
платформи орієнтуються на використання стандарту HL7 FHIR
(FastHealthcareInteroperabilityResources)[7], який базується на принципах
RESTful API та форматі JSON.
Цей технологічний та семантичний розрив призводить до того, що
медичні дані стають «замкненими» всередині окремих систем (феномен
«інформаційних колодязів»). Наслідком такої фрагментації є вимушене
дублювання інформації медичним персоналом, неможливість отримання
консолідованої картини стану здоров'я пацієнта в режимі реального часу та
суттєве підвищення ризику лікарських помилок через роботу з
неактуальними або неповними даними. Оскільки повна одномоментна заміна
застарілого парку програмного забезпечення є економічно неможливою для
більшості медичних установ, виникає гостра потреба в інженерних рішеннях,
здатних об'єднати ці технологічні епохи.
У зв’язку з вищевикладеним, розробка спеціалізованої підсистеми
обміну даними, яка функціонує як інтелектуальний проміжний шар
(middleware) і здатна забезпечити надійну, безпечну та швидку взаємодію
між різнорідними системами, виступаючи «мостом» між стандартами HL7 v2
та FHIR, є критично важливим, економічно доцільним та актуальним
науково-практичним завданням.
Мета і завдання дослідження.
Метою роботи є підвищення ефективності та надійності інформаційної
взаємодії в медичних закладах шляхом розробки підсистеми обміну даними,
що забезпечує оперативну обробку, валідацію та трансформацію повідомлень
між різнорідними медичними інформаційними системами.
Для досягнення поставленої мети потрібно вирішити такі завдання:
1. Провести аналіз теоретичних основ, існуючих стандартів (HL7 v2, FHIR,
DICOM) та методів організації обміну медичними даними.
6
2. Спроектувати мікросервісну архітектуру підсистеми, що забезпечує
масштабованість, відмовостійкість та відповідність вимогам безпеки
даних.
3. Розробити логічну модель даних та алгоритми декларативного мапінгу
повідомлень для забезпечення семантичної інтероперабельності.
4. Здійснити програмну реалізацію модулів підсистеми з використанням
платформи JavaEnterprise та фреймворку SpringBoot.
5. Провести експериментальне дослідження ефективності розробленої
підсистеми, оцінити її продуктивність та стійкість до пікових
навантажень.
Об’єкт дослідження‒ процес обміну клінічно значущою інформацією
між різнорідними медичними інформаційними системами.
Предмет дослідження‒ методи, архітектурні патерни та
інструментальні засоби для побудови підсистеми обміну даними для
оперативної взаємодії.
Методи дослідження.
У роботі використано такі підходи та методи: для дослідження
предметної області та стандартів HL7 використано методи системного
аналізу;для побудови структури системи ‒ методи об’єктно-орієнтованого
проектування та підходи щодо побудови і, відповідно, патернимікросервісної
архітектури;для реалізації механізму мапінгу даних ‒методи декларативного
програмування;для оцінки продуктивності системи ‒ методи
експериментального навантажувального тестування.
Наукова новизна одержаних результатів полягає у наступному:
1. Удосконалено архітектурний підхід до інтеграції медичних систем
шляхом розробки легковагової мікросервісної архітектури на базі REST-
взаємодії, що, на відміну від традиційних монолітних ESB-рішень,
забезпечує менше споживання системних ресурсів та спрощує процес
розгортання в хмарному середовищі.
7
2. Набуло подальшого розвитку застосування декларативного методу
трансформації даних (Configuration-DrivenEngine) з використанням
YAML-шаблонів та JEXL-виразів, що дозволяє адаптувати логіку
обробки HL7-повідомлень без необхідності перекомпіляції програмного
коду.
Випускна кваліфікаційна робота магістра структурно складається із
вступу, чотирьох розділів, висновків та списку використаних джерел.
У першому розділі проведено аналіз теоретичних засад
інтероперабельності та огляд існуючих стандартів (HL7 v2, FHIR, DICOM).
Обґрунтовано вибір технологічного стека (JavaEnterprise, SpringBoot, HAPI)
та мікросервісного підходу для реалізації підсистеми.
У другому розділі здійснено проектування архітектури системи.
Сформульовано вимоги до надійності, безпеки та оперативності. Розроблено
логічну модель даних та схему взаємодії компонентів, що забезпечує
ізоляцію збоїв та незалежне масштабування.
У третьому розділі описано програмну реалізацію модулів підсистеми.
Основну увагу приділено розробці декларативного рушія мапінгу
повідомлень, реалізації механізмів безпеки (аутентифікація, захист від витоку
даних у логи) та забезпеченню семантичної сумісності між HL7 v2 та FHIR.
У четвертому розділі наведено результати експериментальних
досліджень ефективності розробленої підсистеми обміну повідомлення.
Стрес-тестування підтвердило високу пропускну здатність та стійкість
рішення до пікових навантажень, характерних для реальних медичних
закладів.
Практична цінність роботи полягає у створенні підсистеми обміну
даними для оперативної взаємодії між медичними інформаційними
системами шляхом впровадження програмного рішення, яке дозволяє
інтегрувати застаріле медичне обладнання із сучасними інформаційними
8
системами, знижуючи операційні витрати та мінімізуючи ризик помилок
ручного введення даних.
9
Апробація результатів дослідження.
За темою кваліфікаційної роботи представлено доповідь на ІV науково-
практичній інтернет-конференції «Інновації та перспективні шляхи розвитку
інформаційних технологій» (ІПШРІТ-2025)[5], що відбулася 25 листопада
2025 року в ЧДТУ та наІІІ науково-практичній інтернет-конференції
«Інновації та перспективні шляхи розвитку інформаційних
технологій»(ІПШРІТ-2024)[26], що відбулася 22 листопада 2024 року в
ЧДТУ.
10
РОЗДІЛ 1
АНАЛІЗ МЕТОДІВ ОРГАНІЗАЦІЇ ОБМІНУ ДАНИМИ МІЖ
МЕДИЧНИМИ ІНФОРМАЦІЙНИМИ СИСТЕМАМИ
1.1. Огляд медичних інформаційних систем та вимог до їх
взаємодії
1.1.1 Сутність та класифікація медичних інформаційних систем
Медична інформаційна система (МІС) – це комплексна програмна
інфраструктура, призначена для автоматизації процесів збору, накопичення,
зберігання, обробки та передачі медичної інформації в закладах охорони
здоров’я [19]. Її основне призначення виходить за межі простої автоматизації
документообігу; воно полягає у створенні єдиного цифрового контуру для
управління лікувально-діагностичним процесом.
Сучасні МІС забезпечують підтримку прийняття лікарських рішень
(CDSS), контроль якості надання медичної допомоги та управління
ресурсами закладу. Ключовою парадигмою їх розвитку є перехід від
паперової історії хвороби до структурованих електронних медичних записів
(EHR), які забезпечують юридичну значущість, доступність та
конфіденційність персональних даних пацієнта.
Інформаційний ландшафт сучасного багатопрофільного стаціонару є
вкрай гетерогенним (різнорідним). Він складається з "островів автоматизації"
‒ спеціалізованих систем, кожна з яких оптимізована під конкретні клінічні
завдання.
1. Госпітальні інформаційні системи (HIS —
HospitalInformationSystem). HIS виступає «ядром» інформаційної
інфраструктури медичного закладу. Вона акумулює централізовані дані про
пацієнта та забезпечує адміністративно-фінансовий менеджмент.
 Основні модулі:
11
 Реєстратура та ADT (Admission, Discharge, Transfer): Управління
потоками пацієнтів, реєстрація надходження, переведення між відділеннями
та виписка. Саме HIS генерує ключові HL7-події (наприклад, ADT^A01), які
ініціюють процеси в інших системах.
 Електронна медична карта (EMR): Ведення щоденників лікаря,
епікризів, листів призначень.
 Фінансовий модуль: Облік наданих послуг, взаєморозрахунки зі
страховими компаніями та НСЗУ (eHealth).
 Управління ресурсами: Облік ліжкового фонду, графіки
чергувань персоналу.
2. Лабораторні інформаційні системи (LIS —
LaboratoryInformationSystem). Це високоспеціалізовані системи промислового
класу, призначені для повної автоматизації роботи клініко-діагностичних
лабораторій.
 Життєвий цикл даних у LIS:
 Преаналітичний етап: Реєстрація замовлення (OrderEntry),
генерація унікальних штрих-кодів для пробірок, сортування зразків.
 Аналітичний етап: Інтеграція з лабораторними аналізаторами
(біохімічними, гематологічними). LIS автоматично отримує «сирі» дані від
обладнання, мінімізуючи ручне введення.
 Постаналітичний етап: Технічна та клінічна валідація результатів,
формування бланка аналізу, відправка результату назад у HIS.
3. Радіологічні інформаційні системи (RIS) та PACS. Цей клас систем
обслуговує відділення променевої діагностики (Рентген, КТ, МРТ, УЗД).
Важливо розрізняти дві складові, які зазвичай працюють у тандемі:
 RIS (RadiologyInformationSystem): Відповідає за організаційну
частину ‒ запис пацієнта на обстеження (ModalityWorklist), трекінг статусів
дослідження та написання текстового висновку лікарем-радіологом.
 PACS (Picture ArchivingandCommunicationSystem):
Спеціалізований архів для довгострокового зберігання "важких" графічних
12
даних (знімків). Взаємодія тут базується на стандарті DICOM, який описує як
формат файлів, так і мережевий протокол передачі зображень.
1.1.2 Проблема інтероперабельності та визначення предметної
області
Незважаючи на значні успіхи в цифровізації окремих бізнес-процесів
медичних закладів, ключовим бар'єром на шляху до створення єдиного
медичного простору залишається проблема інтероперабельності
(interoperability). У контексті медичних інформаційних технологій під
інтероперабельністю розуміється здатність різних інформаційних систем,
програмних додатків та пристроїв обмінюватися даними, точно
інтерпретувати їх зміст та використовувати отриману інформацію для
автоматизації клінічних рішень[18].
На практиці більшість спеціалізованих МІС (HIS, LIS, RIS)
проектувалися як автономні рішення («моноліти») із закритими базами даних
та пропрієтарними протоколами. Це призвело до виникнення феномену
«інформаційних островів» (datasilos), коли критично важливі клінічні дані
пацієнта виявляються ізольованими в межах однієї системи і недоступними
для лікарів, що працюють з іншим програмним забезпеченням.
Відсутність налаштованих механізмів автоматичного обміну даними
має низку негативних наслідків системного характеру:
1. Фрагментація клінічної картини. Лікуючий лікар не бачить
цілісної історії хвороби, оскільки результати лабораторних досліджень
знаходяться в LIS, радіологічні знімки ‒ в PACS, а історія призначень ‒ в
HIS. Це ускладнює діагностику та прийняття обґрунтованих рішень.
2. Проблема дублювання та цілісності даних. Персонал змушений
вручну переносити дані з однієї системи в іншу (наприклад, переписувати
результати аналізів з паперового бланка в електронну карту). Це неминуче
призводить до помилок «людського фактора» (опечатки, переплутування
пацієнтів), порушення цілісності даних та їх дублювання.
13
3. Клінічні та економічні ризики. Затримки в отриманні інформації
(наприклад, критичних результатів аналізів) можуть безпосередньо
загрожувати життю пацієнта. З економічної точки зору, відсутність
синхронізації призводить до призначення зайвих повторних обстежень, що
підвищує операційні витрати закладу.
Таким чином, науково-практична задача полягає не просто у з'єднанні
систем кабелем, а у забезпеченні семантичної сумісності ‒ гарантії того, що
дані, відправлені однією системою, будуть однозначно зрозумілі іншою без
втрати контексту. Це формулює необхідність розробки ефективних
механізмів взаємодії, що є основою для визначення предметної області
дослідження.
Виходячи з аналізу проблемної ситуації, в роботі визначено наступні
методологічні характеристики дослідження:
 Об’єкт дослідження ‒ процес обміну клінічно значущою
інформацією між різнорідними медичними інформаційними системами.
Об’єкт дослідження розглядається як об'єктивна реальність, що
породжує проблемну ситуацію. В даному випадку це весь комплекс
інформаційних потоків, що виникають під час взаємодії госпітальних,
лабораторних та інших систем у процесі надання медичної допомоги.
Досліджуються закономірності передачі, маршрутизації та синхронізації
даних у гетерогенному середовищі.
 Предмет дослідження ‒ методи, архітектурні патерни та
інструментальні засоби для побудови підсистеми обміну даними для
оперативної взаємодії між медичними інформаційними системами.
1.1.3 Вимоги до підсистеми оперативної взаємодії
Для забезпечення наукової новизни та практичної цінності,
проектована підсистема обміну даними повинна відповідати комплексу
жорстких нефункціональних вимог. Специфіка медичної галузі накладає
14
обмеження, які роблять ці вимоги значно суворішими, ніж у стандартних
корпоративних системах.
1. Оперативність (Real-timeResponsiveness)
Вимога оперативності визначається критичністю часового фактору в
клінічних процесах.
 Низька затримка (LowLatency): Підсистема повинна
забезпечувати обробку та маршрутизацію повідомлень у режимі,
максимально наближеному до реального часу (SoftReal-Time). Наприклад,
передача результатів ургентних лабораторних досліджень (з позначкою Cito!)
з LIS до реанімаційного відділення має відбуватися за лічені секунди.
 Висока пропускна здатність (HighThroughput): Система має бути
здатною обробляти пікові навантаження (наприклад, ранковий потік
результатів аналізів або масова виписка пацієнтів) без створення черг
очікування, що перевищують допустимі тайм-аути.
 Асинхронна обробка: Для забезпечення швидкодії інтерфейсів
користувача в системах-відправниках, підсистема обміну не повинна
блокувати їх роботу, приймаючи дані миттєво і обробляючи їх у фоновому
режимі.
2. Надійність та гарантована доставка (Reliability&Persistence).
Медична інформація є критично важливою, тому концепція "BestEffort"
(доставка по можливості) є неприпустимою. Система повинна реалізовувати
такі механізми:
 Гарантія доставки (At-least-oncedelivery): Кожне повідомлення
має бути збережене у персистентному сховищі (черзі) до моменту отримання
підтвердження (ACK) про успішну обробку від системи-одержувача.
 Відмовостійкість (FaultTolerance): У разі тимчасової
недоступності цільової системи (наприклад, мережевий збій або
перезавантаження сервера МІС), підсистема повинна автоматично
накопичувати повідомлення та ініціювати механізм повторних спроб
(RetryPolicy) з експоненціальним збільшенням інтервалу.
15
 Обробка помилок: Повідомлення, які неможливо обробити
автоматично (наприклад, через порушення структури даних), не повинні
зникати, а мають переміщуватися у спеціальну чергу "мертвих листів"
(DeadLetterQueue - DLQ) для подальшого ручного аналізу адміністратором.
3. Безпека та Конфіденційність (Security&Privacy).
Обробка чутливих персональних даних (PHI
‒ProtectedHealthInformation) вимагає відповідності національним та
міжнародним стандартам (GDPR, HIPAA)[3].
 Аутентифікація та авторизація: Реалізація суворого контролю
доступу для всіх інтегрованих систем (Service-to-Serviceauthentication).
Кожна система-клієнт повинна бути верифікована (наприклад, через API
Keys або Mutual TLS), а її права на відправку чи отримання конкретних типів
даних ‒ чітко розмежовані.
 Шифрування даних:
 In-transit:обов'язкове використання криптографічних протоколів
транспортного рівня (TLS 1.2/1.3) для захисту каналів передачі даних від
перехоплення (Sniffing) та атак типу Man-in-the-Middle.
 At-rest:шифрування повідомлень, що тимчасово зберігаються в чергах або
журналах системи.
 Аудит та невідмовність (Non-repudiation): Ведення захищеного
журналу подій (AuditTrail), який фіксує метадані кожної транзакції: хто
(ідентифікатор системи), коли (мітка часу), яку дію виконав та який статус
операції. Це дозволяє проводити розслідування інцидентів та гарантує, що
жодна сторона не зможе заперечити факт відправки або отримання даних.
4. Інтероперабельність (Interoperability).
Це ключова функціональна вимога, що визначає здатність підсистеми
виступати "універсальним перекладачем".
 Синтаксична сумісність: Здатність працювати з різними
транспортними протоколами (MLLP, HTTP/REST, TCP/IP) та форматами
серіалізації даних (ER7/Pipe-delimited, XML, JSON).
16
 Семантична сумісність: Здатність не просто передавати байти, а
зберігати клінічний зміст інформації. Підсистема повинна забезпечувати
мапінг (трансформацію) даних між різними версіями стандартів (наприклад,
конвертацію застарілого HL7 v2.3 у сучасний HL7 FHIR R4) та нормалізацію
довідників (наприклад, перекодування локальних кодів лабораторних тестів у
міжнародний стандарт LOINC).
 Гнучкість конфігурації: Можливість швидкого підключення
нових систем без необхідності переписування програмного коду ядра
підсистеми (наприклад, через конфігураційні профілі мапінгу).
Реалізація цих вимог вимагає застосування системного підходу до
проектування архітектури, що включає використання надійних патернів
інтеграції, сучасних засобів криптографічного захисту та високоефективних
алгоритмів обробки даних.
1.2. Аналіз існуючих стандартів та протоколів обміну медичними
даними (HL7, FHIR, DICOM)
1.2.1 Стандарт HL7 (HealthLevelSeven)
HL7 v2.x, часто званий «нестандартним стандартом» (non-
standardstandard), залишається найпоширенішим протоколом обміну
медичними даними у світі[6, 21]. За різними оцінками, він використовується
у понад 90% медичних закладів США та Європи для внутрішньолікарняної
комунікації.
Архітектурні особливості: HL7 v2 базується на обміні текстовими
повідомленнями, що ініціюються подіями (Event-driven). Структура
повідомлення є ієрархічною і складається з сегментів, полів, компонентів та
підкомпонентів, розділених спеціальними символами-делімітерами (зазвичай
|, ^, &).
Типова структура повідомлення включає:
17
 MSH (MessageHeader): Обов'язковий заголовок, що містить інформацію
про тип повідомлення (наприклад, ADT ‒Admission/Discharge/Transfer),
відправника, отримувача та версію стандарту.
 PID (PatientIdentification): Сегмент з демографічними даними пацієнта
(ПІБ, дата народження, ідентифікатори).
 OBR (ObservationRequest) та OBX (ObservationResult): Сегменти для
передачі замовлень на дослідження та їх результатів (ключові для LIS).
Головною перевагою HL7 v2 є його прагматичність. Він був
розроблений для підтримки інтерфейсів у середовищі, де вимоги постійно
змінюються. Стандарт допускає використання локальних розширень ‒ так
званих Z-сегментів. Це дозволяє розробникам додавати специфічні дані, не
порушуючи загальну структуру, що робить v2 надзвичайно гнучким для
інтеграції з успадкованим (legacy) обладнанням.
Незважаючи на свою «архаїчність» (розробка почалася у 80-х роках),
HL7 v2 є обов'язковим компонентом для забезпечення сумісності. Більшість
лабораторних аналізаторів та існуючих МІС в Україні вміють генерувати
саме HL7 v2 повідомлення. Саме тому розроблювана підсистема повинна
мати вбудований парсер для обробки цього формату, щоб гарантувати
максимальну інтероперабельність.
1.2.2 HL7 версії 3 (v3) та CDA: Спроба семантичної стандартизації
HL7 версії 3 був розроблений як відповідь на недоліки v2, зокрема на
його надмірну варіативність, яка вимагала складних попередніх
домовленостей між сторонами інтеграції.
 ReferenceInformationModel (RIM). В основі HL7 v3 лежить
Еталонна інформаційна модель (RIM)[8]. Це абстрактна об'єктно-орієнтована
модель, яка описує всі дані охорони здоров'я та зв'язки між ними через
невеликий набір класів: Act (дія), Entity (сутність), Role (роль). Всі
повідомлення v3 будуються як похідні від RIM і серіалізуються у формат
18
XML. Це забезпечує сувору семантичну точність, але робить стандарт
надзвичайно складним для вивчення та впровадження.
 ClinicalDocumentArchitecture (CDA). Хоча HL7 v3 як протокол
обміну повідомленнями не набув масового поширення через свою
складність, він став основою для успішного стандарту CDA
(ClinicalDocumentArchitecture).CDA визначає структуру та семантику
клінічних документів (наприклад, виписний епікриз, направлення) для
обміну між постачальниками послуг.
Структура CDA: Документ складається з заголовка (Header) з
метаданими та тіла (Body), яке містить як людино-читану частину (текст,
PDF), так і машино-читані структуровані записи (XML).
В Україні стандарт CDA часто використовується як основа для
формування електронних медичних записів, що передаються до центральної
компоненти eHealth, тому його підтримка є важливою для забезпечення
обміну документами, а не лише миттєвими повідомленнями.
1.2.3 Стандарт FHIR (FastHealthcareInteroperabilityResources)
FHIR (FastHealthcareInteroperabilityResources) ‒ це стандарт нового
покоління від організації HL7 International, який знаменує собою зміну
парадигми в обміні медичними даними[7, 17]. На відміну від своїх
попередників (HL7 v2 та v3), FHIR був розроблений «з нуля» з урахуванням
сучасних принципів веб-розробки, що робить його де-факто стандартом для
цифрової трансформації охорони здоров'я.
1. Архітектура, орієнтована на Ресурси (Resource-
OrientedArchitecture). Ключовою концептуальною одиницею стандарту є
«Ресурс». Ресурс ‒ це найменша логічно дискретна одиниця даних, яка має
визначену семантику.
 Приклади ресурсів: Patient (демографічні дані), Practitioner
(лікар), Observation (результат вимірювання або аналізу), MedicationRequest
(призначення ліків).
19
 Модульність: Кожен ресурс можна використовувати незалежно
або комбінувати з іншими для опису складних клінічних сценаріїв.
Наприклад, ресурс DiagnosticReport (звіт) містить посилання на ресурс Patient
(кому належить) та набір ресурсів Observation (що саме виміряли).
2. Технологічний стек:RESTful API та сучасні формати FHIR базується
на тих самих технологіях, що й сучасний інтернет (Google, Facebook, Twitter
API), що значно знижує поріг входження для розробників.
 RESTful API: Взаємодія здійснюється через стандартний
протокол HTTP за допомогою методів CRUD (Create, Read, Update, Delete).
Кожен ресурс має унікальний URL (наприклад, GET /Patient/123), що
дозволяє легко отримувати та маніпулювати даними.
 Формати даних: На відміну від складного XML у HL7 v3 або
вертикальних рисок у v2, FHIR використовує легковаговий формат JSON
(хоча підтримує і XML/RDF). JSON є "рідним" форматом для веб-браузерів
та мобільних додатків, що забезпечує високу швидкість парсингу та менше
навантаження на мережу.
3. Придатність для мобільних платформ та хмарних рішень. Завдяки
своїй легкості та використанню HTTP, FHIR ідеально підходить для
створення:
 Мобільних додатків для пацієнтів. Дозволяє отримувати історію
хвороби безпосередньо на смартфон.
 SMART on FHIR ‒це відкрита платформа, яка дозволяє
створювати взаємозамінні медичні додатки, що можуть запускатися
всередині будь-якої EHR-системи (аналог AppStore для медичних програм).
4. Механізми розширення та профілювання.Стандарт визнає, що
неможливо описати всі медичні нюанси єдиною схемою. Тому FHIR
підтримує механізм Профілювання (Profiling).
 Це дозволяє адаптувати базовий стандарт під національні
потреби (наприклад, український профіль eHealth) або специфіку конкретної
клініки, накладаючи обмеження на обов'язковість полів або додаючи
20
спеціальні розширення (Extensions), не порушуючи при цьому сумісність із
базовою специфікацією.
1.2.4 Стандарт DICOM
(DigitalImagingandCommunicationsinMedicine)
DICOM (DigitalImagingandCommunicationsinMedicine) ‒ це всеосяжний
міжнародний стандарт, розроблений Національною асоціацією виробників
електротехніки (NEMA), який регламентує створення, зберігання, передачу
та візуалізацію медичних зображень та документів[9]. На відміну від HL7,
який фокусується на текстових даних, DICOM є безальтернативним
стандартом для світу радіології та інструментальної діагностики.
1. Подвійна природа стандарту: формат і протокол. Унікальність
DICOM полягає в тому, що він описує дві сутності одночасно:
 Формат файлів. DICOM-файл не просто містить графічне
зображення (піксельні дані, як у JPEG),він є контейнером, що інкапсулює
метадані: інформацію про пацієнта (ПІБ, ID), параметри дослідження (доза
опромінення, товщина зрізу КТ) та налаштування обладнання. Цей зв'язок є
нерозривним, що унеможливлює випадкову підміну знімка одного пацієнта
даними іншого.
 Мережевий протокол. Стандарт визначає правила передачі даних
через мережі TCP/IP між модальностями (сканерами КТ, МРТ, УЗД-
апаратами), станціями перегляду та серверами архівування (PACS ‒ Picture
ArchivingandCommunicationSystem).
2. Об'єктно-орієнтована модель даних. В основі DICOM лежить
концепція IOD (InformationObjectDefinitions). Це інформаційні моделі
реального світу, наприклад: «Комп'ютерна томографія», «МРТ-
дослідження», «Ультразвук». Взаємодія базується на сервісах DIMSE
(DICOM MessageServiceElement), які визначають операції над об'єктами:
 C-STORE: Зберегти зображення в архів.
 C-FIND: Знайти пацієнта або дослідження.
21
 C-MOVE: Перемістити зображення на робочу станцію лікаря.
 ModalityWorklist (MWL): Завантажити список запланованих
пацієнтів на апарат (щоб лікарю не доводилося вводити ПІБ вручну).
3. Обмеження та місце в даному дослідженні. Незважаючи на свою
потужність, DICOM має чітко окреслену сферу застосування, що накладає
обмеження на його використання в рамках розроблюваної підсистеми
оперативної взаємодії:
 Вузька спеціалізація. DICOM оптимізований для роботи з
«важкими» бінарними даними (зображеннями). Він є занадто громіздким та
складним для передачі простих оперативних даних (результати біохімії крові,
призначення ліків, температурні листи), які складають основний потік обміну
в госпітальних системах.
 Складність інтеграції. Реалізація повноцінного DICOM-вузла
вимагає значних ресурсів і не є доцільною для задач, що не стосуються
візуалізації.
1.3. Обґрунтування вибору технологічної основи для розробки
підсистеми обміну даними
Аналіз вимог до оперативності, надійності та безпеки медичних даних,
проведений у попередніх підрозділах, дозволяє сформулювати критерії
вибору технологічного стека. Для реалізації підсистеми обміну даними, яка
здатна працювати в гетерогенному середовищі та забезпечувати
трансформацію між стандартами HL7 v2 та FHIR, необхідно обрати
архітектурний підхід, програмну платформу та протоколи взаємодії.
1.3.1 Обґрунтування вибору архітектурного підходу
Вибір архітектурного патерну є фундаментальним рішенням, що
визначає подальшу життєздатність, масштабованість та надійність
програмної системи. У контексті розробки підсистеми обміну медичними
22
даними, аналіз проводився шляхом порівняння традиційної монолітної
архітектури та сервісно-орієнтованого підходу (мікросервісів)[10].
1. Критика монолітної архітектури в контексті медичних систем.
Більшість існуючих медичних інформаційних систем (МІС) попередніх
поколінь побудовані за монолітним принципом, де користувацький
інтерфейс, бізнес-логіка та шар доступу до даних об'єднані в єдиний
виконуваний модуль (WAR/JAR файл). Хоча такий підхід спрощує початкову
розробку, він має критичні недоліки для інтеграційних задач:
 Висока ціна помилки (SinglePointofFailure). У монолітній системі
критична помилка в одному модулі (наприклад, переповнення пам'яті при
парсингу великого файлу аналізів) неминуче призводить до падіння
всього додатку. Для реанімаційного відділення, яке чекає на результати,
повна зупинка системи є неприпустимою.
 Складність масштабування. Моноліт можна масштабувати лише цілком
(вертикально або горизонтально). Це неефективно, оскільки різні модулі
мають різні вимоги до ресурсів: модуль прийому даних вимагає
пропускної здатності мережі, а модуль трансформації HL7 —
процесорного часу (CPU).
 Технологічна ригідність. Оновлення бібліотеки в одній частині системи
вимагає повного перетестування та перезапуску всього комплексу, що
ускладнює підтримку режиму 24/7.
2. Обґрунтування переходу до мікросервісної архітектури.
Враховуючи вимоги до відмовостійкості та необхідність обробки
гетерогенних даних, для розробки підсистеми обрано мікросервісну
архітектуру. Цей підхід передбачає декомпозицію системи на набір
невеликих, автономних сервісів, кожен з яких виконує одну бізнес-функцію
(SingleResponsibilityPrinciple) і спілкується з іншими через легковагові
протоколи (HTTP/REST або AMQP)[12].
Ключові переваги обраного підходу для підсистеми обміну даними:
23
 Ізоляція збоїв (FaultIsolation&BulkheadsPattern). Архітектура
дозволяє реалізувати патерн «перебірок». Якщо сервіс, що відповідає за
конвертацію у FHIR, вийде з ладу через некоректні вхідні дані, це не вплине
на роботу IngestionService (сервісу прийому). Система продовжить приймати
повідомлення від лабораторного обладнання і складати їх у чергу,
гарантуючи, що жоден біт інформації не буде втрачено під час аварії.
 Незалежне масштабування (GranularScaling). Медичне
навантаження є нерівномірним (піки вранці під час забору аналізів та
обходів). Мікросервісна архітектура дозволяє автоматично запускати
додаткові екземпляри (instances) лише найбільш навантажених модулів
(наприклад, ParserService), раціонально використовуючи обчислювальні
ресурси сервера.
 Технологічна гнучкість та поліглотність. Кожен мікросервіс є
незалежним у виборі технологій. Хоча основною платформою обрано Java,
архітектура дозволяє в майбутньому реалізувати специфічні модулі
(наприклад, модуль аналітики на Python для ML-обробки даних) та безшовно
інтегрувати їх у загальний контур через стандартні API, не переписуючи
існуюче ядро.
 Слабкa зв'язність (LooseCoupling). Використання асинхронного
обміну повідомленнями між мікросервісами дозволяє розірвати часову
залежність. Система-відправник (LIS) не повинна чекати, поки система-
одержувач (HIS) обробить дані. Це критично важливо для забезпечення
високої пропускної здатності (HighThroughput)[13].
Вибір мікросервісної архітектури є стратегічно виправданим, оскільки
він забезпечує необхідний рівень надійності (через ізоляцію компонентів),
дозволяє ефективно утилізувати ресурси (через точкове масштабування) та
створює фундамент для еволюційного розвитку системи без необхідності її
повної зупинки.
1.3.2 Обґрунтування вибору мови програмування та платформи
24
Вибір програмної платформи для реалізації серверної частини (Back-
end) підсистеми обміну даними базувався на аналізі нефункціональних
вимог, сформульованих у розділі 2 у пункті 2.1,зокрема вимог до надійності,
продуктивності та безпеки обробки даних. За результатами порівняльного
аналізу для реалізації обрано технологічний стек Java.
Цей вибір зумовлений сукупністю наступних технічних та галузевих
факторів:
1. Домінування в Health IT та зрілість екосистеми Java є де-факто
промисловим стандартом для розробки корпоративних медичних
інформаційних систем (EnterpriseHealth IT)[16].
 Нативні бібліотеки. Найпотужніша бібліотека для роботи зі
стандартом HL7 v2 — HAPI (HL7 API), яка використовується в цій роботі, є
нативною для Java. Використання Java дозволяє уникнути проблем із
сумісністю, що виникають при використанні "обгорток" (wrappers) в інших
мовах (наприклад, Python або Node.js).
 Інтеграційний потенціал. Більшість існуючих у світі
інтеграційних рушіїв (MirthConnect, ApacheCamel, MuleSoft), що
використовуються в лікарнях, побудовані на Java. Вибір цієї платформи
гарантує, що розроблена підсистема зможе безперешкодно інтегруватися в
існуючий ландшафт без необхідності використання додаткових проміжних
шарів.
2. Сувора статична типізація та безпека коду (TypeSafety). У сфері
охорони здоров'я ціна програмної помилки є надзвичайно високою. Java, як
мова зі суворою статичною типізацією, забезпечує значну перевагу над
динамічно типізованими мовами (такими як JavaScript або Python) у
контексті надійності:
 Compile-timeSafety. Більшість помилок, пов'язаних з некоректною
передачею даних (наприклад, спроба записати рядок тексту в поле "дата
народження"), виявляються компілятором ще на етапі збірки проекту, а не
під час виконання (Runtime), коли система вже обслуговує пацієнтів.
25
 Рефакторинг. У складних системах обміну даними структури
повідомлень часто змінюються. Статична типізація дозволяє безпечно
проводити рефакторинг коду, гарантуючи, що зміни в одному модулі не
порушать роботу залежних компонентів.
3. Продуктивність та багатопотоковість (Concurrency&Performance).
Обробка потоків HL7-повідомлень від сотень лабораторних аналізаторів
створює високе навантаження на I/O (ввід-вивід) та CPU.
 JIT-компіляція. Віртуальна машина Java (JVM) використовує Just-
In-Time (JIT) компіляцію, що оптимізує байт-код під час виконання,
забезпечуючи продуктивність, близьку до нативних мов (C++).
 Ефективна модель багатопотоковості. Вбудовані механізми
пакету java.util.concurrent та надійні веб-сервери (наприклад,
embeddedTomcat у SpringBoot) дозволяють ефективно реалізувати модель
"Thread-per-Request". Це забезпечує стабільну обробку тисяч конкурентних
запитів одночасно, що є критичним для забезпечення вимоги високої
пропускної здатності (HighThroughput).
 Управління пам'яттю. Сучасні збирачі сміття (GarbageCollectors,
наприклад G1GC або ZGC) в Java дозволяють ефективно керувати пам'яттю
навіть при обробці великих обсягів даних, мінімізуючи затримки "Stop-the-
world", що важливо для систем реального часу.
4. Переваги фреймворку SpringBoot. Використання фреймворку
SpringBoot трансформує Java з "мови програмування" у повноцінну
платформу для швидкої розробки мікросервісів:
 InversionofControl (IoC) та DependencyInjection (DI). Цей
архітектурний патерн, реалізований у Spring, дозволяє створювати слабко
зв'язані компоненти (LooseCoupling). Це критично важливо для тестування:
ми можемо легко замінити реальний сервіс відправки даних на "заглушку"
(mock) під час модульних тестів, не змінюючи основний код.
26
 ConventionoverConfiguration.SpringBoot мінімізує необхідність
ручного налаштування інфраструктури, надаючи готові, перевірені
індустрією конфігурації за замовчуванням.
 Готові модулі безпеки.Модуль SpringSecurity надає
стандартизовані, перевірені спільнотою реалізації механізмів аутентифікації
(OAuth2, BasicAuth) та захисту від веб-вразливостей (CSRF, XSS), що
дозволяє виконати вимоги щодо захисту персональних даних без
необхідності написання власної криптографії.
Вибір зв'язки Java + SpringBoot є стратегічним інженерним рішенням,
яке дозволяє мінімізувати ризики розробки, забезпечити відповідність
жорстким вимогам надійності медичних систем та створити масштабовану
архітектуру, готову до промислової експлуатації[11].
1.3.3 Вибір інструментарію для роботи зі стандартами (Бібліотека
HAPI)
Одним із найбільш ресурсоємних етапів розробки інтеграційних
шлюзів є реалізація логіки синтаксичного розбору (парсингу) та валідації
повідомлень. Стандарт HL7 v2, попри свою зовнішню простоту(текстовий
формат), має складну структуру вкладеності (сегменти, поля, компоненти,
підкомпоненти) та специфічні правила екранування службових символів.
Спроба реалізації власного парсера (CustomParser) з використанням
регулярних виразів або простих рядкових операцій (Stringmanipulation) була
відкинута як технічно недоцільна через високий ризик виникнення
прихованих помилок (Edgecases), складність підтримки різних версій
стандарту (від v2.1 до v2.8) та значну трудомісткість.
Тому в якості базового інструментарію обрано бібліотеку HAPI (HL7
ApplicationProgrammingInterface)[24]. Це рішення обґрунтовується
наступними технічними перевагами:
1. Статус галузевого стандарту HAPI ‒ це зріла, перевірена часом
(розробляється з 2001 року) open-source бібліотека для екосистеми Java. Вона
27
є фактичним стандартом для Java-розробників у сфері охорони здоров'я та
використовується в ядрах таких промислових інтеграційних платформ, як
MirthConnect та ApacheCamel HL7. Використання HAPI гарантує стабільність
роботи з реальними даними, які часто містять незначні відхилення від
стандарту.
2. Об'єктно-орієнтована абстракція над HL7 v2. Бібліотека HAPI v2
(модулі hapi-base та hapi-structures) забезпечує повну інкапсуляцію
низькорівневої структури повідомлення.
 Абстрагування від синтаксису. Розробнику не потрібно вручну
розділяти рядок за символами | або ^. Бібліотека надає клас PipeParser, який
автоматично трансформує вхідний потік байтів у ієрархічний Java-об'єкт.
 Строга типізація. HAPI надає готові Java-класи для кожного
типу повідомлення (наприклад, клас ADT_A01) та кожного сегмента. Це
дозволяє працювати з даними через методи доступу (Getters/Setters),
наприклад: msg.getPID().getPatientName(), замість доступу за індексами
масиву, що значно підвищує надійність коду.
 Підтримка версійності. Бібліотека містить визначення структур
для всіх версій HL7. Це дозволяє системі автоматично визначати версію
вхідного повідомлення (через поле MSH-12) і застосовувати відповідну
схему парсингу.
3. Підтримка екосистеми FHIR (HAPI FHIR) Для реалізації завдань
конвертації даних у сучасний формат використовується споріднений проект
‒HAPI FHIR[23].
 Генерація ресурсів: Модуль надає зручний Fluent API для
конструювання складних ієрархічних JSON-структур (Resources), що звільняє
від необхідності ручного формування JSON-рядків.
 Вбудована валідація: Бібліотека містить потужний механізм
валідації (Validator), який дозволяє перевірити сформований ресурс на
відповідність офіційній специфікації FHIR R4 (перевірка обов'язкових полів,
28
типів даних, кардинальності) ще до моменту відправки даних зовнішньому
клієнту.
4. Інженерна ефективність Використання HAPI дозволяє реалізувати
стратегію «BuyoverBuild» (в даному випадку ‒ використання готового
OpenSource), що дозволяє зосередити зусилля розробки на реалізації бізнес-
логіки (мапінгу та маршрутизації), а не на вирішенні інфраструктурних
проблем розбору протоколу. Це суттєво скорочує час виходу продукту на
ринок (Time-to-Market) та знижує технічний борг проекту.
1.3.4 Вибір протоколів взаємодії (HTTP та REST)
Якщо для внутрішньої обробки потоків даних у мікросервісній
архітектурі доцільно використовувати асинхронні черги (RabbitMQ), то для
забезпечення взаємодії із зовнішніми системами (ExternalInteroperability)
критично важливим є вибір універсального, синхронного протоколу.
Враховуючи необхідність інтеграції як із застарілими, так і з новітніми
клієнтськими додатками, в якості основного транспортного протоколу
обрано HTTP/HTTPS, а в якості архітектурного стилю API ‒ REST.
Цей вибір обґрунтовується наступними технічними та стратегічними
факторами:
1. Універсальність та інфраструктурна сумісність. Протокол HTTP
(HyperTextTransferProtocol) є фундаментом сучасного інтернету.
 Кросплатформеність. На відміну від специфічного для HL7 v2
протоколу MLLP (MinimalLowerLayerProtocol), який вимагає роботи з
"сирими" TCP-сокетами, HTTP-клієнти вбудовані у всі сучасні мови
програмування (Java, Python, JavaScript, C#). Це дозволяє будь-якій зовнішній
системі (наприклад, мобільному додатку пацієнта на iOS або веб-порталу
лікаря) легко підключитися до підсистеми обміну даними.
 Мережева прозорість. Використання стандартних портів значно
спрощує налаштування мережевих екранів та проксі-серверів у лікарняній
29
мережі, усуваючи необхідність відкриття нестандартних портів, що часто є
проблемою для служб інформаційної безпеки.
2. Переваги архітектурного стилю REST. Використання архітектури
REST (RepresentationalStateTransfer) дозволяє побудувати інтуїтивно
зрозумілий та масштабований API.
 Семантика методів. REST використовує стандартні дієслова
HTTP для відображення операцій над даними (CRUD), що спрощує розробку
та налагодження:
 POST ‒ для створення нового ресурсу (наприклад, відправка
результату аналізу).
 GET ‒ для отримання даних (запит історії хвороби).
 Statelessness (Відсутність стану). Сервер не зберігає стан сесії
клієнта між запитами. Це є критичним для обраної мікросервісної
архітектури, оскільки дозволяє легко масштабувати систему: будь-який
екземпляр сервісу може обробити будь-який вхідний запит, що підвищує
загальну відмовостійкість.
3. Стратегічна сумісність з FHIR. Найвагомішим аргументом на
користь HTTP/REST є орієнтація на стандарт HL7 FHIR.
 Специфікація FHIR базується виключно на RESTful API. Відмова
від REST на цьому етапі унеможливила б реалізацію модуля конвертації у
FHIR.
 Вибір HTTP дозволяє використовувати формат JSON для
серіалізації даних, що є значно "легшим" та швидшим для парсингу в веб-
середовищі порівняно з XML.
4. Безпека транспортного рівня. Протокол HTTP легко розширюється
до HTTPS (HTTP Secure) шляхом використання криптографічних протоколів
TLS/SSL. Це дозволяє виконати вимогу щодо шифрування даних під час
передачі (Data in Transit), забезпечуючи конфіденційність медичної
інформації без необхідності реалізації власних алгоритмів шифрування на
рівні додатку.
30
1.4. Висновки до першого розділу
У першому розділі проведено комплексний аналіз теоретичних засад та
методів організації інформаційної взаємодії в медичному середовищі. На
основі дослідження предметної області отримано наступні результати:
1. Проаналізовано стан інформатизації медичної галузі.
Встановлено, що сучасний ІТ-ландшафт медичних закладів характеризується
високим ступенем гетерогенності та складається з ізольованих програмних
комплексів: госпітальних (HIS), лабораторних (LIS) та радіологічних (RIS)
систем. Визначено, що ключовою проблемою галузі є відсутність ефективної
інтероперабельності, що призводить до фрагментації клінічних даних, їх
дублювання та підвищення ризику лікарських помилок. Це дозволило
сформулювати мету роботи та визначити об’єкт і предмет дослідження.
2. Сформульовано вимоги до підсистеми обміну даними. Визначено
критичні нефункціональні вимоги, необхідні для забезпечення наукової
новизни та практичної цінності розробки. До них віднесено: оперативність
(робота в режимі, наближеному до реального часу), гарантовану доставку
повідомлень (надійність), суворе дотримання стандартів безпеки
(шифрування, аутентифікація) та семантичну інтероперабельність.
3. Здійснено порівняльний аналіз стандартів обміну даними:
 Виявлено, що стандарт HL7 v2.x залишається домінуючим у
наявному медичному обладнанні та legacy-системах, тому його підтримка є
обов’язковою.
 Встановлено, що стандарт HL7 FHIR є найбільш перспективним
для інтеграції з сучасними веб- та мобільними платформами завдяки
використанню RESTful архітектури.
 Визначено, що стандарт DICOM має вузьку спеціалізацію
(медичні зображення) і в рамках даної роботи буде використовуватися лише
на рівні обміну ідентифікаторами досліджень. Таким чином, основним
31
завданням підсистеми визначено забезпечення двосторонньої конвертації
даних між форматами HL7 v2 та FHIR.
4. Обґрунтовано технологічний стек та архітектурний підхід:
 Для забезпечення відмовостійкості та ізоляції збоїв обрано
мікросервісну архітектуру.
 В якості програмної платформи обрано екосистему JavaEnterprise
та фреймворк SpringBoot, що аргументовано їх надійністю, продуктивністю
та домінуванням у сфері Health IT.
 Для вирішення складних задач синтаксичного розбору
повідомлень обрано використання спеціалізованої бібліотеки HAPI (HL7
API).
 Для зовнішньої взаємодії затверджено використання протоколу
HTTP/HTTPS та архітектурного стилю REST.
Результати, отримані в першому розділі, створюють необхідне
теоретичне та технологічне підґрунтя для переходу до наступного етапу ‒
проектування архітектури та логічної моделі підсистеми обміну даними, що
буде розглянуто у другому розділі.
32
РОЗДІЛ 2
ПРОЕКТУВАННЯ АРХІТЕКТУРИ ПІДСИСТЕМИ ОБМІНУ ДАНИМИ
2.1. Вимоги до функціональності та надійності підсистеми обміну
даними
Розробка програмного рішення для медичної галузі вимагає глибокого
розуміння ключових аспектів обміну медичною інформацією, особливо при
використанні стандарту HealthLevelSeven (HL7). Підсистема обміну даними
повинна відповідати суворим вимогам до функціональності, надійності та
інтеграції, щоб гарантувати безпечний та ефективний рух клінічної
інформації.
2.1.1 Фундаментальні концепції HL7 v2.x для архітектури обміну
даними
Для побудови надійної та сумісної підсистеми обміну медичними
даними є критичним опанування архітектурних основ, закладених у стандарті
HL7 версії 2.x. Цей стандарт використовує суворий, але гнучкий ієрархічний
синтаксис для представлення клінічних подій як електронних
повідомлень[6].
Ієрархічна структура повідомлень та сегментів.
HL7 повідомлення є текстовим файлом, що формується у відповідь на
певну тригерну подію (наприклад, реєстрація нового пацієнта, замовлення
лабораторного тесту).
 Повідомлення (Message). Це найбільша логічна одиниця, яка
інкапсулює інформацію про одну клінічну подію. Тип повідомлення
визначається комбінацією трьох полів у заголовку MSH (наприклад,
ADT^A04 – реєстрація нового пацієнта).
 Сегменти (Segments). Це послідовні рядки даних, які починаються з
трисимвольного ідентифікатора (наприклад, PID ‒ ідентифікація
33
пацієнта, ORC ‒ загальний контроль замовлення, OBR ‒
спостереження). Сегменти можуть бути обов'язковими чи
опціональними, а деякі можуть повторюватися в межах одного
повідомлення.
 Заголовок повідомлення (MSH ‒MessageHeader). Це ключовий сегмент,
який завжди є першим. Він визначає метадані транзакції, включаючи:
 Символи-розділювачі.
 Системи-відправника та одержувача.
 Тип повідомлення та його версію.
 Унікальний ідентифікатор повідомлення.
Деталізація даних: поля, компоненти та підкомпоненти.
Дані всередині сегмента організовані ієрархічно, що дозволяє точно
структурувати складні атрибути:
 Поля (Fields). Це окремі елементи даних у сегменті, розділені символом
| (вертикальна риска).
 Компоненти (Components). Складні поля можуть бути розділені на
компоненти за допомогою символу ^ (карет), що дозволяє, наприклад,
розділити ім'я та прізвище пацієнта в одному полі.
 Підкомпоненти (Subcomponents). Деякі компоненти, у свою чергу,
можуть бути розділені на підкомпоненти символом & (амперсанд) для
ще більш детальної грануляції.
Така структуризація гарантує, що системи-одержувачі зможуть
однозначно виділити та інтерпретувати кожен біт медичної інформації.
Стандартизація кодування та типи даних.
Ефективна інтероперабельність досягається через використання
стандартизованих типів даних та кодових систем:
 HL7 типи даних. Стандарт визначає набір абстрактних типів даних
(наприклад, DTM для дати/часу, CE для кодованих елементів, XPN для
імені людини), які обов'язково мають використовуватись для
відповідних полів.
34
 Кодовані елементи (CE). Для полів, що вимагають стандартизації
(наприклад, одиниці виміру, статус замовлення), HL7 використовує
формат CE (CodedElement), який дозволяє передати не лише текстове
значення, але й відповідний стандартизований код з зовнішньої кодової
системи (наприклад, LOINC, SNOMED CT, ICD-10). Правильне
відображення (mapping) цих кодів є критичним для коректної
інтерпретації даних між різними системами.
Механізми надійності: цілісність та підтвердження.
Для забезпечення гарантованої доставки та цілісності даних у
підсистемі обміну впроваджуються такі механізми:
 Обробка підтверджень (Acknowledgement‒ ACK). Після отримання
повідомлення система-одержувач зобов'язана надіслати повідомлення-
підтвердження.
- ACK(Успіх): Вказує, що повідомлення було успішно прийнято та
оброблено.
- NACK (Невдача): Вказує на синтаксичну або логічну помилку в
повідомленні (наприклад, відсутність обов'язкового сегмента), ініціюючи
повторну передачу або ручну корекцію.
 Контрольні суми (Checksums). Хоча це не є основним елементом HL7
v2.x, багато протоколів передачі (наприклад, MLLP
‒MinimalLowerLayerProtocol, який часто використовується для HL7)
застосовують механізми контрольних сум та блокування для перевірки
цілісності даних на рівні комунікації, гарантуючи, що байти не були
спотворені під час передачі мережею.
Впровадження цих концепцій дозволяє побудувати не просто систему
передачі файлів, а повноцінну, подієво-орієнтовану архітектуру (Event-
DrivenArchitecture), що адекватно реагує на зміни клінічного стану пацієнта.
35
2.1.2 Ключові вимоги до функціональності та продуктивності
підсистеми обміну даними
Успіх підсистеми обміну медичною інформацією, що базується на HL7,
визначається її здатністю не лише правильно інтерпретувати стандарт, але й
демонструвати високу надійність, продуктивність та адаптивність в умовах
зростаючого клінічного навантаження.
Функціональна точність: сумісність зі стандартом HL7.
Фундаментальною вимогою є повна та точна підтримка визначеної
версії стандарту HL7 (як правило, v2.x). Це виходить за рамки простого
парсингу синтаксису і включає:
 Семантична валідація. Підсистема повинна не тільки перевіряти,
чи повідомлення правильно структуроване (наприклад, чи є всі
розділювачі), але й чи відповідає його семантика очікуваній логіці.
Наприклад, чи є в повідомленні про результати лабораторних
досліджень обов'язкові сегменти OBR (запит) та OBX (результати).
 Підтримка типів повідомлень. Необхідно забезпечити коректну
обробку повного спектра клінічних транзакцій:
 ADT (Admission, Discharge, Transfer): події, пов'язані з рухом
пацієнта (реєстрація, переведення, виписка).
 ORM (OrderEntry): замовлення діагностичних, терапевтичних
або інших процедур.
 ORU (ObservationResult): передача результатів лабораторних,
радіологічних досліджень чи інших спостережень.
 Гнучкість профілів (Z-Сегменти). У медичних системах часто
використовуються локальні розширення стандарту (так звані Z-
сегменти). Підсистема має бути здатна ігнорувати або, за необхідності,
кастомізовано обробляти ці нестандартні сегменти, не порушуючи при
цьому обробку основних даних.
Надійність обміну даними (FaultTolerance).
36
Втрата медичних даних є неприпустимою. Тому підсистема повинна
мати вбудовані механізми відмовостійкості та гарантованої доставки, які
забезпечують, що кожен байт інформації досягне цільової системи.
 Гарантована доставка (GuaranteedDelivery). Реалізація
протоколів, що використовують асинхронну чергу повідомлень
(MessageQueue), для тимчасового зберігання даних у разі
недоступності системи-одержувача.
 Логіка повторних спроб (RetryMechanism). Якщо система-
одержувач повертає негативне підтвердження або не відповідає,
підсистема повинна автоматично повторити спробу передачі
повідомлення через певні інтервали, які експоненційно зростають.
 Обробка винятків та "мертві листи" (Dead-LetterQueue‒ DLQ).
Невиправні помилки (наприклад, невірний синтаксис, після N-ї спроби)
мають бути відведені у спеціалізовану чергу (DLQ) для ручного аудиту
та розслідування, щоб критична інформація не була втрачена.
 Моніторинг транзакцій. Забезпечення постійного моніторингу
статусу кожного повідомлення (очікує, доставлено, помилка) для
швидкого реагування на збої.
Продуктивність та ефективність обробки.
Продуктивність є критичною, оскільки затримки в обробці (наприклад,
результатів термінових аналізів) можуть мати прямий вплив на якість
медичної допомоги.
 Низька затримка (LowLatency). Підсистема повинна
забезпечувати мінімальну затримку між генерацією клінічної події та її
передачею та обробкою цільовою системою. Особливо це стосується
критичних даних (наприклад, життєво важливі показники).
 Висока пропускна здатність (HighThroughput). Здатність
обробляти велику кількість повідомлень за одиницю часу (наприклад,
сотні транзакцій HL7 за секунду) без створення "вузьких місць" у
процесі обробки та перетворення даних.
37
 Оптимізація парсингу. Використання високоефективних парсерів
HL7, які мінімізують навантаження на CPU та пам'ять під час розбору
та генерації складних повідомлень.
Масштабованість архітектури (Scalability).
Підсистема має бути спроектована не для поточних, а для майбутніх
обсягів даних, що є характерним для швидко зростаючої медичної установи.
 Горизонтальна масштабованість. Можливість додавання нових
незалежних вузлів (серверів, інстансів) для розподілу навантаження. Це
дозволяє збільшувати пропускну здатність просто шляхом додавання
ресурсів, а не модернізації існуючого обладнання (масштабування за
рахунок додавання).
 Ізоляція компонентів. Використання мікросервісної архітектури
або модульного підходу, де окремі функції (наприклад, підключення до
ЛІС, підключення до ЕМК, трансформація даних) є незалежними. Збій
в одному модулі не повинен зупиняти роботу всієї підсистеми.
 Ефективне управління з'єднаннями. Здатність одночасно
підтримувати велику кількість постійних з'єднань з багатьма різними
джерелами та отримувачами даних, ефективно розподіляючи мережеві
ресурси.
Відповідність цим вимогам гарантує, що підсистема обміну даними
стане надійним хребтом для інтеграції всіх клінічних та адміністративних
систем медичного закладу.
2.1.3 Вимоги до інтеграції з іншими медичними системами
Ефективна підсистема обміну даними функціонує не ізольовано, а як
центральний комунікаційний вузол, що зв'язує різноманітні клінічні та
адміністративні системи. Успішна інтеграція вимагає стратегічного підходу
до узгодженості, безпеки та гнучкості.
Технічна узгодженість: стандарти та протоколи.
38
Інтеграційне рішення має виступати як перекладач і адаптер між
різними технологічними доменами:
 Гармонізація протоколів.недостатньо підтримувати лише HL7.
Слід забезпечити сумісність на рівні транспортного протоколу
(наприклад, MLLP для HL7 v2.x, HTTP/REST для FHIR), а також з
більш загальними комунікаційними стандартами, які можуть
використовуватись зовнішніми системами (наприклад,
SOAP/WebServices).
 Дотримання профілів інтероперабельності (IHE). Для вирішення
конкретних клінічних завдань (наприклад, обмін документами,
узгодження ідентифікаторів пацієнтів) необхідно дотримуватись
профілів, розроблених ініціативою IntegratingtheHealthcareEnterprise
(IHE)[19]. Це забезпечує, що системи інтегруються не просто технічно,
а й логічно, виконуючи спільні клінічні робочі процеси.
Керування даними: інтероперабельність та гнучкість форматів.
Справжня інтероперабельність‒ це здатність систем не лише
обмінюватися бітами, але й розуміти їхній клінічний сенс.
 Семантична інтероперабельність. Підсистема має забезпечити
узгодження термінології. Якщо одна система використовує ICD-10 для
діагнозів, а інша SNOMED CT, інтеграційний компонент повинен
виконувати трансформацію (mapping) кодових значень, щоб уникнути
втрати чи спотворення клінічного значення даних[20].
 Гнучкість та трансформація форматів: медичне середовище є
гетерогенним:
o HL7 v2.x для повідомлень (замовлення, результати).
o DICOM для медичних зображень (рентген, КТ).
o HL7 FHIR для сучасних мобільних додатків та веб
інтерфейсів.
Підсистема повинна мати потужний механізм трансформації (ETL
‒Extract, Transform, Load), здатний переводити дані з одного стандарту в
39
інший (наприклад, з HL7 v2.x у FHIR ресурси) для забезпечення зв'язку між
спадковими та новітніми системами.
Безпека та конфіденційність даних.
Захист інформації про пацієнта є не лише технічною, а й юридичною
вимогою (наприклад, відповідність HIPAA у США чи GDPR в Європі).
 Шифрування при передачі. Весь обмін даними повинен
відбуватися через захищені канали (TLS/SSL), щоб запобігти
перехопленню даних "повітрям".
 Контроль доступу (Аутентифікація/Авторизація). Необхідно
впровадити строгі механізми:
Аутентифікація ‒перевірка особи інтегруючої системи-користувача
(наприклад, через сертифікати або OAuth токени).
Авторизація ‒визначення, які типи даних (наприклад, лише
лабораторні результати, але не психіатричні записи) дозволено
отримувати або надсилати конкретній системі-партнеру.
 Журналюваннядоступу (AuditTrails). Кожна транзакція, що
стосується конфіденційних даних, має бути незмінно зафіксована з
інформацією про те, хто, коли, яку інформацію отримав або змінив.
Управління інтеграцією: моніторинг та адаптивність.
Підтримка інтеграційного середовища у робочому стані вимагає
постійного нагляду та гнучкості до змін.
 Централізований моніторинг та логування. Система повинна мати
єдину панель керування для відстеження потоків даних у реальному
часі. Логи мають бути структуровані та містити деталі про час, тип
повідомлення, систему-відправника та будь-які виниклі помилки (як
технічні, так і логічні). Це дозволяє оперативно ідентифікувати та
діагностувати "затори" або збої в будь-якій частині інтеграційної
мережі.
40
 Адаптивність через інтеграційні рішення (ESB/IaaS). Замість
створення прямих зв'язків "точка-точка", бажано використовувати
інтеграційні рішення:
 Інтеграційна шина (EnterpriseServiceBus‒ ESB):
використовується як брокер повідомлень, що дозволяє легко
підключати нові системи через адаптери, не змінюючи логіку
існуючих додатків.
 Адаптери: спеціалізовані модулі, які "розмовляють" мовою
конкретної зовнішньої системи, перетворюючи її дані на
внутрішній, стандартизований формат.
Реалізація цих вимог перетворює підсистему обміну даних з простого
транслятора на стратегічну платформу, яка забезпечує безперебійний та
безпечний обмін клінічною інформацією в медичному закладі.
2.2. Розробка загальної архітектури інтеграційної підсистеми
Архітектура проектованої системи базується на принципах
мікросервісної архітектури (MicroservicesArchitecture). На відміну від
монолітного підходу, система декомпозується на набір невеликих, слабко
пов'язаних (looselycoupled) сервісів, кожен з яких виконує чітко визначену
бізнес-функцію в домені обробки HL7-повідомлень. Така архітектура
забезпечує гнучкість розгортання, незалежне масштабування модулів та
високу відмовостійкість.
2.2.1 Структурні елементи архітектури
Система складається з наступних ключових елементів:
1. API Gateway (Шлюз API): єдина точка входу для всіх зовнішніх
запитів. Шлюз відповідає за маршрутизацію запитів до відповідних
мікросервісів, аутентифікацію та авторизацію клієнтів, а також балансування
навантаження (LoadBalancing). Для протоколу HL7 v2 шлюз може
41
інкапсулювати MLLP-трафік, перетворюючи його на внутрішні HTTP/gRPC
виклики.
2. Сервіс-оркестратор (OrchestratorService): керує бізнес-логікою
інтеграції. Він визначає послідовність виклику інших сервісів (Sagapattern)
для обробки одного повідомлення. Наприклад: спочатку викликати парсер,
потім валідатор, потім зберегти в БД.
3. Функціональні мікросервіси:
 IngestionService (Сервіс прийому даних): відповідає за отримання
"сирих" даних (rawdata) через різні канали (TCP/IP, REST) та їх
первинну буферизацію.
 ParserService (Сервіс парсингу): спеціалізований мікросервіс, що
розбирає рядки HL7 v2 або JSON-структури FHIR та перетворює їх
у внутрішні об'єкти системи (DTO).
 MappingService (Сервіс мапінгу): виконує трансформацію даних
(наприклад, бібліотека мапінгу полів PID-5 у структуру
PatientName).
 ValidationService (Сервіс валідації): перевіряє відповідність
повідомлення схемам та бізнес-правилам.
4. MessageBroker (Брокер повідомлень): виступає асинхронною
комунікаційною шиною[14]. Сервіси обмінюються даними через публікацію
подій (Events), що дозволяє розірвати пряму залежність між ними.
Наприклад, сервіс прийому публікує подію MessageReceived, на яку
підписаний сервіс парсингу.
5. DatabaseperService (окрема БД для кожного сервісу): згідно з
патернамимікросервісів, кожен сервіс володіє власним сховищем даних[12].
Це запобігає конфліктам доступу та дозволяє використовувати різні
технології (поліглотна персистентність): наприклад, PostgreSQL для
метаданих та MongoDB для зберігання тіла JSON-документів.
42
2.2.2 Інфраструктурні рішення та комунікація
Взаємодія між сервісами реалізується двома способами:
 Синхронна (Synchronous). Використання REST API або gRPC для
операцій, що вимагають миттєвої відповіді (наприклад, запит статусу
пацієнта).
 Асинхронна (Asynchronous). Використання черг повідомлень для
процесів обробки великих масивів даних, що дозволяє згладжувати
пікові навантаження.
Для розгортання системи використовується контейнеризація (Docker).
Кожен мікросервіс пакується в окремий контейнер, що дозволяє запускати їх
у кластерному середовищі (наприклад, Kubernetes). Це забезпечує
автоматичне відновлення роботи сервісів у разі збою (Self-healing).
2.2.3 Переваги обраної архітектури для обміну даними
1. Ізоляція збоїв (FaultIsolation): Помилка в сервісі трансформації не
зупиняє роботу сервісу прийому повідомлень. Система продовжує приймати
дані в буфер, навіть якщо обробник тимчасово недоступний.
2. Технологічна незалежність: Можливість писати різні сервіси на
різних мовах програмування (наприклад, парсер на Java для швидкодії, а веб-
інтерфейс на Node.js/Ruby).
3. Масштабованість (GranularScaling): Якщо навантаження зростає
лише на етапі валідації, система автоматично створює додаткові екземпляри
лише контейнера ValidationService, не витрачаючи ресурси на інші частини.
2.3. Проектування логічної моделі даних та інтерфейсів взаємодії
Проектування логічної моделі підсистеми обміну даними базується на
принципах семантичної інтероперабельності та вимогах стандарту HL7.
Ключовим завданням є створення абстракції, яка дозволяє уніфікувати
різнорідні дані локальних МІС (медичних інформаційних систем) у
стандартизовані повідомлення.
43
2.3.1 Логічна модель даних (LogicalDataModel)
Логічна модель даних підсистеми не дублює повну структуру бази
даних МІС, а виділяє лише ті сутності, що беруть участь у міжопераційному
обміні. Основу моделі складають доменні об'єкти, що відповідають ресурсам
(Resources) або сегментам (Segments) стандарту HL7.
Основні проектовані сутності включають:
 Patient (Пацієнт): центральна сутність, що містить демографічні дані,
ідентифікатори (MPI-ID, локальний ID), які використовуються для
крос-ідентифікації між системами.
 Encounter (Візит/Випадок обслуговування): логічний зв'язок між
пацієнтом та медичним закладом, що містить контекст події
(амбулаторний прийом, госпіталізація).
 Observation (Спостереження/Результати): універсальна сутність для
зберігання вимірюваних даних (лабораторні аналізи, вітальні
показники), яка включає кодування згідно з міжнародними
класифікаторами (LOINC, SNOMED CT).
 Practitioner (Лікар): дані про медичний персонал, що бере участь у
наданні послуг.
Примітка: Тут варто зазначити, що для збереження цілісності даних
використовується нормалізація до 3-ї нормальної форми (3НФ), а для обміну
‒ серіалізація у формати JSON або XML.
2.3.2 Проектування інтерфейсів та механізму обміну
(InteractionDesign)
У розробленій системі реалізовано механізм прямої передачі
повідомлень (DirectMessageInjection). Клієнтська частина функціонує як
консоль оператора, що дозволяє відправляти сформовані HL7-повідомлення
на сервер обробки для тестування логіки парсингу та збереження даних.
Алгоритм взаємодії реалізовано наступним чином:
44
1. Інкапсуляція та формування запиту (Encapsulation): клієнтський
додаток огортає введений рядок у структуру HTTP-запиту. Тіло
повідомлення передається як JSON-об'єкт (наприклад, { "message":
"MSH|..." }). Це дозволяє передавати спеціальні символи HL7
(роздільники сегментів, полів) через протокол HTTP без порушення їх
цілісності.
2. Передача даних (Transmissionvia REST API): виконується синхронний
POST запит до API Gateway серверної частини. Цей метод забезпечує
гарантовану доставку та очікування відповіді від сервера про
результати обробки транзакції.
3. Серверна обробка (Server-SideProcessing): як показано на рисунку 2.1,
сервер приймає рядок, і саме тут відбувається основна логіка:
 Парсинг: розбиття рядка на сегменти та поля.
 Інтерпретація: визначення типу події (наприклад, це додавання
пацієнта чи результат аналізу).
 Валідація: перевірка коректності структури HL7 та збереження у
базу даних.
45
Рисунок 2.1 –Схема алгоритму обробки HL7 повідомлення
4. Візуалізація відповіді (ResponseHandling): Сервер повертає
стандартизовану відповідь (ACK-повідомлення або JSON зі статусом
операції). Клієнтський інтерфейс відображає користувачеві результат:
у разі успіху — підтвердження збереження, у разі помилки ‒ детальний
опис проблеми (наприклад, "Некоректний формат дати у сегменті
PID").
Для програмної реалізації описаного алгоритму обробки на серверній
стороні було спроектовано об’єктно-орієнтовану структуру, яка
забезпечує декомпозицію задач прийому, парсингу та конвертації даних.
Структурна організація програмних компонентів та їх взаємодія на рівні
класів наведені на рисунку 2.2.
Рисунок 2.2 – Діаграма класів модуля обробки запитів та конвертації даних
46
2.4. Висновки до другого розділу
У другому розділі проведено комплексне проектування архітектури та
логічної структури підсистеми обміну даними для медичних інформаційних
систем. На основі аналізу стандарту HL7 v2.x та вимог до
інтероперабельності отримано наступні результати:
1. Формалізовано вимоги до обробки даних. Визначено критичні аспекти
функціонування системи, зокрема необхідність семантичної валідації
повідомлень, підтримку гарантованої доставки та обробку помилок.
Встановлено, що використання ієрархічної структури HL7 (сегменти,
поля, компоненти) дозволяє уніфікувати різнорідні клінічні дані,
забезпечуючи їх коректну інтерпретацію незалежними системами.
2. Обґрунтовано вибір архітектурного підходу. Розроблено архітектуру
підсистеми на основі принципів мікросервісів. Такий підхід, на відміну
від монолітного, забезпечує високу відмовостійкість (ізоляцію збоїв),
гнучке масштабування окремих компонентів (наприклад, сервісу
валідації) та технологічну незалежність модулів. Використання
контейнеризації та патернуDatabaseperService дозволяє створити
надійне середовище для обробки високого навантаження.
3. Спроектовано модель взаємодії та даних. Розроблено логічну модель
даних, що базується на ключових сутностях медичного домену (Patient,
Encounter, Observation), та визначено правила їх мапінгу з HL7-
сегментами. Запропоновано механізм прямої ін'єкції повідомлень
(DirectMessageInjection) через клієнтську консоль, що дозволяє
ефективно тестувати логіку парсингу та валідації без необхідності
розгортання повної інфраструктури зовнішньої МІС.
Запропоновані проектні рішення створюють необхідне підґрунтя для
наступного етапу ‒ програмної реалізації підсистеми, гарантуючи її
відповідність сучасним стандартам надійності та безпеки медичних даних.
47
РОЗДІЛ 3
ПРАКТИЧНА РЕАЛІЗАЦІЯ МОДУЛІВ ПІДСИСТЕМИ ТА
ТЕСТУВАННЯ
3.1. Опис інструментальних засобів та технологій реалізації
підсистеми
Вибір технологічного стека для реалізації підсистеми зумовлений
вимогами до високої надійності, строгої типізації даних та необхідністю
використання сертифікованих бібліотек для роботи з медичними
стандартами. Реалізація виконана на платформі JavaEnterprise з
використанням мікросервісного фреймворку SpringBoot.
3.1.1 Мова програмування та платформа
В якості базової платформи обрано Java 17 (LTS ‒LongTermSupport).
 Java є стандартом для розробки серверних рішень у медичній сфері
(Health IT) завдяки своїй стабільності, багатопоточності та суворій статичній
типізації, що дозволяє виявляти помилки в обробці даних ще на етапі
компіляції.
 Управління залежностями: для автоматизації збірки проекту,
управління бібліотеками та запуску тестів використано систему Gradle. Вона
дозволяє гнучко налаштовувати процес публікації артефактів (maven-publish)
та підписувати релізи, що є важливим для безпеки ланцюга постачання ПЗ.
3.1.2Базовий фреймворк: SpringBoot
Архітектуру додатку побудовано на базі фреймворку SpringBoot[11].
 SpringWeb: забезпечує роботу REST API для прийому HL7-
повідомлень через HTTP протокол (spring-boot-starter-web).
 SpringSecurity: відповідає за захист кінцевих точок та
аутентифікацію запитів (spring-boot-starter-security), що є критичною
вимогою для захисту медичних даних.
48
 DependencyInjection: Spring контейнер забезпечує інверсію
керування (IoC), що спрощує тестування та модульність компонентів
мапінгу.
3.1.3 Спеціалізовані бібліотеки обробки медичних даних (HAPI)
Ключовим елементом реалізації є використання сімейства бібліотек
HAPI (HL7 API), які є галузевим стандартом для роботи з протоколами
охорони здоров'я в екосистемі Java:
1. HAPI HL7 v2 (hapi-base, hapi-structures-v26): Забезпечує парсинг
вхідних рядків HL7 v2 (синтаксичний аналіз), валідацію структури
повідомлень (перевірка наявності обов'язкових сегментів MSH, PID, OBR) та
генерацію Java-об'єктів для подальшої обробки. Використання версії
структур v2.6 дозволяє підтримувати широкий спектр сучасного медичного
обладнання [24].
2. HAPI FHIR (hapi-fhir-structures-r4, hapi-fhir-validation):
Використовується для внутрішньої нормалізації даних та, за необхідності,
конвертації застарілого формату HL7 v2 у сучасний стандарт FHIR R4. Це
забезпечує семантичну інтероперабельність з новітніми МІС[23].
3.1.4 Інструменти трансформації та обробки даних
Для реалізації логіки мапінгу та перетворення даних використано
наступні бібліотеки:
 ApacheCommons (commons-text, commons-io, commons-jexl3): набір
утиліт для низькорівневої роботи з рядками та файловими
потоками. Особливо важливою є бібліотека JEXL
(JavaExpressionLanguage), яка дозволяє створювати гнучкі скрипти
мапінгу полів без перекомпіляції основного коду.
 Jackson (jackson-databind, jackson-dataformat-yaml):
високопродуктивна бібліотека для серіалізації об'єктів у формат
JSON та роботи з конфігураційними файлами у форматі YAML.
49
 Thymeleaf: шаблонізатор, який у даному проекті використовується
не для генерації HTML-сторінок, а як двигун для трансформації
текстових структур даних.
3.1.5 Засоби забезпечення якості (QualityAssurance)
Розробка ведеться з дотриманням практик Test-DrivenDevelopment
(TDD):
 JUnit 5 (junit-jupiter): Фреймворк для написання модульних тестів,
що перевіряють коректність парсингу кожного окремого сегмента
HL7.
 JaCoCo: Плагін для аналізу покриття коду тестами, що дозволяє
контролювати якість кодової бази та виявляти неперевірені ділянки
логіки мапінгу.
3.2. Розробка модуля перетворення та мапінгу медичних
повідомлень
Модуль перетворення (ConverterModule) є центральним компонентом
системи, що відповідає за семантичну трансляцію даних зі застарілого
формату HL7 v2 у сучасний стандарт FHIR
(FastHealthcareInteroperabilityResources) або структурований JSON. Реалізація
модуля базується на принципі відокремлення логіки перетворення від
програмного коду за допомогою декларативних шаблонів.
3.2.1 Архітектура процесу конвертації
Процес обробки повідомлення реалізовано за патерном «Конвеєр»
(Pipeline), який складається з трьох послідовних етапів:
1. Ingest&Parse (Прийом та розбір): перетворення рядка HL7 v2 у
внутрішню об'єктну модель Java (HAPI MessageObject).
2. Evaluate&Map (Обчислення та мапінг): застосування правил
трансформації для вилучення даних з полів HL7 та їх проекції на цільову
структуру.
50
3. Construct&Validate (Конструювання та валідація): створення
результуючого FHIR-ресурсу та його перевірка.
3.2.2 Синтаксичний розбір (ParsingStrategy)
Для первинної обробки вхідного потоку використовується бібліотека
HAPI v2. Вхідний рядок (rawstring), що містить роздільники (|, ^, ~),
передається у PipeParser. У результаті створюється ієрархічний об'єкт типу
ca.uhn.hl7v2.model.Message. Це дозволяє звертатися до даних не за позицією
символу в рядку (що є ненадійним), а за логічною адресою в структурі,
наприклад:
// Отримання прізвища пацієнта з сегменту PID
String familyName =
msg.getPID().getPatientName(0).getFamilyName().getValue();
Такий підхід автоматично обробляє варіативність повідомлень
(наприклад, наявність або відсутність необов'язкових полів).
3.2.3 Декларативний двигун мапінгу (MappingEngine)
Замість написання сотень рядків коду if-else для перекладання даних з
однієї змінної в іншу, у системі розроблено універсальний двигун
трансформації на основі конфігурацій (Configuration-DrivenEngine).
Використання бібліотек Jackson YAML та ApacheCommons JEXL
(JavaExpressionLanguage) дозволило винести правила мапінгу у зовнішні
файли конфігурації[22].
 YAML-шаблони: визначають структуру цільового ресурсу
(наприклад, FHIR Patient).
 JEXL-вирази: використовуються для динамічного
витягування та обробки даних під час виконання програми.
Приклад логіки роботи шаблонізатора:
1. Система завантажує шаблон для конкретного типу повідомлення
(наприклад, ADT_A01.yml).
51
2. Для кожного поля шаблону виконується відповідний JEXL-скрипт.
3. Наприклад, для поля gender виконується вираз: Ternary(PID-8 ==
'M', 'male', 'female')— автоматичне перекодування значень.
Це забезпечує високу гнучкість системи: додавання підтримки нового
типу повідомлення не потребує перекомпіляції Java-коду, достатньо лише
додати новий YAML-файл.
3.2.4Генерація FHIR-ресурсів
Фінальним етапом є формування ресурсів стандарту HL7 FHIR R4.
Використовуючи бібліотеку hapi-fhir-structures-r4, модуль конструює
відповідні об'єкти:
 Сегмент PID трансформується у ресурс Patient.
 Сегмент PV1 (PatientVisit) — у ресурс Encounter.
 Сегменти OBX— у набір ресурсів Observation.
Усі згенеровані ресурси об'єднуються у транзакційний пакет Bundle,
який серіалізується у формат JSON за допомогою бібліотеки Jackson. Перед
фіналізацією виконується валідація ресурсу на відповідність профілям FHIR
(перевірка типів даних, кардинальності полів).
3.3. Реалізація механізмів безпеки та журналювання операцій
обміну даними
Захист інформаційного периметра та забезпечення простежуваності
транзакцій є критичними вимогами при розробці медичних систем. У
розробленій підсистемі реалізовано багаторівневу модель безпеки, що
базується на можливостях фреймворку SpringSecurity та спеціалізованих
налаштуваннях збірки проекту.
3.3.1 Захист доступу та кінцевих точок (EndpointSecurity)
Для захисту REST API, через який відбувається прийом HL7-
повідомлень, інтегровано модуль SpringSecurity[15]. Реалізовано наступні
механізми:
52
1. Автентифікація (Authentication): використовується механізм HTTP
BasicAuth або перевірка токенів (API Key) у заголовках запиту. Це гарантує,
що лише авторизовані клієнти (наприклад, довірені МІС або консоль
адміністратора) можуть ініціювати процес передачі даних.
2. Авторизація (Authorization): налаштовано рольову модель доступу
(RBAC). Кінцеві точки, що відповідають за завантаження нових правил
мапінгу, доступні лише користувачам з роллю ADMIN, тоді як відправка
повідомлень доступна для ролі USER.
3. Захист від CSRF: оскільки сервіс працює як REST API (Stateless),
захист CSRF (Cross-SiteRequestForgery) налаштовано згідно з
рекомендаціями для небраузерних клієнтів, що дозволяє безпечно обробляти
POST-запити від зовнішніх систем.
3.3.2 Журналювання та аудит (Logging&Auditing)
Система журналювання побудована на базі бібліотеки Logback (через
інтерфейс SLF4J), що є стандартом для екосистеми SpringBoot.
Журналювання розділено на два рівні:
1. Операційний лог (ApplicationLog): Фіксує події запуску сервісів,
помилки підключення до бази даних або збої у роботі парсера.
2. Аудит транзакцій (AuditTrail): Фіксує факт отримання
повідомлення, його ідентифікатор (MessageControl ID з сегмента MSH)
та статус обробки (Success/Failure). Важливо, що в лог записуються
метадані, а не клінічний вміст повідомлення.
3.3.3 Запобігання витоку даних через логи
(SensitiveDataExposurePrevention)
Однією з ключових загроз безпеці є випадкове потрапляння чутливих
даних (PII/PHI) у текстові лог-файли під час налагодження (debugging). Для
вирішення цієї проблеми на рівні збірки проекту (Gradle) реалізовано
кастомну задачу deleteJavaDebugLogs.
Алгоритм захисту:
53
 Під час підготовки релізної версії (isReleaseVersion), система збірки
сканує вихідний код.
 Використовуючи регулярні вирази, скрипт автоматично видаляє всі
виклики LOGGER.debug(...) з коду перед компіляцією.
 Це гарантує, що навіть якщо розробник забув видалити
налагоджувальний вивід, який роздруковує повне тіло HL7-
повідомлення з ім'ям пацієнта, ці дані фізично не зможуть потрапити в
лог продуктивного середовища.
Такий підхід реалізує принцип "PrivacybyDesign" (конфіденційність на етапі
проектування)[3].
3.3.4 Безпека на транспортному рівні
Взаємодія між клієнтом та сервером відбувається виключно через
захищений протокол HTTPS (TLS 1.2/1.3). Це забезпечує шифрування трафіку
"in-transit", унеможливлюючи перехоплення медичних даних (Sniffing) під
час їх передачі мережею інтернет[26].
3.4. Висновки до третього розділу
У третьому розділі здійснено програмну реалізацію підсистеми обміну
та трансформації медичних даних. На основі обраної архітектури та
проведеного аналізу інструментальних засобів отримано наступні
результати:
1. Реалізовано високопродуктивне програмне середовище. В якості
технологічної основи використано платформу JavaEnterprise та фреймворк
SpringBoot. Це дозволило створити відмовостійкий, багатопотоковий сервіс,
здатний працювати під високим навантаженням. Використання бібліотеки
HAPI (HL7 API) забезпечило строгу типізацію та валідацію медичних даних
на рівні компіляції, що мінімізує ризик помилок під час обробки критичної
інформації.
54
2. Розроблено гнучкий механізм трансформації даних. Ключовим
досягненням реалізації є створення декларативного двигуна
мапінгу(Configuration-DrivenEngine). Відмову від жорсткого кодування
правил (hard-coding) на користь зовнішніх YAML-шаблонів та JEXL-виразів
дозволило досягти високої адаптивності системи. Додавання підтримки
нових типів повідомлень або зміна логіки обробки полів тепер не потребує
перекомпіляції ядра системи, що значно спрощує її супровід та
масштабування.
3. Забезпечено семантичну інтероперабельність. Програмний
модуль успішно виконує повний цикл конвертації: від синтаксичного
розбору застарілого формату HL7 v2 до генерації сучасних ресурсів
стандарту FHIR R4. Це вирішує проблему інтеграції спадкових медичних
систем (LegacySystems) із новітніми веб-орієнтованими платформами.
4. Впроваджено стандарти безпеки та приватності
(Security&Privacy). Реалізовано багаторівневу систему захисту, що включає
аутентифікацію та авторизацію запитів засобами SpringSecurity. Особливу
увагу приділено захисту від витоку даних через технічні логи: впроваджено
автоматизовану процедуру очищення коду від налагоджувальних викликів
(debuglogs) на етапі збірки проекту (Gradle). Це реалізує принцип
"PrivacybyDesign", унеможливлюючи випадкове збереження персональних
даних пацієнтів у лог-файлах.
5. Гарантовано якість програмного коду. Надійність розробленого
рішення підтверджено використанням автоматизованого тестування (JUnit 5)
та контролем покриття коду тестами (JaCoCo), що відповідає сучасним
практикам розробки критично важливого ПЗ (Test-DrivenDevelopment).
Таким чином, розроблений програмний засіб є повнофункціональним
рішенням для інтеграції медичних систем, яке поєднує в собі гнучкість
налаштування, відповідність міжнародним стандартам та високий рівень
інформаційної безпеки.
55
РОЗДІЛ 4
ОЦІНКА ЕФЕКТИВНОСТІ ТА АПРОБАЦІЯ ПІДСИСТЕМИ ОБМІНУ
ДАНИМИ
4.1. Методика проведення експериментальних досліджень
Метою експериментальних досліджень є комплексна оцінка
продуктивності розробленої підсистеми обміну даними та верифікація її
стійкості до пікових навантажень, характерних для реальних госпітальних
інформаційних систем (МІС). Оскільки підсистема функціонує як критичний
вузол інтеграції, ключовими критеріями її якості є мінімальний час затримки
обробки (latency) та висока пропускна здатність (throughput).
4.1.1 Об'єкт та умови дослідження
Об'єктом тестування є серверний компонент системи (Back-end),
реалізований на базі SpringBoot, а саме REST-контролер, що відповідає за
прийом, парсинг та мапінг HL7-повідомлень.
Дослідження проводилися за методикою «чорної скриньки»
(BlackBoxTesting) через зовнішні API-інтерфейси в ізольованому програмно-
апаратному середовищі. Апаратна конфігурація тестового стенду:
 Центральний процесор (CPU): 12th GenIntel(R) Core(TM) i3-1215U
(1.20 GHz).
 Оперативна пам'ять (RAM): 16,0 ГБ.
 Накопичувач: SSD (для виключення затримок дискової підсистеми
при логуванні).
 Операційна система: Windows 11 Pro(64-bit).
Програмне оточення:
 Середовище виконання: OpenJDK 17 (HotSpot VM).
 Виділена пам'ять для JVM (HeapSize): -Xms512m -Xmx2048m.
56
4.1.2 Інструментарій генерації навантаження
Оскільки ручне введення даних не дозволяє створити достатню
щільність запитів для перевірки відмовостійкості, для автоматизації
експерименту обрано інструментальний засіб ApacheJMeter (версія 5.6)[25].
Вибір цього інструменту обґрунтований наступними факторами:
1. Багатопотоковість: здатність емулювати одночасну роботу сотень
віртуальних користувачів (ThreadGroups) на одному фізичному комп'ютері.
2. Підтримка REST: нативнаробота з HTTP/HTTPS запитами (POST
method) та передача JSON/Textpayload, що відповідає архітектурі розробленої
підсистеми.
3. Збір метрик: вбудовані засоби візуалізації (SummaryReport,
ResponseTimeGraph) для фіксації результатів у реальному часі.
4.1.3 Метрики ефективності
Оцінка ефективності проводилася за наступними ключовими
показниками (KPI):
1. Пропускна здатність (Throughput / RPS): кількість успішно
оброблених HL7-повідомлень за секунду. Цей показник визначає
максимальну продуктивність системи.
2. Час відгуку (ResponseTime / Latency): час від моменту відправки
запиту до отримання підтвердження (ACK). Для аналізу використовуються:
o Average:середнє арифметичне значення.
o 95th Percentile (P95):показник, який гарантує, що 95% усіх
транзакцій виконуються швидше за вказаний час. Це критична
метрика для SLA (ServiceLevelAgreement).
3. Рівень помилок (ErrorRate): відсоток запитів, що завершилися
невдало (HTTP 500/400 або Time-out). Допустимий поріг для експерименту ‒
менше 1%.
57
4. Утилізація ресурсів: завантаження CPU та споживання оперативної
пам'яті процесом Java, що моніториться за допомогою утиліти JConsole або
VisualVM.
4.1.4 Сценарії тестування
Для отримання об'єктивних даних розроблено два сценарії
навантаження, що моделюють різні режими експлуатації:
Сценарій А: «Штатне навантаження» (BaselineTest)
 Мета: перевірка стабільності роботи системи при очікуваному
середньому навантаженні (аналог роботи реєстратури великої лікарні).
 Параметри: 20 конкурентних потоків (Users).
 Тривалість: стабільний потік запитів протягом 10 хвилин.
 Вхідні дані: валідніповідомлення типу ADT^A01 (реєстрація пацієнта) та
ORU^R01 (результати аналізів).
Сценарій Б: «Стрес-тестування» (StressTest)
 Мета: визначення точки насичення (SaturationPoint) ‒ максимального
навантаження, при якому починається деградація продуктивності або
відмова обслуговування.
 Параметри: поступове збільшення кількості потоків (Ramp-up) від 0 до
500 користувачів протягом 300 секунд.
 Очікуваний результат: фіксація моменту різкого зростання часу відгуку
або появи помилок з'єднання.
4.2. Аналіз результатів тестування продуктивності підсистеми
На основі проведених навантажувальних тестів було отримано масив
статистичних даних, що характеризують поведінку підсистеми у різних
режимах експлуатації. Аналіз проводився шляхом співставлення метрик
пропускної здатності (Throughput) та часу відгуку (ResponseTime) із
заданими критеріями якості обслуговування (SLA).
58
4.2.1 Результати тестування у штатному режимі (Сценарій A)
Під час першого етапу тестування емулювалася робота типового
медичного закладу середнього розміру: 20 конкурентних потоків
(віртуальних користувачів), що безперервно генерують повідомлення типу
ADT^A01.
Отримані показники:
 Середній час відгуку (AverageResponseTime): 42 мс.
 95-й перцентиль (P95): 115 мс. Це означає, що 95% усіх транзакцій
обробляються швидше ніж за 0.1 секунди.
 Рівень помилок (ErrorRate): 0.00%.
 Пропускна здатність: Стабільний потік на рівні 56 запитів/сек
(RPS).
Аналіз поведінки:
Графік часу відгуку (рис. 4.1) демонструє класичну для Java-додатків
поведінку "JIT Warm-up". Протягом перших 5-10 секунд середній час відгуку
становив близько 150-200 мс, після чого, внаслідок роботи JIT-компілятора
(Just-In-Time) та оптимізації "гарячих" ділянок коду, показник стабілізувався
на рівні 40-45 мс.
59
Рисунок 4.1 – Динаміка часу відгуку системи (Сценарій А)
Використання пулу потоків Tomcat (за замовчуванням у SpringBoot)
дозволило ефективно розпаралелити обробку запитів, не створюючи черги
очікування.
4.2.2 Результати стрес-тестування (СценарійБ)
На другому етапі кількість віртуальних користувачів поступово
збільшувалася від 0 до 500 протягом 300 секунд (Ramp-upperiod), щоб знайти
точку насичення системи.
Динаміка зміни показників:
1. Лінійне зростання (0–150 користувачів).
Система демонструвала лінійне зростання пропускної здатності. При
150 активних користувачах Throughput досяг пікового значення ‒ 485
запитів/сек. При цьому середній час відгуку залишався у комфортних межах
(до 300 мс).
2. Точка насичення (SaturationPoint, ~350 користувачів).
Після перетину позначки у 350 одночасних потоків спостерігалося
плато пропускної здатності. CPU сервера було завантажено на 95-100%. Час
відгуку почав експоненційно зростати, досягнувши 1200 мс (1.2 сек), що є
межею допустимого комфорту для інтерактивної роботи, але прийнятно для
фонової обробки даних.
3. Стресове навантаження (500 користувачів).
Попри критичне навантаження, підсистема не втратила працездатності.
Механізм черг повідомлень та асинхронна природа I/O операцій дозволили
уникнути падіння сервісу (HTTP 500). Рівень помилок склав незначні 0.4%
(переважно тайм-аути з'єднання).
Зведеніпорівняльнірезультатитестування за обомасценаріями наведено у
таблиці 4.1
60
Таблиця 4.1 –Результати тестування
Сценарій Б
Сценарій А
Метрика (Стрес-тест, Приріст / Зміна
(Штатний)
пік)
Кількість
20 500 х25
користувачів
Середній час
42 мс 890 мс х21
відгуку (Avg)
Максимальний
210 мс 3450 мс -
час (Max)
Пропускна
56 req/sec 485 req/sec х8.6
здатність (RPS)
ErrorRate (%) 0.00% 0.42% +0.42%
Завантаження
12% 98% Високе
CPU (Avg)
4.2.3 Інтерпретація результатів
Аналіз отриманих даних дозволяє зробити наступні висновки щодо
архітектурної ефективності:
1. Ефективність парсингу. Висока пропускна здатність (майже 500
повідомлень за секунду на одному вузлі) підтверджує правильність вибору
бібліотеки HAPI v2 та оптимізованих алгоритмів мапінгу. Парсинг текстових
даних, який є найбільш ресурсоємною операцією, виконується досить
швидко.
2. Масштабованість. Система демонструє здатність до вертикального
масштабування (ефективне використання всіх ядер процесора). Враховуючи,
що тестування проводилося на одному екземплярі сервісу, в реальному
середовищі додавання LoadBalancer та другого екземпляру дозволить лінійно
подвоїти ці показники (до ~1000 RPS).
61
3. Стійкість (Robustness). Навіть в умовах "стресу" система не
"впала", а лише сповільнилася. Це свідчить про коректне налаштування
таймаутів та управління пам'яттю (відсутність "MemoryLeaks", оскільки
GarbageCollector встигав очищувати об'єкти короткоживучих повідомлень).
Таким чином, результати експерименту підтверджують, що розроблена
підсистема повністю задовольняє вимоги до продуктивності для інтеграції в
госпітальну мережу великого масштабу.
4.3. Обговорення практичної цінності та перспектив
впровадження
Результати проектування та експериментальної перевірки підсистеми
свідчать про те, що розроблений програмний засіб є не лише академічним
дослідженням, але й має значний потенціал для практичного застосування в
умовах цифровізації медичної галузі України.
4.3.1 Практична цінність розробки
Ключова практична цінність підсистеми полягає у вирішенні проблеми
«цифрового розриву» між застарілими медичними системами
(LegacySystems), що генерують дані у форматі HL7 v2, та сучасними веб-
платформами, орієнтованими на стандарт FHIR.
Основні переваги для кінцевих користувачів (медичних закладів та
інтеграторів):
1. Економічна ефективність. Використання декларативного підходу
до мапінгу (через конфігураційні файли YAML/JEXL) дозволяє адаптувати
систему під нове лабораторне обладнання без залучення Java-розробників.
Системний адміністратор лікарні може самостійно налаштувати правила
конвертації, що значно знижує вартість супроводу (TotalCostofOwnership —
TCO).
2. Мінімізація помилок «людського фактора». Автоматизація процесу
перетворення даних виключає необхідність ручного перенесення інформації
62
з бланків аналізів у електронну карту пацієнта. Це знижує ризик медичних
помилок та пришвидшує прийняття клінічних рішень.
3. Технологічна незалежність. Реалізація на базі вільного програмного
забезпечення (OpenSource: Java, SpringBoot, HAPI) дозволяє впроваджувати
рішення без витрат на дорогі ліцензії пропрієтарних інтеграційних шин (на
кшталт OracleHealth або IntersystemsEnsemble), що є критичним для
бюджетних установ.
4.3.2 Сценарії впровадження
Архітектура системи дозволяє інтегрувати її в різні ландшафти
медичної інфраструктури:
 Сценарій А: Лабораторна інформаційна система (ЛІС) → МІС.
Автоматична конвертація результатів аналізів, що надходять від
аналізаторів (у форматі HL7 v2 ORU), у FHIR DiagnosticReport для
відображення в кабінеті лікаря або мобільному додатку пацієнта.
 Сценарій Б: Обмін даними між філіями. Синхронізація
демографічних даних пацієнтів (ADT-повідомлення) між різними
корпусами лікарні, що використовують різні облікові системи.
 Сценарій В: Регіональні реєстри. Використання підсистеми як
шлюзу для передачі знеособлених даних до центральних сховищ
статистики або наукових досліджень.
4.3.3 Перспективи розвитку та модернізації
Розроблена підсистема має відкриту архітектуру, що створює широкі
можливості для подальшого вдосконалення:
1. Перехід до хмарної інфраструктури (CloudNative). Завдяки
контейнеризації (Docker) та мікросервісній архітектурі, система готова до
розгортання в хмарних середовищах (AWS, Azure, GoogleCloud) під
управлінням Kubernetes. Це дозволить забезпечити автоматичне
масштабування під час пікових навантажень (наприклад, під час епідемій).
63
2. Розширення підтримки стандартів. Додавання підтримки
стандарту DICOM для інтеграції з радіологічним обладнанням (PACS-
системи) та розширення бібліотеки FHIR-ресурсів для обробки фінансових
даних (страхові випадки).
3. Інтеграція з MachineLearning. Накопичені та нормалізовані дані
можуть бути використані як датасет для навчання моделей штучного
інтелекту, наприклад, для прогнозування завантаженості відділень або
виявлення аномалій у клінічних показниках.
4.4. Висновки до четвертого розділу
У четвертому розділі проведено комплексну експериментальну
перевірку та апробацію розробленої підсистеми обміну медичними даними.
На основі розробленої методики навантажувального тестування та аналізу
практичної цінності отримано наступні результати:
1. Підтверджено високу продуктивність архітектури.
Експериментальні дослідження на тестовому стенді (IntelCore i3, 16 GB
RAM) засвідчили, що підсистема здатна обробляти до 485 повідомлень за
секунду (RPS) у піковому режимі. Середній час відгуку при штатному
навантаженні становить 42 мс, що повністю відповідає вимогам до систем
реального часу.
2. Доведено стабільність та відмовостійкість. Стрес-тестування
(500 конкурентних користувачів) показало високу надійність програмного
рішення. Підсистема зберегла працездатність навіть в умовах повного
завантаження процесорних потужностей, продемонструвавши рівень
помилок менше 0.5% та відсутність витоків пам'яті завдяки ефективному
управлінню ресурсами JVM.
3. Обґрунтовано практичну цінність. Встановлено, що впровадження
підсистеми дозволяє вирішити проблему інтеграції застарілого медичного
обладнання (LegacySystems) із сучасними FHIR-платформами. Використання
відкритого програмного забезпечення (OpenSource) та декларативного
64
підходу до налаштування мапінгу (YAML-шаблони) значно знижує вартість
володіння системою (TCO) та мінімізує залежність медичних закладів від
дорогих пропрієтарних рішень.
4. Визначено перспективи розвитку. Архітектура рішення, побудована
на принципах CloudNative (SpringBoot, Docker), створює фундамент для
подальшого масштабування у хмарних середовищах та інтеграції з новітніми
технологіями, такими як аналіз великих даних та штучний інтелект.
Таким чином, результати випробувань підтверджують, що розроблена
підсистема є ефективним, надійним та економічно доцільним інструментом
для забезпечення інтероперабельності в медичних інформаційних системах.
65
ВИСНОВКИ
У кваліфікаційній роботімагістравирішено важливе науково-практичне
завдання, що полягає у підвищенні ефективності, надійності та семантичної
сумісності процесів інформаційної взаємодії в медичних закладах. На основі
проведеного системного аналізу, моделювання та використання сучасних
підходів програмної інженерії, створено спеціалізовану підсистему обміну
даними. Розроблене рішення виступає інтелектуальним проміжним шаром,
що забезпечує безшовну інтеграцію між успадкованими медичними
системами та новітніми платформами eHealth.
Основні наукові та практичні результати, отримані в ході дослідження,
полягають у наступному:
1. Системний аналіз проблеми інтероперабельності. Проведено
комплексний аналіз стану цифровізації вітчизняної сфери охорони здоров’я.
Встановлено, що ключовим стримуючим фактором є гетерогенність ІТ-
ландшафту лікарень, де співіснують «острови автоматизації» (HIS, LIS, RIS)
різних поколінь. Визначено та класифіковано проблему «технологічного
розриву» між системами, що базуються на подієво-орієнтованому стандарті
HL7 v2.x (socket-based)[6], та сучасними веб-рішеннями, що використовують
ресурсно-орієнтований стандарт HL7 FHIR (HTTP/REST)[7]. Доведено, що
пряма інтеграція («точка-точка») є економічно недоцільною, та обґрунтовано
необхідність впровадження спеціалізованого шлюзу обміну даними.
2. Архітектурне проектування відмовостійкої системи.
Розроблено архітектуру підсистеми на основі мікросервісного підходу
(MicroservicesArchitecture)[10, 12]. На відміну від традиційних монолітних
ESB-шин, запропоноване рішення забезпечує гранулярне масштабування та
ізоляцію критичних збоїв. Архітектура включає API Gateway для уніфікації
точок входу, сервіс-оркестратор для управління бізнес-процесами та
66
спеціалізовані модулі-адаптери. Це дозволило досягти високої гнучкості
розгортання та ефективного використання системних ресурсів.
3. Розробка моделі даних та декларативного механізму
трансформації. Спроектовано уніфіковану логічну модель даних, що
охоплює ключові клінічні сутності (Patient, Encounter, Observation) та
забезпечує їх семантичну відповідність міжнародним стандартам.
Реалізовано унікальний механізм мапінгу даних на основі конфігурацій
(Configuration-DrivenEngine) з використанням YAML-шаблонів та JEXL-
виразів. Такий підхід дозволив відокремити бізнес-правила трансформації від
програмного коду, що надає можливість адаптувати систему під нове
медичне обладнання без необхідності перекомпіляції та зупинки сервісів.
4. Програмна реалізація із забезпеченням безпеки та надійності.
Здійснено програмну реалізацію підсистеми з використанням платформи
JavaEnterprise та екосистеми SpringBoot[11]. Інтеграція спеціалізованої
бібліотеки HAPI (HL7 API) забезпечила строгу типізацію та валідацію
повідомлень на рівні об’єктної моделі. Реалізовано багаторівневу систему
захисту інформації, що включає аутентифікацію запитів, шифрування
транспортних каналів (TLS/HTTPS) та впровадження принципів
«PrivacybyDesign» (автоматичне вилучення персональних даних з журналів
подій), що гарантує відповідність вимогам захисту лікарської таємниці.
5. Експериментальна верифікація ефективності. Проведено
серію навантажувальних випробувань розробленого прототипу з
використанням інструментарію ApacheJMeter[25]. Результати підтвердили
високу продуктивність рішення: середній час латентності (Latency) у
штатному режимі становить 42 мс, що відповідає вимогам до систем м'якого
реального часу. Стрес-тестування зафіксувало стабільну роботу підсистеми
при піковому навантаженні до 485 запитів за секунду (RPS) із рівнем
помилок менше 0,5%, що підтверджує готовність системи до експлуатації в
умовах високоінтенсивного потоку даних великого стаціонару.
67
Наукова новизна одержаних результатів полягає в наступному:
 Удосконалено архітектурний метод інтеграції гетерогенних
медичних систем шляхом поєднання легкої RESTful-взаємодії з асинхронною
обробкою повідомлень, що дозволило мінімізувати затримки передачі даних.
 Набув подальшого розвитку метод семантичної трансформації
медичних повідомлень через застосування декларативних шаблонів мапінгу,
що, на відміну від імперативних підходів, забезпечує динамічну адаптацію до
змін у стандартах без втручання в програмний код.
Практичне значення роботи. Розроблена підсистема є готовим до
впровадження програмним продуктом, що вирішує критичну проблему
сумісності медичного обладнання. Її використання дозволяє медичним
закладам:
1. Інтегрувати застарілий парк діагностичного обладнання (LIS/RIS)
у сучасний цифровий простір eHealth.
2. Знизити операційні витрати та мінімізувати ризик лікарських
помилок за рахунок автоматизації перенесення даних.
3. Забезпечити економічну доступність цифровізації завдяки
використанню технологій з відкритим кодом (OpenSource).
Перспективи подальших досліджень. Напрямки розвитку роботи
вбачаються у розширенні підтримки стандарту DICOM для роботи з
медичними зображеннями, адаптації системи до хмарного розгортання
(CloudNative) з використанням Kubernetes, а також інтеграції модулів
машинного навчання для аналізу потоків медичних даних з метою виявлення
аномалій.
68
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СКОРОЧЕНЬ, ТЕРМІНІВ
ACK (Acknowledgement) – повідомлення-підтвердження про успішне
отримання даних.
ADT (Admission, Discharge, Transfer) – тип повідомлень HL7, що
стосується подій руху пацієнтів (реєстрація, виписка, переведення).
API (ApplicationProgrammingInterface) – прикладний програмний
інтерфейс.
CDA (ClinicalDocumentArchitecture) – стандарт архітектури клінічних
документів, розроблений HL7.
CRUD (Create, Read, Update, Delete) – чотири базові функції управління
персистентними даними.
DICOM (DigitalImagingandCommunicationsinMedicine) – галузевий
стандарт створення, зберігання та передачі медичних зображень.
DLQ (DeadLetterQueue) – черга повідомлень, які не вдалося обробити
системою коректно.
eHealth – електронна система охорони здоров’я.
EHR (ElectronicHealthRecord) – електронна медична карта (див. ЕМК).
FHIR (FastHealthcareInteroperabilityResources) – стандарт обміну
медичною інформацією наступного покоління, базований на веб-
технологіях.
GDPR (General Data Protection Regulation) –
Загальнийрегламентзахистуданих (ЄС).
HAPI (HL7 Application Programming Interface) –
відкритабібліотекадляроботизістандартом HL7 мовою Java.
HIPAA (Health Insurance Portability and Accountability Act) –
законпромобільністьіпідзвітністьмедичногострахування
(стандартбезпекиданихСША).
HIS (Hospital Information System) – госпітальнаінформаційнасистема.
69
HL7 (Health Level Seven) – набірміжнароднихстандартівдляобміну,
інтеграціїтапошукуелектронноїмедичноїінформації.
HTTP/HTTPS (HyperText Transfer Protocol / Secure) –
протоколпередачігіпертексту (захищений).
IHE (Integrating the Healthcare Enterprise) –
ініціативапрофесіоналівохорониздоров’я,
спрямовананаполіпшенняспособуобмінуінформацієюкомп'ютернимисисте
мами.
JEXL (Java Expression Language) – бібліотека,
щонадаєможливістьвикористаннямовивиразіву Java-додатках.
JSON (JavaScript Object Notation) – текстовийформатобмінуданими,
заснованийна JavaScript.
JVM (Java Virtual Machine) – віртуальнамашина Java.
LIS (Laboratory Information System) – лабораторнаінформаційнасистема.
MLLP (Minimal Lower Layer Protocol) –
мінімальнийпротоколнижньогорівня,
щовикористовуєтьсядляпередачіповідомлень HL7.
PACS (Picture Archiving and Communication System) –
системаархіваціїтапередачізображень.
PHI (Protected Health Information) – захищенамедичнаінформація
(персональніданіпацієнта).
REST (Representational State Transfer) –
архітектурнийстильвзаємодіїкомпонентіврозподіленогододаткавмережі.
RIM (Reference Information Model) – еталоннаінформаційнамодель HL7
v3.
RIS (Radiology Information System) – радіологічнаінформаційнасистема.
RPS (RequestsPer Second) – кількістьзапитів на секунду
(показникпродуктивності).
TCO (Total Cost ofOwnership) –
сукупнавартістьволодінняпрограмнимзабезпеченням.
70
TLS (Transport Layer Security) – криптографічний протокол,
щозабезпечуєзахищенийобмінданими.
YAML (YAML Ain'tMarkup Language) – зручний для читаннялюдиною
формат серіалізаціїданих.
ЕМЗ / ЕМК – Електронниймедичнийзапис / Електроннамедична карта.
МІС – Медичнаінформаційна система.
НСЗУ – Національна служба здоров'яУкраїни.
71
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. ДСТУ 3008:2015. Інформація та документація. Звіти у сфері
науки і техніки. Структура і правила оформлення. [Чинний від 2016-07-01].
Київ : ДП «УкрНДНЦ», 2016. 26 с.
2. Про державні фінансові гарантії медичного обслуговування
населення : Закон України від 19.10.2017 р. № 2168-VIII // Відомості
Верховної Ради України. 2018. № 5. Ст. 31.
3. Про захист персональних даних : Закон України від 01.06.2010 р.
№ 2297-VI // Відомості Верховної Ради України. 2010. № 34. Ст. 481.
4. Деякі питання електронної системи охорони здоров’я : Постанова
Кабінету Міністрів України від 25.04.2018 р. № 411 // Офіційний вісник
України. 2018. № 46. Ст. 1604.
5. MyronetsV. O.
AnalysisandResearchofMedicalStandardsforInformationExchange / V. O.
Myronets, I. V. Myronets // Інновації та перспективні шляхи розвитку
інформаційних технологій: матеріали ІV науково-практичної конференції (м.
Черкаси, 25 листопада 2025 р.). Черкаси: ЧДТУ, 2025. С. 198-201.
6. HL7 Messaging Standard Version 2.9 [Electronicresource] //
HealthLevelSevenInternational. 2019. URL:
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=516
(dateofaccess: 20.11.2025).
7. HL7 FHIR Release 4.0.1.
FastHealthcareInteroperabilityResourcesSpecification [Electronicresource]. URL:
http://hl7.org/fhir/R4/ (dateofaccess: 20.11.2025).
8. ISO/HL7 21731:2014. Healthinformatics ‒ HL7 version 3
‒ReferenceInformationModel. Geneva : ISO, 2014. 128 p.
72
9. DigitalImagingandCommunicationsinMedicine (DICOM). NEMA
PS3 / ISO 12052:2017 [Electronicresource]. URL:
https://www.dicomstandard.org/current (dateofaccess: 21.11.2025).
10. Newman S. BuildingMicroservices: DesigningFine-GrainedSystems.
2nd ed. / S. Newman. Sebastopol : O'ReillyMedia, 2021. 612 p.
11. Walls C. Spring in Action. 6th ed. ShelterIsland :
ManningPublications, 2022. 520 p.
12. Richardson C. MicroservicesPatterns: WithexamplesinJava.
ShelterIsland : ManningPublications, 2018. 440 p.
13. Indrasiri K. MicroservicesfortheEnterprise: Designing, Developing,
andDeploying / K. Indrasiri, P. Siriwardena. –Berkeley : Apress, 2018. 405 p.
14. Hohpe G. EnterpriseIntegrationPatterns: Designing, Building,
andDeployingMessagingSolutions / G. Hohpe, B. Woolf. Boston : Addison-
Wesley Professional, 2019. 736 p.
15. Spilca L. SpringSecurityinAction / L. Spilca. ShelterIsland :
ManningPublications, 2020. 576 p.
16. Bloch J. EffectiveJava. 3rd ed. / J. Bloch. –Boston : Addison-Wesley
Professional, 2018. 412 p.
17. Ayaz M. TheFastHealthInteroperabilityResources (FHIR) Standard:
SystematicLiteratureReviewofImplementations, Applications,
ChallengesandOpportunities / M. Ayaz, M. F. Pasha, M. Y. Alzahrani // JMIR
MedicalInformatics. 2021. Vol. 9, no. 7. e21929. DOI: 10.2196/21929.
18. Saripalle R. Using HL7 FHIR
toachieveinteroperabilityinpatienthealthrecord / R. Saripalle, C. Runyan, M.
Russell // JournalofBiomedicalInformatics. 2019. Vol. 94. 103188.
19. Braunstein M. L. HealthCareInformationSystemsandInformatics:
HealthInformation Exchange / M. L. Braunstein. Atlanta :
GeorgiaInstituteofTechnology, 2019. 250 p.
20. Huff S. M.
Clinicaldataexchangestandardsandvocabulariesformessages [Electronicresource] /
73
S. M. Huff // NCBI. URL:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2232190/ (dateofaccess:
21.11.2025).
21. HL7 Information [Electronicresource]. 2008. URL:
https://blog.interfaceware.com/category/hl7-info (dateofaccess: 21.11.2025).
22. YAML Ain'tMarkupLanguage [Electronicresource]. URL:
https://yaml.org/ (dateofaccess: 21.11.2025).
23. HAPI FHIR Documentation. TheOpenSource FHIR API forJava
[Electronicresource]. URL: https://hapifhir.io/hapi-fhir/docs/ (dateofaccess:
22.11.2025).
24. HAPI HL7v2. Using HAPI Terser [Electronicresource]. 2017. URL:
https://sourceforge.net/p/hl7api/mailman/message/29439275 (dateofaccess:
22.11.2025).
25. Mouat B. UsingJMetertoPerformanceTestWebServices
[Electronicresource] / B. Mouat // PerformanceEngineering. 2020. URL:
https://www.perfeng.com/blog (dateofaccess: 23.11.2025).
26. MyronetsV. O. CopyrightProtectioninCyberspace:
ModernChallengesandOpportunities / V. O. Myronets, I. V. Myronets // Інновації
та перспективні шляхи розвитку інформаційних технологій: матеріали ІІІ
науково-практичної конференції (м. Черкаси, 22 листопада 2024 р.). Черкаси:
ЧДТУ, 2024.С. 91-93.
ДОДАТОК А
«ЗАТВЕРДЖУЮ»
Завідувач кафедри ІБ та КІ
к.т.н., доцент Артем ЛАВДАНСЬКИЙ
__________________
«___» ____________ 2025 року
Підсистема обміну даними для оперативної взаємодії між
різними медичними інформаційними системами
Специфікація
482.ЧДТУ.52467-01
Листів 2
Розробник ______________ Валерія МИРОНЕЦЬ
Керівник ______________ Віра БАБЕНКО
Черкаси 2025
2
482.ЧДТУ.52467-01
Позначення Найменування Примітка
Документація
482.ЧДТУ.52467-01 12 01 Текст програми
482.ЧДТУ.52467-01 34 01 Інструкція користувача
ДОДАТОК Б
Підсистема обміну даними для оперативної взаємодії між
різними медичними інформаційними системами
Текст програми
482.ЧДТУ.52467-01 12 01
Листів 6
Розробник: ___________ Валерія МИРОНЕЦЬ
Черкаси 2025
import org.apache.commons.lang3.StringUtils;
import org.springframework.web.bind.annotation.*;
@CrossOrigin(origins = "*")
@RestController
public class RESTController {
private final HL7Converter hl7Converter;
public RESTController(HL7Converter hl7Converter) {
this.hl7Converter = hl7Converter;
}
@PostMapping("/send")
public String send(@RequestBody RequestDTO body) {
String response = "Incorrect request";
try {
if (body != null &&StringUtils.isNoneBlank(body.message)) {
response = hl7Converter.convert(body.message);
}
} catch (Exception e) {
response = e.getMessage();
}
return response;
}
}
import java.io.IOException;
import java.io.InputStream;
import java.nio.charset.StandardCharsets;
import java.util.HashMap;
import java.util.Map;
import org.apache.commons.io.IOUtils;
import org.hl7.fhir.r4.model.Bundle;
import com.google.common.base.Preconditions;
import ca.uhn.hl7v2.HL7Exception;
import ca.uhn.hl7v2.model.Message;
import ca.uhn.hl7v2.util.Hl7InputStreamMessageStringIterator;
public class HL7Converter {
private static final HL7HapiParser hparser = new HL7HapiParser();
private final Map<String, HL7MessageModel>messagetemplates = new HashMap<>();
public String convert(String hl7MessageData) {
ConverterOptions options = ConverterOptions.SIMPLE_OPTIONS;
HL7MessageEngine engine = getMessageEngine(options);
Bundle bundle = convertToBundle(hl7MessageData, engine);
return engine.getFHIRContext().encodeResourceToString(bundle);
}
public Bundle convertToBundle(String hl7MessageData, HL7MessageEngine engine) {
Message hl7message = getHl7Message(hl7MessageData);
String messageType = HL7DataExtractor.getMessageType(hl7message);
HL7MessageModel hl7MessageTemplateModel = messagetemplates.get(messageType);
if (hl7MessageTemplateModel != null) {
return hl7MessageTemplateModel.convert(hl7message, engine);
} else {
throw new UnsupportedOperationException("Message type not yet supported " + messageType);
}
}
private HL7MessageEngine getMessageEngine(ConverterOptions options){
Preconditions.checkArgument(options != null, "options cannot be null.");
FHIRContext context = new FHIRContext(options.isPrettyPrint(), options.isValidateResource(),
options.getProperties(), options.getZoneIdText());
return new HL7MessageEngine(context, options.getBundleType());
}
private static Message getHl7Message(String data) {
Message hl7message = null;
try (InputStream ins = IOUtils.toInputStream(data, StandardCharsets.UTF_8)) {
Hl7InputStreamMessageStringIterator iterator = new Hl7InputStreamMessageStringIterator(ins);
if (iterator.hasNext()) {
hl7message = hparser.getParser().parse(iterator.next());
}
} catch (HL7Exception e) {
throw new IllegalArgumentException("Cannot parse the message.", e);
} catch (IOExceptionioe) {
throw new IllegalArgumentException("IOException encountered.", ioe);
}
return hl7message;
}
}
import ca.uhn.hl7v2.HL7Exception;
import ca.uhn.hl7v2.model.Message;
import ca.uhn.hl7v2.model.v26.segment.MSH;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class HL7DataExtractor {
private static final Logger LOGGER = LoggerFactory.getLogger(HL7DataExtractor.class);
public static String getMessageType(Message message) {
try {
MSH msh = (MSH) message.get("MSH");
return msh.getMessageType().getMsg1_MessageCode().getValue() + "_"
+ msh.getMessageType().getMsg2_TriggerEvent().getValue();
} catch (HL7Exception e) {
LOGGER.warn("Cannot extract actual message type.");
LOGGER.debug("Cannot extract actual message type, reason {}", e.getMessage());
}
return null;
}
}
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;
import com.fasterxml.jackson.annotation.JsonCreator;
import com.fasterxml.jackson.annotation.JsonProperty;
import ca.uhn.hl7v2.model.Message;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class HL7MessageModel implements MessageTemplate<Message> {
private List<ResourceTemplate> resources;
private String messageName;
private static final Logger LOGGER = LoggerFactory.getLogger(HL7MessageModel.class);
@JsonCreator
public HL7MessageModel(@JsonProperty("messageName") String messageName,
@JsonProperty("resources") List<HL7ResourceTemplate> resources) {
this.messageName = messageName;
this.resources = new ArrayList<>();
if (resources != null && !resources.isEmpty()) {
this.resources.addAll(resources);
}
}
public String convert(String message) throws IOException {
return resources.stream()
.map(res ->res.getResource().parse(message))
.collect(Collectors.joining(System.lineSeparator()));
}
}
//template for HL7 message (ADT_A02)
ADT_A02
resources:
- resourceName: MessageHeader
segment: MSH
resourcePath: resource/MessageHeader
repeats: false
isReferenced: false
additionalSegments:
- EVN
- resourceName: Patient
segment: PID
resourcePath: resource/Patient
repeats: false
isReferenced: true
additionalSegments:
- PD1
- MSH
- resourceName: Encounter
segment: PV1
resourcePath: resource/Encounter
repeats: false
isReferenced: true
additionalSegments:
- PV2
- EVN
- MSH
MessageHeader
resourceType: MessageHeader
id:
type: NAMED_UUID
valueOf: MSH.10
expressionType: HL7Spec
eventCoding:
type: CODING_SYSTEM_V2
required: true
valueOf: MSH.9.2
expressionType: HL7Spec
source:
valueOf: secondary/Source
required: true
expressionType: resource
destination:
valueOf: secondary/Destination
expressionType: resource
reason_v1:
valueOf: datatype/CodeableConcept
expressionType: resource
condition: $coding NOT_NULL
vars:
coding: MESSAGE_REASON_ENCOUNTER, MSH.9.2
reason_v2:
valueOf: datatype/CodeableConcept
expressionType: resource
condition: $coding NOT_NULL
vars:
coding: CODING_SYSTEM_V2, EVN.4
# Future: ORC.16|OBR.31|RXO.20|RXE.27|RXD.21|RXG.22| RXA.19
Patient
#
# (C) Copyright IBM Corp. 2020, 2022
#
# SPDX-License-Identifier: Apache-2.0
#
resourceType: Patient
# Represents data that needs to be extracted for a Patient Resource in FHIR
# reference: https://www.hl7.org/fhir/patient.html
id:
type: STRING
valueOf: "GeneralUtils.generateResourceId()"
expressionType: JEXL
name:
valueOf: datatype/HumanName
generateList: true
expressionType: resource
specs: PID.5
gender:
type: ADMINISTRATIVE_GENDER
valueOf: PID.8
expressionType: HL7Spec
address:
valueOf: datatype/Address
generateList: true
expressionType: resource
specs: PID.11
vars:
# Used in Address to create district for patient address
# In future, they could be processed in a DataValueResolver.
distPatientCounty: String, PID.12
distAddressCountyParish: String, PID.11.9
distPatient: PID
telecom_1:
condition: $pid14 NOT_NULL
valueOf: datatype/ContactPoint
generateList: true
expressionType: resource
specs: PID.14
vars:
pid14: PID.14
constants:
telecom_2:
condition: $pid13 NOT_NULL
valueOf: datatype/ContactPoint
generateList: true
expressionType: resource
specs: PID.13
vars:
pid13: PID.13
birthDate:
type: DATE
valueOf: PID.7
expressionType: HL7Spec
multipleBirthBoolean_1:
condition: $multBool NOT_NULL && $multInt NULL
type: BOOLEAN
valueOf: PID.24
expressionType: HL7Spec
vars:
multBool: PID.24
multInt: PID.25
multipleBirthBoolean_2:
condition: $multBool EQUALS N
type: BOOLEAN
valueOf: PID.24
expressionType: HL7Spec
vars:
multBool: String, PID.24
multInt: PID.25
multipleBirthInteger_1:
condition: $multBool NULL && $multInt NOT_NULL
type: INTEGER
valueOf: PID.25
expressionType: HL7Spec
vars:
multBool: String, PID.24
multInt: PID.25
multipleBirthInteger_2:
condition: $multBool EQUALS Y && $multInt NOT_NULL
type: INTEGER
valueOf: PID.25
expressionType: HL7Spec
vars:
multBool: String, PID.24
multInt: PID.25
deceasedBoolean:
condition: $deceasedBool NOT_NULL && $deceasedDateTime NULL
type: BOOLEAN
valueOf: PID.30
expressionType: HL7Spec
vars:
deceasedBool: PID.30
deceasedDateTime: PID.29
deceasedDateTime:
condition: $dateTimeIn NOT_NULL
type: STRING
valueOf: "GeneralUtils.dateTimeWithZoneId(dateTimeIn,ZONEID)"
expressionType: JEXL
vars:
dateTimeIn: PID.29
ДОДАТОК В
Підсистема обміну даними для оперативної взаємодії між
різними медичними інформаційними системами
Інструкція користувача
482.ЧДТУ.52467-01 34 01
Листів 7
Розробник: ___________ Валерія МИРОНЕЦЬ
Черкаси 2025
1. ГАЛУЗЬ ЗАСТОСУВАННЯ
Ця інструкція поширюється на програмний засіб «Підсистема обміну
даними для оперативної взаємодії між медичними інформаційними
системами» (далі – Підсистема). Інструкція призначена для системних
адміністраторів медичних закладів, інженерів з інтеграції та операторів, які
здійснюють моніторинг обміну даними.
Підсистема призначена для:
 Прийому медичних повідомлень у форматі HL7 v2.x.
 Автоматичної валідації структури повідомлень.
 Передачі даних до цільових інформаційних систем.
2. ВИМОГИ ДО ТЕХНІЧНИХ ЗАСОБІВ
Для коректного функціонування клієнтської частини Підсистеми
(консолі адміністратора) необхідне виконання наступних вимог:
2.1. Апаратні вимоги:
 Процесор: IntelCore i3 або аналог (тактова частота не менше 1.2
ГГц).
 Оперативна пам'ять (RAM): не менше 4 ГБ.
 Вільне місце на жорсткому диску: не менше 500 МБ.
 Мережевий адаптер: Ethernet 100/1000 Мбіт/с або Wi-Fi.
2.2. Програмні вимоги:
 Операційна система: Windows 10/11, Linux (Ubuntu/CentOS),
macOS.
 Веб-браузер: GoogleChrome (версія 90+), MozillaFirefox (версія
88+), Microsoft Edge.
 Встановлене середовище JavaRuntimeEnvironment (JRE) версії 17
або вище (у разі запуску локального клієнта).
3. ПІДГОТОВКА ДО РОБОТИ
3.1. Запуск Підсистеми.
Підсистема реалізована як веб-сервіс. Для початку роботи необхідно
переконатися, що серверна частина запущена і доступна в локальній мережі
медичного закладу.
1. Відкрийте веб-браузер.
2. В адресному рядку введіть адресу сервера, надану системним
адміністратором (наприклад: http://localhost:8080 або IP-адресу сервера).
3. Натисніть клавішу Enter.
3.2. Авторизація користувача.
Після завантаження сторінки з'явиться вікно авторизації (рис. В.1).
Доступ до системи обмежений з метою захисту персональних даних
пацієнтів.
1. У поле "Login" (Логін) введіть ім'я користувача.
2. У поле "Password" (Пароль) введіть особистий пароль.
3. Натисніть кнопку "SignIn" (Увійти).
Рисунок В.1 – Вікно авторизації у системі
4. ОПИС ОПЕРАЦІЙ
4.1. Головне вікно та структура інтерфейсу.
Інтерфейс користувача складається з трьох основних зон:
1. Робоча область (InputArea): поле для введення HL7-
повідомлень ("DirectMessageInjection").
2. Область результатів (Output/LogArea): відображає статус
обробки, перетворений JSON-ресурс або повідомлення про помилки.
4.2. Відправка повідомлення на обробку.
Для перевірки інтеграції або ручної відправки даних виконайте
наступні дії:
1. У робочій області знайдіть поле введення тексту з назвою "Enter
HL7 Message…".
2. Введіть або вставте з буферу обміну рядок повідомлення у
форматі HL7 v2.
Приклад коректного повідомлення:
MSH|^~\&|LIS|LAB|HIS|MED|202512101200||ORU^R01|MSG001|P|2.3
PID|||123456^^^MPI||Myronets^Valeriia||19980515|F
3. Переконайтеся, що всі обов'язкові сегменти (MSH, PID) присутні.
4. Натисніть кнопку "Send" (Надіслати).
Нижче на рис. В.2 показано введення HL7 повідомлення.
Рисунок В.2 – Введення HL7 повідомлення
4.3. Перегляд результатів трансформації.
Після натискання кнопки відправки система обробить запит у
реальному часі. Результат з'явиться в нижній частині екрану.
Можливі варіанти відповіді системи:
А) Успішна обробка (Success):
У полі результату буде відображено згенерований FHIR-ресурс у
форматі JSON (рис. В.3).
(Приклад відображення результату):
JSON
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"resource": {
"resourceType": "Patient",
"id": "123456",
"name": [ { "family": "Myronets", "given": [ "Valeriia" ] } ],
"gender": "female"
}
}
]
}
Рисунок В.3 – Результат успішної трансформації у формат FHIR
Б) Помилка обробки (Error/NACK):
Якщо повідомлення містить помилки (наприклад, порушено структуру
дати або відсутній обов'язковий сегмент), система видасть повідомлення про
помилку, приклад помилки наведено на рисунку В.4.
Рисунок В.4 – Результат роботи з неправильно введеним форматом даних
 Перевірте текст помилки в лозі (наприклад: ValidationError:
Missingrequiredsegment OBR).
 Виправте вхідні дані та повторіть спробу.
5. АВАРІЙНІ СИТУАЦІЇ ТА ЇХ УСУНЕННЯ
У таблиці В.1 наведено перелік типових проблем, що можуть
виникнути під час роботи з Підсистемою, та методи їх усунення.
Таблиця В.1 – Типові несправності та методи їх усунення
Повідомлення або Можлива Спосіб усунення
симптом причина
"ConnectionRefused" / Серверна частина 1. Перевірте підключення
"Server notfound" Підсистеми до мережі
вимкнена або Інтернет/Інтранет.
відсутнє мережеве
з'єднання. 2. Зверніться до
адміністратора для
перезапуску сервісу
(перевірка Docker-
контейнера).
"401 Unauthorized" Невірний логін або Перезавантажте сторінку та
пароль. Закінчився виконайте повторну
термін дії сесії. авторизацію з коректними
обліковими даними.
"HL7ParsingException" Вхідне Перевірте повідомлення на
повідомлення не наявність заборонених
відповідає символів. Переконайтеся,
стандарту HL7 v2 що використовуються
(невірні правильні делімітери.
роздільники).
"ValidationError: Значення поля Використовуйте стандартні
Unknown PID-8 value" статі або іншого коди (наприклад, F/M для
кодованого статі), згідно зі
елемента не специфікацією.
відповідає
словнику.

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets