Звіт ПП - БС-72 - Гупало - 21

НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ УКРАЇНИ
«КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ

імені ІГОРЯ СІКОРСЬКОГО»
________________ФАКУЛЬТЕТ БІОМЕДИЧНОЇ ІНЖЕНЕРІЇ________________
(повна назва інституту/факультету)
________________кафедра БІОМЕДИЧНОЇ КІБЕРНЕТИКИ________________

(повна назва кафедри)
ЗВІТ
з переддипломної практики
спеціальності 122 Комп’ютерні науки

(шифр назва)
спеціалізації Інформаційні технології в біології та медицині
За темою: Інформаційна система з вибору ліків із урахуванням

непереносимих компонентів пацієнтом
Виконав: студент ІV курсу, групи __БС-72__

(шифр групи)
Гупало Микита Сергійович

(прізвище, ім’я, по батькові) (підпис)
Керівники практики __ст.викл. каф БМК АВЕРЬЯНОВА. О.А._ ______

(вчені ступінь та звання, прізвище,ініціали) (підпис)
__ ст.викл. каф. БМК КОРНІЄНКО Г.А._ ______
Керівник ДР _к.т.н., доц. каф БМК О.К. НОСОВЕЦЬ_ ______

Засвідчую, що у звіті немає запозичень з

праць інших авторів без відповідних
посилань.
Студент _____________
(підпис)
Київ – 2021 рік

Національний технічний університет України
«Київський політехнічний інститут імені Ігоря Сікорського»
Факультет БІОМЕДИЧНОЇ ІНЖЕНЕРІЇ

(повна назва)
Кафедра БІОМЕДИЧНОЇ КІБЕРНЕТИКИ

(повна назва)
Рівень вищої освіти – перший (бакалаврський) за освітньо-професійною програмою

спеціальність 122 «Комп’ютерні науки»
спеціалізація «Інформаційніі технології в біології та медицині»
(код і назва)
ЗАТВЕРДЖУЮ
Завідувач кафедри БМК
__________ _Є.А. Настенко_
(підпис) (ініціали, прізвище)
«_01_»__квітня__2021 р.
ІНДИВІДУАЛЬНЕ ЗАВДАННЯ
на переддипломну практику студенту
Гупало Микиті Сергійовичу

(прізвище, ім’я, по батькові)
1. Тема практики Інформаційна система з вибору ліків із урахуванням

непереносимих компонентів пацієнтом
Керівник роботи
Носовець Олена Костянтинівна, к.т.н., доц.
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені засіданням кафедри БМК від «01» квітня 2021 р. №17

2. Термін подання студентом звіту 14-15 травня 2021 року
3. Вихідні дані до роботи повний перелік медикаментів наявних у
спеціалізованому медичному інтернет-виданні compendium.com.ua
4. Зміст роботи 1) Аналіз предметної області та висвітлення

проблематики
2) Аналіз вимог до програмного продукту
3) Проектування програмного продукту
4) Створення та тестування програмного продукту
5. Перелік ілюстративного матеріалу (із зазначенням плакатів, презентацій тощо)
Презентація захисту практики
6 Орієнтовний перелік публікацій Не планується
3
7. Консультанти розділів роботи1*

Підпис, дата
Прізвище, ініціали та посада
Розділ завдання завдання
консультанта
видав прийняв
Дипломна робота Носовець О.К, к.т.н., доц. 01.04.21 15.05.21
Охорона праці Демчук Г.В., доц., к.т.н. 01.04.21 15.05.21
Розрахунок Шевчук О.А., доц., к.е.н. 01.04.21 15.05.21
економічного
ефекту
8. Дата видачі завдання 01 квітня 2021 р.
Календарний план
№ Назва етапів виконання Термін виконання
Примітка
з/п переддипломної практики етапів практики
1 Отримати завдання на практику 01.04.2021р.
2 Розділ ДР з «Безпеки життєдіяльності та 15.05.2021
охорони здоров’я»
3 Розділ ДР з «Розрахунок економічного 15.05.2021
ефекту»
4 Розділ ДР «ВСТУП» 01.05.2021
5 Розділ ДР «Літературний огляд» 01.05.2021
6 Розділ ДР «Теоретична частина» 01.05.2021
7 Розділ ДР «Аналітична частина» 10.05.2021
8 Розділ ДР «Практична частина» 10.05.2021
9 Подання звіту керівнику ДР. Отримання 12 травня 2021р.
відгуку від керівника ДР.
10 Подання в електронному вигляді Звіту та 12-15 травня
анотації до нього відповідальному з 2021р.
практики.
11 Подання пакету документів по практиці 15 травня 2021р.
12 Захист практики 17-22 травня
2021р.
Студент М.С. Гупало

Керівник роботи О.К. Носовець

1
Консультантом не може бути зазначено керівника ДР.
4
АНОТАЦІЯ
1. «Переддипломна практика» (практика) є частиною циклу нормативних дисциплін

ООП бакалавра за напрямом підготовки за спеціальністю 122 «Комп’ютерні науки»
спеціализація «Комп’ютерні технології в біології та медицині» ).
2. Практика вміщує 5 кредитів (ЕКТС), 150 годин. Період проведения практики с
12.04.2021 р. по 16.05.2021 р.
3. Практика виконувалась Гупало Микитою Сергійовичем студентом 4-го курсу, гр.
БС-72 кафедри Біомедичної кібернетики факультету Біомедичної інженерії НТУУ «КПІ
імені Ігоря Сікорського».
4. Тема практики: Інформаційна система для вибору ліків із урахуванням непереносимих
пацієнтом компонентів.
5. Ціль практики:
Створення програмного застосунку для вибору ліків із урахуванням непереносимих
пацієнтом компонентів.
Задачі практики:
Провести аналіз проблеми виникнення побічних реакцій на лікарські засоби, опрацювати
базу даних із ліцензійними медикаментами в Україні, спроектувати базу даних та API
частину програмного застосунку, реалізувати створення програмного застосунку.
6. Результати по темі практики:
Встановлено місце проблеми виникнення побічних реакцій на лікарські засоби в Україні,
знайдено та програмно оброблено базу даних із ліцензійними медикаментами в Україні,
створено програмний застосунко для пошуку ліків із урахуванням непереносимих пацієнтом
компонентів.
7. Зміст звіту по практиці:
Анотація. Зміст. Список скорочень. Вступ. Теоретична частина. Матеріали досліджень.
Вимоги до ПЗ. Проектування ПЗ. Розробка ПЗ. Охорона праці. Розрахунок економічного
ефекту. Висновки. Список використаних джерел. Додатки.
8. З практики надані документи контроля проходження практики:
- щоденник практики
- індивідуальне завдання
- звіт на 80 листах. 11 ілюстрацій
- ілюстративний матеріал (презентація) на 10 листах (слайдах).
- відгук керівника ДР;
9. Визначена тема дипломної роботи до приказу по університету : «Інформаційна
система для вибору ліків із урахуванням непереносимих пацієнтом компонентів»
10. Проміжна атестація у формі заліку.
11. Ключові слова: непереносимі компоненти пацієнтом, пошук ліків, база даних
ліцензійних медикаментів, побічні реакції на лікарські засоби, гіперучтлиівість до
медикаментів.
5
ABSTRACT
1. "Pre-diploma practice" (practice) is part of a series of normative disciplines OOP bachelor

in the field of training in the specialty 122 "Computer Science" specialization "Computer
Technology in Biology and Medicine").
2. The practice contains 5 credits (ECTS), 150 hours. The period of practice from 14.04.2021
to 16.05.2021
3. The internship was performed by Hupalo Mykyta Sergeevich, a 4th year student, gr. BS-
72 of the Department of Biomedical Cybernetics, Faculty of Biomedical Engineering,
NTUU "KPI named after Igor Sikorsky".
4. Topic of practice: Information system for drug selection considering patient intolerable
components
5. The aim of the practice is create an application for drug selection considering patient
intolerable components.
Tasks of practice are to analyze the problem of adverse reactions to drugs, to process a
database of licensed drugs in Ukraine, to design a database and API part of the software
application, to implement the software application.
6. Results on the topic of practice : The place of the problem of side effects on medicines in
Ukraine is established, the database with licensed medicines in Ukraine is found and
programmatically processed, the software application for search of medicines taking into
account the components intolerable by the patient is created.
7. Contents of the practice report:
Abstract. Content. List of abbreviations. Introduction. Theoretical part. Research materials.
Software requirements. Software design. Software development. Occupational Health.
Calculation of economic effect. Conclusions. References. Additions.
8. On practice documents of control of passing of practice are presented:
a. practice diary;
b. individual task
c. report on 80 pages. 11 pictures
d. illustrative material (presentation) on 10 sheets (slides).
e. review of the supervisor of the DP;
9. The topic of the thesis is defined to the order of the university: "Information system for drug
selection considering patient intolerable components"
10. Intermediate certification in the form of a test.
11. Keywords: intolerable components by the patient, drugs search, database of licensed drugs,
adverse drug reactions, hyperactivity to drugs.
6
ЗМІСТ
ПЕРЕЛІК УМОВНИХ СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ 8
ВСТУП 10
РОЗДІЛ 1 ТЕОРЕТИЧНА ЧАСТИНА 12

1.1 Поняття побічної реакції на ЛЗ.....................................................................12
1.1.1 Класифікація побічних реакцій на ЛЗ 12
1.2. Гіперчутливість до ЛЗ...................................................................................13
1.2.1 Види алергічних реакцій 13
1.2.2 Фактори ризику розвитку гіперчутливості до ЛЗ 14
1.2.3 Поширені медикаменти-збудники 15
1.2.4 Принципи управління ризиками при поширених алергіях на ЛЗ 19
1.2.5 Запобігання можливим несприятливим реакціям від ЛЗ 22
Висновок до розділу 1..........................................................................................22
РОЗДІЛ 2 МАТЕРІАЛИ ДОСЛІДЖЕНЬ 24

2.1 Дані для дослідження......................................................................................24
2.2 Обробка даних.................................................................................................24
2.2.1 Ручна обробка даних 24
2.2.2 Програмне опрацювання даних 25
РОЗДІЛ 3 ВИМОГИ ДО ПЗ 27
3.1 Огляд сучасної системи..................................................................................27
3.2 Функціональні вимоги до продукту..............................................................27
3.2.1 Зміст необхідних функціональних характеристик 27
3.2.2 Опрацювання потенційних некоректних дій користувачів системи 28
3.3 Системні вимоги до продукту........................................................................28
3.3.1 Опис системи 28
3.3.2 Інтеграція систем 29
3.3.3 Налаштування та гнучкість системи 29
3.4 Обладнання та програмне забезпечення.......................................................29
РОЗДІЛ 4 ПРОЕКТУВАННЯ ПЗ 31
4.1 Проектування БД.............................................................................................31
4.1.1 Концептуальне моделювання 31
4.1.2 Даталогічне проектування 31
4.2 Проектування API частини застосунку.........................................................36
4.2.1 REST архітектура. Правила проектування REST API 36
7
4.2.2 Загальні принципи проектування API 38

4.2.3 Проектування API для розроблюваного ПЗ 39
РОЗДІЛ 5 РОЗРОБКА ПЗ 46
5.1 Створення БД та відповідних сутностей......................................................46
5.2 Розробка API частини застосунку.................................................................46
РОЗДІЛ 6 ОХОРОНА ПРАЦІ 53

6.1 Характеристика приміщення.........................................................................53
6.2 Оцінка ключових небезпечних і шкідливих виробничих факторів...........56
6.2.1 Біологічний фактор 56
6.2.2 Психофізіологічний фактор 57
6.2.3 Електробезпека 58
6.2.4 Пожежна безпека 59
РОЗДІЛ 7 РОЗРАХУНОК ЕКОНОМІЧНОГО ЕФЕКТУ 62

7.1 Постановка завдання проектування..............................................................62
7.2 Обґрунтування функцій програмного продукту..........................................62
7.3 Обґрунтування системи параметрів ПП.......................................................64
7.4 Аналіз експертного оцінювання параметрів................................................66
7.5 Аналіз рівня якості варіантів реалізації функцій.........................................68
7.6 Економічний аналіз варіантів розробки ПП.................................................69
7.7 Вибір кращого варіанту ПП техніко-економічного рівня...........................71
ЗАГАЛЬНІ ВИСНОВКИ 73
СПИСОК ВИКОРИСТАННОЇ ЛІТЕРАТУРИ 74
ДОДАТОК А СХЕМА ТА ТЕСТОВІ ДАНІ БАЗИ ДАНИХ 79

8
ПЕРЕЛІК УМОВНИХ СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ
ЛЗ - лікарський засіб.
ПР - побічні реакції.
НПЗП - нестероїдні протизапальні препарати.
АПФ - ангіотензинперетворюючий фермент.
ВІЛ - вірус імунодефіциту людини.
ССД - синдром Стівенса–Джонсона.
ТЕН - токсичний епідермальний некроліз.
ІПП - інгібітори протонної помпи.
ФНП - фактор некрозу пухлин.
АСК - ацетилсаліцилова кислота.
МЛГ - множинна лікарська гіперчутливість.
ImE - імуноглобулін Е.
ImM - імуноглобулін M.
ImG - імуноглобулін G.
БД - база даних.
API - Application Programming Interface (прикладний програмний
інтерфейс).
ІС - інформаційна система.
REST - Representational State Transfer («передача репрезентативного
стану») - підхід до архітектури мережевих протоколів, які надають доступ до
інформаційних ресурсів.
HTTP - HyperText Transfer Protocol - протокол передачі даних, що
використовується в комп'ютерних мережах.
JSON - JavaScript Object Notation (запис об'єктів JavaScript) - текстовий
формат обміну даними між комп'ютерами.
HTML - HyperText Markup Language (мова розмітки гіпертексту) - мова
тегів, засобами якої здійснюється розмітка веб-сторінок у мережі Інтернет.
9
CSS - Cascading Style Sheets (каскадні таблиці стилів) - спеціальна мова,

яка використовується для опису зовнішнього вигляду веб-сторінок, створення
їх стилю.
XML - Extensible Markup Language - розширювана мова розмітки.
PNG - Portable Network Graphics - растровий формат збереження
графічної інформації, що використовує стиснення без втрат.
СУБД - система управління базами даних - система, заснована на
програмних та технічних засобах, яка забезпечує визначення, створення,
маніпулювання, контроль, керування та використання баз даних.
ER - Entity-relationship («сутність-зв'язок») - модель даних, яка дозволяє
описувати концептуальні схеми за допомогою узагальнених конструкцій
блоків.
UML - Unified Modeling Language (уніфікована мова моделювання) -
стандартна графічна мова для визначення та документування
великомасштабних програмних систем.
URI - Uniform Resource Identifier (уніфікований ідентифікатор ресурсів) -
компактний рядок літер, який однозначно ідентифікує окремий абстрактний
або фізичний ресурс.
MIME - Multipurpose Internet Mail Extensions - багатоцільові розширювачі
для інтернету-пошти.
HATEOAS - Hypermedia as the Engine of Application State - гіпермедіа як
двигун стану додатку.
10
ВСТУП
Побічні реакції на лікарські засоби являють собою четверту провідну

причину смерті в США та Канаді після серцевих захворювань, раку та інсульту.
Крім того, підраховано, що ПР ЛЗ є шостою причиною смерті у світі.
Витрати суспільства через ПР ЛЗ важко точно оцінити, але останні
дослідження показують, що витрати становлять від 75 до 180 мільярдів доларів
щороку лише для дорослих. Приблизно 5% усіх госпіталізацій є прямим
результатом ПР ЛЗ і, на жаль, рівень захворюваності не змінився за останні 30
років [19].
За результатами фармаконагляду в Україні протягом 1996-2010 рр. у базі
даних щодо ПР ЛЗ Державного підприємства «Державний експертний центр
МОЗ України» налічується 43 600 спонтанних повідомлень про ПР ЛЗ, про
випадки яких повідомляли лікарі.
За результатами спостережень спеціалістів із фармаконагляду при
медичному застосуванні ЛЗ найбільш часто виникають ПР типу А (які залежать
від дози) та реакції типу В (які не залежать від дози) – 75 та 25% відповідно.
В Україні ж повідомлення про ПР типу В становили 40% від загальної
кількості повідомлень про ПР ЛЗ, які містяться в Національній базі даних про
ПР ЛЗ. Серед них 5,5% – про серйозні ПР, які мали тяжкий перебіг
(анафілактичні реакції, синдром Стівенса – Джонсона, токсичний
епідермальний некроліз, ангіоневротичний набряк, анафілактичний шок) [45].
Основою цих помилок є недоліки системи підготовки і удосконалення
медичних кадрів в галузі фармакотерапії, несвоєчасне і недостатнє надання
медичним і фармацевтичним працівникам необхідної інформації про можливі
несприятливі побічні ефекти медикаментів, а також недоліки в організації і
функціонуванні системи контролю безпеки ліків. Лікарям складно
орієнтуватися у великій кількості поступаючих на фармацевтичний ринок ЛЗ і,
відповідно, їх уміння раціонально вибрати і грамотно призначити ЛЗ
конкретному хворому, тим паче, врахочуючи непереносимі компоненти
пацієнтом,- не є досконалим [44].
11
Алергія на ЛЗ впливає не тільки на якість життя пацієнта, але може також

призвести до затримки лікування, використання неоптимальних
альтернативних ліків, непотрібних досліджень, підвищення захворюваності та
навіть смерті [26].
Основним методом лікування ПР типу В є уникнення ЛЗ. Якщо існує така
можливість, ЛЗ-збудник необхідно замінити альтернативою, яка відрізналася б
за хімічною структурою від ЛЗ-збудника [26].
Актуальність роботи полягає у тому, щоб створити нині неіснуючий
застосунок-помічник, який використовувася б у лікарських установах, для
підбору сприятливих для конкретного пацієнта ЛЗ.
Об’єктом дослідження виступає процесс підбору ЛЗ.
Предметом дослідження виступає автоматизований процесс підбору
сприятливого ЛЗ для кокретного пацієнта.
Мета роботи полягає у розробці застосунка-помічника, який мав би
змогу, враховуючи непереносимі компоненти пацієнтом, правильно підібрати
ЛЗ для пацієнта.
12
РОЗДІЛ 1
ТЕОРЕТИЧНА ЧАСТИНА
1.1 Поняття побічної реакції на ЛЗ
Побічна реакція на лікарський засіб - помітно шкідлива або неприємна

реакція, що виникає внаслідок втручання, пов'язаного із застосуванням
лікарського засобу, яке передбачає небезпеку від майбутнього прийому та
вимагає профілактики або специфічного лікування, або зміни режиму
дозування, або відміни продукту [17].
1.1.1 Класифікація побічних реакцій на ЛЗ
Необхідно встановити особливості досліджуваної області для того, щоб
визначити саме над яким типом ПР автор буде проектувати та розробляти в
майбутньому ПП. Для цього наведемо класифікацію ПР ЛЗ:
1) Реакції типу А. Реакції типу А виникають внаслідок перевищення
допустимої дози лікарського засобу.
2) Реакції типу В. Реакції, які не виникають від відомих
фармакологічних дій препарату,- гіперчутливий тип реакції. Вони
зустрічаються рідше, ніж реакції типу А, і можуть бути виявлені
лише після безпосереднього застосування ЛЗ.
3) Реакції типу С. Реакції типу С виникають внаслідок поступового
підвищення дози протягом тривалого застосування ЛЗ.
4) Реакції типу D. Реакції, які виникають внаслідок тривалого
використання препарату, який не має тенденції до накопичення.
5) Реакції типу E. Реакції типу Е - реакція, яка застрічається як
наслідок припинення прийому препарату.
6) Реакції типу F. Реакція, яка виникає при небажаному зниженні або
підвищенні ефективності дії препарату. Наприклад, при підвищеній
стійкості організму людини до антибіотиків, вплив останніх буде
знижено [7].
13
1.2. Гіперчутливість до ЛЗ
Дана робота спрямована на зниження кількості випадків виникнення

побічних реакцій після вживання лікарських засобів, враховуючи саме такі
побічні реакції, які трапляються через гіперчутливість пацієнта до медикамента
(реакція типу В).
Гіперчутливість до лікарського засобу (алергічна реакція) - реакція,
негативні симптоми або прояви якої можуть бути об’єктивно відтвореними при
вживанні препарату в дозі, що переноситься нормальними людьми без жодних
побічних реакцій [8].
Єдиний спосіб віднайти ЛЗ, до якого у пацієнта спостерігається ймовірна
реакція гіперчутливості до медикаменту, - це ретельний анамнез, що включає
всі випадки впливу ліків із датами прийому, зміною дози та припиненням
лікування [18].
Даний тип реакцій є непередбачуваним і навіть може виникати у деяких
пацієнтів, якщо вони раніше приймали антибіотик без будь-яких негативних
реакцій. Алергічна реакція на ЛЗ становить 11,3% усіх можливих побічних
реакцій на ліки [39]. При цьому будь-який препарат може викликати алергічну
реакцію.
1.2.1 Види алергічних реакцій
Алергічні реакції на ЛЗ класифікуються як імунно-опосередковані реакції
відповідно до системи класифікації Гелла та Кумбса. Дана класифікаця описує
переважні імунні механізми, що беруть участь у цих реакціях. Ця система
класифікації включає наступні типи реакцій: реакції негайного типу,
опосередковані антитілами імуноглобуліну Е (тип I), цитотоксичні реакції,
опосередковані антитілами імуноглобуліну G або імуноглобуліну М (тип II),
реакції імунних комплексів (тип III), а також реакції гіперчутливості
уповільненого типу, опосередковані клітинними імунними механізмами,
такими як вербування та активація Т-клітин (тип IV) [30]. Механізми, клінічні
прояви та терміни прояву вище наведених імунних реакцій відображені в табл.
1.1 [12, 21, 25, 27].
14
Таблиця 1.1
Класифікація Гелла та Кумбса алергічних реакцій на ЛЗ
Імунна реакція Механізм прояву Клінічні прояви Час прояву
Тип 1 (IgE- Комплекс лікарських Анафілаксія, Хвилини -
опосередкований препаратів IgE, що кропив'янка, година після
) зв'язується з тучними ангіоневротичний прийому
клітинами з набряк, препарату
вивільненням бронхоспазма
гістаміну, медіаторів
запалення
Тип 2 Специфічні антитіла Анемія, цитопенія, Непостійний,
(цитотоксичні) IgG або IgM, тромбоцитопенія змінний
спрямовані на клітини,
покриті гаптеном
Тип 3 Відкладення Сироваткова 1–3 тижні
(комплексні) комплексів лікарських хвороба, васкуліт, після
препаратів-антитіл в лихоманка, висип, прийому
тканинах людини із артралгія препарату
активацією та
запаленням
Тип 4 Надходження молекул Контактна 2–7 днів
(відкладені, лікарського засобу до чутливість, шкірні після
клітинно Т-клітин із виділенням висипання, прийому
опосередковані) цитокіну та медіатора пошкодження препарату
запалення тканин органів
1.2.2 Фактори ризику розвитку гіперчутливості до ЛЗ
Фактори, пов'язані з підвищеним ризиком розвитку алергічної реакції на
ЛЗ, включають фактори специфічно до пацієнта (наприклад, вік, стать,
генетичні поліморфізми або зараження певними вірусами) та фактори, пов'язані
саме з особливостями медикаменту (наприклад, частота вживання, шлях
введення або молекулярна вага. Зазвичай алергічна реакція на ЛЗ виникає у
дорослих молодого та середнього віку, частіше у жінок. Генетичні
поліморфізми в антигені лейкоцитів людини, а також вірусні інфекції, такі як
ВІЛ та вірус Епштейна – Барра, також пов'язані з підвищеним ризиком
розвитку алергічної реакції на ліки. Також значний вплив справляють генетичні
15
особливості метаболізму людини. Крім того, місцевий, внутрішньом’язовий та

внутрішньовенний шляхи введення частіше викликають алергічні реакції на
ліки, ніж преоральне введення. Тривале вживання ліків у великих дозах або
часте вживання ліків частіше призводять до реакцій гіперчутливості, ніж
велика разова доза. Більше того, великі високомолекулярні препарати
(наприклад, інсулін) або препарати, які зв’язуються з молекулою гаптена
(зв’язуються з білками тканини або крові та викликають імунну відповідь), такі
як пеніцилін, також пов’язані з більшою ймовірністю розвитку алергії [1, 4, 24,
27, 28, 41].
Наведемо узагалюнюючі фактори ризику розвитку алергії на ЛЗ за типом
та ймовірністю [28].
Фактори, пов’язані з пацієнтом:
● Фактор віку (молоді та люди середнього віку мають більший ризик,
ніж немовлята та люди похилого віку).
● Фактор статі (жінки мають більший ризик розвитку алергії на ЛЗ,
ніж чоловіки).
● Фактор генетики (генетичних поліморфізімів).
● Фактор хвороби вірусними інфекціями (ВІЛ, віруси герпесу).
● Фактор попередньої несприятливої реакції на препарат.
Фактори, пов’язані з медикаментами:
● Фактор більш імуногенних препаратів (високомолекулярні сполуки
та гаптеноутворюючі препарати).
● Фактор способу прийому ЛЗ (місцевий спосіб прийому є більш
ризикованим, ніж внутрішньом’язовий спосіб прийому;

внутрішньом’язовий спосіб прийому є ризикованішим, ніж
внутрішньом'язовий спосіб прийому; внутрішньом'язовий спосіб
прийому є більш ризикованим, ніж преоральний спосіб прийому).
16
● Фактор дозування (частий або тривалий прийом є більш
ризикованим, ніж разова прийом).

1.2.3 Поширені медикаменти-збудники
Шкіра є органом, який найчастіше і найпомітніше уражається
медикаментозними алергічними реакціями [16, 33, 27]. Найбільш поширеним
проявом алергічних реакцій на шкірі є загальний макулопапульозний висип,
який характеризується підвищеними рожевими або червоними ураженнями, які
з’являються протягом кількох днів до 3 тижнів після впливу препарату.
Ураження, як правило, зароджуються в області тулуба і з часом поширюються
на кінцівки. Кропив'янка та ангіоневротичний набряк також часто
зустрічаються і можуть бути наслідком як опосередкованих IgE, так і не
опосередкованих IgE механізмів. У порівнянні з дорослим населенням,
найбільш вірогідною причиною затримки появи макулопапульозних висипань
та гострої кропив'янки (ангіоневротичного набряку) у дитячої популяції є
вірусна інфекція, і діти з такими проявами мають нижчий рівень лікарської
алергії [6, 29]. Найважчими формами шкірних лікарських реакцій є синдром
Стівенса – Джонсона та токсичний епідермальний некроліз. ССД починається з
макулопапульозного висипу, який часто прогресує до великого пухиру, що
містить серозну рідину, також, до виразки слизової оболонки, кон’юнктивіту,
лихоманки, ангіни та втоми. ТЕН - рідкісний стан із подібними
характеристиками до ССД, але ТЕН також сприяє відшаровуванню великих
ділянок епідермісу від нижчих шарів, що призводить до значного відшарування
шкіри. З огляду на тяжкість цих станів, в майбутньому пацієнт повинен суворо
уникати препаратів, які підозрюються у спричиненні ССД та ТЕН (найчастіше
сульфаніламідів) [16].
Незважаючи на те, що шкірні реакції є найпоширенішим фізичним
проявом алергічних реакцій, спричинених медикаментами, також можуть бути
задіяно багато інших систем органів, такі як ниркова, печінкова та
гематологічна системи. Більше того, можуть виникати багатоорганні реакції,
які включають анафілаксію, висипання з еозинофілією та синдромом
17
системних симптомів (DRESS), сироваткова хвороба, системний червоний

вовчак та васкуліт (гетерогенна група розладів, які характеризуються
запальним руйнуванням судин).
Типові симптоми системного червоного вовчаку включають раптовий
початок лихоманки та нездужання. Міалгія, артралгія та артрит також можуть
виникати через кілька тижнів після початку прийому препарату. Приблизно у
25% випадків шкіра також уражеється [16, 33].
Сироваткова хвороба та системний червоний вовчак, як правило,
самообмежені, симптоми проходять спонтанно протягом декількох тижнів
після припинення вживання ЛЗ. Однак симптоми DRESS можуть
погіршуватися або зберігатися протягом декількох тижнів або навіть місяців
після припинення вживання препарату [16, 33].
Узагальнимо найпоширеніші клінічні прояви гіперчутливості до ЛЗ та
приклади збудників у таблиці 1.2 [16, 27, 33].
Таблиця 1.2
Поширені клінічні прояви та приклади збудників гіперчутливості
Прояв Клінічні особливості Приклади медикаментів-збудників
Висип на Дифузні, дрібні макули та Аллопуринол, пеніциліни,
шкірі папули, які еволюціонують цефалоспорини, протисудомні
протягом кількох днів після засоби, сульфаніламіди, препарати
початку прийому препарату моноклональних антитіл
Кропив'янка, Є потенціалом для розвитку Антибіотики, інгібітори АПФ,
набряк Квінке анафілаксії (ефект стає антиконвульсанти, нервово-
помітним протягом м’язові блокуючі засоби, засоби
декількох хвилин або годин на основі платини,
після введення препарату); радіоконтрастні речовини, НПЗП,
часто даний прояв є IgE- наркотики, препарати
опосередкованим моноклональних антитіл
Еритема Гіперпігментовані області Сульфонамідні та тетрациклінові
фіксована на шкірі, що виникають на антибіотики, НПЗП, аспіринові,
(лікарський тому ж самому місці при седативні засоби,
висип) повторному вживанні хіміотерапевтичні засоби,
препарату-збудника протисудомні засоби
Синдром Лихоманка, біль у горлі, Сульфаніламіди, невирапін,
18
Стівенса – втома, ураження очей. кортикостероїди,

Джонсона Виразки та інші ураження антиконвульсанти, НПЗП
слизових оболонок, зокрема (оксикамні), алопуринол,
фенітоїн, карбамазепін,
рота і губ, а також на
ламотриджин, барбітурати,
ділянці тулуба
психотропні, пантопразол,
трамадол, препарати
моноклональних антитіл
Продовження табл. 1.2

Токсичний Подібні до ССД, але Ідентичні до ССД
епідермальний зазвичай передбачає значне
некроліз епідермальне відшарування.
Є потенційно небезпечним
для життя проявом
Гематологічні Гемолітична анемія, Пеніцилін, сульфаніламіди,
лейкопенія, протисудомні засоби,
тромбоцитопенія цефалоспорини, хінін, гепарин,
тіазиди, ауротіомалат натрію
(“солі золота”)
Печінкові Гепатит, холестатична Сульфонаміди, фенотіазини,
жовтяниця карбамазепін, еритроміцин,
протитуберкульозні засоби,
алопуринол, препарати на основі
золота
Ниркові Інтерстиціальний нефрит, Пеніцилін, сульфаніламіди,
гломерулонефрит алопуринол, ІПП, інгібітори АПФ,
НПЗП
Анафілактичні Одночасне виникнення Антибіотики, нервово-м’язові
декількох проявів: блокатори, анестетики,
кропив'янка або набряк радіоконтрастні середовища,
Квінке, бронхоспазм, рекомбінантні білки (наприклад,
шлунково-кишкові омалізумаб)
симптоми, гіпотонія
Висип від ЛЗ з Одночасне виникнення Антиконвульсанти,
19
еозинофілією декількох проявів: шкірний сульфаніламіди, міноциклін,

та системними висип, лихоманка, алопуринол, ранелат стронцію,
симптомами еозинофілія, порушення препарати моноклональних
функції печінки, антитіл
лімфаденопатія
Сироваткова Одночасне виникнення Гетерологічні антитіла,
хвороба декількох проявів: інфліксімаб, алопуринол, тіазиди,
кропив'янка, артралгія, антибіотики (наприклад,
лихоманка цефаклор), бупропіон, препарати
моноклональних антитіл
Cистемний Одночасне виникнення Гідралазин, прокаїнамід,
червоний декількох проявів: ізоніазид, хінідин, міноциклін,
вовчак артралгія, міалгія, антибіотики та засоби проти
лихоманка, нездужання альфа-ФНП
1.2.4 Принципи управління ризиками при поширених алергіях на ЛЗ
Найефективнішою стратегією боротьби з гіперчутливістю до ЛЗ є
уникнення або припинення вживання лікарського засобу. Якщо існує така
можливість, тоді несприятливий медикамент слід замінити на альтернативний,
який не був би пов’язаним із першим за хімічною структурою. Перехресну
реакцію серед вживаних ліків також слід враховувати при виборі
альтернативних засобів [16, 33].
Стратегії лікування деяких найпоширеніших лікарських алергій
розглядаються нижче.
1) Пеніцилін. Пеніцилін - найпоширеніша алергічна реакція на прийом
медикаментів, якою страждає приблизно 10% пацієнтів. Для пацієнтів з
алергією на пеніцилін найкращим лікуванням є використання
непеніцилінових препаратів. Карбапенеми (наприклад, іміпенем) не
виявляють значного ступеня перехресної реактивності з пеніциліном, і їх
можна вводити поступово після проведення профілактичних шкірних
тестів з відповідним карбапенемом [3, 11]. Монобактами (наприклад,
азтреонам) зазвичай добре переносяться пацієнтами з алергією на
пеніцилін, за винятком випадків, коли пацієнти мали алергічну реакцію
на цефтазидим [2, 31, 32]. Цефалоспорини другого або третього
20
покоління також підлягають розгляду, оскільки виявлено, що ступінь

перехресної реактивності з цими агентами та пеніциліном нижча, ніж із
агентами першого покоління [15, 16]. Якщо пеніцилін вважається
абсолютно необхідним у лікуванні пацієнта з алергією на пеніцилін, слід
розглянути питання про десенсибілізацію, і процедуру слід проводити
лише під наглядом лікаря в лікарні [16].
2) Цефалоспорини. Найпоширенішими алергічними реакціями на
цефалоспорини є макулопапульозний висип та лікарська лихоманка.
Кропив'янка зустрічається рідше, а анафілаксія - дуже рідко [15]. У
пацієнтів, які страждають алергією на пенцилін, може бути доцільним
уникати застосування цефалоспоринів першого покоління, за винятком
випадків, коли шкірний тест відповідного цефалоспорину є негативним.
Якщо шкірне тестування є позитивним і альтернативного препарату не
існує, можна спробувати запровадити процедуру тимчасової
толерантності до медикаменту [16, 38].
3) Сульфаніламіди. Сульфонамідні антибіотики є ще однією поширеною
причиною алергічних реакцій на ЛЗ і часто асоціюються із затриманною
появою шкірних макулопапульозних висипань, ССД та ТЕН. У пацієнтів,
інфікованих ВІЛ, підвищений ризик розвитку шкірних реакцій на
сульфаніламідні антибіотики, що, ймовірно, пов'язано з імунологічними
факторами та частим впливом цих антибіотиків. Триметоприм–
сульфаметоксазол є препаратом вибору для профілактики та лікування
ряду опортуністичних інфекцій, і тому багато ВІЛ-позитивних пацієнтів,
які в анамнезі реагували на сульфаніламіди, все ще потребують лікування
цим антибіотиком. Оскільки хімічна структура неантибіотичних
сульфаніламідів (наприклад, тіазидних діуретиків, деяких НПЗП та
антиконвульсантів) відрізняється від сульфаніламідних антибіотиків, не
очікується, що ці агенти будуть перехресно реагувати, і, як правило, їх
можна безпечно вводити пацієнтам з алергією на сульфаніламідні
антибіотики. Винятком є сульфасалазин, який внаслідок розкладу у
21
кишечнику стає сульфапіридином, набуваючи властивості імуногенної

структури, подібної до сульфаметоксазолу [9, 16, 37, 43].
4) Контрастна речовина. Контрастні речовини пов’язані як з алергічними,
так і з псевдоалергічними реакціями. Частота реакцій на контрастні
речовини, включаючи важкі реакції, що загрожують життю, статистично
являється нижчою при застосуванні неіонних та іонних агентів.
Псевдоалергічними реакціями зазвичай можна запобігти, застосовуючи
схеми попередньої обробки, які включають преоральні кортикостероїди
та H1-антигістамінні препарати. За таких обставин також слід
застосовувати засоби з низькою осмолярністю [16, 38].
5) Місцеві анестетики. Справжні алергічні реакції на місцеві анестетики
(наприклад, новокаїн, лідокаїн) надзвичайно рідкісні. Дані реакції, як
правило, зумовлені іншими інгредієнтами ліків, такими як консерванти
або адреналін. Однак, якщо історія подібної реакції узгоджується з
можливою негайною IgE реакцією, тоді необхідно почати застосовути
місцеві анестетики без епінефрину та консервантів [16].
6) Загальні анестетики. Хоча і рідко, анафілаксія може спостерігатися у
пацієнтів під загальним наркозом. Реакції під час загальної анестезії
часто зумовлені нервово-м’язовими блокаторами та антибіотиками [13],
але також були пов’язані з внутрішньовенними анестетиками (наприклад,
пропофолом, тіопентоном, етомідатом), НПЗП, хлоргексидином та
алергією на латекс. Крім того, опіоїди можуть справляти власний вплив,
оскільки вони можуть послабляти або посилювати ці реакції. Випадків
алергії на інгаляційні анестетики не було зареєстровано. Для лікування
необхідно за допомогою лікаря-алерголога підібрати альтернативні
засоби, які можуть бути безпечно використані при майбутньому
лікуванні [10].
7) Реакції на АСК та НПЗП. АСК та НПЗП можуть спричиняти як справжні
алергічні, так і псевдоалергічні реакції, включаючи загострення основних
респіраторних захворювань, кропив'янку, набряк Квінке та анафілаксію.
Пацієнти з основними хронічними респіраторними захворюваннями,
22
такими як астма, риніт та синусит, можуть реагувати на АСК та НПЗП,

які інгібують циклооксигеназу-1. Лікування цих пацієнтів передбачає
уникнення аспірину та НПЗП для агресивного лікування основного
дихального розладу. Селективні інгібітори циклооксигенази-2 майже
ніколи не викликають реакцій, і їх зазвичай можна безпечно приймати
пацієнтам з алергією на АСК, НПЗП [16].
8) Реакції на моноклональні антитіла. Реакції гіперчутливості на
моноклональні антитіла, які за тяжкістю можуть варіювати від легких до
небезпечних для життя, є розповсюдженою клінічною проблемою,
оскільки ці біологічні препарати все частіше використовуються для
лікування різних запальних, аутоімунних та злоякісних захворювань [20,
42]. Найчастішим проявом гіперчутливості є реакція, схожа на
сироваткову хворобу, з васкулітичними проявами (наприклад, лихоманка,
нездужання, артралгія або артрит, біль або скутість щелепи, пурпура та
кон'юнктивала гіперемія), яка зазвичай з’являється через 5–7 днів після
інфузії [43]. Гіперчутливість тимчасово можна послабити при
попередньому застосуванні медикаментів із наступним хімічним
складом: антигістамінні препарати H1 або H2, монтелукаст, аспірин,
ацетамінофен, кортикостероїди або бензодіазепіни.
9) Синдром МЛГ. Множинна гіперчутливість до лікарських засобів - досить
новий синдром, який характеризується уповільненими реакціями
гіперчутливості на два або більше структурно не пов’язаних між собою
лікарських засобів [23]. Реакції можуть бути різними і включати сиптоми
екзантеми, еритродермію, DRESS, ССД, ТЕН, гепатиту та
агранулоцитозу. Щоб знизити ризик розвитку МЛГ у пацієнтів з тяжкими
реакціями, опосередкованими Т-клітинами, експерти рекомендують
наступні стратегії: мінімізація використання додаткових інших
лікарських засобів, використання жарознижуючих засобів, уникати
антибіотиків, за необхідності вибирати препарати, які можна вводити у
меншій дозі (наприклад, менше, ніж 50 мг на добу), пригнічення
23
гіперактивації імунної системи за допомогою кортикостероїдної терапії

[23].
1.2.5 Запобігання можливим несприятливим реакціям від ЛЗ
Запобігання можливим несприятливим реакціям після прийому ЛЗ є
важливою частиною лікування пацієнта. Пацієнту слід надати письмову
інформацію про те, яких ліків слід уникати (включаючи ліки, що продаються
без рецепта). Дані препарати слід окремо виділяти в лікарняних примітках та в
електронній базі данних (за наявності), також, сімейний лікар пацієнта повинен
бути проінформованим про непереносимі пацієнтом медикаментом. Також слід
враховувати браслети, в які влаштовано технологію MedicAlert, особливо якщо
пацієнт в анамнезі мав тяжкі алергічні реакції, викликані медикаментами [28].
Висновок до розділу 1
У теоретичному розділі були розглянуті питання про побічні реакції на

лікарські засоби, їх класифікація, де було встановлено, що при подальшому
виконанні роботи розглядаються ПР ЛЗ типу В. Детально були розглянуті
фактори ризику розвитку гіперчутливості до ЛЗ, поширені медикаменти-
збудники, а також принципи управління ризиками при поширених алергіях на
ЛЗ та принципи запобігання можливим несприятливим реакціям на ЛЗ.
24
РОЗДІЛ 2
МАТЕРІАЛИ ДОСЛІДЖЕНЬ
2.1 Дані для дослідження
Повний перелік лікарських засобів, які будуть використовуватися для

роботи було взято з інформаційного фонду інтернет-ресурсу "Державний
реєстр лікарських засобів України", який дозволяє завантажити відомості із
державного реєстру лікарських засобів [22].
2.2 Обробка даних

2.2.1 Ручна обробка даних
Так як база даних має вичерпну кількість змінних (44) по кожному
торгівельному найменуванню, тому, перш за все, необхідно позбутися зайвих в
межах цієї роботи змінних, залишивши тільки необхідні або ті, які можуть
потенційно використовуватися, бути корисними для подальшого виконання
роботи. Таким чином, видаливши зайві змінні, надалі будуть
використовуватися наступні характеристики по кожному ЛЗ: ‘’Торгівельне
найменування’’, “Склад (діючі)”, “Міжнародне непатентоване найменування”,
“Фармакотерапевтична група”, “Код АТС”, “Заявник: назва українською”,
“Заявник: країна”, “Заявник: адреса”, “Виробник: назва українською”,
“Виробник: країна”, “Виробник: адреса”, “Номер Реєстраційного посвідчення”,
“Термін придатності: значення”, “Термін придатності: одиниця вимірювання”.
База даних містить дубліковані торгівельні найменування медикамента
через різні форми випуску ЛЗ у вигляді таблеток, капсул, ін’єкцій, суспензій і
так далі. Форма випуску призначена для точного та ефективного введення
лікарської речовини пацієнту людини. Проте для даної роботи форма випуску
ЛЗ неважлива, так як складові компоненти медикаменту від цього не
змінюються, можливе тільки зменшення або збільшення кількості певного
компоненту, саме тому дубліковані торгівельні найменування будуть видалені з
25
БД. Загалом було видалено 7065 записів. Для подальшої роботи будуть
використовуватися 8019 торгівельних найменувань ЛЗ.
2.2.2 Програмне опрацювання даних
Так як для 1489 медикаментів не вказано код класифікації АТХ та для
жодного з медикаментів не вказано склад його допоміжних речовин, необхідно
додати цю інформацію перед подальшим виконанням роботи. Ручне
знаходження та опрацювання даної інформації займе досить велику кількість
часу. Саму тому пропонується створити невелику програму для знаходження
даної інформацію та додавання її до загального файлу з даними. Наступні
колонки є необхідними для подальшого виконання роботи: “Допоміжні
речовини” (компоненти, які містить медикамент, не враховуючи активну
речовину; до опрацювання БД містить інформацію тільки про діючу речовину
медикамента), “Діючі речовини” (БД до опрацювання містить активну
речовину медикамента, проте, ця інформація досить складна для автоматичного
опрацювання, так як вона містить додаткову інформацію як-то “не менше
99,0% і не більше 101,0% у перерахунку на суху речовину”; пропонується
додати нову колонку із чітким указанням тільки діючої речовини), “Посилання
на медикамент” (посилання на сторінку медикамента з веб-сайту Компендіум).
Дані про АТХ класифікацію ЛЗ та їх допоміжні речовини
отримуватимемо зі спеціалізового медичного інтернет-видання для лікарів,
провізорів, фармацевтів, студентів медичних і фармацевтичних вишів:
“Компендіум — лікарські препарати” (доступ за посиланням
https://compendium.com.ua/uk/).
Для написання даної програми буде викристано мову програмування
Groovy версії 3.0.7, так як дана мова програмування має стислий, короткий,
прямий синтаксис, що дозволяє розробникам набагато швидше та простіше
розробляти програмні застосунки. Для взаємодії із веб-сайтом Компендіум буде
використано Selenium Webdriver - програмну бібліотеку, яка дозволяє
розробляти програмні застосунки, які керують поведінкою браузера.
Повний код застосунку наявний за посиланням
https://github.com/hupaloo/Process-Drugs-Data.
26
Алгоритм роботи створеного застосунку для пошуку медикаментів:

1. Відкриваємо головну сторінку веб-сайту Компендіум.
2. Вставляємо торгівельне найменування медикамента у пошуковий рядок
сайту.
3. Приймаємо рішення в залежності від умови існування шуканого ЛЗ на веб-
сайті.
3.1.1. Якщо шуканий ЛЗ існує, тоді переходимо на його сторінку та
беремо інформацію про допоміжні речовини, діючу речовину,
посилання на сторінку.
3.1.2. Якщо шуканий ЛЗ не існує, тоді повертаємося до пункту 1.
Внаслідок опрацювання існуючих записів та пошуку додаткової
інформації про медикаменти через веб-сайт Компендіум інформацію про 4661
медикаменти було знайдено, 3095 з яких містить хоча б один додатковий
компонент. Для подальшого виконання роботи буде використано саме ці 4661
опрацьованих медикаменти (БД у форматі CSV доступна за посиланням
https://github.com/hupaloo/Process-Drugs-Data/blob/master/src/main/org/mhupalo/
resources/reestr_atc_final.csv).
При виконанні розділу було опрацьовано вручну та програмно

загальнодоступну БД із ліцензійними медикаментами в Україні таким чином,
щоб дані були якісними для подальшого використання при створенні та роботі
ПП.
27
РОЗДІЛ 3
ВИМОГИ ДО ПЗ
3.1 Огляд сучасної системи
На даний час в державних закладах охорони здоров’я (надалі - Замовник)

не існує програмного застосунку, який зберігав би дані про непереносимі
компоненти певним пацієнтом та мав би змогу допомагати лікарю із пошуком
відповідного ЛЗ для пацієнта, враховуючи непереносимі пацієнтом
компоненти. Завдяки ПЗ частота помилок при виписуванні рецептів потенційно
повинна зменшитися, також, пацієнтам не доведеться витрачати час та гроші
для повторного лікування після виникнення побічних ефектів внаслідок
лікування ненереносимим ліками.
3.2 Функціональні вимоги до продукту

3.2.1 Зміст необхідних функціональних характеристик
Замовник вимагає рішення, яке базується на технології для збору даних
про непереносимі компоненти пацієнтами та створення інформаційної системи
для пошуку медикаментів, врахочуючи персональну непереносимість.
Основний функціонал та характеристики застосунку:
1) Доступність даних. Користувач застосунку повинен мати змогу
безперешкодно та швидко знаходити інформацію про непереносимі
компоненти пацієнтом, медикаменти за АТХ-класифікацією.
2) Уповноважені користувачі можуть оновити картку непереносимих
компонентів пацієнтом, видаливши або додавши певний
компонент. Також уповноважені користувачі повинні мати змогу
додавати та видаляти медикаменти з БД, діючи безпосередньо через
веб-сайт.
3) Визначені представники можуть делегувати права редагування
іншим користувачам у їхній установі.
28
4) Цілісність даних. Інформація, що зберігається в БД, повинна

залишатися повною, точною та надійною незалежно від того, як
довго вона зберігається або як часто до неї звертаються. Також дані
повинні бути надійно захищеними від будь-якого зовнішнього
втручання.
5) API повинен забезпечувати доступ лише до даних.
Додатковий функціонал застосунку (із нижчим пріоритетом):
1) Деталі непереносимих компонентів пацієнтом та рекомендовані ЛЗ
для нього можна завантажити у форматі Excel або PDF.
2) Система повинна надсилати нагадування про певні елементи даних,
коли дані застаріли (якщо пацієнт потребує повторного тесту на
підтвердження непереносимості; закінчився термін дії ліцензії на
розповсюдження медикаменту по Україні).
3.2.2 Опрацювання потенційних некоректних дій користувачів
системи
Система повинна використовувати наступні методики забезпечення
якості даних, включаючи їх, але не обмежуючись ними:
• вхідні маски (рядок символів, що вказує формат допустимих
вхідних значень);
• випадаючі списки зі стандартними відповідями (АТХ-
класифікація, компоненти медикаментів);
• вимог щодо повноти даних (скорочення записів не
допускається);
• Перегляд і перевірка нових медикаментів вручну призначеним
адміністратором до того, як вони додаються безпосередньо до
системи.
3.3 Системні вимоги до продукту

3.3.1 Опис системи
Запропонована ІС з підбору ліків із урахуванням непереносимих
компонентів пацієнтом складатиметься з веб-центру та централізованої бази
29
даних. Як правило, всі користувачі будуть безпосередньо взаємодіяти із веб

частиною застосунку. Для забезпечення здатності до можливого майбутнього
зростання необхідна гнучкість як для режимів введення, так і для виведення.
Вхідні дані переліку медикаментів, їх компонентів, групи АТХ повинні
бути взятими з перевірнених джерел (можливе використання відкритих
джерел). Дані про пацієнтів не будуть передані до Виконавця для розробки ПЗ.
Натомість, Замовник надасть унікальний ідентифікатор на кожного пацієнта із
ціллю нерозкриття персональних даних пацієнтів та інтеграцією
розроблюваного застосунку із уже існуючою БД обліку користувачів, яка
використовується Замовником.
3.3.2 Інтеграція систем
Необхідною функціональністю системи є інтеграція з іншими зовнішніми
системами Замовника. Замовник бажає мати можливість імпортувати та
експортувати дані без постійної підтримки з боку Виконавця. З цією метою
система повинна надати RESTful API через HTTP, щоб забезпечити передачу
даних у форматі JSON для зовнішнього споживача.
3.3.3 Налаштування та гнучкість системи
Бажано, щоб система постійно оновлювалася та система
вдосконалювалася. Також Замовник вимагає, щоб система була гнучкою та
настроюваною відповідно до їх потреб. Код повинен бути побудованим таким
чином, щоб робота з налаштування ПЗ була доступним завданням для
програміста на Groovy, JavaScript, і Замовник матиме доступ до сховища коду,
щоб зробити такі зміни за власним бажанням.
Будь-які інструменти, які будуть використані, крім тих, що
обговорюються в цій пропозиції, повинні обговорюватися із Замовником перед
використанням. Закриті джерела чи власні інструменти використовувати
заборонено.
3.4 Обладнання та програмне забезпечення

30
Замовник несе відповідальність за укладання контрактів із сервісами веб-

хостингу для розгортання застосунку.
REST API додаток повинен бути побудованим із використанням мови
програмування Groovy версії 3.8. Дані повинні зберігатися в базі даних MySQL.
Інтерфейс користувача буде розроблений із використанням HTML5, CSS3 та
JavaScript. Виконавець має право використовуючи компоненти із стандартних
та загальновизнаних бібліотек, наприклад, таких як jQuery для Javascript.
Замовник несе відповідальність за захист сервера, на якому буде
розгорнено застосунок.
Код програми використовуватиме програму для контролю версій Git, і всі
коміти будуть архівовані у визначеному сховищі, яке може бути доступним для
усіх інших потенційних Виконавців та Замовника. Вихідний код буде
зберігатися на взаємоузгодженій платформі.
При виконанні розділу були висунуті основні вимоги до розроблюваного

ПП.
31
РОЗДІЛ 4
ПРОЕКТУВАННЯ ПЗ
4.1 Проектування БД
4.1.1 Концептуальне моделювання
Метою концептуального проектування схеми БД є охоплення вимог до
реальних даних, які будуть викоритовуватися ПЗ, простим і розумним
способом, таким, щоб він був зрозумілий як дизайнеру БД, так і кінцевому
користувачу. Кінцевим користувачем є особа, відповідальна за доступ до БД та
виконання запитів та оновлень за допомогою програмного забезпечення СУБД
[36].
Ми будемо використовувати модель ER для того, щоб проілюструвати
модель даних на етапі логічного проектування бази даних (рис. 4.1).
Рисунок 4.1 Діаграма сутність-зв'язок БД

32
4.1.2 Даталогічне проектування

Бази даних з різними моделями даних мають різну структуру для подання
даних. Для проектування і подальшої реалізації пропонується використовувати
реляційну модель зберігання даних, так як такі БД мають гнучкішу структуру
та додатки для таких баз підтримувати легше, ніж ті, що написані для
ієрархічних або мережевих баз даних. Ця гнучкість структури дає можливість
отримувати такі комбінації даних, які, можливо, ще не були потрібні при
проектуванні бази даних [46].
Правила та обмеження, які стосуються взаємозв’язку елементів даних:
• кожний пацієнт системи має унікальний ідентифікатор;
• пацієнт може бути нетолерантним як до жодного компонента,
так і для багатьох;
• кожний медикамент має унікальний ідентифікатор;
• кожний медикамент містить як мінімум один компонент,
максимум - необмежений;
• АТХ код, назва та міжнародна назва для кожного медикамента є
обов’язковими;
• кожний компонент має унікальний ідентифікатор;
• компонент може належати до багатьох медикаментів або до
жодного;
• компонент може належати до багатьох пацієнтів або до жодного;
• кожний компонент може належати тільки до однієї або жодної
групи компонентів;
• найменування компонента є обо’язковим;
• група компонентів має унікальний ідентифікатор;
• найменування для групи компонентів є обо’язковим;
• група компонентів повинна містити як мінімум 2 компоненти,
максимум - необмежений.
Використаємо підхід взаємозв'язку сутностей (або ж підхід ER) для
нормалізації БД. Підхід нормалізації, використовуючи теоретичні концепції
правил нормалізації, не будуть використовуватися, так як це ще один підхід для
33
логічного проектування реляційної бази даних, який на перший погляд,

здається, мало що поділяє з моделлю ER. Однак насправді, реляційний
дизайн, заснований на ретельному проектуванні ER-діаграми та дотриманні
правил перетворень ER-діаграми в реляційну форму дає на виході майже
однакові результати із підхідом нормалізації. Саме тому при використанні
першого підходу при отриманні фінального результату перші чотири форми
нормалізації повинні виконуватися.
Підхід ER намагається визначити ряд об’єктів для класифікації даних.
Потім від конструктора баз даних передбачається класифікація елементів
даних. Три основні класифікації даних: сутності, атрибути та взаємозв’язки.
Сутностями для проектованої БД виступають: Drugs (медикаменти),
Patients (пацієнти), Ingredients (компоненти медикаментів), Ingredients Group
(групи компонентів медикаментів). Спосіб назви сутностей у множині
використовувався для того, щоб підкреслити той факт, що кожен із них
представляє собою набір реальних об’єктів, які, як правило, містить кілька
елементів.
Атрибут - елемент даних, який описує властивість сутності або відносин
між сутностями. Кожна сутність повинна мати унікальний ідентифікатор та
атрибут або набір атрибутів, які приймають унікальні значення для кожного
екземпляра сутності.
Сутність Drugs має унікальний ідентифікатор drug_id та наступні
атрибути: applicant_details, name, producer_details, atc_code,
registration_certificate_number, international_name, compendium_url,
expiration_date.
Сутність Patients має унікальний ідентифікатор patient_id, інші атрибути
відсутні.
Сутність Ingredients має унікальний ідентифікатор ingredient_id та
атрибут ingredient_name.
Сутність IngredientsGroup має унікальний ідентифікатор group_id та
атрибут group_name.
34
Скористаємось правилами перетворень для того, щоб перетворити дизайн

ER у набір визначень для реляційної таблиці в комп'ютеризованій БД.
Перше правило трансформації вимагає, щоб кожна сутність на діаграмі
ER відображалася в одній таблиці в реляційній БД. Таблиця повинна бути
названою ім’ям сутності. Стовпці таблиці представляють усі однозначні прості
атрибути, які приєднані до сутності. Ідентифікатор сутності відображається як
первинний ідентифікатор для таблиці [36].
Відповідно до першого правила наведемо таблиці 4.1 – 4.4 представлення
сутностей.
Таблиця 4.1
Представлення реляційної таблиці ‘’Компоненти’’
Назва таблиці Назва стовпця Опис атрибуту
Ingredients ingredient_id Ідентифікатор компонента
ingredient_name Назва компоненту
Таблиця 4.2
Представлення реляційної таблиці ‘’Медикаменти’’
Назва Назва стовпця Опис атрибуту
таблиці
Drugs drug_id Ідентифікатор медикамента
name Торгівельна назва медикамента
applicant_details Деталі про заявника: назва, країна

та адреса
producer_details Деталі про виробника: назва,
країна та адреса
registration_certificate_number Номер реєстраційного посвідчення
atc_code Код за АТХ-класифікацією
compendium_url Посилання на медикамент на веб-

35
сайті Компендіум
expiration_date Термін придатності ЛЗ
international_name Міжнародне непатентоване

найменування
Таблиця 4.3
Представлення реляційної таблиці ‘’Компоненти’’
IngredientGroups group_id Ідентифікатор групи
group_name Назва узагальнюючої групи

компонентів
Таблиця 4.4
Представлення реляційної таблиці ‘’Пацієнти’’
Patients patient_id Ідентифікатор пацієнта
Друге правило трансформації свідчить, що якщо дано певну сутність із

первинним ідентифікатором p, яка містить багатозначний атрибут на ER-
діаграмі, тоді такий атрибут повинен відображатися у власній таблиці. Таблиця
повинна бути названою за атрибутом множини. Стовпці нової таблиці повинні
бути названими відповідно до параметрів p та a (де атрибут p або a може
складатися з кількох атрибутів), а рядки таблиці відповідають (p, a) парам
значень, що представляють усі сполучення значень атрибутів [36].
Відповідно до другого правила трансформації необхідно відобразити
діаграму ER для сутностей, які містять багатозначний атрибут. Проте жодна із
сутностей не містить у собі багатозначних атрибутів. Вважаємо, що друге
правило трансформації виконується.
36
Третє правило трансформації дозволяє вирішити проблему відносин

“багато-до-багатьох”: коли в бінарному відношенні беруть участь дві сутності
E і F, тоді їх зв'язок відображається у репрезентативній таблиці T у відповідній
конструкції реляційної бази даних. Таблиця містить стовпці для всіх атрибутів
у вигляді первинних ключів обох таблиць, взятих із сутностей E і F, і цей набір
стовпців утворює первинний ключ для таблиці T [36].
Так як взаємовідносини між сутностями Ingredients і Drugs, Patients і
Ingredients є відносинами типу “багато-до-багатьох”, використаємо третє
правило трансформації для вирішення проблем, які виникають при
використанні такого типу відносин (табл. 4.5, 4.6).
Таблиця 4.5
Представлення сутності ‘’Компоненти медикаментів’’
DrugsIngredients ingredient_id Ідентифікатор компонента
drug_id Ідентифікатор медикамента
Таблиця 4.6
Представлення сутності ‘’Нетолерантність пацієнтів до компонентів’’
PatientsIngredients ingredient_id Ідентифікатор компонента
patient_id Ідентифікатор пацієнта
Правило трансформації 4 стосується вирішення відносин "багато-до-

одного": коли в бінарному відношенні беруть участь дві сутності E і F і вони
мають відношення "багато-до-одного", тоді необхідно свторити додаткову
таблицю в реляційному дизайні БД.
Використаємо дане правило для вирішення відносин “багато-до-одного”
між сутностями Ingredients - IngredientGroup (табл. 4.7).
Таблиця 4.7
37
Представлення сутності ‘’Група компонентів’’

IngredientsGroupBelongin ingredient_id Ідентифікатор компонента

g
group_id Ідентифікатор пацієнта
П’яте та шосте правило трансформації стосується виду відносин “один-

до-одного”, де найбільш доцільним варіантом буде поєднання таблиць для двох
сутностей в одну і таким чином уникнути додавання будь-яких зовнішніх
ключів [36].
П’яте та шосте правило не розповсюджується на проектовану БД, так як
відносини між сутностями “один-до-одного” відсутні.
4.2 Проектування API частини застосунку

4.2.1 REST архітектура. Правила проектування REST API
Відповідно до вимог до продукту, API розроблюваного ПЗ повинен
виконувати принципи архітектурного стилю побудови API - REST архітектури.
Дана архітектура пропонує використання протоколу HTTP для передачі даних і
підтримання такої концепції ресурсів, де кожен компонент розглядається як
окремий ресурс, і доступ до цих ресурсів здійснюється через загальні
інтерфейси за допомогою HTTP методів [14].
Архітектура REST проста і забезпечує доступ до ресурсів, завдяки чому
клієнт REST отримує доступ та надає ресурси на стороні клієнта. Дотримючись
принципів REST, URI або глобальні ідентифікатори допомагають точно
ідентифікувати кожен ресурс. REST підтримує декілька варіантів представлень
ресурсів, таких як XML, JSON, текст, зображення тощо [14].
Існують правила проектування, які застосовуються для встановлення
різних характеристик архітектурного стилю REST, які називаються
обмеженнями REST. Для дотримання архітектурного стилю REST кожне із
наступних правил повинно бути дотриманим при проектуванні та подальшій
реалізації розроблюваного ПЗ:
38
1) Client-server - правило дотримання клієнт-серверної архітектури,

яке вимагає, щоб сервіс пропонував одну або декілька операцій і
щоб сервіси чекали до тих пір, поки клієнт сервісу зробить запит на
виконання цих операцій [5]. Для того, щоб дане спілкування
відбувалося ефективно, необхідно мати чітко визначений протокол
спілкування, який встановлює ці правила спілкування, такі як
формат повідомлень запитів, формат відповідей, обробки помилок
тощо [14].
2) Statelessness - правило в контексті REST, яке означає, що всі запити
клієнта на сервер несуть всю інформацію як детальну, чітко
визначену, таким чином, що сервер розуміє запити та розглядає їх
як незалежні, а тому ці запити клієнта забезпечують серверу
незалежність від будь-якого збереженого контекста. Зберігати стан
сеансу в клієнті важливо для управління цим обмеженням у
службах. Дане обмеження допомагає службам бути більш
масштабованими та надійними [14].
3) Cacheable - правило кешування - можливість зберігати дані, на які
часто поступають запити від клієнта таким чином, щоб серверу
ніколи не доводилося генерувати однакову відповідь більше одного
разу до тих пір, поки це не стане потрібним (запит не зміниться).
Налагоджене кешування усуває часткову або повну взаємодію
клієнта та сервера і все ще забезпечує клієнта очікуваною
відповіддю. Очевидно, що кешування приносить масштабованість у
систему, а також покращує продуктивність завдяки швидшому часу
відгуку та зменшенню навантаження на сервер [14].
4) Uniform interface - правило однаковості та незмінності - можливість
використання методів інтерфейсу HTTP, таких як GET, POST, PUT,
DELETE тощо із метою підтримання константності типів запитів в
Інтернеті. Також дане правило охоплює встановлення URI, яке
однозначно визначає концепцію кореневого ресурсу певного веб-
сайту, підтриманню MIME - список можливих чітко визначених
39
форматів або типів носіїв, таких як JSON, XML, HTML, PNG тощо,
підтриманню HATEOAS - представлення стану ресурсу, який
включає посилання на пов'язані з ним ресурси [14].
5) Layered systems - правило багатошарової системи, яке вимагає
створення шарів з різними одиницями функціональності.
Основними характеристиками багатошарових систем є те, що
рівень комунікації здійснюється за допомогою заздалегідь
визначених інтерфейсів і певний шар взаємодіє лише із шаром, що
знаходиться шаром вище або шаром нижче. Таким чином, по мірі
розвитку архітектури шари можна додавати, видаляти,
модифікувати або переупорядковувати [14].
6) Code on demand (COD) - будь-яка технологія, яка дозволяє серверу
надсилати код програмного забезпечення клієнтам для виконання
на клієнтському комп'ютері за запитом програмного забезпечення
клієнта. Деякі відомі приклади парадигми COD в Інтернеті - це
аплети Java або застосунки JavaScript [14].
4.2.2 Загальні принципи проектування API
Щоб створити гнучкі, масштабовані та безпечні API, дизайнеру API
потрібен набір керівних принципів. Ми обговоримо наступні основні
принципи:
1) Використання загальних веб-стандартів. Дизайнери API повинні
прийняти існуючі веб-стандарти та розробити свій дизайн API
таким чином, щоб комунікація між RESTful API та клієнтами була
стандартизованою, так, щоб:
● будь-який клієнт програми мав можливість використовувати
API в ідеалі без необхідності посилатися на документацію;
● використовувалися стандартні методи HTTP, доступні на
будь-якій мові та платформі, для надсилання запитів та

отримання вдповідей через API;
40
● не було жодних припущень щодо технологій розробки
програмного забезпечення, що використовуються

споживачами додатку [14].
2) Гнучкість API. Дані API повинні бути незалежними від ресурсів або
методів. Це означає, що API повинно обробляти різні типи запитів і
повертати різні формати даних, навіть з деякими змінами в
структурі (наприклад, зміни гіпермедіа) [14].
3) Стандартизація API. Принцип стандартизації передбачає, що
впровадження API слід розробляти з використанням стандартних
інформаційних компонентів, коли вони доступні [14].
4) Оптимізація API. Принцип впровадження найкращого чи
найефективнішого використання ресурсу.
5) Детальність API. Принцип деталізації API, який повинен
відповідати конкретним потребам бізнес-функцій або випадків
використання. Мета полягає в тому, щоб мінімізувати запити в
мережі, щоб досягти кращої продуктивності [14].
Дотримання даних загальних принципів проектування API допоможе нам
спроектувати, а далі й розробити високоякісний RESTful API.
4.2.3 Проектування API для розроблюваного ПЗ
REST API повинен використовувати уніфікований ідентифікатор ресурсу
для надання доступу до своїх ресурсів. Проте, так як Замовник буде
використовувати власні сервери, для розробки API використаємо стандартне
доменне ім’я URI у вигляді ‘’localhost’’ на порту 8080.
REST API - це сукупність взаємопов’язаних ресурсів або моделей
ресурсів. Ресурси передають свій стан за допомогою версій. Отже,
встановлення версій є одним із важливих принципів проектування. Кореневий
URI виглядатиме наступним чином: “https://localhost:8080/v1”.
Створимо шляхи до ресурсів, які будуть відокремлені косою рискою для
позначення унікального ресурсу в ієрархії його моделі.
41
Першою моделлю є сутність пацієнти, тому шлях посилання до пацієнтів

починатиметься з “/patients”. Для кожного із необхідної для ПЗ дії вкажемо
шлях до ресурсу, а також HTTP метод:
1) GET : “/patients” - отримати наявні дані про всіх пацієнтів. Повертає
статус код 200, якщо перелік пацієнтів було успішно повернено,
204 - якщо жодного пацієнта не існує.
2) GET : “/patients/{patientId}” - отримати інформацію про
конкретного пацієнта. Повертає статус код 200, якщо інформацію
про пацієнта було успішно повернено, 404 - якщо пацієнта з даним
ідентифікатором не існує.
3) DELETE: “/patients/{patientId}” - видалити конкретного пацієнта.
Повертає статус код 200, якщо пацієнта було успішно видалено,
404 - якщо пацієнта з даним ідентифікатором не існує, 500 - у
випадку невдачі при видаленні запису зі сторони ПЗ.
4) POST: “/patients”, вказавши ідентифікатор пацієнта в тілі запиту у
форматі JSON як {“patientId”: “{inputPatientId}”},- додати запис про
пацієнта. Повертає статус код 200, якщо запис про пацієнта було
успішно створено, 409 - якщо пацієнт із даним id уже існує, 500 - у
випадку невдачі при створенні запису зі сторони ПЗ.
5) POST : “/patients/{patientId}/ingredients”, вказавши параметр
ingredientName в тілі запиту в наступному вигляді
[{"ingredientName": “{input_name_1}”}, {"ingredientName":
“{input_name_2}”}],- додати непереносимі конкретним пацієнтом
компоненти. Повертає статус код 200, якщо запис про компонент
було успішно додано, 404 - якщо пацієнта з даним ідентифікатором
не існує, 409 - якщо дані компоненти вже були додані до картки
пацієнта, 500 - у випадку невдачі при створенні запису зі сторони
ПЗ.
6) DELETE : “/patients/{patientId}/ingredients/{ingredientName}” -
видалити непереносимий конкретним пацієнтом компонент.
Повертає статус код 200, якщо запис про компонент було успішно
42
видалено, 404 - якщо пацієнта з даним ідентифікатором або

компонента не існує, 500 - у випадку невдачі при видаленні запису
зі сторони ПЗ.
Другою моделлю є сутність медикаменти, тому ендпоінт запиту для
взаємодії із сутністю медикаментів починатиметься з “/drugs”. Вкажемо шлях
до ресурсу, HTTP метод та опис ендпоінту:
1) GET : “/drugs” - отримати дані про всі наявні медикаменти.
Повертає статус код 200, якщо перелік медикаментів було успішно
повернено, 204 - якщо жодного ЛЗ не існує.
2) GET : “/drugs/{drugName}” - отримати дані по конкретному
медикаменту. Повертає статус код 200, якщо медикамент було
успішно повернено, 404 - якщо даного ЛЗ не існує.
3) PUT : “/drugs”, вказавши тіло запиту,- змінити дані по конкретному
медикаменту. Повертає статус код 200, якщо дані медикамент було
успішно змінено, 400 - якщо користувач не вказав обов’язкові
атрибути медикамента, 404 - якщо даного ЛЗ не існує, 500 - у
випадку невдачі при зміні запису зі сторони ПЗ.
4) POST : “/drugs”, вказавши тіло запиту,- додати новий медикамент.
Приклад тіла запиту: {"drugId":4,"name":"drug_name_unique",
"applicantDetails":"drug_applicant_det","producerDetails":"drug_produ
cer_details","registrationCertificateNumber":"drug_cert_num","atcCode
":"atc_code_1","compendiumUrl":"drug_compendium_url","expiration
Date":"drug_expiration_date","internationalName":"drug_international_
name","ingredients":
[{"ingredientId":2,"ingredientName":"test_name_2"},
{"ingredientId":3,"ingredientName":"test_name_3"}]}. Повертає
статус код 200, якщо запис про ЛЗ було успішно створено, 400 -
якщо користувач не вказав обов’язкові атрибути медикамента, 500 -
у випадку невдачі при створенні запису зі сторони ПЗ.
5) DELETE : “/drugs/{drugName}” - видалити конкретний медикамент.
Повертає статус код 200, якщо запис про ЛЗ було успішно
43
видалено, 404 - якщо ЛЗ з даною назвою не існує, 500 - у випадку

невдачі при видаленні запису зі сторони ПЗ.
Функціональними ендпоінтами, які будуть виконувати основні функції
ПЗ починатимуться із “/drugs”, відповідно до вище наведеної моделі
медикаментів, так як ПЗ повинен повертати перелік толерантних ЛЗ для
пацієнта. Для цього застосунку буде необхідно виконати певні розрахунки,
враховуючи непереносимі компоненти. Саме тому пропонується наступна
структура запиту. По-перше, клієнт повинен надіслати POST запит для того,
щоб ПЗ почав підбір сприятливих медикаментів. По-друге, клієнт повинен
зробити GET запит для того, щоб отримати перелік медикаментів після того, як
ПЗ завершив опрацювання. Виникає необхідність створення наступних
ендпоінтів:
1) POST : “/drugs/run-tolerance”, використовуючи тіло запиту із
переліком кодів за АТХ-класифікацією та ідентифікатором
пацієнта,- опрацювання та підбір ПЗ сприятливих для пацієнта
медикаментів. Приклад тіла запиту: {"atcCodes":["N02",
"M01A"],"patientId":1}. Також є можливим підбір медикаментів
вказавши перелік непереносимих компонентів, не вказуючи
пацієнта. Повертає статус код 200, якщо процесс підбору
медикаментів було розпочато, 500 - у випадку перебоїв роботи
сервера.
2) GET : “/drugs/run-tolerance/{runId}” - повертає перелік сприятливих
медикаментів після того, як ПЗ завершив опрацювання. Повертає
статус код 200, якщо були підібрані толерантні ЛЗ, 204 - якщо
жодного ЛЗ не було підібрано, 404 - якщо даного ідентифікатора
запуску не існує.
Третьою моделлю є сутність компоненти медикаментів, тому ендпоінт
запиту для взаємодії із сутністю компонентів медикаментів починатиметься з
“/ingredients”. Вкажемо шлях до ресурсу, HTTP метод та опис ендпоінту:
44
1) GET : “/ingredients” - отримати дані про всі наявні компоненти

медикаментів. Повертає статус код 200, якщо перелік компонентів
було успішно повернено, 204 - якщо жодного компонента не існує.
2) POST : “/ingredients”, вказавши тіло запиту у вигляді JSON формату
як {“ingredientName” : {yourIngredientName}},- додати новий
компонент. Повертає статус код 200, якщо запис про компонент
було успішно створено, 409 - якщо компонент із даним ім’ям уже
існує, 500 - у випадку невдачі при створенні запису зі сторони ПЗ.
3) DELETE : “/ingredients/{ingredientName}” - видалити конкретний
компонент. Повертає статус код 200, якщо запис про компонент
було успішно видалено, 404 - якщо компонента з даною назвою не
існує, 500 - у випадку невдачі при видаленні запису зі сторони ПЗ.
Четвертою моделлю є сутність груп компонентів медикаментів, тому
ендпоінт запиту для взаємодії із даною сутністю починатиметься з “/ ingredient-
groups”. Вкажемо шлях до ресурсу, HTTP метод та опис ендпоінту:
1) GET : “/ingredient-groups” - отримати дані про всі наявні групи
компонентів медикаментів. Повертає статус код 200, якщо групи
компонентів було успішно повернено, 204 - якщо жодної групи не
існує.
2) GET : “/ingredient-groups/{groupName}” - отримати компоненти із
конкретної групи. Повертає статус код 200, якщо перелік
компонентів було успішно повернено, 404 - якщо групи із даною
назвою не існує.
3) PUT : “/ingredient-groups”, вказавши тіло запиту,- змінити
компоненти по конкретній групі. Повертає статус код 200, якщо
компоненти було успішно змінено, 404 - якщо даної групи не існує,
500 - у випадку невдачі при зміні запису зі сторони ПЗ.
4) POST : “/ingredient-groups”, вказавши тіло запиту у форматі JSON
як {“groupName”:“{inputGroupName}”},- додати нову групу
компонентів медикаментів. Повертає статус код 200, якщо запис
про групу було успішно створено, 409 - якщо група із даним ім’ям
45
вже існує, 500 - у випадку невдачі при створенні запису зі сторони

ПЗ.
5) DELETE : “/ingredient-groups/{groupName}” - видалити конкретну
групу компонентів медикаментів. Повертає статус код 200, якщо
запис про групу було успішно видалено, 404 - якщо групи з даною
назвою не існує, 500 - у випадку невдачі при видаленні запису зі
сторони ПЗ.
6) DELETE : “/ingredient-groups/{groupName}/ingredients
/{ingredientName}” - видалити вказаний компонент із певної групи.
Повертає статус код 200, якщо компонент було успішно видалено із
групи, 404 - якщо групи або компоненту з даною назвою не існує,
500 - у випадку невдачі при видаленні запису зі сторони ПЗ.
7) POST : “/ingredient-groups/{groupName}/ingredients”, вказавши в тілі
запиту у формату JSON необхідні компоненти як
[{"ingredientName": “{input_name_1}”}, {"ingredientName":
“{input_name_2}”}],- додати певні компоненти до вказаної групи.
Повертає статус код 200, якщо певний компонент було успішно
додано до вказаної групи, 409 - якщо дані компоненти вже були
додані до групи, 500 - у випадку невдачі при створенні запису зі
сторони ПЗ.
Кожен запит клієнта до будь-якого API ендпоінту, який повинен
повернути певну відповідь, повинен містити, а клієнт, відповідно, обробляти
наступні HTTP заголовки:
● content-type - тип контенту запиту;
● content-length - довжину контенту;
● accept - тип, який сервер повинен обробляти.
У випадку GET запитів обмежимося стандартними заголовками.

Заголовок cache-control повинен бути присутнім для кожного запиту.
46
Так як комунікації REST API для розроблюваного ПЗ виконуються у

вигляді текстового формату, зручніше буде використовувати JSON формат для
представлення усіх ресурсів та сутностей.
Для захисту ресурсів пропонується використовувати Oauth - протокол
авторизації на основі HTTP.
При виконанні розділу було спроектовано всі необхідні сутності

(реляційні таблиці) для модливості подальшої розробки і додавання даних до
бази даних.
При проектуванні API були розглянуті основні вимоги та характеристики
щодо дизайну API та принципів побудови API на основі REST архітектури. В
результаті було спроектовано API із використанням даних принципів та правил,
а також найкращих світових практик.
47
РОЗДІЛ 5
РОЗРОБКА ПЗ
5.1 Створення БД та відповідних сутностей
Розробка БД проводилась згідно із спроектованою базою даних в

підрозділі 4.1. Схема створення таблиць бази даних наведено в додатку А.
Після виконання скрипта створюється база даних із таблицями у вигляді,
наведеному на рис. 5.1.
Рисунок 5.1 Сутності бази даних застосунку
5.2 Розробка API частини застосунку
Повний код застосунку можна знайти за посиланням

https://github.com/hupaloo/Drugs-API. Для створення API застосунку була
використана мова програмування Groovy. Фреймворком для створення API
було використано Spring Boot. Spring Boot - фреймворк на основі Java, який
використовується для створення додатків із використанням мікросервісів. Це є
фреймворк з відкритим кодом, який забезпечує гнучку конфігурацію XML,
48
транзакції баз даних, надійну пакетну обробку, полегшене адміністрування

служб REST та кінцевих точок [34]. Серед переваг Spring Boot:
● мінімізація часу, витраченого на розробку;
● зменшення ручної роботи із написання анотацій, типових кодів та
конфігурацій XML;
● підтримка інтеграції з екосистемою Spring, яка включає Spring
Security, Spring Data, Spring JDBC та Spring ORM;
● розробники мають легкий доступ до вбудованих HTTP-серверів,
таких як Jetty, Tomcat, а також легко тестують веб-програми без

особливих зусиль;
● забезпечує легкий доступ до інтерфейсу командного рядка, що
зробило розробку та тестування програм Spring Boot, розроблених

за допомогою Java або Groovy, гнучкими;
● пропонує безліч плагінів, які допомагають у легкій розробці та
тестуванні побудови додатків за допомогою таких інструментів, як

Gradle та Maven;
● надає плагін, завдяки якому робота з вбудованою базою даних є
дуже плавною та легкою.

Як засіб збирання проекту було використано фреймворк Maven. Apache
Maven - це програмний засіб управління та розуміння проектів. На основі
концепції об'єктної моделі проекту, Maven може управляти збіркою проекту,
звітуванням та документацією з центральної інформації. Maven спрощує та
стандартизує процес побудови проекту. Він безперешкодно обробляє
компіляцію, розподіл, документацію, співпрацю в команді та інші завдання.
Maven збільшує можливість повторного використання та опікується більшістю
завдань, пов’язаних зі збіркою [35].
49
У більшості типових додатків ми маємо різні рівні, такі як доступ до

даних, презентація, сервіс, бізнес шар тощо. Крім того, у кожному шарі ми
маємо різні компоненти. Для автоматичного виявлення цих компонентів Spring
використовує анотації сканування шляху. Потім він реєструє кожен компонент
у класі ApplicationContext [40]. Перелік цих анотацій:
● @Controller - це анотація на рівні класу, яка повідомляє Spring
Framework, що цей клас служить контролером у Spring MVC.
● @Service визначає класи на сервісному рівні.
● @Repository коментує класи на рівні продовження, який буде діяти
як сховище бази даних.

Для обміну даними було використано формат JSON, бібліотекою для
серіалізації та десеріалізації JSON у об’єкти стала загальновизнана бібліотека
Jackson.
У першу чергу були створено моделі на кожну сутність для можливості
передачі даних між БД та застосунком та подальшим використанням об’єкту
даної сутності в застосунку. Моделі створено у відповідному пакеті за шляхом
infrastructure.model. Як приклад, модель групи компонентів виглядає наступним
чином (див. рис. 5.2).
50
Рисунок 5.2 Модель сутності групи компонентів
Потім були створені класи-репозиторії для можливості взаємодії із БД:

виконанням запитів на пошук, додавання, видалення тощо. Класи-репозиторії
створено у відповідному пакеті за шляхом infrastructure.repositories.
Далі було створено класи-сервіси, які використовують класи-репозиторії
для виконання основних функції програми. Класи-сервіси створено у
відповідному пакеті за шляхом infrastructure.services.
Після цього було створено класи-контроллери, які взаємодіють із
класами-сервісами та визначають кінцеві точки, на які клієнт відправлятиме
запити, а контроллер повертатиме певні відповіді за необхідності. Класи-
контролери створено у відповідному пакеті за шляхом infrastructure.controllers.
Наведемо для прикладу код контроллера для взаємодії із сутністю компонентів
медикаментів (див. рис. 5.3).
51
Рисунок 5.3 Контроллер сутності компонентів
Також для обробки потенціальних помилок було створено 4 класи для

можливості кастомної відповіді на запит клієнта із різними HTTP статус
кодами (400 - у випадку невалідних даних зі сторони клієнта, 409 - якщо
сутність вже існує, 404 - якщо сутність не існує, 204 - якщо контент відсутній)
та зрозумілими повідомленнями про причину помилку. Класи для обробки
помилок знаходяться у пакеті infrastructure.exception.
Загальний вигляд структури програми виглядає наступним чином (див.
рис. 5.4).
52
Рисунок 5.4 Фінальна структура застосунку
Для перевірки працездатності роботи програми додамо тестові дані до

створеної БД. SQL скрипт для заповнення таблиць із тестовими даними
наведено в додатку А.
Тестові дані містять дані про двох пацієнтів, перший з яких
нетолерантний до кофеїну та пальмової олії, другий - до парацетамолу. Також
53
наведено два медикаменти: “Цитрамон Дарниця”, який складається з

компонентів ацетилсаліцилової кислоти, фенацетину, кофеїну, лимонної
кислоти та “Фаніган”, який складається з парацетамолу та диклофенаку натрію.
Перевіримо, що ПЗ при підборі толерантних медикаментів для першого
пацієнта, наприклад, для лікування від головної болі (властивості тестових
медикаментів), повертає валідні результати (див. рис. 5.5).
Рисунок 5.5 Перевірка функції підбору медикаментів

Як бачимо, лікар, до якого звернувся пацієнт із ідентифікатором 1 із
проханням підібрати ліки від головної болі, скористався застосунком, вказавши
групи препаратів за АТХ-кодами, які справляють знеболювальну дію (N02 -
засоби, що діють на нервову систему (анальгетики); M01A - нестероїдні
протизапальні препарати) і через те, що пацієнт нетолерантний до компоненту
кофеїн, препарат “Цитрамон дарниця” не було рекомендовано пацієнту, а
54
“Фаніган”, котрий не містить непереносимих компонентів пацієнтом, було

рекомендовано для застосування пацієнту.
В результаті кодування, було створено схему базу даних та було створено

API частину ПП. Програма пройшла перевірку на тестових даних та є цілком
функціональною.
55
РОЗДІЛ 6
ОХОРОНА ПРАЦІ
6.1 Характеристика приміщення
Приміщення мають відповідати вимогам, встановленим законодавством:
• ДБН В.2.2-10:2017 «Будинки і споруди. Заклади охорони здоров’я»

(далі – ДБН В.2.2-10:2017);
• ДБН В.2.5-67:2013 «Опалення, вентиляція і кондиціонування»;
• ДБН В.2.2-17:2006 «Будинки і споруди. Доступність будинків і споруд

для маломобільних груп населення».
Для медичної практики можуть використовуватися лише нежитлові

приміщення, які можуть розташовуватися в тому числі в житлових та
громадських будинках. Зокрема, відповідно до ДБН В.2.2-10:2017, у житлових
та громадських будинках допускається розміщувати за умови наявності
окремого входу та дотримання протипожежних, санітарно-гігієнічних вимог,
що забезпечують оптимальний режим експлуатації кабінету сімейного лікаря.
Параметри кабінету, зокрема, перелік оснащень та обладнання

представлені в таблиці 6.1.
Таблиця 6.1
План приміщення, специфікація обладнання та оснащення
№ Найменування Основні характеристики Кількість Позиція

на
рисунку
Приміщення
Параметри Розміри: 5000 * 5000 * 3000 мм, – –
56
приміщення площа рівна S = 25 м 2, об’єм

рівний V = 75 м 3
Кількість Лікар-терапевт, медсестра, 3 –
працюючих пацієнт
Природне Вікно металопластикове 1 –
освітлення
Розміри: 1200 * 1400 мм
Штучне Світильник ЛПО-01 2 0
освітлення дволамповий
Розміри 1313 * 255 мм
Обладнання і оснащення
Кушетка Розміри: 1890 * 600 * 560 мм 1 1
оглядова КО-1
Матеріал: сталевий каркас,
покриття вінілісшкіра
Стіл письмовий Розміри: 1400 * 740 * 760 мм 2 2
Ліра 2 СП-2
Матеріал: дерево
Стілець Розміри: 470 * 470 * 820 мм 3 3
Примтекс Плюс
Матеріал: металевий каркас,
ISO СТ-3
покриття ткань
Шафа медична Розміри: 900 * 400 * 1800 мм 1 4
ШМ-4
Матеріал: сталь
Шафа для одягу Розміри: 600 * 400 * 1800 мм 1 5
ШО-5
Матеріал: метал
Моноблочна Розміри: 630 * 300 2 6
станція
Матеріал: алюміній
медичного
призначення
MPC225-873
Вогнегасник Розміри: 160 * 480 мм, 2 7
ОП-5 порошковий
Протипожежна Розміри 40 * 60 * 60 мм 1 8
57
система ДТЛ-10
План приміщення зображено на рис. 6.1.
Рисунок 6.1. План приміщення

У таблиці 6.2 описано нормативні значення та реальні значення
параметрів кабінету.
Таблиця 6.2
Реальні та нормативні характеристики приміщення
Характеристики Нормативні значення (за Реальне значення

ДсанПіН 3.3.2.007-98)
58
Параметри одного 6 кв.м. (3м х 2м) 12,5 кв. м.

робочого місця
Об’єм робочого місця 20 куб. м. (3м х 2м х 3.3 м) 37,5 куб. м.
Згідно із нормами ДБН В.2.2-9-99 мінімальна ширина проходу повинна
бути не менше 1 м, реальне значення - 1,4 м, мінімальна ширина дверного
проходу - не менше 1 м, реальне значення - 1,09 м.
6.2 Оцінка ключових небезпечних і шкідливих виробничих факторів
Всі шкідливі виробничі фактори ГОСТ поділяє на наступні групи:
- фізичні;
- хімічні;
- біологічні;
- психофізіологічні, до яких можна віднести важкі та напружені умови

праці.
Можна відзначити, що немає чіткої межі між шкідливими та

небезпечними факторами, вона завжди умовна і в будь-який момент може бути
зруйнована.
Так як хімічний фактор відсутній для нашого випадку, розглянемо

біологічні, психофізіологічні, фізичні фактори, конкретніше: фактор
електробезпеки та пожежної безпеки.
6.2.1 Біологічний фактор

У зв’язку зі складною епідеміологічною ситуацією у світі, розглянемо
біологічний фактор, враховуючи можливість робітника заразитися вірусом
(див. табл. 6.3-6.5).
Таблиця 6.3
Джерела небезпеки при біологічних факторах
Джерело небезпеки Причина небезпеки Наслідки
59
Вірус - недотримання Може призвести до

соціальної дистанції тривалого
відсторонення від
- недотримання правил
роботи.
індивідуальної гігієни
Таблиця 6.4
Порівняння реальних та нормативних значень біологічних факторів
Фактор небезпеки Реальне значення Нормативне значення
Небезпека Присутнє Нормативне значення
захворювання для даного випадку є
внаслідок поширення відсутнім
вірусного
захворювання
Таблиця 6.5
Методи захисту виникнення та поширення біологічних факторів
Методи захисту Результат його впровадження
Забезпечення необхідними Зниження ризику захворювання
засобами захисту працівників робітників
Регулярне провітрення приміщення
Дезінфекція приміщення
6.2.2 Психофізіологічний фактор
Будь-яка професія має безпосередній ризик психофізичних небезпек,
розглянемо фактори небезпеки (див. табл. 6.6-6.8).
Таблиця 6.6
Джерела небезпеки при психофізіологічних факторах
Джерело небезпеки Причина небезпеки Наслідки
Перевантаження Понаднормова робота Стрес, слабкість,
лікаря нервовий розлад
Конфліктні пацієнти
Таблиця 6.7
60
Порівняння реальних і нормативних значень психофізіологічних факторів

Перевантаження Присутнє Нормативне значення
для даного випадку є
відсутнім
Таблиця 6.8
Методи захисту виникнення та поширення психофізіологічних факторів
Методи захисту Результат його впровадження
Уникати випадків понаднормової Зменшення можливості
роботи, якщо неможливо, - перевантаження на роботі.
оплачувати по подвійній ставці.
Не приймати конфліктних
пацієнтів
6.2.3 Електробезпека
Фактори електробезпеки наведено в табл. 6.9-6.11.
Таблиця 6.9
Джерела потенційної електронебезпеки
Найменування Джерело Причини небезпеки Наслідки
обладнання небезпеки небезпеки
1 Моноблочна Оголений Пошкодження ізоляції робітника
станція кабель кабелю може
медичного вдарити
призначення струмом,
можливий
летальний
результат
Таблиця 6.10
Порівняння реальних та нормативних значень
1 Максимальна напруга 220-230 В 42 В
61
2 Максимальний струм 0,025 А
Таблиця 6.11
Заходи забезпечення охорони праці
Група заходів з ОП Вид заходу Критерій вибору

1 Технічні Необхідно ізолювати Захист від
кабель випадкового дотику
працівника
2 Організаційні Проведення інструктажу Поглиблення знань
з правил електробезпеки працівників з питань
електробезпеки
3 Режимні Заборонена на вхід Захист від
постороннім у кімнату постороннього
втручання
4 Експлуатаційні Регулярна перевірка Отримання
роботи та справності достовірності щодо
пристрою безпеки та справності
6.2.4 Пожежна безпека
Фактори пожежної безпеки наведено в табл. 6.12-6.16.
Таблиця 6.12
Джерела потенційної пожежної небезпеки
№ Джерело Причини небезпеки Наслідки небезпеки

небезпеки
1 Несправність Коротке замикання Обладнання, оснащення
кабелів або пробій ізоляції може бути пошкодженим
моноблочної або цілком зруйнованим.
62
станції Робітник може отримати

опіки або навіть є
2 Перегрів ізоляції Коротке замикання
можливим летальний
3 Недотримання Займання матеріалів результат
правил пожежної
безпеки
Таблиця 6.13
Пожежна небезпека приміщення
Клас пожежі Категорія пожежної Класифікація

небезпеки приміщення пожежонебезпечних зон
Е, А В ІІ-ІІа
Таблиця 6.14
Необхідне оснащення приміщення вогнегасниками
Категорія Гранична Клас Пінні Порошкові

приміщення площа, м 2 пожежі вогнегасники, вогнегасники, 10 л
10 л
В 25 В - 1
Таблиця 6.15
Оснащення приміщення пожежними сповіщувачами
Тип Висота Схема трикутного розміщення сповіщувачів

пожежного приміщення
Площа м 2, що Максимальна відстань, м
сповіщувач ,м
контролює
а Між Від
один
сповіщувачам сповіщувача до
сповіщувач
и стіни
Тепловий До 3,5 До 25 5 2,5
ДТЛ, ИТМ, включно
ИП-105-1/2
Таблиця 6.16
Заходи забезпечення охорони праці
№ Група заходів з ОП Вид заходу Критерій вибору

63
1 Технічні Використання При пожежі необхідно

порошкового використовувати
вогнегасника ОП-5 порошковий вогнегасник

Використання
протипожежної
системи ДТЛ
2 Організаційні Проведення Поглиблення знань
інструктажу з працівників з питань
правил пожежної пожежної безпеки
безпеки
3 Режимні Заборонити куріння В приміщенні розміщено
та використання датчик ДТЛ
вогню
4 Експлуатаційні Перевірка Достовірність справності
справності обладнання
обладнання та
оснащення
Відповідно до ДСТУ 3855-99 в кабінеті дотримані всі необхідні правила
щодо пожежної безпеки.
В даному розділі було визначено небезпечні фактори, які є потенційно

небезпечними для працівників кабінету сімейного лікаря. Було проаналізовано
психофізіологічні, біологічні, фізичні фактори та встановлено методи захисту
для зниження вірогідності виникнення конкретної загрози або її повного
уникнення. В результаті було сплановано приміщення, яке повністю підлягає
під правила та заходи з електробезпеки та пожежної безпеки.
64
РОЗДІЛ 7
РОЗРАХУНОК ЕКОНОМІЧНОГО ЕФЕКТУ
7.1 Постановка завдання проектування
Завданням виступає надання оцінки основним характеристам

програмного продукту, призначеного для пошуку ліків із урахуванням
непереносимих компонентів пацієнтом. Для створення програмного
інтерфейсу застосунку була використана мова програмування Python у
середовищі розробки PyCharm 2020.3. Інтерфейс користувача було створено за
допомогою мови програмування JavaScript і використанням фреймворку
ReactJS. Для обробки бази даних із медичними засобами також
використовувалася мова програмування Groovy. Програмний продукт
призначено для використання на персональних комп’ютерах під управлінням
операційних систем MacOS, Linux, Windows.
Необхідно провести аналіз можливих варіантів реалізацію програмного
продукту із метою вибору найоптимальнішої, яка б поєднувала високі
економічні фактори, а також характеристики продукту, що впливають на
продуктивність роботи і на його сумісність з апаратним забезпеченням. Для
виконання поставленого завдання використаємо апарат функціонально-
вартісного аналізу.
7.2 Обґрунтування функцій програмного продукту
Головною функцією F0 є розробка програмного продукту, призначеного

для пошуку ліків із урахуванням непереносимих компонентів пацієнтом.
Виходячи з мети, приведемо основні функції програмного застосунку та
можливі варіанти реалізації.
65
Таблиця 7.1
Основні функції програмного додатку
№ Умовні позначення Основні функції Варіанти реалізації
1 F1 Вибір мови програмування для А) Groovy

створення back end частини
Б) Python
застосунку
2 F2 Вибір мови програмування для А) JavaScript
створення front end частини
Б) TypeScript
застосунку
3 F3 Фреймворк для GUI А) ReactJS
Б) Angular
Відобразимо на морфологічній карті всі можливі комбінації варіантів
реалізації обраних функцій, які складають повну множину варіантів
програмного продукту (рис. 7.1).
Рисунок 7.1 Морфологічна карта
На основі приведеної морфологічної карти побудовано позитивно-

негативну матрицю основних функції, представлену у таблиці 7.2.
66
Таблиця 7.2
Позитивно-негативна матриця
Основні Варіанти Переваги Недоліки
функції реалізації
Простота синтаксису, є
При використанні динамічних
надлаштунком над мовою Java,
властивостей можлива
А дозволяючи, окрім власних,
безладність і важкість у
використовувати всі особливості
F1 розумінні коду
мови Java
При поганому проектуванні
Кросплатформність, ООП,
Б спостерігається низька
безпека
продуктивність
Реалізує концепції ООП,
Не всі браузери (старі версії)
А дозволяє писати і надалі
підтримують дану мову.
підтримувати більш складні ПП
F2
Легкість в використанні плагінів
Б Знижений рівень безпеки
та скриптів
Легкий у вивченні, дуже Охоплює лише функції
А швидкий створення інтерфейса програми
та нічого іншого
F3
Різноманітність різних структур,
Складніший у вивченні, проте
Б відносно повільна
містить більше функцій
продуктивність
Зробивши аналіз матриці, робимо висновок, що деякі недоліки для
продукту, що розробляється, занадто вагомі і їх варто відкинути. Розглядаючи
варіанти F1a та F1б використання будь-якої з мов програмування суттєво не
вплине на працездатність та якість продукту, тому дані варінти є гідними для
розгляду. Розглядачи F2, безпека застосунку є дуже важливим параметром при
проектуванні ПП, тому F2a відкидається. Розглядаючи F3, повільна
продуктивність фреймворку є великим мінусом для застосунку, який повинен
швидко видавати результати із великої бази даних з ліками, тому варіант F3б
відкидається. Тому будемо розглядати такі варіанти реалізації ПП:
F1а – F2а – F3а
F1б – F2а – F3а
67
7.3 Обґрунтування системи параметрів ПП
Для того, щоб охарактеризувати програмний продукт, розглянемо

наступні параметри:
X1 – час ознайомлення з мовою програмування ПД;
X2 – час для розробки інтерфейсу ПД;
X3 – потенційний об’єм ПД;
Значення параметрів базуються на вимогах описаних у технічному
завдані до програмного продукту. Результати наведені у таблиці 7.3.
Таблиця 7.3
Основні параметри ПП
Значення параметра
Назва Умовні Одиниці
Гранично
Параметра позначення виміру середні кращі
допутиме
Час ознайомлення з
мовою програмування X1 год 20 17 13
ПД
Час для розробки
X2 год 15 10 8
інтерфейсу
кількість
Потенційний об’єм ПД X3 2500 2000 1400
рядків коду
За даними таблиці будуємо графіки бальної оцінки (рис 5.2 – 5.4).
68
Рис. 7.2. Значення параметру Х1 – час ознайомлення з мовою програмування

для розробки ПД
Рис. 7.3. Значення параметру Х2 – час для розробки інтерфейсу
Рис. 7.4. Значення параметру Х3 – потенційний об’єм застосунку
7.4 Аналіз експертного оцінювання параметрів
Для прийняття групового рішення необхідно провести оцінку важливості

параметрів. Для цього введемо шкалу із значеннями параметрів від 1 до 3, де
69
значення 1 – важливо, а значення 3 – неважливо,. Результати ранжування

приведено у таблиці 7.4.
Таблиця 7.4
Результати ранжування параметрів
Позначення Назва параметра Одиниці Ранг Сума Відхил Δi2
параметра виміру параметра за рангів ення
оцінкою
експерта
1 2 3 4 5 6 7 Ri Δi
X1 Час ознайомлення з 2 1 1 2 2 2 1 16
мовою програмування год
для розробки ПД
10 -4
X2 Час для розробки 2 2 3 3 2 3 2 9
год
інтерфейсу ПД 17 3
X3 Потенційний об’єм ПД Мб 2 3 2 2 2 1 3 1
15 1
Разом 6 6 6 6 6 6 6 42 0 26
Порахуємо коефіцієнт конкордації:

12 S 12∗26
W= 2 3
= 2 3
=1 , 06>W норм=0.67 ,
N ( n −n) 7 ∗(3 −3)
N
де N=7, n=3, S=∑ ❑ ∆2i =26

i=1
Ранжування можна вважати достовірним, тому що знайдений коефіцієнт

узгодженості перевищує нормативний, котрий дорівнює 0,67, отже можна
використовувати результати опитування експертів для наступних розрахунків,
попарне порівняння параметрів наведено у табл. 7.5.
Таблиця 7.5
Попарне порівняння параметрів
Експерти
Параметри Кінцева оцінка Числове значення
1 2 3 4 5 6 2
X1 і X2 > < < < > < < < 0.50
X1 і X3 > < < > > > < > 1.50
X2 і X3 > < > > > > < > 1.50
Розрахунок вагомості параметрів ПД для медичного працівника наведено

у табл. 7.6.
70
Таблиця 7.6
Розрахунок вагомості параметрів
Пара- Параметри Xj Перша ітерація Друга ітерація
метри Xi
X1 X2 X3
Х1 1 0.5 1,5 3 0.3 10.5 0.3088
Х2 0,5 1 1,5 3 0.3 10.5 0.3088
Х3 1,5 1,5 1 4 0.4 13 0.3812
Всього: 10 1 34 1
Відносні оцінки розраховуються декілька разів доти, поки наступні
значення не будуть незначно відрізнятися від попередніх (менше 2%), чого ми і
досягли.
7.5 Аналіз рівня якості варіантів реалізації функцій
Визначаємо рівень якості кожного варіанту виконання основних функцій

окремо.
Для визначення рівня якості кожного варіанту виконання окремо, спершу
з умови технічного завдання треба виключити варіант б з F2 та F3.
Бальна оцінка буде у шкалі значень від 0 до 10, де 10 – найкращий
показник, 5 – середній показник, 0 – найгірший показник, а також значення в
інтервалі між цими показниками (див. табл. 7.7).
Таблиця 7.7
Розрахунок показників рівня якості варіантів реалізації функцій ПД
Основн Варіант Пара Абсолютн Бальна Коефіцієнт Коефіцієнт
і реалізації - е значення оцінка вагомості рівня
функції функції метри параметра параметра параметра якості
А Х1 14 9 0,3088 2,7792
F1
Б Х1 17 5 0,3088 1,544
F2 А Х2 9 9 0,3088 2,7792
F3 А Х3 1700 7,5 0,3812 2,859
За даними з таблиці 7.7 за формулою визначаємо рівень якості кожного з

варіантів:
КК1 = 2.7792 + 2.7792 + 2.859 = 8.4174
КК2 = 1.544 + 2.7792 + 2.859 = 7.1822
71
Як видно з розрахунків, кращим є перший варіант, для якого коефіцієнт

технічного рівня має найбільше значення.
7.6 Економічний аналіз варіантів розробки ПП
Для визначення вартості розробки ПП спочатку проведемо розрахунок

трудомісткості. Усі варіанти мають наступні завдання:
1. Розробка front end частини ПП.
2. Розробка back end частини ПП.
Кожен із варіантів має два додаткових завдання, які представляють собою
варіації деталізованих програмних реалізацій. Нижче наведено ці завдання:
3.1. Створення дизайну веб інтерфейсу.
3.2. Розробка веб-сторінок.
4.1. Створення API.
4.2. Завантаження иа опрацювання бази даних ліків до ПП.
У варіанті 1 (F1а-F2а-F3а) присутні такі додаткові завдання: 3.1 та 4.1. У
варіанті 2 (F1б-F2а-F3а) присутні такі додаткові завдання: 3.2 та 4.2.
За ступенем новизни завдання під №1 та 4.2 відноситься до групи А,
завдання під № 2, 4.1 – до групи Б, 3.1, 3.2 – до групи В. За складністю
виконання завдання № 1, 4.1, 4.2 належить до групи 1, а завдання №2, 3.1, 3.2
належить до групи 2.
Перейдемо до розрахунків норм часу та трудомісткості на розробку
програмного додатку для медичного працівника за кожним із завдань.
Для першого завдання трудомісткість дорівнює Т Р = 55 людино-днів,
поправочний коефіцієнт, який враховує вид інформації (з БД) для першого
завдання КП = 1.42, поправочний коефіцієнт, який враховує складність
контролю вхідної та вихідної інформації для всіх завдань рівний К СК = 1,
коефіцієнт КСТ = 0.8. Тоді загальна трудомісткість виконання першого завдання
дорівнює:
Т1 = 55*1.42*1*0.8 = 62.48 людино-днів.
Проведемо аналогічні розрахунки для подальших завдань.
72
Для завдання 3.2 та 4.1 трудомісткість дорівнює ТР = 45 людино-днів та

35 людино-днів відповідно, а поправочні коефіцієнти К П = 0.60 та 1.01
відповідно, тоді загальна трудомісткість для цих завдань:
Т3.2 = 45*0.6*1*0.8 = 21.6 людино-днів.
Т4.1 = 35*1.01*1*0.8 = 28.28 людино-днів.
Аналогічно для другого завдання трудомісткість дорівнює Т Р = 50
людино-днів, поправочний коефіцієнт КП = 0.9, тобто:
Т2 = 50*0.9*1*0.8 = 36 людино-днів.
Для завдання 3.1 та 4.2 трудомісткість дорівнює Т Р = 10 людино-днів на
кожне завдання, а поправочні коефіцієнти КП = 0.6 та 1.42 відповідно, тоді
загальна трудомісткість для цих завдань:
Т3.1 = 10*0.6*1*0,8 = 4.8 людино-днів.
Т4.2 = 10*1.42*1*0,8 = 11.36 людино-днів.
Повна трудомісткість відповідних завдань для кожного з обраних
варіантів реалізації програми:
ТI = (Т1 + Т2 +Т3.2 + Т4.1) * 8 = (62.48 + 36 + 21.6 +28.28) * 8 = 1186.88 людино-
годин.
ТIІ = (Т1 +Т2 + Т3.1 + Т4.2) * 8 = (62.48 + 36 + 4.8 + 11.36) * 8 = 917.12 людино-
годин.
В розробці беруть участь full-stack програміст з окладом 25000 грн. та
один тестувальник програмних застосунків з окладом 17000 грн.
Тоді зарплата за годину:
М 25000+17000
С ч= = =125 грн
Tmt 2∗21∗8
Далі розглянемо заробітну плату в залежності від трудомісткості.

Заробітна плата розробників за варіантами становить:
I. СЗП = 125* 1186.88 * 1.2 = 178032 грн.
II. СЗП = 125* 917.12 * 1.2 = 137568 грн.
Відрахування на соціальний внесок становить 22%:
I. СВІД = СЗП * 0.22 = 178032 * 0.22 = 39167.04 грн.
II. СВІД = СЗП * 0.22 = 137568 * 0.22 = 30264.96 грн.
Так як одна ЕОМ обслуговує програміста з окладом 25000 грн., з
коефіцієнтом зайнятості 0,35, а друга ЕОМ тестувальника ПЗ з окладом 17000
грн, то для двох машин отримаємо:
73
СГ = 12 * 25000 * 0.35 + 12 * 17000 * 0,35 = 176400 грн.

З урахуванням додаткової заробітної плати:
СЗП =СГ * (1+ KЗ) = 118800 * (1 + 0.35) = 238140 грн.
Відрахування на соціальний внесок:
СВІД= СЗП * 0.22 = 238140 * 0,22 = 52390.8 грн.
Амортизаційні відрахування розраховуємо при амортизації 25% та
вартості ЕОМ – 47300 грн.
СА = КТМ * KА * ЦПР = 1.15 * 0.25 * 47300 = 13598,75 грн.,
де КТМ – коефіцієнт, який враховує витрати на транспортування та монтаж
приладу у користувача; KА– річна норма амортизації; ЦПР– договірна ціна
приладу.
Витрати на ремонт та профілактику розраховуємо як:
СР = КТМ * ЦПР * КР = 1.15 * 47300 * 0.05 = 2719,75 грн.,
Ефективний годинний фонд часу ПК за рік розраховуємо як:
ТЕФ =(ДК – ДВ – ДР) * tЗ * КВ = (365 – 106 – 10) * 8 * 0.9 = 1792.8 годин.
Накладні витрати розраховуємо за формулою:
СН = ЦПР * 0.67 = 47300 * 0.67 = 31691 грн.
Витрати на оплату електроенергії розраховуємо за формулою:
СЕЛ = ТЕФ * NС * KЗ * ЦЕН =1792.8 * 0.3 * 0.9 * 3.32 = 1607.066 грн.,
Тоді, річні експлуатаційні витрати будуть:
СЕКС =СЗП + СВІД + СА + СР+ СЕЛ + СН,
СЕКС= 238140 + 52390,8 + 13598,75 + 2719,75 + 1607,066 + 31691 = 340147.4 грн.
Собівартість однієї машино-години ЕОМ дорівнюватиме:
СМ-Г = СЕКС/ ТЕФ = 340147.4 /1792.8 = 189.7297 грн/год.
Оскільки в даному випадку всі роботи, які пов‘язані з розробкою
програмного продукту ведуться на ЕОМ, витрати на оплату машинного часу, в
залежності від обраного варіанта реалізації, складає:
І. СМ = СМ-Г⋅T1= 189.7297 * 1186.88 = 225186.4 грн.
ІІ. СМ = СМ-Г⋅T2= 189.7297 * 917.12 = 174004.9 грн.
Накладні витрати складають 67% від заробітної плати:
І. СН = СЗП * 0.67 = 225186.4 * 0.67 = 119281.4 грн.
ІІ. СН =СЗП * 0.67 = 174004.9 * 0.67 = 92170.56 грн.
Отже, вартість розробки ПП за варіантами становить:
СПП = СЗП+ СВІД+ СМ +СН,
І. СПП = 178032 + 39167,04 + 225186,4 + 119281,4 = 561666,8 грн.
ІІ. СПП = 137568 + 30264,96 + 174004,9 + 92170,56 = 434008.4 грн.
74
7.7 Вибір кращого варіанту ПП техніко-економічного рівня
Розрахуємо коефіцієнт техніко-економічного рівня за формулою:

КТЕР1 =ККj ⁄ СФj = 8.4174 / 561666.8 = 1.49 * 10-5,
КТЕР2 =ККj ⁄ СФj = 7.1822 / 434008.4 = 1.65 * 10-6.
За результатами проведеного функціонально-вартісного аналізу ПП для

пошуку ліків із урахуванням непереносимих компонентів пацієнтом, можна
зробити висновок, що після зменшення кількості варіантів можливих
реалізацій, найоптимальнішим виявився другий варіант з показником техніко-
економічного рівня якості КТЕР = 1.65 * 10-5.
Цей варіант реалізації програмного продукту має такі параметри:
● мова програмування для back end – Python;
● мова програмування для back end – JavaScript;
● фреймворк для створення GUI - ReactJS;
Розробка даного варіанту передбачає такі обов’язкові завдання як:
● Розробка back end частини програмного продукту;
● Розробка front end частини програмного продукту;
Даний варіант виконання програмного комплексу дає користувачу

зручний інтерфейс, непоганий функціонал і швидкодію.
75
ЗАГАЛЬНІ ВИСНОВКИ
Побічні реакції, які трапляються після прийому лікарських засобів,

посідають шосте місце в рейтингу причин смерті в світі.
Близько 40% побічних реакцій внаслідок прийому лікарських засобів в
українців класифікуються як реакції типу В (тобто тих, які не залежать від
дози), серед яких 5,5% - серйозні побічні реакції.
Помилки при виписуванні нетолерантних ліків пацієнтам лікарями
трапляються як через недоліки системи підготовки і удосконалення медичних
кадрів в галузі фармакотерапії, так і через несвоєчасне і недостатнє надання
медичним і фармацевтичним працівникам необхідної інформації про можливі
несприятливі побічні ефекти медикаментів. Лікарям складно орієнтуватися у
великій кількості поступаючих на фармацевтичний ринок ЛЗ і, відповідно, їх
уміння раціонально вибрати і грамотно призначити ЛЗ конкретному хворому,
тим паче, врахочуючи непереносимі компоненти пацієнтом,- не є досконалим.
Для покращення здатності лікарів підбирати медикаменти серед
величезної кількості медикаментів на ринку, при цьому мати можливість
вибору ліків враховуючи непереносимі компоненти пацієнтом, і було
запропоноване створення даного ПП. Результатами даної роботи є розроблена
API частина ПП, головною функцією якої є підбирання сприятливих
медикаментів, враховуючи персональну непереносимість певних компонентів
пацієнтом, також лікар має можливість вручну додати необхідні назви
компонентів для пошуку. API було виконано досить гнучко, при подальшому
створенні веб-застосунку розробник має можливість взаємодіяти із 23-ма
кінцевими точками, які надають можливість додавати, читати, видаляти,
змінювати дані про пацієнтів, непереносимі ними компоненти, виконувати ті ж
самі операції над сутностями медикаментаів, груп компонентів медикаментів та
власне над самими компонентами. Створений ПП надає можливість призвести
до зниження частоти помилок при виписуванні рецептів на ЛЗ лікарями.
76
СПИСОК ВИКОРИСТАННОЇ ЛІТЕРАТУРИ
1. Adkinson NF Jr. Immunogenicity and cross‐allergenicity of aztreonam. Am J

Med. 1990;88(3C):12S–5S.
2. Adkinson NF Jr. Risk factors for drug allergy. J Allergy Clin Immunol.
1984;74(4 Pt 2):567–72.
3. Atanasković‐Marković M, Gaeta F, Gavrović‐Jankulović M, Velicković TC,
Valluzzi RL, Romano A. Tolerability of imipenem in children with IgE‐
mediated hypersensitivity to penicillins. J Allergy Clin Immunol.
2009;124(1):167–9.
4. Barranco P, Lopez‐Serrano MC. General and epidemiological aspects of
allergic drug reactions. Clin Exp Allergy. 1998;28(Suppl 4):61–2.
5. CA Technologies. A Guide to REST and API Design. [Електронний ресурс].
– Режим доступу: https://docs.huihoo.com/api/A-Guide-to-REST-and-API-
Design.pdf.
6. Caubet JC, Kaiser L, Lemaitre B, Fellay B, Gervaix A, Eigenmann PA. The
role of penicillin in benign skin rashes in childhood: a prospective study based
on drug rechallenge. J Allergy Clin Immunol. 2011;127(1):218–22.
7. Classification of adverse drug reactions [Електронний ресурс]. - 03.20.2019.
– Режим доступу до ресурсу: https://derangedphysiology.com/main/cicm-
primary-exam/required-reading/variability-drug-response/Chapter%20320/
classification-adverse-drug-reactions.
8. David A. Khan, Aleena Banerji. Drug Allergy Testing. Pages 19-26. 2018. doi:
10.1016/B978-0-323-48551-7.00003-1. ISBN: 978-0-323-48551-7.
9. Dibbern DA, Montanaro A. Allergies to sulfonamide antibiotics and sulfur‐
containing drugs. Ann Allergy Asthma Immunol. 2008;100(2):91–100.
10.Ewan PW, Dugué P, Mirakian R, Dixon TA, Harper JN, Nasser SM, BSACI.
BSACI guidelines for the investigation of suspected anaphylaxis during
general anaesthesia. Clin Exp Allergy. 2010;40(1):15–31.
77
11.Frumin J, Gallagher JC. Allergic cross‐sensitivity between penicillin,

carbapenem, and monobactam antibiotics: what are the chances? Ann
Pharmacother. 2009;43(2):304–15.
12.Gell PGH, Coombs RRA. Clinical aspects of immunology. 3. Oxford:
Blackwell Scientific Publications; 1975.
13.Gurrieri C, Weingarten TN, Martin DP, Babovic N, Narr BJ, Sprung J,
Volcheck GW. Allergic reactions during anesthesia at a large United States
referral center. Anesth Analg. 2011;113(5):1202–12.
14.Harihara Subramanian, Pethuru Raj. Hands-On RESTful API Design Patterns
and Best Practices. 2019. ISBN 978-1-78899-266-4.
15.Kelkar PS, Li JT. Cephalosporin allergy. N Engl J Med. 2001;345(11):804–49.
16.Khan DA, Solensky R. Drug allergy. J Allergy Clin Immunol. 2010;125:S126–
37.
17.Lancet. 2000 Oct 7;356(9237):1255-9. doi: 10.1016/S0140-6736(00)02799-9.
Adverse drug reactions: definitions, diagnosis, and management.
18.Lisa B. Zaoutis, Vincent W. Chiang. Comprehensive Pediatric Hospital
Medicine. Pages 858-863. 2007. ISBN: 978-0-323-03004-5. DOI:
10.1016/B978-0-323-03004-5.X5001-7.
19.Miles Hacker, William Messer and Kenneth Bachmann. Pharmacology
Principles and Practice, 2006, doi: 10.1016/C2009-0-01474-3, ISBN: 978-0-
12-369521-5.
20.Picard M, Galvão VR. Current knowledge and management of hypersen‐
sitivity reactions to monoclonal antibodies. J Allergy Clin Immunol Pract.
2017;5(3):600–9.
21.Pichler WJ, Srinoulprasert Y, Yun J, Hausmann O. Multiple drug hypersensi‐
tivity. Int Arch Allergy Immunol. 2017;172(3):129–38.
22.МІНІСТЕРСТВО ОХОРОНИ ЗДОРОВ'Я УКРАЇНИ. Департамент
фармацевтичної діяльності. Державний експертний центр Міністерства
охорони здоров'я України. "Державний реєстр лікарських засобів
України". Інформаційний фонд. [Електронний ресурс]. – Режим доступу
до ресурсу: http://www.drlz.com.ua/ibp/ddsite.nsf/all/shlist?opendocument.
78
23.Pichler WJ. Delayed drug hypersensitivity reactions. Ann Intern

Med. 2003;139(8):683–693. doi: 10.7326/0003-4819-139-8-200310210-
00012.
24.Pirmohamed M, Park BK. Adverse drug reactions: back to the future. Br J Clin
Pharmacol. 2003;55(5):486–92.
25.Posadas SJ, Pichler WJ. Delayed drug hypersensitivity reactions: new
concepts. Clin Exp Allergy. 2007;37(7):989–999. doi: 10.1111/j.1365-
2222.2007.02742.x.
26.Richard Warrington. Drug allergy. September 2018. Allergy Asthma and
Clinical Immunology 14(S2). DOI:10.1186/s13223-018-0289-y.
27.Riedl MA, Castillas AM. Adverse drug reactions: types and treatment options.
Am Fam Physician. 2003;68(9):1781–1790.
28.Mirakian R, Ewan PW, Durham SR, Youlten LJ, Dugué P, Friedmann PS,
English JS, Huber PA, Nasser SM, BSACI. BSACI guidelines for the manage‐
ment of drug allergy. Clin Exp Allergy. 2009;39(1):43–61.
29.Rubio M, Bousquet PJ, Gomes E, Romano A, Demoly P. Results of drug
hypersensitivity evaluations in a large group of children and adults. Clin Exp
Allergy. 2012;42(1):123–30.
30.S G O Johansson, Thomas Bieber, Ronald Dahl, Peter S Friedmann, Bobby Q
Lanier, et al. Revised nomenclature for allergy for global use: Report of the
Nomenclature Review Committee of the World Allergy Organization. 2004
May;113(5):832-6. doi: 10.1016/j.jaci.2003.12.591. PMID: 15131563.
31.Saxon A, Adelman DC, Patel A, Hajdu R, Calandra GB. Imipenem cross‐
reactivity with penicillin in humans. J Allergy Clin Immunol. 1988;82(2):213–
7.
32.Saxon A, Hassner A, Swabb EA, Wheeler B, Adkinson NF Jr. Lack of cross‐
reactivity between aztreonam, a monobactam antibiotic, and penicillin in
penicillin‐allergic subjects. J Infect Dis. 1984;149(1):16–22.
33.Schnyder B. Approach to the patient with drug allergy. Immunol Allergy Clin
N Am. 2009;29(3):405–18.
79
34.Spencer Bos. Java Basics: What Is Spring Boot?August 5, 2020.

[Електронний ресурс]. – Режим доступу: https://www.jrebel.com/blog/what-
is-spring-boot.
35.The Apache Software Foundation. Welcome to Apache Maven. [Електронний
ресурс]. – Режим доступу: https://maven.apache.org/
36.Stephen Buxton, Lowell Fryman, Ralf Hartmut Güting, Terry Halpin, Jan L.
Harrington et al. Database Design. Know It All. - 2009. ISBN: 978-0-12-
374630-6
37.Strom BL, Schinnar R, Apter AJ, Margolis DJ, Lautenbach E, Hennessy S,
Bilker WB, Pettitt D. Absence of cross‐reactivity between sulfonamide
antibiotics and sulfonamide nonantibiotics. N Engl J Med.
2003;349(17):1628–35.
38.Sylvia LM. Drug allergy, pseudoallergy and cutaneous diseases. In: Tisdale JE,
Miller DA, editors. Drug‐induced diseases: prevention, detection, and
management. 2nd ed. Bethesda: American Society of Health ‐System
Pharmacists; 2010.
39.T R Einarson. Drug-related hospital admissions. Jul-Aug 1993;27(7-8):832-
840. PMID: 8364259 DOI: 10.1177/106002809302700702
40.The RapidAPI Blog. How to Build a Java RESTful API with Spring Boot.
[Електронний ресурс]. – Режим доступу: https://rapidapi.com/blog/how-to-
build-an-api-with-java/
41.Vervloet D, Durham S. Adverse reactions to drugs. BMJ.
1998;316(7143):1511–4.
42.Vultaggio A, Castells MC. Hypersensitivity reactions to biologic agents.
Immunol Allergy Clin North Am. 2014;34(3):615–32.
43.Zawodniak A, Lochmatter P, Beeler A, Pichler WJ. Cross ‐reactivity in drug
hypersensitivity reactions to sulfasalazine and sulfamethoxazole. Int Arch
Allergy Immunol. 2010;153(2):152–6.
44.Лизогуб В.Г., Богдан Т.В., Шараєва М.Л., Крайдашенко О.В., Волошина
О.О.. Національний медичний університет імені О.О. Богомольця.
Побічні дії лікарських засобів. Київ 2013.
80
45.О.В. Матвєєва, О.П. Вікторов, В.Є. Бліхар, В.П. Яйченя, І.О. Логвіна, ДП
«Державний експертний центр МОЗ України», м. Київ. Аналіз
спонтанних повідомлень про побічні реакції на лікарські засоби. Номер
статті: 4 (21)' 2011, с. 12-14.
46.Язык запросов SQL : Почему реляционная модель лучше [Електронний
ресурс]. – Режим доступу: http://www.sql-soft.ru/glava-01- pochemu-
reljacionnaja-model-luchshe.htm, вільний.
81
ДОДАТОК А
СХЕМА ТА ТЕСТОВІ ДАНІ БАЗИ ДАНИХ
Нижче наведено SQL скрипт для створення схеми БД.

create SCHEMA `drugs`;
create TABLE `drugs`.ìngredients` (

ìngredient_id` INT NOT NULL AUTO_INCREMENT,
ìngredient_name` VARCHAR(100) NOT NULL,
PRIMARY KEY (ìngredient_id`),
UNIQUE INDEX ìngredient_name_UNIQUE` (ìngredient_name` ASC) VISIBLE);
create TABLE `drugs`.`drugs` (

`drug_id` INT NOT NULL AUTO_INCREMENT,
`name` VARCHAR(200) NOT NULL,
àpplicant_details` VARCHAR(500) NULL,
`producer_details` VARCHAR(500) NULL,
`registration_certificate_number` VARCHAR(20) NULL,
àtc_code` VARCHAR(12) NOT NULL,
`compendium_url` VARCHAR(500) NULL,
èxpiration_date` VARCHAR(50) NULL,
ìnternational_name` VARCHAR(100) NULL,
`created` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
ùpdated` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
ON update CURRENT_TIMESTAMP,
PRIMARY KEY (`drug_id`),
UNIQUE INDEX `name_UNIQUE` (`name` ASC) VISIBLE);
create TABLE `drugs`.ìngredient_groups` (

`group_id` INT NOT NULL AUTO_INCREMENT,
`group_name` VARCHAR(200) NOT NULL,
ON update CURRENT_TIMESTAMP,
PRIMARY KEY (`group_id`),
UNIQUE INDEX `group_name_UNIQUE` (`group_name` ASC) VISIBLE);
create TABLE `drugs`.`patients` (

`patient_id` INT NOT NULL,
ON update CURRENT_TIMESTAMP);
CREATE TABLE `drugs`.`tolerance_finder` (

`run_id` INT NOT NULL AUTO_INCREMENT,
àtc_codes` VARCHAR(500) NOT NULL,
ìngredient_names` VARCHAR(500) NULL,
`run_status` VARCHAR(45) NOT NULL,
`patient_id` INT NULL,
ùpdated` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`run_id`),
UNIQUE INDEX `run_id_UNIQUE` (`run_id` ASC) VISIBLE,
FOREIGN KEY (`patient_id`) REFERENCES `drugs`.`patients`(`patient_id`));
create TABLE `drugs`.`patients_ingredients` (

`patient_id` INT NOT NULL,
ìngredient_id` INT NOT NULL,
FOREIGN KEY (ìngredient_id`) REFERENCES `drugs`.ìngredients`(ìngredient_id`),
FOREIGN KEY (`patient_id`) REFERENCES `drugs`.`patients`(`patient_id`)
);
create TABLE `drugs`.ìngredients_group_belonging` (

`group_id` INT NOT NULL,
82
FOREIGN KEY (`group_id`) REFERENCES `drugs`.ìngredient_groups`(`group_id`)
);
create TABLE `drugs`.`drugs_ingredients` (

`drug_id` INT NOT NULL,
FOREIGN KEY (`drug_id`) REFERENCES `drugs`.`drugs`(`drug_id`)
);
Нижче наведено SQL скрипт для заповнення таблиць схеми БД
тестовими даними.
use drugs;
insert into ingredients values

(1, "acetylsalicylic", DEFAULT),
(2, "phenacetin", DEFAULT),
(3, "caffeine", DEFAULT),
(4, "cocoa", DEFAULT),
(5, "citric acid", DEFAULT),
(6, "paracetamol", DEFAULT),
(7, "diclofenac sodium", DEFAULT),
(8, "benzylpenicillin", DEFAULT),
(9, "aminopenicillins", DEFAULT),
(10, "mezlocillin", DEFAULT);
insert into patients values

(1, DEFAULT, DEFAULT),
(2, DEFAULT, DEFAULT),
(3, DEFAULT, DEFAULT);
insert into patients_ingredients values

(1, 3),
(1, 4),
(2, 6);
insert into drugs values

(1, "Citramon",
"Alvogen IPKo S.r.l, 5, Rue Heinhaff, L-1736, Senningerberg, Luxembourg", "S. A. FARMATEN (first and second pakuvannya,
control of the series, approval for the release of the series), 6, Dervenakion, Pallini Attiki 15351, Grecia",
"UA/15524/02/02", "N02B A51",
"https://compendium.com.ua/dec/261896/", "",
"Voriconazole", DEFAULT, DEFAULT),
(2, "Phenergan",
"Kusum Helthker Pvt Ltd, India", "KUSUM HELTHKER PVT LTD, India",
"UA/15524/02/02", "M01A B55",
"https://compendium.com.ua/info/6905/fanigan/", "unlimited from 15.12.2016",
"", DEFAULT, DEFAULT);
insert into drugs_ingredients values

(1, 1),
(1, 2),
(1, 3),
(1, 4),
(1, 5),
(2, 6),
(2, 7);
insert into ingredient_groups values(1, "Penicillins", DEFAULT, DEFAULT);

insert into ingredients_group_belonging values
(1,8),
(1,9),
(1,10);

Звіт ПП - БС-72 - Гупало - 21

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Звіт ПП - БС-72 - Гупало - 21

Uploaded by

Copyright:

Available Formats

НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ УКРАЇНИ

«КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ

________________кафедра БІОМЕДИЧНОЇ КІБЕРНЕТИКИ________________

спеціальності 122 Комп’ютерні науки

спеціалізації Інформаційні технології в біології та медицині

За темою: Інформаційна система з вибору ліків із урахуванням

Виконав: студент ІV курсу, групи __БС-72__

Гупало Микита Сергійович

Керівники практики __ст.викл. каф БМК АВЕРЬЯНОВА. О.А._ ______

Керівник ДР _к.т.н., доц. каф БМК О.К. НОСОВЕЦЬ_ ______

Засвідчую, що у звіті немає запозичень з

Київ – 2021 рік

Факультет БІОМЕДИЧНОЇ ІНЖЕНЕРІЇ

Кафедра БІОМЕДИЧНОЇ КІБЕРНЕТИКИ

Рівень вищої освіти – перший (бакалаврський) за освітньо-професійною програмою

Гупало Микиті Сергійовичу

1. Тема практики Інформаційна система з вибору ліків із урахуванням

затверджені засіданням кафедри БМК від «01» квітня 2021 р. №17

4. Зміст роботи 1) Аналіз предметної області та висвітлення

7. Консультанти розділів роботи1*

Студент М.С. Гупало

Керівник роботи О.К. Носовець

1. «Переддипломна практика» (практика) є частиною циклу нормативних дисциплін

1. "Pre-diploma practice" (practice) is part of a series of normative disciplines OOP bachelor

ПЕРЕЛІК УМОВНИХ СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ 8

РОЗДІЛ 1 ТЕОРЕТИЧНА ЧАСТИНА 12

РОЗДІЛ 2 МАТЕРІАЛИ ДОСЛІДЖЕНЬ 24

4.2.2 Загальні принципи проектування API 38

РОЗДІЛ 6 ОХОРОНА ПРАЦІ 53

РОЗДІЛ 7 РОЗРАХУНОК ЕКОНОМІЧНОГО ЕФЕКТУ 62

СПИСОК ВИКОРИСТАННОЇ ЛІТЕРАТУРИ 74

ДОДАТОК А СХЕМА ТА ТЕСТОВІ ДАНІ БАЗИ ДАНИХ 79

ПЕРЕЛІК УМОВНИХ СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ

CSS - Cascading Style Sheets (каскадні таблиці стилів) - спеціальна мова,

Побічні реакції на лікарські засоби являють собою четверту провідну

Алергія на ЛЗ впливає не тільки на якість життя пацієнта, але може також

1.1 Поняття побічної реакції на ЛЗ

Побічна реакція на лікарський засіб - помітно шкідлива або неприємна

Дана робота спрямована на зниження кількості випадків виникнення

особливості метаболізму людини. Крім того, місцевий, внутрішньом’язовий та

● Фактор віку (молоді та люди середнього віку мають більший ризик,

ніж немовлята та люди похилого віку).

● Фактор статі (жінки мають більший ризик розвитку алергії на ЛЗ,

● Фактор генетики (генетичних поліморфізімів).

● Фактор хвороби вірусними інфекціями (ВІЛ, віруси герпесу).

● Фактор попередньої несприятливої реакції на препарат.

Фактори, пов’язані з медикаментами:

● Фактор більш імуногенних препаратів (високомолекулярні сполуки

● Фактор способу прийому ЛЗ (місцевий спосіб прийому є більш

ризикованим, ніж внутрішньом’язовий спосіб прийому;

● Фактор дозування (частий або тривалий прийом є більш

ризикованим, ніж разова прийом).

системних симптомів (DRESS), сироваткова хвороба, системний червоний

Стівенса – втома, ураження очей. кортикостероїди,

Продовження табл. 1.2

еозинофілією декількох проявів: шкірний сульфаніламіди, міноциклін,

покоління також підлягають розгляду, оскільки виявлено, що ступінь

кишечнику стає сульфапіридином, набуваючи властивості імуногенної

такими як астма, риніт та синусит, можуть реагувати на АСК та НПЗП,

гіперактивації імунної системи за допомогою кортикостероїдної терапії

У теоретичному розділі були розглянуті питання про побічні реакції на

2.1 Дані для дослідження

Повний перелік лікарських засобів, які будуть використовуватися для

кафедра БІОМЕДИЧНОЇ КІБЕРНЕТИКИ

Виконав: студент ІV курсу, групи БС-72