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

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

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

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

(повна назва кафедри)

«До захисту допущено»

Завідувач кафедри БМК
________ __Євген НАСТЕНКО_
(підпис) (ініціали, прізвище)

“___”__червня___2021 р.

Дипломна робота
на здобуття ступеня бакалавра
за освітньо-професійною
програмою Комп'ютерні технології в біології та медицині
зі спеціальності 122 Комп'ютерні науки
ті (код і назва)

на тему: Універсальна програмна оболонка системи підтримки

прийняття діагностичних рішень при дифузних захворюваннях печінки.
Виконав: студент ІV курсу, групи __БС-73__
(шифр групи)

ДУБОВИК ДАНИЛО ІГОРОВИЧ

(прізвище, ім’я, по батькові) (підпис)

Керівник доц. каф.БМК, доц.., к.т.н.

Павлов Володимир Анатолійович
(посада, науковий ступінь, вчене звання, прізвище та ініціали) (підпис)

Консультант з
розділів ДР
(назва розділу) ( посада, вчене звання, науковий ступінь, прізвище, ініціали) (підпис)

Рецензент

(посада, науковий ступінь, вчене звання, науковий ступінь, прізвище та ініціали) (підпис)

Засвідчую, що у цій дипломній роботі

немає запозичень з праць інших авторів
без відповідних посилань.
Студент _____________
(підпис)

Київ – 2021 року

Нормо контролер Галина КОРНІЄНКО
 Національний технічний університет України
«Київський політехнічний інститут імені Ігоря Сікорського»

Інститут (факультет) БІОМЕДИЧНОЇ ІНЖЕНЕРІЇ

(повна назва)

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

(повна назва)

Рівень вищої освіти – перший (бакалаврський)

Спеціальність 122 Комп'ютерні науки
Освітньо-професійна програма Комп'ютерні технології в біології та медицині
(код і назва)

ЗАТВЕРДЖУЮ
Завідувач кафедри БМК
__________ Євген НАСТЕНКО
(підпис) (власне ім’я, прізвище)

«24»__травня_2021 р.

ЗАВДАННЯ
на дипломну роботу студенту

ДУБОВИК ДАНИЛО ІГОРОВИЧ

(прізвище, ім’я, по батькові)

1. Тема роботи Універсальна програмна оболонка системи

підтримки прийняття діагностичних рішень при дифузних
захворюваннях печінки
Керівник роботи Павлов Володимир Анатолійович, доц. каф. БМК
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)

затверджені наказом по університету від «27 » травня 2021 р. № 1361-с

2. Термін подання студентом роботи 1-4 червня 2021 року

3. Вихідні дані до роботи УЗД знімки здорової печінки, а також з
наявними патологіями.
4. Зміст роботи 1. Розробка архітектури для універсальної
програмної оболонки та вибір технологій.
2. Розробка частини для реєстрації, збереження та модифікації даних
пацієнта.
3. Розробка частини для збереження, модифікації, сегментації та аналізу
знімків.
4. Розробка реєстрації та входу лікаря для додатку. Налаштування серверу
для розгортання додатку
5. Перелік ілюстративного матеріалу (із зазначенням плакатів, презентацій тощо)
1 презентація, 11 ілюстрацій

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

Підпис, дата
Прізвище, ініціали та посада
Розділ завдання завдання
консультанта
видав прийняв
Дипломна робота

7. Дата видачі завдання 05 квітня 2021 р.

Календарний план
№ Назва етапів виконання Термін виконання
Примітка
з/п дипломної роботи етапів роботи
1 Отримати завдання на ДР 05 квітня 2021р.
2 Розділ ДР ВСТУП, Літературний огляд. 15 травня 2021 р.
3 Розділ ДР Основна частина (Теоретична). 15 травня 2021 р.
4 Розділ ДР Основна частина (Аналітична). 24 травня 2021 р.
5 Розділ ДР Основна частина (Практична).
До 01 червня 2021 р.
ВИСНОВКИ. ДОДАТКИ
6 Подання роботи керівнику ДР До 01 червня 2021р.
7 Проходження нормоконтролю по
1-3 червня 2021р
оформленню ДР
8 Перевірка роботи на плагіат (UNICHEK) 4-5 червня 2020р
9 Отримати допуск до захисту ДР (від кафедри) 07 червня 2021р.
10 Подання ДР рецензенту. Отримання рецензії. 8-11 червня 2021р
11 Подання в електронному вигляді ДР та
11 червня 2021р
анотації до неї на сайт кафедри.
12 Підготовка супровідної документації,
До 10 червня 2021 р.
Презентація.
13 Подання пакету документів по ДР до захисту
11-12 червня 2021р.
в ЕК2
14 Захист ДР в ЕК 14-22 червня 2010р

Студент Данило ДУБОВИК

(підпис) (власне ім’я, прізвище)

Керівник роботи Володимир ПАВЛОВ

(підпис) (власне ім’я, прізвище)

1* Консультантом не може бути зазначено керівника ДР.

2 не пізніше ніж за один тиждень до затвердженої дати захисту ДР в ЕК
 4

АНОТАЦІЯ

Структура та обсяг роботи: пояснювальна записка складається із

вступу, шести розділів, висновків, списку використаної літератури із 16
джерел. Загальний обсяг дипломної роботи складає: 67 сторінок, ілюстрацій
– 52, таблиць – 33.
Метою роботи є спрощення прийняття діагностичних рішень при
дифузних захворюваннях печінки.
Завдання:
1) обрати технології для створення веб-додатку та пояснити їх вибір;
2) розробити базу даних;
3) розробити серверну частину;
4) розробити клієнтську частину;
5) провести тестування додатку.
Розробка була здійснена засобами мов програмування Golang з
бібліотекою Echo та TypeScript з бібліотекою React.
Проект розроблено на замовлення ДУ «Інститут ядерної медицини та
променевої діагностики НАМН України» (ДУ «ІЯМПД») та буде
впроваджений у використання 17 травня 2021 р. (акт впровадження від 17
травня 2021 р.)
Ключові слова: печінка, веб-додаток, TypeScript, Golang, React, Echo.
 5

ABSTRACT

The total volume of the explanatory note is 67 pages, the number of sections
6 , the number of drawings - 52, the number of tables - 33.
The aim of the work is to simplify decision-making in diffuse liver disease .
Task:
1) choose technologies for creating a web application and explain their
choice;
2) develop database;
3) develop server part of application;
4) develop client part of application;
5) to test the application;
Development was developed using Golang with Echo library and
TypeScript with React library.
The project is developed by order of SI "Institute of Nuclear Medicine and
Radiation Diagnostics of the National Academy of Medical Sciences of Ukraine"
(SI "IAMPD") and will be implemented for use on May 10, 2021 (implementation
act from May 10, 2021).
Key words: liver, web-application , TypeScript, Golang, React, Echo.
 6

ЗМІСТ

ВСТУП 8
РОЗДІЛ 1 ЛІТЕРАТУРНИЙ ОГЛЯД 9
1.1 Загальні відомості 9
1.2 Моделі зображень 11
1.3 B-режим 13
1.4 Доплерівське УЗД 15
1.5 Фіброз та цироз 18
Висновки до розділу 1 22
РОЗДІЛ 2 ТЕОРЕТИЧНА ЧАСТИНА 24
2.1 Загальні відомості 24
2.2 База даних 24
2.3 Серверна частина веб-додатку 25
2.4 Клієнтська частина веб-додатку 26
2.5 Автентифікація у веб-додатку 30
Висновки до розділу 2 34
РОЗДІЛ 3 АНАЛІТИЧНА ЧАСТИНА 35
3.1 Функціональні вимоги 35
3.1.1 Створення нового об'єкту типу “Лікар” 35
3.1.2 Створення нового об'єкту типу “Пацієнт” 35
3.1.3 Редагування об'єкту типу “Пацієнт” 36
3.1.4 Видалення об'єкту типу “Пацієнт” 37
3.1.5 Створення нового об'єкту типу “Аналіз” 37
3.1.6 Створення нового об'єкту типу “Знімок” 38
3.1.7 Видалення об'єкту типу “Знімок” 39
3.1.8 Виділення та збереження області інтересу на знімку 39
3.1.9 Відображення об’єктів типу “Пацієнт” 40
3.1.10 Відображення об’єкту типу “Пацієнт” 41
3.1.11 Відображення об’єктів типу “Аналіз” 41
3.1.12 Відображення об’єктів типу “Знімок” 42
3.2 Проектування бази даних 42
Висновки до розділу 3 48
РОЗДІЛ 4 ПРАКТИЧНА РЕАЛІЗАЦІЯ 49
 7

4.1 Розробка серверної частини веб-додатку 49

4.1.1 Функція створення лікаря 49
4.1.2 Функція отримання даних лікаря 49
4.1.3 Функція створення пацієнта 50
4.1.4 Функція редагування пацієнта 50
4.1.5 Функція видалення пацієнта 51
4.1.6 Функція отримання пацієнтів лікаря 51
4.1.7 Функція отримання даних певного пацієнта 52
4.1.8 Функція створення аналізу пацієнта 52
4.1.9 Функція отримання аналізів пацієнта 53
4.1.10 Функція отримання даних про знімок 53
4.1.11 Функція створення завантаження знімку 54
4.1.12 Функція отримання знімків пацієнта 54
4.1.13 Функція отримання всіх знімків 55
4.2 Розробка клієнтської частини веб-додатку 56
4.2.1 Реєстрація лікаря 56
4.2.2 Реєстрація нового пацієнта 58
4.2.3 Сторінка пацієнта 59
4.2.4 Додавання аналізу 59
4.2.5 Збереження зображення 60
4.2.6 Виділення області інтересу на зображені 61
4.2.5 Аналіз зображення 62
Висновки до розділу 4 63
ЗАГАЛЬНІ ВИСНОВКИ 64
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 65
 ВСТУП

Приблизно 1 з 10 дорослих людей у світі має проблеми з печінкою.

Серед них: гепатит, гепатит, цироз, рак тощо. Це серйозні захворювання,
які потрібно діагностувати на ранніх термінах. В даний час УЗД є
найпоширенішим методом діагностики інвазійних захворювань печінки.
Однак є серйозні недоліки. Як правило, точність діагностики не перевищує
80%, використання процедур біопсії може підвищити точність. Це
агресивний метод дослідження, який збирає тканини з організму протягом
життєвих процесів. Цей метод є травматичним і вимагає від пацієнта
відновлення. Це може спричинити усёкладнення від 1% до 20% та від 0,1%
до 2% смертей. Тому пошук нових і старих, вдосконалених діагностичних
засобів, які не потребують хірургічного втручання, є предметом
подальших досліджень.
Актуальність роботи полягає у розробці веб-додатку для спрощення,
підвищення точності та прискорення прийняття рішень лікарем щодо
хвороб печінки.
Об’єкт дослідження в нашому випадку є УЗД знімки здорової
печінки, а також з наявними патологіями.
Задачі для вирішення:
1. Обрати технології для створення веб-додатку та пояснити їх вибір;
2. Розробити базу даних;
3. Розробити серверну частину;
4. Розробити клієнтську частину;
5. Провести тестування додатку;
 9

РОЗДІЛ 1
ЛІТЕРАТУРНИЙ ОГЛЯД

1.1 Загальні відомості

Ультразвук (УЗД) відіграє важливу роль у діагностиці та лікуванні

хронічних захворювань печінки шляхом надання діагностичної та
прогностичної інформації, а також виявлення ускладнень, таких як ННС та
портальна гіпертензія. Хоча звичайне ультразвукове дослідження є цінним
для оцінки паренхіми печінки та виявлення уражень печінки, був
розроблений цілий ряд інших американських методик, які збільшують його
потенційне значення.
Цироз печінки - це кінцева стадія хронічного захворювання печінки.
Це спричинено дифузним фіброзом та регенеруючими вузликами, що
виникають внаслідок повторного некрозу клітин печінки та дегенерації. Це
визнано незворотною формою паренхіматозного фіброзу. Цироз печінки
зменшує печінкову функцію і призводить до численних ускладнень,
викликаних вузловою регенерацією та портальною гіпертензією,
включаючи асцит, варикозну кровотечу, ниркову недостатність через
гепаторенальний синдром, печінкову енцефалопатію та спонтанний
бактеріальний перитоніт. Крім того, різко збільшується частота розвитку
гепатоцелюлярної карциноми. Нещодавно було показано, що ранній цироз
печінки поліпшується регресією колагенової тканини [3]. Регресія, як
правило, пов'язана з поліпшенням клінічного статусу, але може варіювати
за ступенем поліпшення, залежно від оборотності ураження печінки.
Великі рубці з деструкцією паренхіми навряд чи регресують. Тому рання
діагностика цирозу печінки та кількісне визначення частки фіброзу в
печінці дуже важливі для лікування хронічних захворювань печінки.
Прогнозування та лікування хронічних захворювань печінки сильно
залежить від кількості та прогресування фіброзу печінки.
 10

Основна візуалізаційна діагностика цирозу печінки була розроблена

за останні кілька десятиліть, що дозволило на ранніх термінах виявити
морфологічні зміни печінки за допомогою ультрасонографії (УЗД),
комп’ютерної томографії (КТ) та магнітно-резонансної томографії (МРТ).
Ці методи є точними для діагностики запущеного цирозу печінки. Однак,
оскільки морфологічні зміни вказують на поширений цироз, існують
обмеження щодо ранньої діагностики цирозу печінки за допомогою
візуалізації. Для полегшення ранньої діагностики цирозу печінки були
розроблені аналіз текстури та еластографія для вимірювання ригідності
печінки та перфузійні дослідження для визначення обсягу кровотоку, часу
транзиту та швидкості.
Хронічна хвороба печінки є основним розладом у всьому світі.
Краще розуміння анатомії, кровотоку та патофізіології може бути
ключовим питанням для належного управління ними. УЗД - простий та
неінвазивний діагностичний засіб у черевній області. Доплерівський
режим пропонує оцінку гемодинаміки в режимі реального часу, а показник
контрастності США є одним із найбільш часто використовуваних методів
детальної оцінки. Подальший розвиток цифрових технологій дозволяє
тривимірну (3D) візуалізацію цільових зображень з високою роздільною
здатністю. У цій статті розглядається широкий спектр застосування в
черевній порожнині та описується останній прогрес у діагностиці
хронічних захворювань печінки.
З урахуванням різних спектрів етіології поширеність хронічних
захворювань печінки зростає у всьому світі [3]. Цироз є найбільш
запущеною стадією хронічного захворювання печінки. Це пов’язано з
можливими несприятливими явищами, такими як варикозне розширення
шлунково-стравохідної системи, асцит, печінкова енцефалопатія та
розвиток гепатоцелюлярної карциноми (ГЦК), що вимагає ретельної
медичної допомоги [2-4].
 11

Через переваги простих та менш інвазивних оцінок, УЗД може бути

найбільш часто використовуваним засобом візуалізації при практичному
лікуванні пацієнтів із хронічними захворюваннями печінки. На додаток до
зображення в режимі B, нещодавній розвиток цифрових технологій
представив різні режими, кольоровий / енергетичний доплерівський
режим, гармонічну візуалізацію як контрастний режим на основі
мікропухирців та тривимірний (3D) режим [5-7]. З огляду на ці
передумови, ця оглядова стаття описує останні досягнення США у
діагностиці хронічних захворювань печінки.

1.2 Моделі зображень

Класична роль багатьох методів візуалізації в діагностиці цирозу

печінки полягає у виявленні морфологічних змін у печінці. Циротична
печінка демонструє вузловий печінковий контур, зміни в розподілі обсягу,
включаючи збільшену хвостату частку та бічний сегмент лівої частки,
атрофію медіальних сегментів правої та лівої частки, розширення тріщин
та ворота гепатису та регенеративні вузлики (рис. 1.1).
Можуть спостерігатися вторинні висновки, пов’язані з портальною
гіпертензією, включаючи варикоз, асцит, спленомегалію, жирову
інфільтрацію в сальнику та брижу, потовщення набряклої стінки
шлунково-кишкового тракту внаслідок венозної перевантаженості та
внутрішньопечінкові артеріопортальні або артеріовенозні шунти (рис.1.2).
 12

Рисунок 1.1. Зображення фази портальної комп’ютерної томографії на

контрастній основі у пацієнта з цирозом печінки через хронічний гепатит

Рисунок 1.2. Зображення цирозу печінки, викликаного хронічним

гепатитом.
 13

УЗД є безпечним і відносно недорогим засобом візуалізації, що

дозволяє проводити щорічні або дворічні тести у хворих на хронічний
гепатит. Первинні дані про фіброз печінки за УЗД подібні до простого
гепатостеатозу [10]. Фіброз печінкової паренхіми послаблює проникнення
пучка, підвищує ехогенність паренхіми та зменшує судинну помітність.
Цироз печінки характеризується змінами в розподілі об'єму печінки,
поверхневою вузликовістю, акцентуацією тріщини, неоднорідністю,
яскравим та грубим печінковою архітектурою, циротичними вузлами,
включаючи регенеративні та диспластичні вузли, та ознаками портальної
гіпертензії. Дослідження показали загальну чутливість до хронічних
захворювань печінки 65% -95%, при позитивному прогнозному значенні
98% [11-13]. Найбільш показовою знахідкою цирозу печінки була вузлова
поверхня, яка була більш чутливою на нижній поверхні печінки, ніж
верхня поверхня (86% проти 53%) (рис. 1.3). Він також був більш
чутливим у високочастотному зонді [11-13]. Хоча будь-яка окрема
характеристика США мала обмежену чутливість або специфічність при
виявленні цирозу, поліпшення можна було досягти поєднанням двох або
трьох параметрів.

Рисунок 1.3. Вузлова поверхня під час цирозу печінки.

1.3 B-режим
 14

Нещодавні цифрові розробки показали покращення просторової

роздільної здатності та відношення сигнал / шум B-режиму, який є єдиним
зображенням, що демонструє основні зображення тканин. Роль простої
техніки при хронічних захворюваннях печінки полягає у виявленні цирозу,
вимірюванні діаметра (тобто печінки, селезінки та судин) та виявленні
асциту, колатеральних судин та вогнищевих уражень печінки [8-10].
М’язи - ще одна мета В-режиму США. Кількісна оцінка м’язової
маси є важливим питанням догляду за пацієнтами, оскільки вона тісно
пов’язана з недоїданням, що призводить до зниження якості життя,
пов’язаного зі здоров’ям [11,12]. Саркопенія визначається значним
зменшенням м’язової маси та / або сили і широко прийнята як загальне
порушення при цирозі [13,14]. Це важливий фактор для поганого прогнозу,
для прогнозування результату у пацієнтів з HCC та для розвитку
ускладнень після операції на печінці або трансплантації печінки [11].
Дослідження, засноване на В-режимі УЗ, повідомило, що виявляемость
клубово-м’язового м’яза (ІП) становила 100% як у контрольній групі
(глибина 31,7–61,2 мм; середнє ± стандартне відхилення, 45,8 ± 7,7), так і в
групі цирозу ( 20,6–75,4 мм; 43,7 ± 9,2) (рис. 1.4). Чутливість,
специфічність та площа під робочою характеристикою приймача (AUROC)
за індексом IP (площа IP / висота2, мм2 / м2), розрахована США для
виявлення втрати м’язової маси, діагностованої за допомогою
комп’ютерної томографії (КТ) з використанням індексу скелетних м’язів
на рівні L3 становили 79,5%, 73,1% та 0,835 відповідно з найкращим
граничним значенням 189,2 для чоловіків та 84,6%, 78,8% та 0,874
відповідно, з найкращим граничним значенням 180,6 для жінок [18] .
Таким чином, індекс ІР, отриманий через черезшкірний УЗД, може бути
альтернативою КТ кількісної оцінки м’язової маси при цирозі, не
вимагаючи радіаційного опромінення.
 15

Рисунок 1.4. Приклад знімку з цирозом у 84х річної жінки.

Недавній розвиток цифрових технологій призвів до демонстрації 3D

сонограми поверхні печінки з висококваліфікованими зображеннями в
режимі реального часу; 74% (23/31) показників успішності візуалізації, що
демонструє характерну нерівність печінкової поверхні у всіх хворих на
цироз печінки, а домовленості між операторами та операторами та
інтерв'юерами були чудовими (к = 1,0) [11]. Здатність відрізнити
циротичну печінку від нециротичної печінки покращилася завдяки
використанню комбінації 2D- та 3D-зображень порівняно з 2D-
зображеннями (чутливість, P = 0,02; точність, P = 0,02) або лише 3D-
зображення (чутливість, Р = 0,03). Таким чином, сонографія на основі 3D
може виступати як віртуальний метод лапароскопії з потенціалом для
поліпшення діагностики цирозу.

1.4 Доплерівське УЗД

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

печінковий кровотік. У минулому було проведено кілька досліджень
корисності доплерівського ультразвуку як неінвазивного методу оцінки
ступеня фіброзу печінки. Теоретичною основою є гемодинамічні зміни
 16

печінки під час прогресування від гепатиту до фіброзу та цирозу. Однак

відтворюваність доплерівських індексів була поганою, і кореляція між
показниками та стадією захворювання невідома. У добре стратифікованій
когорті з 65 пацієнтів із підтвердженою біопсією захворюваннями печінки,
пов’язаними з біопсією, проспективно досліджували різні індекси
печінкових судин, включаючи швидкість печінкової артерії та резистивний
індекс печінкової артерії, швидкість ворітної вени, діаметр та окружну
вену, застійні явища ворітної вени. індекс та відношення швидкості руху
печінкова артерія – ворітна вена [46]. Менш ніж у половини пацієнтів у
цьому дослідженні можна було отримати відтворювані та точні сліди
печінкової артерії та похідні показники, а менш ніж у третини пацієнтів
можна було визначити точну окружність ворітної вени. Швидкість ворітної
вени можна було виміряти у 62 пацієнтів, але середні значення були майже
однаковими для різних ступенів гепатиту та цирозу. В цілому не
спостерігалось суттєвих відмінностей у показниках Доплера із
збільшенням тяжкості захворювання печінки. Автори приходять до
висновку, що похідні доплерівського аналізу важко відтворювати надійно,
і тому мають обмежену клінічну цінність при оцінці фіброзу печінки або
запалення.
Форми сигналів печінкової вени використовувались для
прогнозування цирозу з тенденцією до того, що форма сигналу буде
двофазною або монофазною при цирозі порівняно з трифазною у
звичайних випадках. Нещодавно форми печінкової вени були повторно
оцінені у серії із 120 пацієнтів з цирозом із широким спектром причин.
Плоскі форми хвиль спостерігались лише у 3% випадків; в іншому випадку
форми хвиль були дво- та трифазними. Не було виявлено кореляції між
дисфункцією печінки та характеристикою форм печінкових вен [12].
Варіабельність венозних форм хвиль зазвичай зустрічається в клінічній
практиці.
 17

Основна роль доплерівського ультразвуку - оцінка портальної

венозної гіпертензії як ускладнення цирозу. Доплерівське ультразвукове
дослідження зв’язок (рис. 1.5), що показує гепатофугальний венозний
сигнал (тобто патентна параумбіляльна вена) та гепатофугальний потік у
ворітній вені, є специфічними ознаками та мають високе позитивне
прогностичне значення на наявність портальної гіпертензії [48,49 ].

Рисунок 1.5. Реканалізація парамбілікальної вени, як показано венозною.

Швидкість ворітної вени як маркер портальної

гіпертензії була оцінена в дослідженні 118 пацієнтів і
виявлена дуже мінливою, коливаючись від 7 до 83 см /
с. Лише 2,6% пацієнтів у цій серії мали швидкість ≤10
см / с (поріг, запропонований Золі [8]), а 6,1% -
швидкість ≤11 см / с [8]. Отже, низька швидкість
ворітної вени не є дуже корисним ознакою портальної
гіпертензії. Співвідношення діаметра ворітної вени в
поперечному перерізі та швидкості ворітної вени, що
називається «індексом застійних явищ» [8] було
запропоновано як маркер портальної гіпертензії на
 18

основі тенденції до збільшення діаметра ворітної вени

та швидкості зменшення. Як індекс він широко не
використовується частково, оскільки вимірювання
обох параметрів індексу є дуже змінним [8].
Оцінка структури портального венозного потоку також є цінною для
діагностики портальної гіпертензії. Нормальний портальний венозний
потік безперервний і гепатопетальний на доплерівському УЗД з
мінімальними варіаціями внаслідок серцевого циклу та дихання.
Зворотний (гепатофугальний) портальний венозний кровотік може бути
наявним, коли внутрішньопечінковий опір більший, ніж опір
портосистемних колатералів. Безперервний гепатофугальний потік
присутній у 8,3% пацієнтів з цирозом [12] та асоційованим з
портосистемними шунтами [12].
Значення діаметра лівої шлункової вени незрозуміле. Хоч була
визначена певна кореляція із варикозною кровотечею [12], інші виявили,
що розширення лівої шлункової вени не є необхідним для виникнення
кровотечі з варикозного розширення [12].
У більш недавньому дослідженні діаметр лівої шлункової вени
більше 6 мм був виявлений у 58% пацієнтів із нещодавнім кровоточивим
варикозом та у 12% пацієнтів без нещодавнього кровоточивого варикозу;
однак ця різниця не була статистично значущою [4].

1.5 Фіброз та цироз

Паренхіматозна структура печінки - це дещо суб’єктивна

характеристика, яка має низьку чутливість для виявлення цирозу.
Нещодавнє ретроспективне дослідження точності звичайних УЗ при
постановці фіброзу показало, що звичайні УЗД не є точним предиктором ні
для раннього, ні для значного фіброзу при хронічному вірусному гепатиті
[16]. Однак у серії із 103 пацієнтів із хронічними захворюваннями печінки
 19

було показано, що паренхіматозна структура печінки (класифікована як

дрібна ехотекстура, м'яко груба, груба і дуже груба) має статистично
значущу кореляцію (rs = 0,8853) зі ступенем фіброзу [15]. У поєднанні з ще
двома ознаками (вузликовість поверхні печінки та край печінки) кореляція
зі ступенем фіброзу зросла до rs = 0,9524. У порівнянні з ехотекстурою,
вузликовість поверхні печінки (рис.1.5) має кращу точність щодо наявності
цирозу [8-11], що досягає як чутливості, так і специфічності 0,88. Для
забезпечення інтерфейсу рідина-тканина для оптимальної оцінки повинен
бути присутній асцит. Як тільки асцит присутній, цироз, як правило, є
більш розвиненим і менш діагностичним завданням
Іншим підходом є використання просвіту печінкової вени як
внутрішнього інтерфейсу рідина-тканина, коли асцит відсутній (рис.1.6).
Припускаючи, що внутрішня вузликовість при цирозі може спричинити
архітектурні спотворення, морфологія печінкової вени також буде змінена.
У проспективному пілотному дослідженні, яке включало 38 пацієнтів з
цирозом та 50 пацієнтів без захворювань печінки, оцінювали такі
особливості: прямолінійність вен печінки, рівномірність ехогенності
печінкових вен та візуалізацію 1-сантиметрового сегмента печінкової вени
[36].

Рисунок 1.6. Поверхня печінки.

Прямолінійність печінкових вен, стратифікована на три категорії

(пряма, злегка хвиляста та дуже хвиляста), дала найвищу чутливість та
 20

специфічність відповідно 0,97 та 0,91 за допомогою складеної візуалізації

у реальному часі (RTCI) з датчиком 5–2 МГц. Рівномірність ехогенності
стінок печінкової вени була наступною корисною характеристикою з
чутливістю та специфічністю 0,88 та 0,86 відповідно, подібно до
попередніх досліджень поверхневої вузлової поверхні. З урахуванням усіх
трьох ознак, специфічність цирозу досягла 0,98 за допомогою RTCI; однак
чутливість знижена до 0,65. У цьому пілотному дослідженні було показано
(рис. 1.7), що оцінка морфології печінкової вени є хорошим показником
цирозу із сприятливою похибкою між- та внутрішньообсерваторними.
Хоча необхідна валідація з більш суворою клініко-патологічною
кореляцією та більшим числом пацієнтів, три морфологічні
характеристики печінкових вен можуть бути легко оцінені в клінічній
практиці. Зараз автори рекомендують проводити обстеження стінки
печінкової вени в сегменті 5 або 6. Периферичну притоку слід вибирати
перпендикулярно ультразвуковому променю, щоб досягти хорошого
дзеркального відбиття. Периферійна притока повинна мати розміри
приблизно 3 мм у діаметрі та щонайменше 15 мм у довжину; вибір
периферійної притоки також дозволяє використовувати сканування з більш
високою роздільною здатністю [7].

Рисунок 1.7. Морфологія стінки печінкової вени.

 21

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

з надзвичайною точністю для діагностики цирозу в експериментальному
дослідженні [4], недавнє дослідження не змогло продемонструвати таку
високу чутливість і повідомило, що вузли на поверхні печінки є більш
чутливими [4]. Цілком ймовірно, що ці суперечливі висновки пов'язані з
технікою. При застосуванні скрупульозної техніки, як це детально описано
у Gibson et al. [4], досвід авторів полягає в тому, що діагностична
впевненість вища при морфології печінкової вени, ніж при поверхневій
нодулярності.
Відомо, що діаметр портальної вени збільшується після прийому їжі,
і ефект може становити до 50% [4]. У невеликій серії було показано, що
цей ефект присутній і у звичайних пацієнтів, і у хворих на хронічний
гепатит, проте середній калібр цирозу печінки, середня швидкість потоку
та середній об’єм потоку залишаються в основному незмінними після їжі
[7]. Абсолютний калібр ворітної вени вважався ознакою портальної
венозної гіпертензії із граничними значеннями 13–15 мм [7], однак із
слабкою чутливістю 0,13–0,4. Відсутність чутливості, ймовірно, пов’язана
з наявністю побічних шляхів, які декомпресують систему. Дослідження,
проведене на основі ангіографії, погодилося з висновком, що діаметр
ворітної вени не збільшувався разом із портогепатичним градієнтом при
портальній венозній гіпертензії [4]. З нашого досвіду, діаметр ворітної
вени може навіть здаватися малим в умовах гепатофугального потоку. У
нашій практиці цьому параметру надається незначне значення, оскільки
він має низьке позитивне прогностичне значення для портальної
гіпертензії, а невеликий відсоток нормалів має діаметр ворітної вени> 13
мм. Тому діаметр портальної вени слід тлумачити з обережністю як маркер
портальної гіпертензії.
При портальній гіпертензії більш важливою, ніж абсолютний діаметр
ворітної вени, може бути відсутність нормальних коливань калібру при
 22

диханні [14] із зафіксованою чутливістю до 0,79. Очевидно, однак, що

існує занадто велика різниця в абсолютному діаметрі ворітної вени, яку
слід використовувати для діагностики гіпертонії ворітної вени. Крім того,
за нашим досвідом доступ до ультразвуку та дотримання напрямків
дихання часто надто погані, щоб отримати надійні та відтворювані
вимірювання зміни діаметра ворітної вени.

Висновки до розділу 1

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

призвела до виявлення та вимірювання тонких змін. Це дозволило ранню і
точну діагностику цирозу печінки. В даний час еластографія, яка
використовується для вимірювання ригідності та еластичності печінки,
застосовується ширше, ніж аналіз текстури, для діагностики цирозу
печінки. Результати сильно корелюють з фіброзом печінки, не потребуючи
процедури після операції. Незважаючи на те, що МРЕ має більш точні
тенденції, США є простим інструментом візуалізації для діагностики
цирозу і може бути доданий як кілька додаткових додаткових технологій.
Неповноцінна діагностична здатність, неінвазивність та відносна
економічна ефективність еластографії в США можуть дозволити їй стати
однією з найкорисніших методик діагностики цирозу печінки.
Ми очікуємо стандартизації методів еластографії, щоб кількісні
параметри, отримані клінічними системами від різних постачальників,
могли дати подібні результати в майбутньому.
Існує значна суперечка щодо часу, необхідного для реалізації
повністю автоматизованих клінічних завдань методами глибокого
навчання [13]. Обговорюваний час коливається від кількох років до
десятиліть. Автоматизовані рішення, засновані на глибокому навчанні,
мають на меті вирішити найпоширеніші клінічні проблеми, які вимагають
 23

довготривалого накопичення досвіду або є надто складними для читачів,

наприклад, КТ скринінгу легенів, мамографія тощо. Далі дослідникам
потрібно розробити більш досконалі алгоритми глибокого навчання для
вирішення більш складних медичних проблем візуалізації, таких як
ультразвук або ПЕТ. В даний час загальним дефіцитом засобів штучного
інтелекту є те, що вони не можуть вирішити декілька завдань. В даний час
не існує комплексної системи штучного інтелекту, здатної виявляти
численні відхилення в організмі людини.
ШІ, особливо глибоке навчання, швидко стає надзвичайно
перспективною допомогою у виконанні завдань із зображення печінки, що
призводить до поліпшення ефективності виявлення та оцінки уражень
печінки, полегшення клінічної терапії печінки та прогнозування реакції на
лікування печінки. У майбутньому розвиток ШІ невіддільний від лікарів, і
робота лікарів буде тісно пов’язана з ШІ. Медичні послуги, що надаються
машиною, стануть оптимальним рішенням для майбутньої медичної
допомоги печінці. Нам потрібно визначити, які конкретні завдання
рентгенології найімовірніше виграють від алгоритму глибокого навчання,
беручи до уваги сили та обмеження цих алгоритмів. В контексті
бурхливого розвитку технології ШІ, лікарі повинні йти в ногу з часом і
ретельно застосовувати технології, щоб стати драйвером технологій та
краще обслуговувати пацієнтів.
 24

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

2.1 Загальні відомості

Для реалізації програмного забезпечення був розроблений веб-

додаток серверна частина якого написана на мові програмування Golang з
використанням бібліотеки Echo та базою даних MongoDB, клієнтська
частина написана на мові програмування TypeScript з використанням
бібліотеки React, автентифікація була реалізована за допомогою Firebase.

2.2 База даних

Для збереження інформації необхідної для нормального

функціонування додатку, використовувалась документоорієнтована база
даних MongoDB на сервісі Atlas.
MongoDB - документоорієнтована, проста для вивчення та
використання розробниками, і при цьому надає всі можливості, необхідні
для необхідні для найскладніших вимог у будь-якому масштабі.
Переваги MongoDB:
1. MongoDB зберігає дані у гнучких документах, схожих на
JSON, тобто поля можуть відрізнятися від документа до документа, а
структура даних може змінюватися з часом.
2. Модель документа відображається на об'єктах коду вашої
програми, що полегшує роботу з даними.
3. Спеціальні запити, індексація та агрегування в реальному часі
забезпечують потужні способи доступу та аналізу даних.
4. MongoDB - це розповсюджена база даних за своєю суттю,
завдяки високій доступності, горизонтальному масштабуванню.
 25

2.3 Серверна частина веб-додатку

Go або Golang - це мова програмування, створена в Google

розробниками Google та іншими програмістами. Ця мова програмування
безкоштовна та з відкритим кодом і в даний час підтримується Google.
Одним із засновників Go є Кен Томпсон, який відомий своєю роботою з
розробки операційної системи Unix. Спочатку компілятор Go був
написаний на мові C, але тепер він написаний на самому Go, що робить
його самостійним.
1. Go - це статично компільована мова.
2. Вона підтримує вбудовану модель паралельності за допомогою
GoRoutines.
3. Він має вбудований збирач сміття та безпеку пам’яті.
4. Строки в Go за замовчуванням кодуються UTF-8.
5. Він має простіший синтаксис порівняно з іншими
скомпільованими мовами програмування.
Чотири важливі речі, яких має розвивати мова, - це швидкість /
ефективність, надійність, масштабність та простота.
Якщо розглядати такі мови, як С або С ++, вони чудові за
швидкістю, масштабом та надійністю, але з точки зору простоти вони не
такі вже й гарні.
Java з іншого боку, дуже надійна і масштабована, але в міру проста у
написанні та не така ефективна в порівнянні з іншими мовами низького
рівня. Python - широко розповсюджена мова і дуже проста в написанні, але
не така ефективна і надійна.
GoRoutines - це функції або методи, які працюють одночасно з
іншими функціями або методами. GoRoutines можна сприймати як легкі
потоки. Вартість створення Goroutine незначна, якщо порівнювати з
потоками.
 26

Переваги GoRoutines над потоками:

1. GoRoutines надзвичайно дешеві в порівнянні з потоками. Вони
мають розмір стека всього на кілька кб., і стек може зростати і стискатися
відповідно до потреб програми, тоді як у випадку потоків розмір стека
повинен бути вказаний і фіксований.
2. GoRoutines мультиплексуються до меншої кількості потоків
ОС. У програмі з тисячами GoRoutines може бути лише один поток. Якщо
будь-яка Goroutine в цих блоках потоку каже, що чекає введення
користувачем, тоді створюється інший потік ОС, а інші Goroutines
переміщуються до нового потоку OS.
3. GoRoutines спілкуються за допомогою каналів. Канали за
дизайном запобігають появі гонки умов при доступі до спільної пам'яті за
допомогою Goroutines. Канали можна сприймати як трубу, за допомогою
якої GoRoutines спілкуються.
Echo - Високопродуктивний, розширюваний, мінімалістичний
веб- фреймворк Go.
Переваги Echo:
1. Оптимізований маршрутизатор HTTP, який розумно розставляє
пріоритети маршрутам.
2. Надійні та масштабовані RESTful API.
3. Розширювана система middleware.
4. Централізована обробка помилок HTTP.
5. Високонастоюваний.
6. Автоматичний TLS через Let’s Encrypt.
7. Підтримка HTTP/2.

2.4 Клієнтська частина веб-додатку

 27

TypeScript - це мова для JavaScript у масштабі програми. TypeScript

додає до JavaScript необов’язкові типи, які підтримують інструменти для
масштабних програм JavaScript для будь-якого браузера, для будь-якого
хосту та будь-якої ОС. TypeScript компілюється в зручний для читання
стандартний JavaScript.
JavaScript (ECMAScript) - це інтерпретована мова програмування. Хоча
вона найбільш відома як мова сценаріїв веб-сторінок, її використовують
також багато середовищ, що не належать до браузера, такі як Node.js,
Apache CouchDB та Adobe Acrobat та на будь якому пристрої де є так
званий двигун JavaScript. JavaScript - це прототипно орієнтована,
однопотокова динамічна мова, що підтримує об’єктно-орієнтований,
імперативний та декларативний (наприклад, функціональне
програмування) стилі.
Для різних браузерів використовуються різні двигуни: Chrome та
Opera - V8, SpiderMonkey - Firefox, Chakra - IE i т.д. Найвикористованішим
двигуном є V8.
Сучасний JavaScript - це "безпечна" мова програмування. Він не
забезпечує низькорівневий доступ до пам'яті або центрального процесора,
оскільки спочатку був створений для браузерів, не потребують що цього.
Можливості JavaScript сильно залежать від середовища, в якому він
працює. Наприклад, платформа Node.js може підтримувати функції, що
дозволяють JavaScript читати / писати файли та виконувати мережеві
запити тощо.
JavaScript у браузерному середовищі може робити все, що стосується
маніпулювання веб-сторінками, взаємодії з користувачем та веб-сервером.
Наприклад, JavaScript у браузері може:
1. Додає на сторінку новий HTML, змінює наявний вміст, змінює
стилі.
2. Реагує на дії користувача.
3. Надсилає запити через мережу на віддалені сервери,
завантажує та файли (так звані технології AJAX та COMET).
 28

4. Отримує та встановлює файли cookie, задає питання

відвідувачеві, показує повідомлення.
5. Запам’ятає дані на стороні клієнта (localStorage, sessionStorage,
indexDB).
Що не може робити JavaScript у браузері?
Можливості JavaScript у браузері обмежені заради безпеки
користувача. Мета полягає в тому, щоб запобігти доступу зловмисної веб-
сторінки до приватної інформації або шкоди даним користувача.
1. JavaScript на веб-сторінці не може читати / писати довільні
файли на жорсткому диску, копіювати їх або виконувати програми. Він не
має прямого доступу до функцій ОС.
2. Сучасні браузери дозволяють йому працювати з файлами, але
доступ обмежений і надається лише в тому випадку, якщо користувач
робить певні дії, наприклад, "скидає" файл у вікно браузера або вибирає
його за допомогою тегу <input>.
3. Різні вкладки / вікна, як правило, не знають один про одного.
Іноді вони це роблять, наприклад, коли одне вікно використовує JavaScript,
щоб відкрити інше. Але навіть у цьому випадку JavaScript з однієї сторінки
може не мати доступу до іншої, якщо вони надходять з різних сайтів (з
іншого домену, протоколу чи порту).
4. Це називається "Same Origin Policy". Щоб обійти це, обидві
сторінки повинні домовитись про обмін даними та містити спеціальний
код JavaScript, який обробляє його.
5. JavaScript може легко зв’язатись через мережу з сервером,
звідки походить поточна сторінка. Але здатність отримувати дані з інших
сайтів / доменів зменшена. Хоча це можливо, для цього потрібна явна
згода (виражена в заголовках HTTP) з віддаленої сторони. Ще раз, це
обмеження безпеки.
Що робить JavaScript унікальним?
У JavaScript є щонайменше три чудові речі:
1. Повна інтеграція з HTML / CSS.
 29

2. Підтримка всіх основних браузерів і ввімкнена за

замовчуванням.

JavaScript - це єдина технологія браузера, яка поєднує ці три речі.

Саме це робить JavaScript унікальним. Ось чому це найпоширеніший
інструмент для створення інтерфейсів браузера. Тим не менш, JavaScript
також дозволяє створювати сервери, мобільні додатки тощо.
React - це бібліотека JavaScript для побудови користувальницьких
інтерфейсів на основі Virtual DOM, алгоритму React Fiber та запускається
на Node.js. Він підтримується Facebook та спільнотою окремих
розробників та компаній. React можна використовувати як основу при
розробці односторінкових або мобільних додатків. Однак React займається
лише управлінням станом та наданням цього стану DOM, тому для
створення додатків React зазвичай потрібно використовувати додаткові
бібліотеки для маршрутизації, а також певну функціональність на стороні
клієнта.
Можна розширити його для створення багатосторінкових додатків за
допомогою React Router. Це стороння бібліотека, яка забезпечує
маршрутизацію в програмах React.
Маршрутизація - це здатність показувати різні сторінки
користувачеві. Це означає, що користувач може переходити між різними
частинами програми, вводячи URL-адресу або натискаючи елемент.
За замовчуванням React поставляється без маршрутизації. А щоб
увімкнути це у проекті, потрібно додати бібліотеку з назвою react-router.
Virtual DOM (VDOM) - це концепція у програмуванні, де
«віртуальне», представлення інтерфейсу в пам'яті що синхронізується з
DOM такою бібліотекою, як ReactDOM. Цей процес називається
примиренням.
Цей підхід дозволяє декларативному API React: Повідомляє React, у
якому стані ви хочете знаходитись UI, і він гарантує, що DOM відповідає
 30

цьому стану. Це абстрагує обробку атрибутів, обробку подій та оновлення

DOM вручну, які вам інакше довелося б використовувати для створення
своєї програми.
Оскільки DOM є скоріше шаблоном, ніж конкретною технологією,
люди іноді кажуть, що це означає різні речі. У світі React термін "virtual
DOM" зазвичай асоціюється з елементами React, оскільки вони є
об'єктами, що представляють користувальницький інтерфейс. Однак React
також використовує внутрішні об'єкти, які називаються "волокнами", щоб
утримувати додаткову інформацію про дерево компонентів. Їх також
можна вважати частиною реалізації "virtual DOM" у React.
React Fiber - це постійне втілення основного алгоритму React. Це
кульмінація двох років досліджень команди React.
Метою React Fiber є підвищення його придатності для таких
областей, як анімація, макет та жести. Його особливістю заголовка є
поступовий рендеринг: можливість розділити роботу з рендеринга на
фрагменти та розподілити її по кількох кадрах.
Інші ключові функції включають можливість призупинення,
переривання або повторного використання роботи, коли надходять нові
оновлення; можливість присвоювати пріоритет різним типам оновлень; та
нові примітиви одночасності.

2.5 Автентифікація у веб-додатку

Більшість програм повинні знати особу користувача. Знання

ідентифікації користувача дозволяє додатку безпечно зберігати дані
користувача в хмарному сховищі та забезпечувати однакову
персоналізовану роботу на всіх пристроях користувача.
Firebase Authentication надає серверні сервіси, прості у використанні
SDK та готові бібліотеки інтерфейсу для автентифікації користувачів у
вашому додатку. Він підтримує автентифікацію за допомогою паролів,
 31

телефонних номерів, популярних постачальників об'єднаних

ідентифікаційних даних, таких як Google, Facebook та Twitter тощо.
Автентифікація Firebase тісно інтегрується з іншими службами
Firebase і використовує галузеві стандарти, такі як OAuth 2.0 та OpenID
Connect, тому її можна легко інтегрувати з вашим власним серверним
серверним середовищем.
Firebase - це набір інструментів для "створення, вдосконалення та
розвитку додатка", а інструменти, які він надає, охоплюють значну частину
служб, які розробники, як правило, повинні будувати самі, але насправді
не хочуть створювати, оскільки вони скоріше зосередитись на самому
досвіді роботи програми. Це включає такі речі, як аналітика,
автентифікація, бази даних, конфігурація, зберігання файлів, push-
повідомлення, і список можна продовжувати. Сервіси розміщуються в
хмарі та масштабуються, практично не вимагаючи зусиль з боку
розробника.
Щоб увійти до додатка, треба спочатку отримати від нього облікові
дані для автентифікації. Ці дані можуть бути адресою електронної пошти
та паролем користувача або маркером OAuth від постачальника об'єднаних
ідентифікаційних даних. Потім ці облікові дані передаються до Firebase
Authentication SDK. Потім наші серверні служби перевірять ці облікові
дані та повернуть клієнту відповідь.
Структура авторизації OAuth - це протокол, який дозволяє
користувачеві надавати сторонній веб-сайт або програму доступ до
захищених ресурсів користувача, не обов'язково розкриваючи їхні
довгострокові дані або навіть свою особу.
OAuth представляє рівень авторизації та відокремлює роль клієнта
від ролі власника ресурсу. В OAuth клієнт подає запит на доступ до
ресурсів, контрольованих власником ресурсів і розміщених на сервері
ресурсів, і йому видаються інші набори облікових даних, ніж дані власника
ресурсу. Замість того, щоб використовувати облікові дані власника
 32

ресурсу для доступу до захищених ресурсів, клієнт отримує маркер

доступу - рядок, що позначає певний обсяг, термін служби та інші
атрибути доступу. Токени доступу видаються стороннім клієнтам
сервером авторизації з дозволу власника ресурсу. Потім клієнт
використовує маркер доступу для доступу до захищених ресурсів,
розміщених на сервері ресурсів.
Auth0 генерує маркери доступу для сценаріїв авторизації API у
форматі веб-маркера JSON (JWT). Дозволи, представлені маркером
доступу, в термінах OAuth, відомі як сфери дії. Коли програма
аутентифікується за допомогою Auth0, вона вказує потрібні обсяги. Якщо
ці сфери дозволені користувачем, то маркер доступу буде представляти ці
авторизовані області.
Потік OAuth 2.0 виконує такі ролі:
1. Власник ресурсу: Організація, яка може надати доступ до
захищеного ресурсу. Як правило, це кінцевий користувач.
2. Серверні ресурси: Сервер, при якому розміщені захищені
ресурси. Це API, до якого ви хочете отримати доступ.
3. Клієнт: Програма, що вимагає доступу до захищеного ресурсу
від імені Власника ресурсу.
4. Сервер авторизації: Сервер, який автентифікує Власника
ресурсу та видає маркери доступу після отримання належної авторизації. У
цьому випадку Auth0.
JWT токен, є відкритим стандартом (RFC 7519), що визначає не
великий, безпечний та автономний спосіб передачі інформації між
клієнтами як об'єкт JSON. Знову ж таки, JWT - це стандарт, що означає, що
всі JWT є маркерами, але не всі токени є JWT.
Через відносно невеликий розмір, JWT може надсилатися через
URL-адресу, через параметр POST або всередині заголовка HTTP, і він
передається швидко. JWT містить всю необхідну інформацію про сутність,
 33

щоб уникнути запитів до бази даних більше одного разу. Одержувачу JWT
також не потрібно викликати сервер для перевірки маркера.
Використання JWT дає переваги порівняно з простими токенами
(SWT).
Переваги JWT токенів:
1. Більш компактний: JSON менш детальний, ніж XML, тому,
коли він кодується, JWT менше, ніж маркер SAML. Це робить JWT
хорошим вибором для передачі в середовищах HTML і HTTP.
2. Більш безпечний: JWT можуть використовувати для
підписання пару відкритого / приватного ключів у формі сертифіката
X.509. JWT також може бути симетрично підписаний загальним секретом
за допомогою алгоритму HMAC. І хоча маркери SAML можуть
використовувати пари відкритих / приватних ключів, таких як JWT,
підписання XML за допомогою цифрового підпису XML без введення
неясних дірок у безпеці є дуже складним у порівнянні з простотою
підписання JSON. Докладніше про алгоритми підписання JWT.
3. Більш поширені: синтаксичні аналізатори JSON поширені в
більшості мов програмування, оскільки вони безпосередньо накладаються
на об’єкти. І навпаки, XML не має природного зіставлення документа з
об’єктом. Це полегшує роботу з JWT, ніж твердження SAML.
4. Легше обробити: JWT використовується в Інтернеті. Це
означає, що його легше обробити на пристроях користувача, особливо на
мобільних.
JWT можна використовувати різними способами:
1. Автентифікація: Коли користувач успішно входить в систему,
використовуючи свої облікові дані, повертається маркер ідентифікатора.
Відповідно до специфікацій OpenID Connect (OIDC), маркер
ідентифікатора завжди є JWT.
2. Авторизація. Після того, як користувач успішно увійшов в
систему, програма може вимагати доступу до маршрутів, служб або
 34

ресурсів (наприклад, API) від імені цього користувача. Для цього в

кожному запиті він повинен передавати маркер доступу, який може бути у
формі JWT. Система єдиного входу (SSO) широко використовує JWT через
невеликі накладні витрати на формат та його здатність легко
використовуватись у різних доменах.
3. Обмін інформацією: JWT - це хороший спосіб безпечної
передачі інформації між сторонами, оскільки їх можна підписати, що
означає, що ви можете бути впевнені, що відправники є тими, за кого вони
кажуть. Крім того, структура JWT дозволяє вам перевірити, що вміст не
був підроблений.
Інформацію, що міститься в об'єкті JSON, можна перевірити та
довірити, оскільки вона має цифровий підпис. Незважаючи на те, що JWT
також можуть бути зашифровані для забезпечення секретності між
сторонами, видані Auth0 JWT є веб-підписами JSON (JWS), тобто вони
підписані, а не зашифровані.
Як правило, JWT можна підписати, використовуючи секрет (з
алгоритмом HMAC) або пару відкритого / приватного ключів,
використовуючи RSA або ECDSA (хоча Auth0 підтримує лише HMAC і
RSA). Коли токени підписуються за допомогою пар відкритого /
приватного ключів, підпис також засвідчує, що лише сторона, яка тримає
закритий ключ, та, яка підписала його.
Перед використанням отриманого JWT його слід належним чином
перевірити за допомогою підпису. Успішно перевірений маркер означає
лише те, що інформація, що міститься в маркері, не була змінена ніким
іншим. Це не означає, що інші не бачили вмісту, який зберігається у
вигляді простого тексту. Через це ніколи не слід зберігати конфіденційну
інформацію всередині JWT, а також вживати інших заходів, щоб
забезпечити неперехоплення JWT, наприклад, надсилаючи JWT лише
через HTTPS, дотримуючись найкращих практик та використовуючи лише
безпечні та сучасні бібліотеки.
 35

Висновки до розділу 2

В даному розділі було проведено теоретичний огляд усього

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

РОЗДІЛ 3
АНАЛІТИЧНА ЧАСТИНА

3.1 Функціональні вимоги

В даному підрозділі охарактеризовані варіанти використання

програмного додатку у таблицях, та рисунках у вигляді діаграми в нотації
UML.
3.1.1 Створення нового об'єкту типу “Лікар”

Таблиця 3.1.
Створення нового об'єкту типу “Лікар”

№ Назва Мета Дійові особи Опис

1 Створення Зберегти у Лікар Лікар робить запит з

нового об'єкту базу необхідними полями та
типу “Лікар” нового JWT-токеном аутентфікації
Лікаря в системі Firebase, при
заповненні полів в базі
даних створюється новий
запис про лікаря.

Рисунок 3.1 Створення нового лікаря

3.1.2 Створення нового об'єкту типу “Пацієнт”

Таблиця 3.2.
Створення нового об'єкту типу “Пацієнт”

№ Назва Мета Дійові особи Опис

1 Створення Створення Лікар, Лікар робить запит з

нового об'єкту запису Пацієнт необхідними полями та
типу “Пацієнт” нового JWT-токеном
 37

пацієнта у аутентфікації. Створюється

базі даних новий запис про пацієнта з
посиланням на лікаря.

Рисунок 3.2. Створення нового пацієнта

3.1.3 Редагування об'єкту типу “Пацієнт”

Таблиця 3.3.
Редагування об'єкту типу “Пацієнт”

№ Назва Мета Дійові особи Опис

1 Редагування Редагування Лікар, Лікар робить запит з

об'єкту типу даних Пацієнт необхідними полями та
“Пацієнт” пацієнта у JWT-токеном
базі даних аутентфікації. У базі даних
оновлюється запис
пацієнта.

Рисунок 3.3. Редагування даних пацієнта

3.1.4 Видалення об'єкту типу “Пацієнт”

Таблиця 3.4.
Видалення об'єкту типу “Пацієнт”

№ Назва Мета Дійові особи Опис

1 Видалення Видалення Лікар, Лікар робить запит з

 38

об'єкту типу запису Пацієнт необхідними полями та

“Пацієнт” пацієнта з JWT-токеном
бази даних аутентфікації. У базі даних
видаляється запис пацієнта.

Рисунок 3.4. Видалення пацієнта

3.1.5 Створення нового об'єкту типу “Аналіз”

Таблиця 3.5.
Створення нового об'єкту типу “Аналіз”

№ Назва Мета Дійові особи Опис

1 Створення Створення Лікар, Лікар робить запит з

нового об'єкту запису про Пацієнт необхідними полями та
типу “Аналіз” аналізи JWT-токеном
пацієнта у аутентфікації. Створюється
базі даних новий запис аналізу з
посиланням на пацієнта.

Рисунок 3.5. Створення нового аналізу

3.1.6 Створення нового об'єкту типу “Знімок”

Таблиця 3.6.
Створення нового об'єкту типу “Знімок”

№ Назва Мета Дійові особи Опис

 39

1 Створення Створення Лікар, Лікар робить запит з

нового об'єкту запису про Пацієнт необхідними полями та
типу “Знімок” знімок JWT-токеном
пацієнта у аутентфікації. Створюється
базі даних і новий запис знімку з
збереження посиланням на пацієнта та
знімку зберігається знімок.

Рисунок 3.6. Створення нового знімку

3.1.7 Видалення об'єкту типу “Знімок”

Таблиця 3.7.
Видалення об'єкту типу “Знімок”

№ Назва Мета Дійові особи Опис

1 Видалення Видалення Лікар, Лікар робить запит з

об'єкту типу запису Пацієнт необхідними полями та
“Знімок” знімку з JWT-токеном
бази даних аутентфікації. У базі даних
та видаляється запис знімку та
жорсткого знімок з жорсткого диску.
диску
 40

Рисунок 3.7. Видалення знімку

3.1.8 Виділення та збереження області інтересу на знімку

Таблиця 3.8.
Виділення та збереження області інтересу на знімку

№ Назва Мета Дійові Опис

особи

1 Виділення та Збереження Лікар Лікар робить запит з

збереження області необхідними полями та
области інтересу інтересу JWT-токеном
знімку як аутентфікації. У базі даних
об’єкт типу записується знімок з .зі
знімок. значенням поля isCropped:
true, та зберігається на
жорсткому диску

Рисунок 3.8. Виділення та збереження області інтересу знімку

 41

3.1.9 Відображення об’єктів типу “Пацієнт”

Таблиця 3.9.
Відображення об’єктів типу “Пацієнт”

№ Назва Мета Дійові особи Опис

1 Відображення Дістати дані Лікар Лікар робить запит з JWT-

об’єктів типу про записи токеном аутентфікації. З
“Пацієнт” пацієнтів бази даних дістаються
певного записи пацієнтів, які
лікаря належать цьому лікарю.

Рисунок 3.9. Відображення об’єктів типу пацієнт

3.1.10 Відображення об’єкту типу “Пацієнт”

Таблиця 3.10.
Відображення об’єктів типу “Пацієнт”

№ Назва Мета Дійові особи Опис

1 Відображення Дістати дані Лікар Лікар робить запит з JWT-

об’єкту типу про запис токеном аутентфікації. З
“Пацієнт” пацієнта бази даних дістається запис
пацієнта.
 42

Рисунок 3.10. Відображення об’єктів типу пацієнт

3.1.11 Відображення об’єктів типу “Аналіз”

Таблиця 3.11.
Відображення об’єктів типу “Аналіз”

№ Назва Мета Дійові особи Опис

1 Відображення Дістати дані Лікар Лікар робить запит з JWT-

об’єктів типу про аналізи токеном аутентфікації. З
“Аналіз” певного бази даних дістаються
пацієнта записи аналізів, які
належать певному
пацієнту.

Рисунок 3.11. Відображення об’єктів типу аналіз

3.1.12 Відображення об’єктів типу “Знімок”

Таблиця 3.12.
Відображення об’єктів типу “Аналіз”

№ Назва Мета Дійові особи Опис

1 Відображення Дістати дані Лікар Лікар робить запит з JWT-

об’єктів типу про токеном аутентфікації. З
“Знімок” зображення бази даних та з жорсткого
та диску дістаються записи
відобразити знімків, які належать
 43

їх певному пацієнту.

Рисунок 3.12. Відображення об’єктів типу знімок

3.2 Проектування бази даних

Для збереження всіх даних у базі було створено 4 таблиці даних:
1. analizes;
2. doctors;
3. patients;
4. images;
Для опису кожної таблиці створено таблицю елементів даних де
описуються сутності.
Специфікація елементів даних для таблиці analizes (таблиця 3.13).
Таблиця 3.13.
Специфікація елементів даних таблиці analizes
Сутність Атрибут Тип
analize date Date
s patientId ObjectID
name String
value String

Також кожну таблицю описано за допомогою UML-діаграм для

відтворення абстрактної моделі. UML-модель таблиці analizes (рис. 3.13).
 44

Рисунок 3.13. UML-діаграма таблиці analizes.

Специфікація елементів даних для таблиці doctors (таблиця 3.14)

Таблиця 3.14.
Специфікація елементів даних таблиці doctors
Сутність Атрибут Тип
doctors firebaseUID String
role String

UML-модель таблиці doctors (рис. 3.14).

Рисунок 3.14. UML-діаграма таблиці doctors.

Специфікація елементів даних для таблиці doctors (таблиця 3.15. )

Таблиця 3.15.
 45

Специфікація елементів даних таблиці images

Сутність Атрибут Тип
name String
type String
date Date
images
isCropped Boolean
isVisible Boolean
patientId ObjectID

UML-модель таблиці doctors. (рис. 3.15.)

Рисунок 3.15. UML-діаграма таблиці images.

Специфікація елементів даних для таблиці patients (таблиця 3.16).

Таблиця 3.16.
Специфікація елементів даних таблиці patients
Сутність Атрибут Тип
doctorId ObjectID
lastName String
firstName String
fathersName String
patients
age Number
height Number
weight Number
date Date
 46

UML-модель таблиці patients (рис. 3.16).

Рисунок 3.16. UML-діаграма таблиці patients.

Для відображення зв’язків між таблицями у базі даних, створено

схему за допомогою UML-моделювання, діаграма (рис. 3.17).
 47

Рисунок 3.17 UML-діаграма відношень таблиць баз даних.

3.3. Проектування серверної частини

При проектуванні серверної частини були виділенні маршрути API.

Маршрути (таблиця 3.17).
Таблиця 3.17.
Структура серверної частини

№ Маршрут Метод Header Body Опис

1 /analize POST JWT-токен Name: String Додає аналіз

користувача користувачу.
Value: String

2 /analizes GET JWT-токен Повертає аналізи

користувача, користувача
patientId

3 /calculate POST JWT-токен Name: String Повертає дані

користувача оброблені дані про
Task: String знімок
Sensor: String

SaveTransform:
String

SaveBinaryzation:
String

4 /doctor POST JWT-токен

користувача

5 /doctor GET JWT-токен Повертає особисту

користувача інформацію лікаря

6 /image POST JWT-токен Name: String Зберігає знімок

користувача Image: String

Type: String

IsCropped:
Boolean
 48

Image: String

7 /image/:id DELETE JWT-токен Видаляє знімок

користувача

8 /images GET JWT-токен Повертає знімки

користувача пацієнта

9 /all/images GET JWT-токен Повертає всі знімки

користувача

10 /patient POST JWT-токен Age: Integer Додає дацієнта

користувача
Height: Float32

Weight: Float32

FirstName: String

LastName: String

FathersName:
String

Date: Date

Diagnosis: String

11 /patient/:id DELETE JWT-токен Видаляє пацієнта

користувача

12 /patients GET JWT-токен Повертає всіх

користувача пацієнтів лікаря

13 /patients/:id PUT JWT-токен Змінені дані Редагує пацієнта

користувача користувача

Висновки до розділу 3

В розділі було проведено аналіз і проектування найбільш важливих

елементів даної системі. Був проведений аналіз функціональних вимог,
спроектовані логічна та фізична моделі бази даних, веб-інтерфейс додатку.
 49

РОЗДІЛ 4
ПРАКТИЧНА РЕАЛІЗАЦІЯ
4.1 Розробка серверної частини веб-додатку
4.1.1 Функція створення лікаря

Дана функція відповідає за запис даних лікаря у базу даних, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту ( рис 4.1).

Рисунок 4.1. Діаграма запиту на створення лікаря

4.1.2 Функція отримання даних лікаря

Дана функція відповідає за отримання даних лікаря, для подальшого

використання їх в додатку. Алгоритм роботи функції даної представлений
у вигляді діаграми запиту ( рис 4.2).
 50

Рисунок 4.2. Діаграма отримання даних лікаря

4.1.3 Функція створення пацієнта

Дана функція відповідає за запис пацієнта в базі даних, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту ( рис 4.3).

Рисунок 4.3. Діаграма створення пацієнта

4.1.4 Функція редагування пацієнта

Дана функція відповідає за запис пацієнта в базу даних, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту (рис 4.4).
 51

Рисунок 4.4. Діаграма редагування пацієнта

4.1.5 Функція видалення пацієнта

Дана функція відповідає за запис пацієнта в базу даних, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту (рис 4.5).

Рисунок 4.5. Діаграма видалення пацієнта

4.1.6 Функція отримання пацієнтів лікаря

 52

Дана функція відповідає за отримання пацієнтів лікаря, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту (рис 4.6).

Рисунок 4.6. Діаграма отримання даних пацієнтів

4.1.7 Функція отримання даних певного пацієнта

Дана функція відповідає за отримання пацієнтів лікаря, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту (рис 4.7).

Рисунок 4.7. Діаграма отримання даних пацієнта

4.1.8 Функція створення аналізу пацієнта

 53

Дана функція відповідає за запис аналізу в базу даних, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту (рис 4.8).

Рисунок 4.8. Діаграма створення аналізу

4.1.9 Функція отримання аналізів пацієнта

Дана функція відповідає за отримання аналізу пацієнта, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту (рис 4.9)

Рисунок 4.9. Діаграма отримання даних аналізів

4.1.10 Функція отримання даних про знімок

 54

Дана функція відповідає за даних про знімок пацієнта, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту (рис 4.10).

Рисунок 4.10. Діаграма отримання даних про знімок

4.1.11 Функція створення завантаження знімку

Дана функція відповідає за запис знімку в базі даних та на жорсткий

диск, для подальшого використання їх в додатку. Алгоритм роботи функції
даної представлений у вигляді діаграми запиту (рис 4.11).

Рисунок 4.11. Діаграма створення аналізу

4.1.12 Функція отримання знімків пацієнта

 55

Дана функція відповідає за отримання знімків пацієнта, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту (рис 4.12).

Рисунок 4.12. Діаграма отримання знімків пацієнтів

4.1.13 Функція отримання всіх знімків

Дана функція відповідає за отримання знімків пацієнта, для

подальшого використання їх в додатку. Алгоритм роботи функції даної
представлений у вигляді діаграми запиту (рис 4.13).

Рисунок 4.13. Діаграма отримання всіх знімків

 56

4.2 Розробка клієнтської частини веб-додатку

4.2.1 Реєстрація лікаря

Перш за все при використанні веб-додатку лікар повинен

зареєструватися в додатку ввівши свою пошту та пароль. Форма реєстрації
(рис. 4.14). Форми були побудовані за допомогою бібліотек Formik та Yup.
Якщо дані будуть введені неправильно, то будуть виведені помилки (рис.
4.15 - 4.17).

Рисунок 4.14. Форма реєстрації

 57

Рисунок 4.15. Помилка при реєстрації нового лікаря. Наявні порожні поля.

Рисунок 4.16. Помилка при реєстрації нового лікаря. Невалідне поле

пошти.
 58

Рисунок 4.17. Помилка при реєстрації нового лікаря. Ненадійний пароль.

4.2.2 Реєстрація нового пацієнта

Після успішного входу відкривається сторінка з пацієнтами (рис.

4.18).
Щоб додати нового пацієнта треба перейти на сторінку “Додати
пацієнта” (рис. 4.19).

Рисунок 4.18. Сторінка пацієнтів.

 59

Рисунок 4.19. Сторінка реєстрації нового пацієнта.

4.2.3 Сторінка пацієнта

Після успішної реєстрації пацієнта переходить на сторінку пацієнта

(рис. 4.20). На сторінці є такі блоки як: форма редагування пацієнта,
аналізи, зображення.

Рисунок 4.20. Сторінка пацієнта.

4.2.4 Додавання аналізу

 60

На сторінці пацієнта можна додати аналізи пацієнта та відстежувати

їх динаміку. Форма додавання аналізів (рис. 4.21).

Рисунок 4.21. Форма додавання аналізу.

4.2.5 Збереження зображення

При натисненні на кнопку “Завантажити” відкривається вікно вибору

зображення. Після вибору зображення відкривається модальне вікно з
формою (рис. 4.22) для вводу даних про знімок, таких як назва та тип
датчику у форматі випадаючого списку.
 61

Рисунок 4.22. Модальне вікно для збереження знімку.

4.2.6 Виділення області інтересу на зображені

При натисканні на зображення воно буду вибране та відкриється вище

блоку зображень (рис. 4.23). За допомогою інструменту можна виділити
область інтересу (рис.4.24). Виділення області інтересу на зображенні
виконується за допомогою технології Canvas. Після виділення зображення
треба натиснути на кнопку “Обрізати” для збереження області інтересу.

Рисунок 4.23.Вибране зображення.

 62

Рисунок 4.24. Виділення області інтересу.

4.2.5 Аналіз зображення

Для аналізу знімку треба вибрати знімок та заповнити форму в яку
входять тип переробки зображення у вигляді випадаючого списку та тип
аналізу (рис. 4.25) та після натиснути кнопку “Аналіз”. Після проведення
аналізу на сторінку будуть виведені графіки по різним показникам, дані
моделі МГУА, дані лісу класифікацій, трансформоване зображення,
бінарізоване зображення, а також типова норма, типова патологія і не
визначено (рис. 4.26).

Рисунок 4.25. Вибір типу переробки зображення та типу аналізу.

 63

Рисунок 4.26. Відображення даних про знімок.

Висновки до розділу 4

В даному розділі була розглянута реалізація веб-додатку такі як

додавання пацієнта, реєстрація лікаря, додавання зображень та їх аналіз і
т.д. Використання бібліотеки Reaсt.js, мови програмування Golang та
бібліотеки Formik для валідації форм значно прискорило розробку додатку.
В розділі були розглянуті усі функції додатку.
 ЗАГАЛЬНІ ВИСНОВКИ

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

універсальної оболонки одного класу систем підтримки прийняття
діагностичних рішень при дифузних захворюваннях печінки.
Метою роботи є спрощення прийняття діагностичних рішень при
дифузних захворюваннях печінки.
Веб-інтерфейс надає можливість зберігати лікарю дані пацієнта та
допомагає аналізувати його знімки.
 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Байк С.К. Оцінка гемодинаміки за допомогою допплерівської
ультрасонографії у пацієнтів з портальною гіпертензією: огляд. Liver Int.
2010; 30: 1403–1413. [PubMed] [Google Scholar]
2. Болезни печени / [С.Д. Подимова]. // Медицинское
Информационное Агенство Москва, 2018 – 967 с.
3. Вільямс Р. Глобальні проблеми при захворюваннях печінки.
Гепатологія. 2006; 44: 521–526. [PubMed] [Google Scholar]
4. Загальна теорія статистики. / [Ткач Є., Сторожук В.]. // Центр
навчальної літератури, 2017 – 442 с.
5. Кім М.Й., Чонг В.К., Баїк С.К. Інвазивна та неінвазивна
діагностика цирозу та портальної гіпертензії. Світ J Gastroenterol. 2014; 20:
4300–4315. [Безкоштовна стаття для PMC] [PubMed] [Google Scholar]
6. Класифікація станів печінки при дифузних захворюваннях на
основі статистичних показників текстури ультразвукових зображень та
МГУА. Індуктивне моделювання складних систем. / [Є.А.Настенко., І.М.
Дикан, Б.А. Тарасюк, В.А. Павлов, О.К. Носовець, В. О. Бабенко, В.В.
Круглий, М.Б.Диба, В.В. Солодущенко]. // Збірник наук. праць. К.:
МННЦІТС, Вип.11, 2019- 104-113 С.
7. Практична статистика для фахівців Data Science. / [Ендрю Брюс,
Пітер Брюс]. // БХВ-Петербург, 2017 – 304 с.
8. Ультразвукова диагностика. / [Едвард Блют]. // Медицинская
литература, Плєшков Ф. І., 2014 – 192 с.
9. Фрактальные размерности для времен возвращения Пуанкаре/
[Афраймович В., Угальде Э., Уриас Х.] // Удмуртский университет, 2011 –
292 с.
10. Cárdenas A, Ginès P. Ведення пацієнтів з цирозом, які очікують
трансплантації печінки. Кишечник. 2011; 60: 412–421. [PubMed] [Google
Scholar]
 66

11. Colli A, Fraquelli M, Andreoletti M, Marino B, Zuccoli E, Conte D.

Важкий фіброз печінки або цироз печінки: точність УЗД для виявлення -
аналіз 300 випадків. Рентгенологія. 2003; 227: 89–94. [PubMed] [Google
Scholar]
12. Fractals in Biology and Medicine / [Mantegna R. N., Havlin S.,
Buldyrev S.V.]. // Department of Biology, MIT, 1995 – 201 p.
13. Maruyama H, Shiha G, Yokosuka O, Kumar A, Sharma BC, Ibrahim
A, et al. Неінвазивна оцінка портальної гіпертензії та фіброзу печінки за
допомогою ультрасонографії з контрастом. Hepatol Int. 2016; 10: 267–276.
[PubMed] [Google Scholar]
14. Nissen NN, Martin P. Гепатоцелюлярна карцинома: пацієнт
високого ризику. J Clin Gastroenterol. 2002; 35 (5 доповнення 2): S79 – S85.
[PubMed] [Google Scholar]
15. Oberti F, Valsesia E, Pilette C, Rousselet MC, Bedossa P, Aubé C та
ін. Неінвазивна діагностика фіброзу або цирозу печінки.
Гастроентерологія. 1997; 113: 1609–1616. [PubMed] [Google Scholar]
16. Tandon P, Garcia-Tsao G. Портальна гіпертензія та
гепатоцелюлярна карцинома: прогноз та не тільки. Clin Gastroenterol
Hepatol. 2006; 4: 1318–1319. [PubMed] [Google Scholar]