Дипломна роботаbmc.fbmi.kpi.ua/uploads/diplom/bezruk-dmitro-pavlovich.pdf6 Розробка ПП 7 грудня 2015р. 7 Написання та оформлення

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

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

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

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

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

Завідувач кафедри БМК

__________ __Є.А. Настенко_ (підпис) (ініціали, прізвище)

“___”_____________20__ р.

Дипломна робота

на здобуття освітньо-кваліфікаційного рівня «спеціаліст»

зі спеціальності 7.05010101 «Інформаційні управляючі системи та технології» (код і назва)

на тему: Веб-інтегроване середовище дослідження стану системи кровообігу

Виконав: студент __6_ курсу, групи _БС-41с__ (шифр групи)

Безрук Дмитро Павлович (прізвище, ім’я, по батькові) (підпис)

Керівник доц., к.т.н., Добровська Л. М.

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

Консультант з розділів ДР ст. викл., к.т.н., Яковенко А. В.

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

Консультант з охорони праці доц., к.т.н. Демчук Г.В.


Консультант з економічних питань проф., д.е.н.,Семенченко Н.В.


Рецензент доц., к.т.н., Зубчук В. І.

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

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

запозичень з праць інших авторів без

відповідних посилань.

Студент _____________ (підпис)

Київ – 2016 року

Національний технічний університет України

«Київський політехнічний інститут»

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

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

Освітньо-кваліфікаційний рівень – «спеціаліст»

Спеціальність 7.05010101 «Інформаційні управляючі системи та технології» (код і назва)

ЗАТВЕРДЖУЮ

Завідувач кафедри БМК

__________ _Є.А. Настенко_ (підпис) (ініціали, прізвище)

«___»_____________2016 р.

ЗАВДАННЯ

на дипломну роботу студенту

Безруку Дмитру Павловичу (прізвище, ім’я, по батькові)

1. Тема роботи Веб-інтегроване середовище дослідження стану системи

кровообігу

керівник роботи Добровська Людмила Миколаївна, доц., к.т.н.

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

затверджені наказом по університету від «18» листопада 2015 р. № 3166с

2. Термін подання студентом роботи

3. Вихідні дані до роботи База даних пацієнтів кардіохірургічного

відділення

4. Зміст роботи 1) Математичні алгоритми та методи прийняття

рішень в задачах діагностики та прогнозу

2) ПП, що реалізує обрану модель прогнозування

5. Перелік ілюстративного матеріалу (із зазначенням плакатів, презентацій тощо)

1) Презентація Power Point

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

Розділ Прізвище, ініціали та посада

консультанта

Підпис, дата

завдання

видав

завдання

прийняв

Дипломної роботи Яковенко А. В., ст. викл.

Охорони праці Демчук Г.В., доц.

Економічних питань Семенченко Н.В., проф.

7. Дата видачі завдання 02 листопада 2015 р.

Календарний план №

з/п

Назва етапів виконання

дипломної роботи

Термін виконання

етапів роботи Примітка

1 Отримати завдання на ДР 02 листопада 2015р.

2 Аналітичний огляд літератури 03 листопада 2015р.

3 Розробка змісту та структури дипломної роботи 10 листопада 2015р.

4 Аналіз засобів розробки ПП 15 листопада 2015р.

5 Проектування архітектури ПП 25 листопада 2015р.

6 Розробка ПП 7 грудня 2015р.

7 Написання та оформлення дипломної роботи 15 січня 2016р.

8 Подання ДР рецензенту. Отримання рецензії. 24 січня 2016р.

9 Подання в електронному вигляді ДР та анотації

до неї на сайт кафедри.

25 січня 2016р.

10 Подання пакету документів по ДР до захисту в

ЕК

26 січня 2016р.

11 Захист ДР в ЕК 4 лютого 2016р.

Студент Безрук Д. П.

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

Керівник роботи Добровська Л. М.

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

Консультантом не може бути зазначено керівника дипломної роботи.

АНОТАЦІЯ

Обсяг роботи 88 сторінок, кількість ілюстрацій – 12, таблиць – 45, додатків –

1, джерел за переліком посилань – 40.

Мета дослідження – розробка веб-інтегрованого середовища для

централізованого транзакційного доступу до бази даних пацієнтів, роботи з їх

медичними записами та прогнозування розвитку ГСН в кожного з них.

Об’єкт дослідження – дані пацієнтів кардіохірургічного відділення та їх

показники.

Предметом дослідження є залежність вірогідності розвитку ГСН від наявних

в пацієнта симтомів.

Результати роботи впроваджено в клінічній практиці Державної установи

«Інститут фізіології імені О. О. Богомольця НАН України».

Ключові слова: бінарна логістична регресія, веб-інтегроване середовище,

гостра серцева недостатність, система кровообігу, медичні інформаційні

системи.

ABSTRACT

The scope of project work – 88 pages, number of images – 12, number of tables –

45, number of annexes – 1, number of the sources according to the list of references – 40.

The goal of the studies – development of the web-integrated environment for the

centralized transactional approach to the patients’ data base, working with the medical

notes and prognostication of the cardiac failure for every patient.

The object of the studies – data base of the patients of the cardiac surgery

department.

The subject of studies – influence of the current symptoms of a patience on the risk

of the cardiac failure development.

The results of the work have been applied in the clinical practice of a State

institution “O.O. Bogomolets physiology institute of the National Academy of Sciences

of Ukraine"

Key words: binary logistic regression, web-integrated environment, cardiac

failure, blood circulatory system, medical informational systems.

Вим Лист № докум. Підпис Дата

Лист

6

БС41с.4102.1300.3166.ПЗ

Розробив Безрук Д.П.

Перевірив Добровська Л.М.

Реценз. Зубчук В.І.

Н. Контр. Кисляк C.В.

Зав. каф. Настенко Є.А.

«Веб-інтегроване середовище

дослідження стану системи

кровообігу»

Літ. Листів

83

НТУУ "КПІ" ФБМІ БС-41с

ЗМІСТ

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ, СКОРОЧЕНЬ

І ТЕРМІНІВ .............................................................................................................. 8

ВСТУП ..................................................................................................................... 9

1 ПОСТАНОВКА ЗАДАЧІ.................................................................................. 11

Огляд проблеми ....................................................................................... 11

Методи математичної статистики для прийняття рішень ................... 13

Класифікація медичних інформаційних систем ................................... 16

2 РОЗРОБКА АЛГОРИТМУ ТА АРХІТЕКТУРА ВЕБ-ІНТЕГРОВАНОГО

СЕРЕДОВИЩА ..................................................................................................... 18

Структура алгоритму .............................................................................. 18

Архітектура веб-інтегрованого середовища ......................................... 22

Впровадження залежностей ................................................................... 24

3 РЕАЛІЗАЦІЯ ПРОГРАМНОГО ПРОДУКТУ ТА РЕЗУЛЬТАТИ

РОБОТИ ................................................................................................................. 26

3.1 Створення програмного продукту ......................................................... 26

4 ОХОРОНА ПРАЦІ ТА БЕЗПЕКА В НАДЗВИЧАЙНИХ СИТУАЦІЯХ .... 29

Характеристика об’єкту та умови його експлуатації .......................... 29

Оцінка небезпечних i шкідливих виробничих факторів та розробка

заходів по покращенню (нормалізації) умов праці при технологічному

процесі (розробці програмного продукту). ..................................................... 32

4.2.1 Електромагнітне випромінювання ...................................................... 33

4.2.2 Небезпека враження людини електричним струмом ........................ 35

4.2.3 Небезпеки, пов’язані з рухомими механізмами ................................. 36

4.2.4 Хімічна безпека ..................................................................................... 37

Вим Лист № докум. Підпис Дата

Лист

7

БС41с.4102.1300.3166.ПЗ

Розробив Безрук Д.П.

Перевірив Добровська Л.М.

Реценз. Зубчук В.І.

Н. Контр. Кисляк C.В.

Зав. каф. Настенко Є.А.

«Веб-інтегроване середовище

дослідження стану системи

кровообігу»

Літ. Листів

83

НТУУ "КПІ" ФБМІ БС-41с

4.2.5 Шум ........................................................................................................ 39

4.2.6 Пожежна безпека при надзвичайних ситуаціях ................................. 41

5 ЕКОНОМІЧНА ЧАСТИНА ............................................................................. 46

Обґрунтування функцій програмного продукту .................................. 47

Обґрунтування системи параметрів програмного продукту .............. 51

Аналіз рівня якості реалізації варіантів функцій ................................. 56

Економічний аналіз варіантів розробки програмного продукту ........ 57

5.4.1 Визначення витрат на розробку і розрахунок вартості програмного

продукту ………………………………………………………………………….59

5.4.2 Вибір кращого варіанта програмного продукту техніко-

економічного рівня ................................................................................................ 62

ВИСНОВКИ ........................................................................................................... 65

ПЕРЕЛІК ПОСИЛАНЬ ......................................................................................... 66

ДОДАТОК А .......................................................................................................... 69

Изм. Лист № докум. Підпис Дата 8 БС41с.4102.1300.3166.ПЗ

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ, СКОРОЧЕНЬ

І ТЕРМІНІВ

CRUD (create, read, update, delete) – стандартний функціонал роботи з

базою даних, що реалізовується веб-інтегрованим середовищем

MVC (Model – View – Controller) – архітектурний шаблон побудови веб-

інтегрованого середовища

АКШ – аорто-коронарне шунтування

БЛР – бінарна логістична регресія

ГСН – гостра серцева недостатність

ІАД – інтелектуальний аналіз даних

ІС – інформаційна система

ІХС – ішемічна хвороба серця

ПЗ – програмне забезпечення


ВСТУП

Інформаційні технології щодня полегшують виконання рутинних і

нетривіальних задач у дослідницьких центрах по всьому світу та медичних

установахрізного профілю. Серед типових задач, які розв’язують медичні

інформаційні технології, можна виділити зберігання, обробку та аналіз

медичних даних. Ще одне завдання, яке можливо виконати з застосуванням

медичних інформаційних технологій – це прогнозування. Прогнозування

здійснюється на основі вже отриманої вибірки даних з метою передбачити

подальші тенденції у зміні стану всієї вибірки або окремих її елементів. Але

обробка даних при великій кількості показників ускладнює процес їх обробки

та час на виконання аналізу. Крім цього, виявлення показників, які впливають

на результат, також ускладнюється. Широкого розповсюдження набули

методи інтелектуального аналізу даних (Data Mining).

На жаль, незважаючи на розповсюдженість та доступність медичних

інформаційних технологій, досить частою є проблема централізації доступу до

медичних даних, збереження їх цілісності та нормалізація. Саме тому сховище

медичних даних має бути єдиним, доступ до нього має бути можливим з будь-

якого місця фізичного розташування (за допомогою веб-інтерфейсу), форма

збереження даних має бути нормалізована, зведена до єдиного стандарту, а

робота зі сховищем має носити транзакційний характер.

Актуальність теми обґрунтовується необхідністю розробки веб-

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

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

пацієнтів ГСН.


Мета роботи: розробка веб-інтегрованого середовища для

централізованого транзакційного доступу до бази даних пацієнтів, роботи з їх

медичними записами та прогнозування розвитку ГСН в кожного з них.

Об’єктом дослідження є дані пацієнтів кардіохірургічного відділення

та їх показники.

Предметом дослідження залежність вірогідності розвитку ГСН від

наявних в пацієнта симтомів.

Методи дослідження: бінарна логістична регресія.

Практична цінність полягає в перевірці можливості застосування

алгоритму для аналізу показників.

Новизна полягає в інтеграції керування базою пацієнтів та алгоритму

прогнозування розвитку ГСН з веб-інтерфейсом.


1 ПОСТАНОВКА ЗАДАЧІ

Огляд проблеми

В практичній діяльності медичних працівників, організаторів та

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

медичної інформації завжди використовувались для аналізу поточного стану

охорони здоров’я, для вироблення управляючих впливів і планування

діяльності медичних закладів на всіх рівнях. По мірі розвитку і вдосконалення

обчислювальної техніки з’явилася можливість збирати, зберігати та обробляти

великі масиви інформації, що міститься в локальних чи розподілених

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

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

прогнозування та планування з використанням інформаційних технологій у

формі інтелектуальних та експертних автоматизованих систем.

У процесі лікування лікарю неодноразово доводиться вирішувати

завдання прогнозування, виходячи з анамнезу, накопиченого досвіду

лікування, об’єктивних даних про хворого і реакції організму на попереднє

лікування. Лікар вибирає ті чи інші лікувальні впливи, припускаючи ту чи

іншу реакцію від їх застосування. Як правило, прогнозування поширюється

тільки на поточний або наступний етап лікування. Водночас лікар, вибираючи

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

тривалого тимчасового періоду. Точність прогнозування значною мірою

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

досягати значної величини. У зв’язку з цим виникає необхідність у

систематизації апріорної інформації та в розробці об’єктивних методів і

засобів прогнозування [1 - 3].


За допомогою статистики можна знаходити найбільш інформативні

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

Існує безліч статистичних критеріїв і методів для підтвердження або

спростування висунутих експертом гіпотез (критерій Вілкоксона, Стьюдента,

Хі-квадрат, кореляція, метод класифікації, регресійний аналіз). Дані

статистичні критерії працюють на принципі порівняння сукупностей.

Ці методи не дозволяють безпосередньо переходити до будь-якої

прогностичної моделі. Але це не зменшує значущості критеріїв при побудові

інтелектуальної системи прийняття рішень, оскільки такий первинний

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

подальшому використовуються для прийняття рішень.

Багатовимірний статистичний аналіз став невід’ємною частиною

досліджень, що стосуються післяопераційної летальності та ускладнень

кардіохірургії. Цей метод забезпечує математичний вираз поєднаного впливу

багатьох змінних на несприятливий прогноз операції.

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

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

статистичного аналізу, виконуваного дослідниками із застосуванням сучасних

інформаційних технологій.

По моделі вирішують основні завдання дослідження, серед яких:

вивчення характеру зміни показника при зміні діючих на систему чинників;

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

величини для заданих рівнів факторів; визначення оптимальних рівнів

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

системи. Побудова таких моделей проводитися на основі вибіркового

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

представляє собою матрицю спостережень з числом рядків, що дорівнює

кількості об’єктів, що спостерігалися і числом стовпців, що дорівнює кількості


контрольованих факторів і модельованого вихідного показника на фактори,

що впливають.

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

побудови моделі показника – рівняння регресії – застосовують багатовимірний

регресійний аналіз. Коефіцієнти моделі при цьому визначаються методом

найменших квадратів. В основу методу найменших квадратів закладений

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

показника за моделлю від значень, що спостерігалися у вибірці [4].

В умовах спостереження якісних оцінок вихідного показника всього на

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

регресію, що представляє собою нелінійну функцію розподілу ймовірностей.

Коефіцієнти рівняння логістичної регресії визначається методом

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

максимізації ймовірності відповідності, адекватності прогнозованих по

модулям рівнів вихідного показника з значеннями цього показника, що

спостерігалися у вибірці.

Бінарна логістична регресія, застосовується у разі, коли залежна змінна є

бінарною (тобто може приймати тільки два значення). Іншими словами, за

допомогою логістичної регресії можна оцінювати вірогідність того, що подія

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

ускладнень і т.д.).

У клінічній медицині метод логістичної регресії дозволяє отримати

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

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

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

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

Методи математичної статистики для прийняття рішень


Складність та різноманітність методів ІАД вимагають створення

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

аналізу інформації в конкретних областях оскільки, ці засоби

використовуються у складі складних багатофункціональних систем підтримки

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

Для статистичного аналізу та подальшого моделювання було застосовано

метод бінарної логістичної регресії (БЛР) з примусовим включенням ознак, які

статистично значимо корелювали з післяопераційними ускладненнями у

хворих з ІХС після АКШ в ранньому післяопераційному періоді [4];

Результатом логістичного регресійного аналізу є розрахунок оцінок

регресійних коефіцієнтів a0, a1, a2, … an рівняння [5]:

011... axaxaz

nnnn

, (1.1)

де n

x...1

– прогностично цінні незалежні (пояснюючі) ознаки. Значення

коефіцієнтів n

a...1

представляють собою натуральні логарифми відношення

шансів – odds ratio (OR) для кожного з відповідних предикторів n

x . Значення

z у рівнянні регресії – це натуральний логарифм OR для випадку, що

вивчається, тобто ))1/(ln( ppz . Вірогідність настання події для кожного

конкретного випадку обчислюється за формулою [5]:

zep

1

1, (1.2)

де p – вірогідність настання події,


е – експонента, основа натуральних логарифмів 2,71.

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

значна, при великих – ймовірність позитивного ефекту зростає від 0,5 до 1.

Результат рішення в ПП SPSS включає:

– таблицю коефіцієнтів моделі з оцінками їх значимості;

– таблиці прогнозованих за моделлю значень показника р;

– класифікаційну матрицю, що характеризує абсолютні величини та

відносні частоти правильних прогнозів позитивних і негативних значень

моделі;

– рівень значущості моделі за критерієм Хі-квадрат;

– оцінку відповідності розподілу залишків нормальному закону;

– відношення шансів, що виражає співвідношення ймовірностей

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

досліджуваного фактору [6 - 8].

Модель визнається значущою при рівні значущості р ≤ 0,05

(достовірності 1–р ≥ 0,95).

Слід зазначити, що в процедурі Logistic Regression ПП SPSS можливий

покроковий відбір значущих коефіцієнтів для включення в модель. З цією

метою задається критичне значення критерію Фішера F ≥ 4, що забезпечує

рівень значущості коефіцієнтів р ≤ 0,05.


Класифікація медичних інформаційних систем

Ключовою ланкою в інформатизації охорони здоров'я є інформаційна

система. Класифікація медичних інформаційних систем ґрунтується на

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

Розрізняють:

1) медичні інформаційні системи базового рівня, основна мета яких –

комп'ютерна підтримка роботи лікарів різних спеціальностей, вони

дозволяють підвищити якість профілактичної і лабораторно-діагностичної

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

кваліфікованих фахівців. За розв'язуваними завданнями виділяють:

- інформаційно-довідкові системи (призначені для пошуку і видачі

медичної інформації на запит користувача);

- консультативно-діагностичні системи (для діагностики патологічних

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

захворюваннях різного профілю);

- апаратно-комп'ютерні системи (для інформаційної підтримки або

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

контакті з організмом хворого);

- автоматизовані робочі місця фахівців (для автоматизації всього

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

інформаційної підтримки при прийнятті діагностичних і тактичних лікарських

рішень);

2) медичні інформаційні системи рівня лікувально-профілактичних

установ. Представлені наступними основними групами:

- інформаційними системами консультативних центрів (призначені для

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


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

невідкладних станах);

- банками інформації медичних служб (містять зведені дані про якісний

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

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

необхідні відомості);

- персоніфікованими регістрами (містять інформацію щодо

прикріпленого або спостережуваного контингенту на основі формалізованої

історії хвороби або амбулаторної карти);

- скрінінговими системами (для проведення долікарського

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

хворих, що потребують у допомоги фахівця);

- інформаційними системами лікувально-профілактичної установи

(засновані на об'єднанні всіх інформаційних потоків у єдину систему і

забезпечують автоматизацію різних видів діяльності установи) ;

- інформаційними системами НДІ і медичних вузів (вирішують 3

основні завдання: інформатизацію технологічного процесу навчання, науково-

дослідної роботи і управлінської діяльності НДІ і вузів) ;

3) медичні інформаційні системи територіального рівня. Представлені:

- системи територіального органу охорони здоров'я;

- системи для вирішення медико-технологічних завдань, які

забезпечують інформаційною підтримкою діяльність медичних працівників

спеціалізованих медичних служб;

- комп'ютерні телекомунікаційні медичні мережі, які забезпечують

створення єдиного інформаційного простору на рівні регіону;

- федеральний рівень, призначений для інформаційної підтримки

державного рівня системи охорони здоров'я [9].


2 РОЗРОБКА АЛГОРИТМУ ТА АРХІТЕКТУРА ВЕБ-ІНТЕГРОВАНОГО

СЕРЕДОВИЩА

Структура алгоритму

За допомогою методу БЛР було створено математичні моделі

прогнозування розвитку ГСН за статистично значимими факторами.

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

приймальному, передопераційному та операційному відділеннях.

Розподіл змінних досліджувався за допомогою критерію Колмогорова-

Смірнова на відповідність нормальному розподілу. Для нормально

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

за допомогою t-критерію Ст’юдента. Для інших безперервних змінних та

дискретних було використано критерій Мана-Уітні. Для бінарних змінних

здійснювався частотний аналіз за допомогою критерію 2.

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

ретроспективний масив було розділено на навчальну (N = 2769) та перевірочну

(N = 1030) вибірки, відповідно. Після попереднього аналізу та аналізу зв’язків

вихідних даних за допомогою кореляційного аналізу у навчальній вибірці для

подальшого дослідження залишилося 20 ознак. Всі вони мали статистично

значимий (р < 0,05) кореляційний зв'язок з розвитком ГСН в ранньому

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

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

розвитку гострої серцевої недостатності представляється неможливим. Тому

було застосовано крокові методи БЛР для виявлення структури факторів

ризику.


Модель, представлена рівнянням БЛР (1.1), визначає структуру факторів,

що зумовлюють розвиток ГСН в ранньому післяопераційному періоді у

пацієнтів навчальної вибірки з ІХС після АКШ, має наступний вигляд:

zek

1

1, (2.1)

де 01n1nnn a...xaxaz ;

k – ймовірність розвитку ГСН в ранньому післяопераційному періоді;

е – експонента, основа натуральних логарифмів;

z – показник, що визначає ступінь впливу факторів ризику на розвиток

ГСН;

n...1a – вагові коефіцієнти рівняння регресії;

n...1x – фактори, що впливають на розвиток ГСН.

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

правдоподібності (ВП) бінарної логістичної регресії за допомогою модуля

Binary Logistic ПП IBM SPSS Statistics 20.0.

Після попереднього аналізу вихідних даних за допомогою крокового

методу відбору змінних до моделі, залишилося 9 показників. Значення

показників a1…m та x1…m, частота розподілу, їх статистична значущість та

відносний ризик (відношення шансів) розвитку ГСН у навчальній вибірці

ретроспективного масиву за 2008 – 2011 рр. (табл. 2.1).

Таблиця 2.1 - Фактори ризику, які ввійшли в модель прогнозування

№

п/п Фактори ризику

Ум.

позн.

в

мат.

мод.

Число пацієнтів n

Відношення

шансів OR

(95% CI)

Коеф.

регресії

a1…n

Рівень

значу-

щості, p

Відсутність

ГСН

n=2641

наявність

ГСН

n=128

1 2 3 4 5 6 7 8

1

Задишка: немає

X1

2586 114 1,0

0,46 0,004 є у стані спокою 55 14

2,9

(1,4–5,9)


Продовження таблиці 2.1

2

Характер

стенокардії:

спокою X2

948 68 1,0 0,61 < 0,001

напруги 1693 60 0,4 (0,3–0,6)

3

Недостатність АК:

немає X3 2529 116 1,0

0,91 0,001

є 112 12 3,3 (1,6–6,5)

4

Стеноз лівої

коронарної артерії

> 50%: немає X4

2465 108 1,0 0,79 0,001

є 176 20 2,6 (1,5–4,5)

5 ДМШП: немає

X5 2634 120 1,0

1,43 0,014 є 7 8 2,6 (1,5–4,5)

6

Застосування ШК:

планово X6 2057 41 1,0

2,68 < 0,001

екстрено 584 87 14,8 (9,5–23,2)

7

Істинна аневризма:

немає X7 2234 102 1,0

–1,23 < 0,001

є 407 26 0,2 (0,1–0,4)

8

Маніпуляції на

аортальному

клапані: немає X8

2544 123 1,0 –2,01 < 0,001

є 95 7 0,1 (0,1–0,4)

9

Переливання

препаратів крові:

немає X9

2627 122 1,0 1,26 0,005

є 14 6 5,1 (1,6–16,1)

a0 = –8,79

Математична модель прогнозування ймовірності розвитку ГСН в

ранньому післяопераційному періоді після АКШ на навчальній вибірці

ретроспективного масиву, на основі формули (2.1), має наступний вигляд:

11

11 z

ek

,


де z1 = 0,46·x1 + 0,61·x2 + 0,91·x3 + 0,79·x4 + 1,43·x5 + 2,68·x6 –

– 1,23·x7 – 2,01·x8 + 1,26·x9 – 8,79. (2.2)

k1 – ймовірність розвитку ГСН в ранньому післяопераційному періоді на

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

операційних факторів;

e – експонента, основа натуральних логарифмів;

z1 – показник, що визначає ступінь впливу ФР на розвиток ГСН;

x1..n – доопераційні та операційні фактори, що впливають на розвиток

ГСН.

З даних таблиці 2.1 (стовпець 5) видно, що найбільші шанси розвитку

ГСН в ранньому післяопераційному періоді мають хворі, яких було

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

процедури та тяжкий стан хворих. Крім того, висока ймовірність розвитку

ГСН у хворих в яких присутній дефект міжшлуночкової перегородки (ДМШП)

та хворі, яким робили переливання крові.

Відсутність у моделі таких вагомих факторів, як інфаркт міокарда в

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

те, що у відділенні з цими факторами успішно справляються і підтримують

необхідні показники на належному рівні, тобто вплив їх успішно нівелюється

в процесі передопераційної підготовки хворого.


Архітектура веб-інтегрованого середовища

На даний момент, розробка складних та масштабних веб-інтегрованих

середовищ проводиться з використанням архітектурного шаблону MVC. Цей

шаблон набув значного розповсюдження та віднесений до найкращих практик

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

зобов’язань між компонентами програми та зручному подальшому

масштабуванню та модифікації середовища.

Моде́ль – вигляд – контро́лер (або Модель – вид – контролер, англ. Model

– view – controller, MVC) — архітектурний шаблон, який використовується під

час проектування та розробки програмного забезпечення.

Цей шаблон поділяє систему на три частини: модель даних, вигляд даних

та керування. Застосовується для відокремлення даних (модель) від

інтерфейсу користувача (вигляду) так, щоб зміни інтерфейсу користувача

мінімально впливали на роботу з даними, а зміни в моделі даних могли

здійснюватися без змін інтерфейсу користувача.

Мета шаблону — гнучкий дизайн програмного забезпечення, який

повинен полегшувати подальші зміни чи розширення програм, а також

надавати можливість повторного використання окремих компонентів

програми. Крім того використання цього шаблону у великих системах

призводить до певної впорядкованості їх структури і робить їх зрозумілішими

завдяки зменшенню складності [10].


Рисунок 2.1 – Діаграма взаємодії між компонентами шаблону

MVC поділяє програму на три частини. У тріаді до обов'язків

компоненту Модель (Model) входить зберігання даних і забезпечення

інтерфейсу до них. Вигляд (View) відповідальний за представлення цих

даних користувачеві. Контролер (Controller) керує компонентами, отримує

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

компоненту Модель. Така внутрішня структура в цілому поділяє систему на

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

MVC поділяє цю частину системи на три самостійні частини: введення

даних, компонент обробки даних і виведення інформації. Модель, як вже

було відмічено, інкапсулює ядро даних і основний функціонал з їх обробки.

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

даних. Компонент виводу Вигляд може мати декілька взаємопов'язаних

областей, наприклад, різні таблиці і поля форм, в яких відображається

інформація. У функції Контролера входить моніторинг за подіями, що

виникають в результаті дій користувача (зміна положення курсора миші,

натиснення кнопки або введення даних в текстове поле).

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

компонентам Моделі або об'єктам, відповідальним за відображення даних.

Відокремлення моделі від вигляду даних дозволяє незалежно

використовувати різні компоненти для відображення інформації. Таким

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


інформація, подана одним або декількома візуальними компонентами, буде

автоматично відкоригована відповідно до змін, що відбулися [10].

В якості фреймворка, що реалізує архітектурний шаблон MVC, для

побудови веб-інтегрованого середовища було обрано Spring MVC [11]. В

основі цього фреймворку, як і всіх інших з екосистеми Spring Framework,

лежить концепція впровадження залежностей.

Впровадження залежностей

Впровадження залежності (англ. Dependency injection, DI) — процес

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

«інверсію управління» (англ. Inversion of control, IoC) для розв'язання

(отримання) залежностей.

Впроваждення — це передача залежності (тобто, сервісу) залежному

об'єкту (тобто, клієнту). Передавати залежності клієнту замість дозволити

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

проектування.

Існує три найбільш поширені форми впровадження залежностей:

- впровадження в конструктор,

- впровадження у властивість,

- впровадження в метод.

Впровадження залежностей — це шаблон проектування, в якому

залежності (або сервіси) впроваджуються, або передаються по посиланню в

залежний об'єкт (клієнт) і стають частиною клієнтського стану. Шаблон

відокремлює створення залежностей клієнта від власної логіки клієнта, що

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


інверсії залежностей і єдиного обов'язку. Це протирічить анти-шаблону service

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

пошуку залежностей.

До переваг даного підходу слід віднести:

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

коду, його можна застосувати у якості рефакторингу. В результаті

цього клієнти стають більш незалежними і над ними легше

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

об'єкта, які імітують інші об'єкти, від яких залежить об'єкт, що

тестується. Простота тестування найчастіше є першою помітною

перевагою використання впровадження залежностей;

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

конкретну реалізацію, яку йому потрібно використовувати. Це

дозволяє ізолювати клієнт від впливу змін проектування і дефектів.

Це сприяє повторному використанню, тестуванню і підтримці коду;

- впровадження залежностей може використовуватися для

перенесення деталей конфігурації системи в конфігураційні файли,

що дозволяє системі змінювати конфігурацію без перекомпіляції.

Окремі конфігурації можуть бути написані для різних ситуацій, що

вимагають різних реалізацій компонентів;

- впровадження залежностей сприяє паралельній і незалежній

розробці. Два розробника можуть незалежно створювати класи, які

використовують один одного, знаючи тільки про інтерфейси, через

які класи співпрацюють;

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

залежностями [12].


3 РЕАЛІЗАЦІЯ ПРОГРАМНОГО ПРОДУКТУ ТА РЕЗУЛЬТАТИ

РОБОТИ

3.1 Створення програмного продукту

Для реалізаціії веб-інтегрованого середовища дослідження стану

системи кровообігу було обрано мову програмування Java.

Завдяки цьому вибору веб-інтегроване середовище може бути

розгорнуте на веб-сервері під керуванням будь-якої операційної системи

(GNU/Linux та інші UNIX-подібні ОС, MAC ОС X та Windows).

При розробці цієї програми були використанні наступні фреймворки:

- Spring MVC [11] – фреймворк для побудови складних та

масштабних веб-інтегрованих середовищ;

- Hibernate [13] – фреймворк об’єктно-реляційного відображення, що

дозволяє відображати об’єкти бази даних у об’єкти програми;

- Spring Boot [14] – фреймворк, що пришвидшує розробку програмних

продуктів, що базуються на Spring Framework;

- Thymeleaf [15] – фреймворк для побудови інтерфейсу користувача у

програмних продуктах, написаних на мові програмування Java.

Після запуску веб-інтегрованого середовища на вбудованому контейнері

сервлетів Apache Tomcat [16], перейшовши у веб-браузері за посиланням

http://localhost:8080 (або за іншим посиланням на сервер, на якому було

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

авторизації користувача (рисунок 3.1).


Рисунок 3.1 – Сторінка авторизації користувача

Розроблене веб-інтегроване середовище реалізує наступний функціонал:

а) авторизація користувача;

б) захист персональних даних пацієнтів;

в) CRUD-функціонал;

г) пошук пацієнта в базі;

д) прогнозування ймовірності розвитку ГСН для кожного окремого

пацієнта.

Домашня сторінка користувача представлена на рисунку 3.2.


Рисунок 3.2 – Домашня сторінка користувача

Вигляд сторінки пошуку пацієнта представлений на рисунку 3.3.

Рисунок 3.3 – Вигляд сторінки пошуку пацієнта

Оскільки Java є кросплатформною мовою програмування, розроблене

веб-інтегроване середовище можна розгорнути на будь-якій робочій станції із

встановленим Java Development Kit версії 8. Встановлення додаткових

компонентів не потрібне, оскільки готовий jar-архів вже містить у собі

вбудований контейнер сервлетів.

Лістинг коду розробленого веб-інтегрованого середовища наведено у

Додатку А.


4 ОХОРОНА ПРАЦІ ТА БЕЗПЕКА В НАДЗВИЧАЙНИХ СИТУАЦІЯХ

Вступ

Метою даного розділу є дослідження санітарно-гігієнічних умов праці,

умов безпеки праці і пожежної безпеки науково-дослідницької лабораторії. У

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

заходи щодо їх оптимізації.

Характеристика об’єкту та умови його експлуатації

Науково-дослідницька лабораторія знаходиться на першому поверсі.

Лабораторія поділяється на 2 частини: робочий відсік та вимірювальний

відсік.

План лабораторії наведений на рисунку 4.1 та характеристика вказані в

таблиці 4.1.

Таблиця 4.1 – Характеристики приміщення

Параметри Кількісна і візуальна характеристика

Розміри приміщення 14,85 м × 6 м × 3 м

Кількість працюючих 1 чол.

Площа кабінета 14,85 м × 6 м= 89.1 (м2)

Об'єм кабінета 14,85 м × 3,0 м × 6 м = 267.3 (м3)

Площа вимірювального відсіку 8,6 м × 6 м = 51.6 (м2)

Об'єм вимірювального відсіку 8,6 м × 6 м × 3,0 м = 154.8 (м3)


У приміщенні знаходиться ПЕОМ – модель Core 2 Duo Processor E6750,

принтер HP DeskJet F2483, сканер Epson GT-1500, а за перегородкою

знаходиться МР-томограф General Electric SIGNA HDx 1.5T. В таблиці 4.2

приведені характеристики обладнання.

Таблиця 4.2 – Характеристики обладнання

Обладнання Характеристика

МР-томограф

General Electric

SIGNA HDx 1.5T

Максимальная выходная мощность - 21 кВт при

сканировании тела и 4 кВт при сканировании головы;

напряженность магнитного поля 1.5 Tesla;

шиммирование - 18 сверхпроводящих катушек,

экранирование – активное, охлаждение - криогенное

ПЕОМ (2 шт.)

Модель Core 2 Duo

Processor E6750

Частота процесора - 2.66 ГГц; потужність, що

розсіюється 65 Вт; критична температура 72 ° C;

напруга живлення 0.850 - 1.350 В.

TFT монітор LG

Flatron L1750SQ (2

шт.)

Тип РК-матриці: TFT TN; максимальна роздільна

здатність, пікселі: 1280x1024; яскравість: 250 кд/м2;

контрастність: 550:1; споживана потужність під час

роботи, Вт: 40

Стул (1 шт.) Габарити (ШхДхВ): 600х600х1000 мм

Стіл (1 шт.) Габарити (ШхДхВ): 1800х1000х1000 мм

Принтер HP DeskJet

F2483 (1 шт.)

U= 110~220 В, Р (при роботі)= 22,8 Вт

Сканер Epson GT-

1500 Р (при роботі)= 12,5 Вт

Кондиціонер

SAMSUNG

AQ12UGF

Тип: спліт-система; холодо/теплопродуктивн.: 3,5/3,8

кВт; обігрів/охолодження: 1,053/1,09 кВт; габарити

зовнішнього блока: 470х660х240 мм. Вес: 25 кг.


Рисунок 4.1 – План приміщення

При розміщенні обладнання в приміщенні слід дотримуватись норм

ДСанПІН 3.3.2.007-98 [17]. У даному приміщенні норми розміщення та

відстаней наведені у таблиці 4.3.

Таблиця 4.3 – Норми відстаней за ДСанПІН 3.3.2.007-98

Параметр Норма Фактично

Площа, Sкаб Не менше 6 (м2) 51.6 (м2)

Об’єм, Vкаб Не менше 20 (м3) 154.8 (м3)

Відстань від томографа до стіни 0.9 (м) 1 (м)

Прохід Не менше 1 (м) 1,7 (м)

Двері 1 (м) × 2.1 (м) 1(м)×2.1 (м)

Вікно 1.200 (м) × 2 (м) 1.6 (м) × 2 (м)

Відстань до робочого місця 1.5 (м) 2 (м)


Реальні показники повністю відповідають вимогам всіх нормативних

документів з ОП.

Оцінка небезпечних i шкідливих виробничих факторів та

розробка заходів по покращенню (нормалізації) умов праці при

технологічному процесі (розробці програмного продукту).

Небезпечні та шкідливі виробничі чинники відповідно до ГОСТ

12.0.003-74 [18] за природою дії поділяються на 4 групи (таблиця 4.4).

Таблиця 4.4 – Небезпечні та шкідливі виробничі фактори

Фізичні Хімічні Біологічні Психо-фізіологічні

Електронебезпека,

механічні небезпеки,

небезпека пожежі,

електромагнітне

поле, мікроклімат,

шум та вібрація

Аерозолі

(пил, пари),

гази (рідкий

гелій)

Патогенні

мікроорганізми

Розумове

перенавантаження,

клаустрофобія.

Будуть проаналізовані найнебезпечніші шкідливі фактори.


4.2.1 Електромагнітне випромінювання

Допустимі значення електромагнітного випромінювання

регламентуються "Державними санітарними нормами і правилами захисту

населення від впливу електромагнітних випромінювань" [19]. Наслідки

враження електромагнітним випромінюванням описані в таблиці 4.5.

Таблиця 4.5 – Вплив електромагнітного випромінювання

Фактор Наслідки

Для людини Для обладнання

Електромагнітне

випромінювання

Вплив на нервову,

імунну, ендокринну

системи

Зміна фізики роботи приладу

Нормативні та фактичні значення наведені в таблиці 4.6.

Таблиця 4.6 – Параметри електромагнітного випромінювання

Фактор ГДД реальне, Тл ГДД нормативне, Тл

Індукція магнітного поля 1.5 3

Засоби і заходи захисту наведені у таблиці 4.7. Дотримання правил

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

електромагнітного випромінювання.


Таблиця 4.7 – Захист від електромагнітного випромінювання

Вид захисту Заходи подолання небезпеки

Технічні

заходи

Екранування джерел випромінювання ЕМП;

екранування робочих місць; дистанційне керування

установками, до складу яких входять джерела ЕМП;

застосування попереджувальної сигналізації. Для

захисту обладнання від згубної дії ЕМП застосовується

активне екранування.

Організаційні

заходи

Розміщення об'єктів, які випромінюють ЕМП таким

чином, щоб звести до мінімуму можливе опромінення

людей; "захист часом" - перебування персоналу в зоні дії

ЕМП обмежується мінімально необхідним для

проведення робіт часом; "захист відстанню" - віддалення

робочих місць на максимально допустиму відстань від

джерел ЕМП; "захист кількістю" - потужність джерел

випромінювання повинна бути мінімально необхідною;

виділення зон випромінювання ЕМП відповідними

знаками безпеки; проведення дозиметричного

контролю.

ЗІЗ Спецодяг, виготовлений з металізованої тканини у

вигляді комбінезонів, халатів.

Індукція електромагнітного поля не перевищує встановлених норм.


4.2.2 Небезпека враження людини електричним струмом

Енергопостачання кабінетів МРТ здійснюється від трансформаторної

підстанції (ТП), що знижує високу напругу розподільчої мережі,

характеристики мережі приведені в таблиці 4.8. Для меншого впливу різких

змін мережевої напруги, які викликані включенням і вимиканням інших

споживачів ТП, енергопостачання МР-томографа здійснюють безпосередньо

від досить потужної підстанції.

Таблиця 4.8 – Характеристика електромережі

Напруга живлення від мережі 220 В

Частота 50 Гц

Сила струму від 0,1 до 1А

Характеристики приміщення за ступенем ураження електричним

струмом представлені в таблиці 4.9.

Таблиця 4.9 – Основні характеристики приміщення

Ступінь ураження Вологість Підлога Середовище

З підвищеною

небезпекою

Часто

перевищує

75%

Вкрита

гумовими

пластинами

Хімічно

активне

Відповідно до категорії приміщення у приміщенні застосовуються

засоби електробезпеки, представлені в таблиці нижче.


Таблиця 4.10 – Заходи захисту від дії електричного струму

Вид захисту Засоби подолання небезпек:

Технічні В

обладнанні

Ізоляція обладнання відповідно

нормам; підключення устаткування

відповідно вимогам ПБЕ і ПУЕ;

В

приміщенні

Щитки ЕЩР-0-6 та блоки розеток Р-06М;

- прихована проводка;

- підлога вкрита антистатичним

лінолеумом.

Організаційні - встановлення знаків безпеки (кнопка

ручного вмикання, телефон для

сповіщення, евакуаційний вихід,

вогнегасник, заборона палити); проведення

інструктажу з правил техніки безпеки.

ЗІЗ - не передбачені

Персонал ознайомлений з правилами техніки безпеки при роботі з МР-

томографом. Можна зробити висновки, що дане приміщення відповідає

вимогам з електробезпеки ДНАОП 0.00-1.31-99 [20].

4.2.3 Небезпеки, пов’язані з рухомими механізмами

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

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

для здоров’я людини. Характеристика небезпечних факторів наведена у

таблиці 4.11.


Таблиця 4.11 – Фактори і наслідки механічної небезпеки

Джерела небезпеки Небезпеки

Для людини Для обладнання

Магніт томографа спричинення

травм, вібрація,

клаустрофобія

-механічні пошкодження;

-електронебезпека. Стіл пацієнта

Дотримання правил безпеки наведених в таблиці 4.12 попереджує

виникнення виробничого травматизму.

Таблиця 4.12 – Засоби і заходи захисту від механічних небезпек

Технічні В обладнанні Електрогальма; дистанційне керування;

ремені та кріплення для голови та тіла

пацієнта

В приміщенні Дотримання стандартів розміщення

обладнання

Організаційні Всі працюючі ознайомлені з правилами

експлуатації; проведення первинних та

додаткових інструктажів

Індивідуальні Відсутні

4.2.4 Хімічна безпека

Нормування шкідливих речовин проводять по гранично допустимих

концентраціях (ГДК, мг/м3) у відповідності з ГОСТ 12.1.005-88 [21], СН 245-

71 «Шкідливі речовини. Класифікація і загальні вимоги безпеки» [22]. Хімічні

речовини присутні в приміщенні описані в таблиці 4.13.


Таблиця 4.13 – Хімічні небезпечні фактори в повітрі приміщення

Назва речовини Клас

небезпеки

Наслідки

Для людини Для

обладнання

Трихлорметан

(хлороформ)

2 Запаморочення,

слабкість

Корозія та

окислення

Хлор 2 Запаморочення

Йод 2 Опіки

Спирт метиловий 3 Головні болі,

нудота

Пропілен 3 Головні болі

Оксид вуглецю 4 Сонливість,

слабкість

Спирт етиловий 4 Опіки,

гіпертермія

Таблиця 4.14 – Реальні та нормативні значення

Речовина ГДКнормативне, мг/м3 ГДКфактичне, мг/м3

Трихлорметан (хлороформ) 0,1 0,03

Хлор 0,1 0,03

Йод 0,1 0,03

Спирт метиловий 1,0 0,5

Пропілен 3,0 3,0

Оксид вуглецю (СО) 3,0 1,0

Спирт етиловий 5,0 4,6


Таблиця 4.15 – Засоби і заходи для захисту

Вид захисту Засоби подолання небезпеки

Технічні

заходи

В обладнанні контроль шкідливих речовин

газоаналізатором УГ-2;

В приміщенні - розпилення пропіленгліколю – 1г на 5м3

повітря;

- постійна вентиляція приміщення

кондиціонером типу «спліт».

Організаційні заходи - проведення інструктажу з техніки

безпеки.

ЗІЗ - маски медичні тришарові з нетканого

матеріалу та латексні рукавички

Ambulance PF.

Вміст шкідливих речовин в приміщенні не перевищує норми і є

допустимим для безпечної роботи персоналу

4.2.5 Шум

Таблиця 4.16 – Джерела виникнення шуму і наслідки

Джерело шуму Наслідки

Кондиціонер - порушення слуху працівника;

- зниження рівня працездатності;

- втомлюваність і загальна

раздратованість;

- віброакустичний дискомфорт.

Сканер

Принтер


ПК

Зовнішній шум від транспорту


Таблиця 4.17 – Порівняння нормованого і фактичного шумів

Джерело шуму Рівень

звуку

Li, дБА

Час

впливу

звуку ti,

год

Кількість

n, шт

Нормований

рівень шуму,

дБА (ДСН

3.3.6.037-99 )

Фактичний

рівень

шуму, дБА

МР-томограф 63 8 1

<50

84,11

Кулер процессора

Intel Core Duo 430

18 8 4

Жорсткий диск

120Gb 7200rpm

SATAII

25 8 4

Зовнішній шум

(вулиця та

внутрішній шум)

35 8 1

Кондиціонер

SAMSUNG

AQ12UGF

30

4

2

Таблиця 4.18 – Заходи для нормалізації параметрів шуму

Вид захисту Засоби подолання небезпеки

Технічні заходи Кулери для відсутності шуму від

перегріву (30%)

Перегородка з шумоізоляцією для

зменшення шуму в робочому

місці (70%)

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

охолодження(кондиціонер) та

МР-тофографа (85%)

Перевірка на відсутність зазорів

(15%)

ЗІЗ навушники, СОМЗ-1 (100%)


Рівень звуку у приміщенні перевищує встановлені норми (за ДСН

3.3.6.037-99 «Санітарні норми виробничого шуму, ультразвуку та інфразвуку»

[23]). Для того, щоб захистити працівників необхідна товща перегородка від

вимірювального відсіку. Нижче розраховується товщина перегородки.

Розрахунок.

Lо = 85 дБ — фактичний шум, LД = 50 дБ — норма шуму.

R = Lо – Ld - LД = 85 - 10 - 50 = 25 дБ — звукоізолююча здатність, де

Ld = 10lg(a0*S0/a1*S1) = 10lg(0.31*8.4 / 0.032*8.4) = 10, де a0 -

коефіцієнт звукопоглинання шлакобетону, a1 - коефіцієнт звукопоглинання

акустичної штукатурки S0, S1 - поверхня стінок (1,5*2*2,8) у м3.

Значенню R=25дБ по відповідає шлакобетонна стіна товщиною h0 = 22

(мм).

4.2.6 Пожежна безпека при надзвичайних ситуаціях

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

конструктивні елементи - не спалювані. Будинок відноситься до I-II ступеня

вогнестійкості. Межа вогнестійкості конструкції 0,5 -2,5 ч.

У вказаному приміщенні можливі горючі матеріали вказані у табл. 4.19.


Таблиця 4.19 – Горючі матеріали

№ Тип матеріалу Температура горіння

1 Папір 233 °C

2 Поліетилен 310-340 °C

3 Дерево 300 °C

4 ABS-пластик 450 °C

При вказаних горючих матеріалах приведена характеристика

приміщення.

Таблиця 4.20 – Характеристика пожежонебезпечності приміщення

Клас пожежі А2 – горіння твердих речовин, що не

супроводжуються тлінням; Е - горіння

електроустановок, під напругою до 1000 В

Підклас пожежі А1 горіння супроводжується тлінням (А2

обернено до А1)

Вибухопожежонебезпеч

на

Категорія В (пожежонебезпечна)

Клас робочої зони

приміщення по

пожежній безпеці

Клас - П-ІІа

Горючі матеріали та

речовини

Волокнисті (папір), тверді (столи, стільці,

двері, шафи), пластикові (вікно, стільці,

лінолеум, комп’ютер)


Таблиця 4.21 – Джерела та наслідки

Джерела Небезпечний

фактор

Наслідки


ПЕОМ

Коротке

змикання

Опіки живих

тканин

Виникнення

пожежі

Знищення

необхідних

речей

Матеріали і

речовини

схильні до

займання

Загоряння

матеріалів

Для запобігання пожежі у приміщенні вжито наступні заходи

протипожежної безпеки зазначені в таблиці 4.22.

Таблиця 4.22 – Заходи протипожежної безпеки

Вид захисту Заходи подолання небезпеки

Технічні

заходи

Кімната обладнана чотирма ручними

вуглекислотними вогнегасниками ОУ-3 згідно з (на

кожні 20м2 приміщення повинно бути 2

вогнегасники, але в жодному разі не менше двох).

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

вимикачів. Використовуються сповіщувачі СП 212-

45 (сповіщувачі типу «димні»), що встановлені в

якості пожежної сигналізації у кількості 5 шт.

рівномірно розподілених по всій поверхні стелі. У

коридорі присутній спеціальний щит пожежного

гідранта з відповідним рукавом.


Продовження таблиці 4.22

Організаційні

заходи

Керівником персоналу призначене

відповідальна особа, яка відповідає за дотримання

персоналом вимог пожежної безпеки. Розроблено

план евакуації персоналу офісного приміщення.

Вільний доступ до вимикача електроживлення.

ЗІЗ Не передбачені

Рисунок 4.2 – План евакуації з першого поверху при пожежній небезпеці


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

Параметри даного кабінету відповідають встановленим нормам.

Підтримання відповідного рівня мікрокліматичних показників

використовують необхідні засоби та здійснюють заходи їх контролю. Щоб

зменшити вплив шкідливих речовин на організм людини приймають

відповідні захисні міри. Для задовольнення ДНАОП 0.00.1.31-99 і ДСанПіН

3.3.2-007-98 між праціниками і МР-томографом повинна стояти

шлакобетонна стінка з товщиною 22 мм.


5 ЕКОНОМІЧНА ЧАСТИНА

Вступ

У даній роботі проводиться оцінка основних характеристик веб-

інтегрованого середовища дослідження стану системи кровообігу.

Програмний продукт був розроблений на мові програмування Java, з

застосуванням фреймворків Spring MVC, Spring Boot, Spring Data JPA,

Hibernate, Thymeleaf у інтегрованому середовищі розробки IntelliJ IDEA

15.0.2. Програмний продукт призначено для розгортання на будь-якому веб-

сервері або персональному комп’ютері під керуванням будь-якої операційної

системи із встановленими JDK 1.8 та СКБД MySQL. Веб-інтегроване

середовище розгортається на вбудованому контейнері сервлетів Apache

Tomcat 8.0.27. Взаємодія з середовищем відбувається за допомогою будь-

якого браузера за відповідним посиланням. Веб-інтерфейс побудований за

допомогою Thymeleaf template engine, HTML, CSS та Javascript.

Розроблене веб-інтегроване середовище покликане централізувати та

уніфікувати роботу з базою даних пацієнтів, захистити персональні дані

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

недостатності.

Проаналізуємо різні варіанти реалізації модуля з метою вибору

оптимальної, враховуючи як на економічні фактори, зокрема такі,

характеристики продукту, що впливають на продуктивність роботи і на його

сумісність з апаратним забезпеченням. Для цього було використано апарат

функціонально-вартісного аналізу.

Функціонально-вартісний аналіз (ФВА) – це технологія, яка дозволяє

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

структури компанії. Як прямі, так і побічні витрати розподіляються по


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

обсягів ресурсів. Виконані на цих етапах дії у контексті методу ФВА

називають функціями.

Мета ФВА полягає у забезпеченні правильного розподілу ресурсів,

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

витрати, у нашому випадку – аналізу функцій ПП й виявлення усіх витрат на

реалізацію цих функцій.

Фактично цей метод працює за таким алгоритмом:

● визначається послідовність функцій, необхідних для виробництва

продукту. Спочатку – всі можливі, потім вони розподіляються за двома

групами: ті, що впливають на вартість продукту, і ті, що не впливають. На

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

впливають на цінність і відповідно витрати;

● для кожної функції визначаються повні річні витрати й кількість

робочих годин;

● для кожної функції на основі оцінок попереднього пункту

визначається кількісна характеристика джерел витрат;

● після того, як для кожної функції будуть визначені їх джерела

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

Обґрунтування функцій програмного продукту

Головна функція F0 – розробка веб-інтегрованого середовища, яке

дозволяє взаємодіяти з базою даних пацієнтів та обчислює вірогідність

виникнення гострої серцевої недостатності за 9-ма критеріями. Виходячи з


конкретної мети, можна виділити наступні основні функції програмного

продукту:

F1 – вибір мови програмування;

F2 – вибір методів зберігання інформації;

F3 – вибір технології проектування;

F4 – виведення результатів;

F5 – форма подання результатів;

Кожна з основних функцій може мати декілька варіантів реалізації.

Функція F1:

а) мова програмування PHP;

б) мова програмування Javascript;

в) мова програмування Java.

Функція F2:

а) MySQL;

б) Oracle DB;

Функція F3:

а) Servlet API;

б) Spring MVC.

Функція F4:

а) збереження результатів роботи в базу;

б) збереження результатів роботи у файл.

Функція F5:

а) виведення результатів роботи у вигляді таблиці;

б) виведення результатів роботи у вигляді графіку.

Варіанти реалізації основних функцій наведено у морфологічній карті

системи (рисунок 5.1). На основі цієї карти побудовано позитивно-негативну

матрицю варіантів основних функцій (таблиця 5.1)


Рисунок 5.1 – Морфологічна карта

Морфологічна карта відображає всі можливі комбінації варіантів

реалізації функцій, які складають повну множину варіантів програмного

продукту.


Таблиця 5.1 – Позитивно-негативна матриця функцій

Основні

функції

Варіанти

реалізації

Переваги Недоліки

F1

а Займає менше часу при

написанні коду

Швидкість виконання

коду

б Код швидко виконується,

кросплатформений

Займає більше часу

при написанні коду

в

Код швидко виконується,

кросплатформений, вимагає

менше часу на написання


при відладці

F2

а

Простота роботи,

розповсюдженість, добре

підходить для збереження

структурованих даних,

безкоштовна ліцензія

Відсутність вбудованої

мови програмування,

складність роботи з

кириличним текстом

б Висока надійність, наявність

вбудованої мови програмування

Складність

встановлення, роботи

та підтримки, платна

ліцензія

F3

а Швидкодія


при написанні коду,

складність підтримки

б

Швидкість розробки, витримка

логічної архітектури

програмного продукту, простота

підтримки

Нижча швидкодія

F4

a

Уніфікована форма збереження,

надійність збереження,

централізований доступ

Нижча швидкість

доступу, складність


б Швидкість доступу, простота


Нижча надійність,

відсутність

централізованого

доступу

F5 а Простота реалізації

Менша наочність

представлених даних

б Більша наочність результатів Складність реалізації

На основі аналізу позитивно-негативної матриці робимо висновок, що

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


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

продуктам задачам.

Функція F1: оскільки розрахунки проводяться з великими об’ємами

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

найважливішими факторами, отже варіант а) і б) потрібно відкинути.

Функція F2: для зниження витрат на реалізацію та через мале значення

переваг потрібно відкинути варіант б).

Функція F3: незначна перевага у швидкодії не варта тих ресурсів, що

витрачаються на написання та підтримку коду, написаного на Servlet API.

Тому потрібно відкинути варіант а).

Функція F4: через низьку надійність, відсутність уніфікованої форми

запису та загальну застарілість такого підходу потрібно відкинути варіант б).

Функція F5: через ключове значення наочності представлення даних

потрібно відкинути варіант а).

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

програмного продукту:

F1в – F2а – F3б – F4а – F5б.

Обґрунтування системи параметрів програмного продукту

Маючи вимоги щодо основних функцій, які реалізовуються в

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

використовуватимуться для розрахунку коефіцієнта технічного рівня.

Введемо наступні параметри:

- Х1 – швидкодія мови програмування;

- Х2 – об’єм пам’яті для збереження даних;


- Х3 – швидкість обробки та виводу даних

- Х4 – точність розв’язку;

- Х5 – потенційний об’єм програмного коду.

Х1: відображає швидкодію операцій залежно від обраної мови

програмування

Х2: відображає об’єм пам’яті в оперативній пам’яті персонального

комп’ютера, необхідний для збереження та обробки даних підчас виконання

програми.

Х3: відображає час, який витрачається на розрахунки;

Х4: показує точність розв’язку;

Х5: відображає розмір програмного коду для створення.

Будемо розглядати 3 типи варіантів значення параметрів.

Таблиця 5.2 – Основні параметри програмного продукту

Назва параметра Умовні

позначення

Одиниці

виміру

Значення параметра

гірші середні кращі

Швидкодія мови

програмування X1

Оп/мс 2000 11000 19000

Об’єм пам’яті для

збереження даних X2

Мб 32 16 8

Час розрахунків X3 мс 800 420 60

Точність розв’язку X4 % 10 5 1

Потенційний об’єм

програмного коду X5

кількість

строк коду

2000 1500 1000

Рисунок 5.2 – Бальна оцінка швидкодії мови програмування


Рисунок 5.3 – Бальна оцінка об’єму пам’яті, займаємого даними

Рисунок 5.4 – Бальна оцінка часу розрахунків

Рисунок 5.5 – Бальна оцінка точності розв’язку

Рисунок 5.6 – Бальна оцінка об’єму коду програмного продукту


Кожен експерт оцінює ступінь важливості кожного параметру для

конкретно поставленої цілі – розробка програмного продукту, який дає

найбільш точні результати при знаходженні апроксимуючого багаточлену.

Таблиця 5.3 – Результати ранжування параметрів

Розрахуємо коефіцієнт конкордації (узгодженості) експертних оцінок.

Таблиця 5.4 – Результати ранжування показників

Порахуємо коефіцієнт узгодженості:

Для перевірки степені достовірності експертних оцінок, визначимо

наступні параметри:

а) сума рангів кожного з параметрів і загальна сума рангів:


138

2

1

nNnRrR ijij

Nji

де N – кількість експертів, n – кількість параметрів;

б) середня сума рангів:

6,271

ijRn

T

в) відхилення суми рангів кожного параметра від середньої суми рангів:

TRii

Сума відхилень по всім параметрам повинна дорівнювати 0;

г)загальна сума квадратів відхилення:

n

i

iS1

2 2,505

67,003,1

55*7

2,505*12,

123232

kWWnnN

SW

Ранжирування можна вважати достовірним, тому що знайдений

коефіцієнт узгодженості перевищує нормативний, котрий дорівнює 0,67.

Скориставшись результатами ранжирування, проведемо попарне

порівняння всіх параметрів і результати занесемо у таблицю.

Числове значення, що визначає ступінь переваги i–го параметра над j–

тим, aij визначається по формулі:

ji

ji

ji

ij

XX

XX

XX

a

,5.0

,1

,5.1

З отриманих числових оцінок переваги складемо матрицю A=║ aij ║.

Для кожного параметра зробимо розрахунок вагомості Kві за наступними

формулами:


де

b

bE

n

ii

i

a,ˆ

1

ˆ3

n

iiji ab

1

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

значення не будуть незначно відрізнятися від попередніх (менше 2%).На

другому і наступних кроках відносні оцінки розраховуються за наступними

формулами:

де

b

bE

n

ii

i

a,ˆ

1

ˆ3

n

jjiji bab

1

Таблиця 5.5 – Розрахунок вагомості параметрів

Аналіз рівня якості реалізації варіантів функцій

Визначаємо рівень якості кожного варіанту виконання основних

функцій окремо.

Абсолютні значення параметрів Х2 (об’єм пам’яті для збереження

даних) та X1 (швидкодія мови програмування) відповідають технічним

вимогам умов функціонування даного ПП.


Абсолютне значення параметра Х3 (час розрахунків) обрано не

найгіршим (не максимальним).

Абсолютні значення параметра Х4 (точність розв’язку) обрані з тих

міркувань, що висока точність розв’язку не є необхідною умовою.

Коефіцієнт технічного рівня для кожного варіанта реалізації ПП

розраховується за формулою:

і

івіТР nіВКК ,...1,

де n – кількість параметрів, Квi – коефіцієнт вагомості i–го параметра, Вi

– оцінка i–го параметра в балах.

Таблиця 5.6 – Розрахунок показників рівня якості варіантів реалізації

За цими даними визначаємо рівень якості обраного варіанту:

КТЕР1 = 0,684 + 0,809 + 0,71 + 0,765 + 0,7 = 3,668

Економічний аналіз варіантів розробки програмного продукту

При визначенні трудомісткості ПП враховують наступні фактори:

- об’єм ПП в умовних машинних командах (УМК);

- складність розроблюваного ПП;


- ступінь новизни розроблюваного ПП;

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

програм.

Склад функцій, реалізованих у даному продукті:

- створення інтерфейсу користувачу;

- організація пошуку та пошук в базі;

- безпека даних;

- чисельні методи.

Даний програмний продукт призначений для вже існуючих комп’ютерів

й операційних систем, використання типових програмних продуктів не

планується.

Оскільки дана система не має жодної з характеристик, які дозволяють

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

складності.

Об’єм кожної з функцій визначається відповідно “Каталогу функцій ПС

ВТ”, для наших функцій підрахунки зведемо у таблицю 5.7.

Таблиця 5.7 – Визначення об’єму функцій

Номер

функції

у

каталозі

Вміст функції

Відсоток

використання

у даному

програмному

продукті

Об’єм

функції,

УМК

Уточнення

об’єму

функції за

каталогом,

УМК

203 Створення інтерфейсу користувача 25 6260 1565

305 Обробка даних 25 3670 550,5

208 Організація пошуку та пошук в базі 20 17270 658

701 Чисельні методи 30 11650 3495

Всього 5740,5


Таким чином, загальний об’єм розроблюваного ПП для кожного з

варіантів дорівнює 5740,5.

Встановлюємо норму часу на розробку програмного продукту ТР:

Тр1 – 385 людино-днів;

Загальна трудомісткість Т0:

Т01= Ксл * Тр1 = 1,0 * 385 = 385

По ступені новизни програмний продукт відноситься до третього

ступеню, тому значення поправочного коефіцієнта Кн, що її враховує,

дорівнює 0,7. У зв’язку з тим, що використання типових програмних продуктів

не планується, коефіцієнт приймаємо рівним 1,0.

Таблиця 5.8 – Розрахунок трудомісткості на всіх ступенях розробки

Ступінь Код ступеня Трудомісткість розробки ступеня

Технічне завдання ТЗ 27,41

Ескізний проект ЭП 0

Технічний проект ТП 42,64

Робочий проект РП 185,78

Впровадження ВН 48,72

Разом 304,75

Отже необхідна кількість виконавців всього програмного продукту за

рік – дві людини.

5.4.1 Визначення витрат на розробку і розрахунок вартості

програмного продукту

Витрати на оплату праці розробників ПП:

Сз=Сг·T·(1+Hд/100),

де Сг – розмір погодинної оплати праці програміста, грн.;


Т – трудомісткість розробки ПП, людино-година;

Hд – норматив, який враховує додаткову заробітну плату, Hд = 20%.

У розробці беруть участь два програміста з окладом 15700 грн.

Визначимо зарплату програміста за годину при 21 робочому дні на місяць:

.45,938*21*2

1570015700грнС

г

Тоді зарплати розробників відповідно рівні:

Сз = 93,45 *385 *(1+0,2) = 43 175 грн.

Відрахування на єдиний соціальний внесок:

Сот=43 175 *0,3677 = 15 875,45 грн.

Для обслуговування ПК залучений спеціаліст із ЗП 4800 грн./міс.

Коефіцієнт його зайнятості при обслуговуванні – 0,45.

Вартість одного комп’ютера – 4500 грн.

Для однієї машини отримаємо:

Сг = 12 * 4500* 0,45 = 24 300 грн.

З урахуванням додаткової заробітної плати

Соб = 24 300 * (1 + 0,2) = 29 160 грн.

Відрахування на єдиний соціальний внесок (36.77 % від фонду оплати

праці, 2 клас професійного ризику виробництва):

Свід = Сзп * 0.3677 = 29 160 * 0,3677 = 10 722,13 грн.

Амортизаційні відрахування обчислимо за формулою:

Са=0,01*На*Ктм*Цд,

де Цдог – договірна ціна приладу, грн;

Ктм– коефіцієнт, який враховує витрати на транспортування та монтаж

приладу у користувача;

На – річна норма амортизації, %.

За амортизації 25% та вартості ЕОМ 4500 грн. маємо:

Са = 1,15 * 0,25 * 4500 = 1293,75 грн.


Витрати на ремонт та профілактику розрахуємо за формулою:

Срем = (Кр / 100%) Цд * Ктм,

де Крем – відсоток витрат на поточні ремонти. У розрахунках значення

цього нормативу орієнтовно візьмемо 5%.

Срем = 1,15 * 4500 * 0,05 = 258.75 грн.

Ефективний годинний фонд часу ПК за рік розрахуємо за формулою:

Тр = (Дк – Дв – Дс – Др.)*tз * nз * Кв,

де Дк – календарна кількість днів у році;

Дв, Дс – відповідно кількість вихідних та святкових днів;

Дрем – кількість днів планових ремонтів устаткування;

tзм – час зміни;

nзм – кількість змін експлуатації пристрою;

Кв коефіцієнт використання приладу у часі протягом зміни (можна

взяти 0,9);

Цен – тариф за 1 КВт-год. електроенергії, грн., (0.4 грн.)

Tеф ( 365 10 52 * 2 )* 8 * 0.9 * 0.4 1706.8 год.

Витрати на оплату електроенергії знаходимо за формулою:

Cел Цен * Р *Tеф,

де Р – потужність,

Р =0,5 кВт.

Сел 0,4 * 0,5 * 1706.8 341.4 грн.

Накладні витрати в розмірі 67 % від витрат на оплату праці:

Снакл = 24 300 * 0,67 = 16 281 грн.

Тоді, річні експлуатаційні витрати складуться у формулу:

Секс=4800/21/8*0.45*1706,8*(1+0,368+0,67)+1293,75+341,4 = 46 358,19

грн

Собівартість однієї машино-години ЕОМ дорівнюватиме:

Смг = Секс / Теф = 46 358,19/1 706,8 = 27,16 грн/год.


Оскільки в цьому випадку всі роботи, пов’язані з розробкою

програмного продукту, ведуться на ЕОМ, витрати на оплату машинного часу

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

Смч = Т * Смг = 385 * 27,16 = 10 456,94 грн.

Накладні витрати становлять 67 % від заробітної плати:

Снакл = Сз * 0.67 = 43175 * 0,67 = 28 927,25 грн.

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

формулою:

Спп=Сз + Свід + Смч + Снакл

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

варіанта:

Спп = 43 175 + 10 722,13 + 10 456,94 + 28 927,25 = 93 281,32 грн.

5.4.2 Вибір кращого варіанта програмного продукту техніко-

економічного рівня

Для обраного варіанта реалізації функцій ПП коефіцієнт техніко-

економічного рівня розраховується за формулою:

КТЕРj= КТРj /СПП.

КТЕР1 = 3,668/93281,32 = 3,932E-05;

Цей варіант реалізації функцій ПП дає величину коефіцієнта техніко-

економічного рівня КТЕР1 = 3,932E-05, вартість витрат для нього становить СПП

= 93 281,32 грн.

Цей варіант передбачає:

- написання програми на мові програмування Java.

- використання СКБД MySQL;


- використання Spring MVC;

- збереження результатів роботи в базу;

- виведення результатів у вигляді графіку.


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

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

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

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

функціонально-вартісного аналізу.

На основі даних про зміст основних функцій, які повинен реалізувати

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

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

програмування Java, використання СКБД MySQL, використання Spring MVC,

збереження результатів роботи в базу, виведення результатів у вигляді

графіку.

При такому варіанті виконання ПП він матиме достатню

універсальність і легкість модифікації.

Розроблений програмний продукт ще не має аналогів (тим більше,

безкоштовних), оскільки функція передбачення розвитку гострої серцевої

недостатності на основі застосованої моделі ще не була реалізована, всі

попередні методи захисту персональних даних пацієнта були більш

примітивними та менш надійними. До того ж, розроблений програмний

продукт централізував, систематизував та уніфікував методику роботи

персоналу з базою даних пацієнтів. Як наслідок, були вирішені проблеми

конкурентної модифікації даних пацієнта, втрати або пошкодження цих даних,

помилок та несправностей, спричинених людським фактором. Саме тому, на

мою думку, даний проект вартий фінансування.


ВИСНОВКИ

В цій дипломній роботі були проаналізовані алгоритми бінарної

класифікації та вибраний алгоритм бінарної логістичної регресії, розглянуті

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

реалізовано та застосовано алгоритм прогнозування ймовірності розвитку в

пацієнта гострої серцевої недостатності. Було розроблене веб-інтегроване

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

бази даних пацієнтів, виконання CRUD-операцій над нею та прогнозування

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

обраних статистично значущих критеріїв.

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

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

показників нормам.

Було розрахунок з економіки: було розраховано найоптимальніший

варіант реалізації та обґрунтовано доцільність реалізації даного програмного

продукту.


ПЕРЕЛІК ПОСИЛАНЬ

Бирман Э.Г. Сравнительный анализ методов прогнозирования //НТИ.

Сер.2. – 1986. – № 1. – С. 11–16.

Гвишиани Д.М., Лисичкин В.А. Прогностика. – М., «Знание», 1968. – 421

с.

Глущенко В.В. Прогнозирование. 3-е издание. – М.: Вузовская книга,

2000. – 208 с.

Григорьев, С.Г. Логистическая регрессия. Многомерные методы

статистического анализа категориальнных данных медицинских

исследований / С.Г. Григорьев, В.И. Юнкеров, Н.Б. Клименко // Уч.

пособие. ВМедА. – СПб, 2001. – С. 10–21.

Реброва О.Ю. Статистический анализ медицинских данных. Применение

пакета прикладных программ STATISTICA. – М.: МедиаСфера, 2002. –

312 с.

Бююль, Ахим. SPSS: искусство обработки информации. Анализ

статистических данных и восстановление скрытых закономерностей: Пер.

с нем. / Ахим Бююль, Петер Цефель. – СПб.: ООО «ДиаСофтЮП», 2002.

– 608 с.

Флетчер Р., Флетчер С., Вагнер Э. Клиническая эпидемиология. Основы

доказательной медицины: Пер. с англ. – М.: Медиа Сфера, 1998. – 352 с.

Parsonnet V.,Dean D.,Bernstein A.D.A method of uniform stratification of risk

for evaluating the results of surgery in acquired adult heart disease.Circulation.

– 1989 vol.79. – p. 13–112.

Портал освітньо-інформаційних послуг «Студентська консультація»

[Електронний ресурс]. Режим доступу: http://studcon.org/perspektyvy-

rozvytku-medychnyh-informaciynyh-system


Модель – вид – контролер. Вікіпедія – вільна енциклопедія [Електронний

ресурс]. Режим доступу:

https://uk.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%B

B%D1%8C-%D0%B2%D0%B8%D0%B4-

%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D0%

B5%D1%80

Web MVC framework. Spring [Електронний ресурс]. Режим доступу:

http://docs.spring.io/spring/docs/current/spring-framework-

reference/html/mvc.html

Впровадження залежностей. Вікіпедія – вільна енциклопедія

[Електронний ресурс]. Режим доступу:

https://uk.wikipedia.org/wiki/%D0%92%D0%BF%D1%80%D0%BE%D0%B

2%D0%B0%D0%B4%D0%B6%D0%B5%D0%BD%D0%BD%D1%8F_%D0

%B7%D0%B0%D0%BB%D0%B5%D0%B6%D0%BD%D0%BE%D1%81%

D1%82%D0%B5%D0%B9

Hibernate [Електронний ресурс]. Режим доступу: http://hibernate.org/

Spring Boot [Електронний ресурс]. Режим доступу:

http://projects.spring.io/spring-boot/

Thymeleaf [Електронний ресурс]. Режим доступу:

http://www.thymeleaf.org/

Apache Tomcat [Електронний ресурс]. Режим доступу:

http://tomcat.apache.org/

ДСанПіН 3.3.2.007-98. Державні санітарні правила і норми роботи з

візуальними дисплейними терміналами електронно-обчислювальних

машин ЕОМ.

ГОСТ 12.0.003-74. Система стандартов безопасности труда. Опасные и

вредные производственные факторы. Классификация


ДСН 239-96. Державні санітарні норми і правила захисту населення від

впливу електромагнітних випромінювань.

ДСанПіН 3.3.2.007-98. Державні санітарні правила і норми роботи з

візуальними дисплейними терміналами електронно-обчислювальних

машин ЕОМ.

ГОСТ 12.1.005-88. Общие санитарно-гигиенические требования к воздуху

рабочей зоны.

СН 245-71 Шкідливі речовини. Класифікація і загальні вимоги безпеки.

ДСН 3.3.6.037-99. Санітарні норми виробничого шуму, ультразвуку та

інфразвуку.


ДОДАТОК А

Лістинг коду розробленого програмного продукту

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-

4.0.0.xsd">

<modelVersion>4.0.0</modelVersion>

<groupId>com.shadowbring</groupId>

<artifactId>circulatory-research</artifactId>

<version>0.0.1-SNAPSHOT</version>

<packaging>jar</packaging>

<name>circulatory-research</name>

<description>Web Application for investigation of the state of the circulatory system</description>

<parent>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-parent</artifactId>

<version>1.3.1.RELEASE</version>

<relativePath/> 

</parent>

<properties>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

<java.version>1.8</java.version>

<start-class>com.shadowbring.CirculatoryResearchApplication</start-class>

</properties>

<dependencies>

<dependency>


<artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-actuator-docs</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-starter-aop</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-starter-data-jpa</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-starter-jdbc</artifactId>

</dependency>

<dependency>

<groupId>org.projectlombok</groupId>

<artifactId>lombok</artifactId>

<version>1.16.6</version>

</dependency>

<dependency>



<artifactId>spring-boot-starter-mail</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-starter-security</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.session</groupId>

<artifactId>spring-session</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-starter-social-facebook</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-starter-social-linkedin</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-starter-social-twitter</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-starter-thymeleaf</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-starter-web</artifactId>

</dependency>

<dependency>

<groupId>org.flywaydb</groupId>

<artifactId>flyway-core</artifactId>

</dependency>

<dependency>

<groupId>mysql</groupId>

<artifactId>mysql-connector-java</artifactId>

<scope>runtime</scope>

</dependency>

<dependency>


<artifactId>spring-boot-starter-test</artifactId>

<scope>test</scope>

</dependency>

<dependency>

<groupId>javax.validation</groupId>

<artifactId>validation-api</artifactId>

<version>1.1.0.Final</version>

</dependency>

<dependency>

<groupId>org.hibernate</groupId>

<artifactId>hibernate-validator</artifactId>

<version>5.1.3.Final</version>

</dependency>

</dependencies>

<build>

<plugins>

<plugin>



<artifactId>spring-boot-maven-plugin</artifactId>

</plugin>

</plugins>

</build>

</project>

package com.shadowbring.configuration;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.boot.autoconfigure.security.SecurityProperties;

import org.springframework.context.annotation.Bean;

import org.springframework.core.annotation.Order;

import org.springframework.security.config.annotation.authentication.builders.AuthenticationManagerBuilder;

import org.springframework.security.config.annotation.web.builders.HttpSecurity;

import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;

import org.springframework.security.crypto.password.PasswordEncoder;

import javax.sql.DataSource;

@Order(SecurityProperties.ACCESS_OVERRIDE_ORDER)

public class ApplicationSecurity extends WebSecurityConfigurerAdapter {

private static final int BCRYPT_ENCODER_STRENGTH = 11;

@Autowired

private DataSource dataSource;

@Override

protected void configure(HttpSecurity http) throws Exception {

http.authorizeRequests().antMatchers("/css/**").permitAll().anyRequest()

.fullyAuthenticated().and().formLogin().loginPage("/login")

.failureUrl("/login?error").permitAll().and().logout().permitAll();

}

@Override

public void configure(AuthenticationManagerBuilder auth) throws Exception {

auth.jdbcAuthentication().dataSource(this.dataSource).passwordEncoder(passwordEncoder());

}

@Bean

public PasswordEncoder passwordEncoder() {

return new BCryptPasswordEncoder(BCRYPT_ENCODER_STRENGTH);

}

}

package com.shadowbring.configuration;

import org.springframework.context.annotation.Bean;

import org.springframework.context.annotation.Configuration;

import org.springframework.web.servlet.config.annotation.ViewControllerRegistry;

import org.springframework.web.servlet.config.annotation.WebMvcConfigurerAdapter;

@Configuration

public class MvcConfiguration extends WebMvcConfigurerAdapter {

@Override


public void addViewControllers(ViewControllerRegistry registry) {

registry.addViewController("/login").setViewName("login");

}

@Bean

public ApplicationSecurity applicationSecurity() {

return new ApplicationSecurity();

}

} package com.shadowbring.controller;

import com.shadowbring.domain.Patient;

import com.shadowbring.service.PatientService;


import org.springframework.security.core.Authentication;

import org.springframework.security.core.context.SecurityContextHolder;

import org.springframework.stereotype.Controller;

import org.springframework.ui.ModelMap;

import org.springframework.web.bind.annotation.RequestMapping;

import org.springframework.web.bind.annotation.RequestMethod;

import org.springframework.web.bind.annotation.RequestParam;

import javax.servlet.http.HttpServletRequest;

import java.util.Date;

import java.util.logging.Logger;

@Controller

public class ApplicationController {

@Autowired

private PatientService patientService;

private static final Logger LOGGER = Logger.getLogger(ApplicationController.class.getClass().getName());

@RequestMapping("/")

public String home(ModelMap modelMap, HttpServletRequest request) {

Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

modelMap.put("title", authentication.getName());

modelMap.put("date", new Date());

return "home";

}

@RequestMapping("/hash")

public String hash(ModelMap modelMap) {



patientService.hashCredentials();

return "home";

}

@RequestMapping("/one")

public String one(ModelMap modelMap) {




String surname = "Фетисенко";

String firstName = "Анатолий";

String lastName = "Евгеньевич";

Patient fetisenko = patientService.getPatientByCredentials(surname, firstName, lastName);

modelMap.put("originalPassword", fetisenko.getFamilia());

modelMap.put("encodedPassword", fetisenko.getImja());


return "home";

}

@RequestMapping(value = "/find", method = RequestMethod.GET)

public String find() {

return "find";

}

@RequestMapping(value = "/find", method = RequestMethod.POST)

public String showPatient(@RequestParam String surname,

@RequestParam String firstName,

@RequestParam String lastName,

ModelMap modelMap) {

Patient fetisenko = patientService.getPatientByCredentials(surname, firstName, lastName);

modelMap.put("originalPassword", fetisenko.getFamilia());

modelMap.put("encodedPassword", fetisenko.getImja());


return "home";

}

}

package com.shadowbring.repository;


import org.springframework.data.repository.CrudRepository;

public interface PatientRepository extends CrudRepository<Patient, Integer>{

Patient findOneByCredentialsHashed(String credentialsHashed);

}

package com.shadowbring.service;


public interface PatientService {

void hashCredentials(); Patient getPatientByCredentials (String surname, String firstName, String lastName);

}

package com.shadowbring.service;


import com.shadowbring.repository.PatientRepository;


import org.springframework.security.core.token.Sha512DigestUtils;

import org.springframework.stereotype.Service;

import java.util.logging.Level;

import java.util.logging.Logger;

@Service

public class PatientServiceImpl implements PatientService {

@Autowired

private PatientRepository patientRepository;

private static final Logger LOGGER = Logger.getLogger(PatientServiceImpl.class.getClass().getName());

@Override


public void hashCredentials() { Iterable<Patient> allPatients = patientRepository.findAll();

for (Patient patient : allPatients) {

String allCredentials = patient.getFamilia().toLowerCase();

if (patient.getImja() != null) {

allCredentials = allCredentials + patient.getImja().toLowerCase();

} if (patient.getOtchestvo() != null) {

allCredentials = allCredentials + patient.getOtchestvo().toLowerCase();

} String salt = Sha512DigestUtils.shaHex(allCredentials);

String finalHash = Sha512DigestUtils.shaHex(salt + allCredentials);

patient.setCredentialsHashed(finalHash);

patientRepository.save(patient);

}

}

@Override

public Patient getPatientByCredentials(String surname, String firstName, String lastName) {

String allCredentials = surname.toLowerCase();

if (firstName != null) {

allCredentials = allCredentials + firstName.toLowerCase();

} if (lastName != null) {

allCredentials = allCredentials + lastName.toLowerCase();

} String salt = Sha512DigestUtils.shaHex(allCredentials);

String credentialsHashed = Sha512DigestUtils.shaHex(salt + allCredentials);

LOGGER.log(Level.WARNING, "HASHED IS: " + credentialsHashed);

return patientRepository.findOneByCredentialsHashed(credentialsHashed);

}

}

package com.shadowbring;

import org.springframework.boot.SpringApplication;

import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication

public class CirculatoryResearchApplication {

public static void main(String[] args) {

SpringApplication.run(CirculatoryResearchApplication.class, args);

}

}

<!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org">

<head lang="en">

</head>

<body th:fragment="header">

<div class="container">

<div class="navbar">

<div class="navbar-inner">

<a class="brand" th:href="@{/}" href="home.html"> Домашня сторінка </a>

<ul class="nav">

<li><a th:href="@{/}" href="home.html"> Додати пацієнта </a></li>

<li><a th:href="@{/find}" href="find.html"> Знайти пацієнта </a></li>


<li><form th:action="@{/logout}" method="post">

<input class="btn btn-primary" type="submit" value="Вийти"/>

</form></li>

</ul>

</div>

</div>

</div>

</body>

</html>


<head th:fragment="head">

<link rel="stylesheet" th:href="@{/css/bootstrap.min.css}"

href="../../css/bootstrap.min.css" />

</head>

<body>

</body>

</html>


<head>

<title>Error</title>



</head>

<body>




<h1 th:text="${title}">Title</h1>

<div id="created" th:text="${#dates.format(timestamp)}">July 11,

2012 2:17:16 PM CDT

</div>

<div>

There was an unexpected error (type=<span th:text="${error}">Bad</span>, status=<span

th:text="${status}">500</span>).

</div>

<div th:text="${message}">Fake content</div>

<div>

Please contact the operator with the above information.

</div>

</div>

</body>

</html>


<head>

<title>Знайти пацієнта</title>


</head>

<body>



<div class="content">

<h2>Введіть прізвище, ім’я та по-батькові пацієнта</h2>

<form name="form" th:action="@{/find}" action="/find" method="POST">


<fieldset>

<input type="text" name="surname" value="" placeholder="Прізвище"/>

<input type="text" name="firstName" placeholder="Ім’я"/>

<input type="text" name="lastName" placeholder="По-батькові"/>

</fieldset>

<input type="submit" id="find" value="Знайти"

class="btn btn-primary"/>

</form>

</div>

</div>

</body>

</html>


<head>

<title th:text="${title}">Title</title>


</head>

<body>



<h1 style="color: royalblue; text-align: center">Вітаю, <span th:text="${title}">Someone</span>!</h1>

<h2>Це твоя домашня сторінка.</h2>

<h2>Зараз на годиннику <span th:text="${#dates.format(date)}">Some time</span>.</h2>

<h3>Тобі доступні такі дії:</h3>

<ul>

<li><a th:href="@{/}" href="home.html">Занести нового пацієнта до бази даних</a></li>

<li><a th:href="@{/find}" href="find.html">Знайти пацієнта в базі для подальших маніпуляцій</a></li>

</ul>

<div th:text="${message}">Fake content</div>

<div th:text="${originalPassword}">Fake content</div>

<div th:text="${encodedPassword}">Fake content</div>

<div th:text="${sha}">Fake content</div>

<div th:text="${matches}">Fake content</div>

<div th:text="${salt}">Fake content</div>

<div th:text="${hash}">Fake content</div>

</div>

</body>

</html>


<head>

<title>Вхід</title>


</head>

<body>



<div class="content">

<p th:if="${param.logout}" class="alert">Ви вийшли з системи</p>

<p th:if="${param.error}" class="alert alert-error">Відбулася помилка, будь ласка, спробуйте ще раз</p>

<h2>Введіть Ім’я користувача та Пароль</h2>

<form name="form" th:action="@{/login}" action="/login" method="POST">

<fieldset>

<input type="text" name="username" value="" placeholder="Ім’я користувача"/>

<input type="password" name="password" placeholder="Пароль"/>

</fieldset>


<input type="submit" id="login" value="Увійти"

class="btn btn-primary"/>

</form>

</div>

</div>

</body>

</html>

spring.datasource.driverClassName = com.mysql.jdbc.Driver

spring.datasource.url = jdbc:mysql://localhost:3306/patient?useUnicode=true&characterEncoding=UTF-

8&characterSetResults=UTF-8

spring.datasource.username = root

spring.datasource.password = Homi100500100

spring.jpa.database-platform = org.hibernate.dialect.MySQLDialect

spring.jpa.show-sql = true

spring.jpa.hibernate.ddl-auto = update

security.basic.enabled = false

flyway.baseline-on-migrate = true

package com.shadowbring.domain; import javax.persistence.Column; import javax.persistence.Entity; import javax.persistence.Id; import javax.persistence.Table; import java.math.BigDecimal; import java.sql.Timestamp; @Entity @Table(name = "patient") public class Patient { private int patientId; //TODO Re-generate equals() and hashcode() for new field, delete FIO private String credentialsHashed; private String familia; private String imja; private String otchestvo; private String nBolezni; private Timestamp dataPostuplenija; private String otdelenie; private String postuplenie; private String postuplenie2; private Timestamp dataOperatsii; private Timestamp dataVypiski; private Integer dneyPosleOperatsii; private Integer koykoDni; private String oblast; private String gorod; private String adres; private Integer vozrast; private String pol; private Integer ves; private Integer rost; private String diagnozPostuplenija; private String diagnozOkonchatelnyy; private String lechaschiyVrach; private String vmeshatelstvo; private String perenesZabolevan; private String perenesZabolevan2; private String bolezniPochek; private String bolezniPochek2; private String embSosGm;


private String hronichZabolLegkih; private String gb; private String diabet; private String yaB; private String nevrolgiya; private String nevrolgiya2; private String periferSos; private String periferSos2; private String porazhSgm; private String drugie; private String ibsVSemye; private String perenOperatsii; private String perenVmeshNaSerdtse; private BigDecimal logisticEuroScore; private String odyshka; private String aritmii; private String aritmii2; private String astsit; private String perifOteki; private String otekLegkih; private String xhk; private String nyha; private Integer adV; private Integer adN; private Integer zhEL; private String stenokardiya; private String harakterStenokardii; private String kardiogennyyShok; private String reanMeropriyatiya; private String fk; private int kolIm; private String harIm; private String vremyaPoslePosledIm; private String nitraty; private String nitraty2; private String antiAgreganty; private String bBlokatory; private String statiny; private BigDecimal urovenHolesterina; private BigDecimal triglitseridyKrovi; private String ritmIb; private int chSS; private String aVProv; private String kardioskleroz; private String xkh; private String gipertrofLZh; private String mOchagIzm; private String ishemiya; private String im; private String zaklyuchenie; private String ritmIb2; private int chSS2; private String aVProv2; private String kardioskleroz2; private String xkh2; private String gipertrofLZh2; private String mOchagIzm2; private String ishemiya2; private String im2; private String zaklyuchenie2; private int kdo1; private int kco1; private int uo1; private String moc1; private int fv1;


private String kdd1; private String sokratimost; private String gipertrofiyaLZh; private String mk; private String mkGradient; private String ak; private String akGradient; private String tk; private String tkGradient; private String gipikoneziya; private String anevrizmaLZh; private String tromby; private String kaltsinozAorty; private String fbSposobOpredeleniya; private String zakljuchenie; private Integer kdo2; private Integer kco2; private Integer uo2; private String moc2; private Integer fv2; private String kdd2; private Integer deltaPNaPoreze; private String zhidkostVPlevralnyh; private BigDecimal zhidkostVPolosti; private String zakljuchenie2; private String anemiya; private String mertsatelnayaAritmiya; private String yazvennayaBolezn; private String retorakotomiya; private String sepsis; private String ligaturnyySvisch; private BigDecimal temperaturaNaVypisku; private String tipKrovi; private int kolPorazhKa; private String osLka50; private String pmzhv; private String dv; private String ov; private String vtk; private String aInterm; private String osPka; private String pka; private String zmzhv; private String bok; private String lvPka; private String caAorty; private String sokratim; private Integer fv; private String anast; private String alzh; private String porazhPerifSos; private String porPochS; private String ak2; private String akGradient2; private String mk2; private String mkGradient2; private String tk2; private String tkGradient2; private String vsd; private String rLzh; private String rLzh2; private String operatsiya; private String prichEkst; private Integer vremyaOtKlvg; private String dostup;


private String vmeshatelstvoAdd; private Integer dlitOper; private String krovopoterya; private String aik; private String perehodNaIi; private Integer tPerfuzii; private Integer tPereAorty; private String kardioplegiya; private String ov2; private String shuntUOv; private String anevrizmaLzh; private String lokalizatsiyaAnevrizmy; private String korrektsiyaAnevrizmy; private String udalenieTrombov; private Integer dlinaPoreza; private String plVsd; private String ralzh; private String ralzh2; private String koronarnoeShuntirovanie; private Integer kolichDistAnastomozov; private Integer kolichArtAnst; private String ispolzVga; private String pmzhvAdd; private String pmzhv2; private String dv1; private String dv12; private String dv2; private String dv22; private String aInt; private String aInt2; private String mgI; private String mgI2; private String mgIi; private String mgIi2; private String vok; private String vok2; private String zmzhvAdd; private String zmzhv2; private String lvPkaAdd; private String lvPka2; private String sekventsShunty; private String kaltsinozAorty2; private String manipulatsiyaNaAk; private String naAkVidProteza; private String manipulatsiyaNaMk; private String naMkTip; private String naMkVidProteza; private String manipulatsiyaNaTk; private String hirurg; private String assistent1; private String assistent2; private String assistent3; private String opSestra; private String anesteziolog; private String anestezistka; private String perfuziolog; private String intaOpOsoben; private String intaOpOslozhn; private String ssn; private String aritmii3; private String krovotechenie; private String perNaIk; private String prichina; private String vabk; private Integer dlitIvl;


private Integer reintubatsiya; private String perelivPrepKrovi; private String poOslozhneniya; private String ssnAdd; private String im3; private String aritmii4; private String nevrologich; private String legochnye; private String pochechNedost; private String sosudistye; private String retoratokomiya; private String infektsiya; private String ishod; private String prichinaSmerti; private String prichinaSmerti2; private String prichinaVypiskiNeoperirovanyh; private String srok; private String zhaloby; private String im4; private String povtKvg; private String deystvie; private Integer id; @Column(name = "credentials_hashed", nullable = false) public String getCredentialsHashed() { return credentialsHashed; } public void setCredentialsHashed(String credentialsHashed) { this.credentialsHashed = credentialsHashed; } @Id @Column(name = "patient_id", nullable = false) public int getPatientId() { return patientId; } public void setPatientId(int patientId) { this.patientId = patientId; } @Column(name = "Familia", nullable = true, length = 25) public String getFamilia() { return familia; } public void setFamilia(String familia) { this.familia = familia; } @Column(name = "Imja", nullable = true, length = 25) public String getImja() { return imja; } public void setImja(String imja) { this.imja = imja; } @Column(name = "Otchestvo", nullable = true, length = 25) public String getOtchestvo() {


return otchestvo; } public void setOtchestvo(String otchestvo) { this.otchestvo = otchestvo; } @Column(name = "N_bolezni", nullable = true, length = 12) public String getnBolezni() { return nBolezni; } public void setnBolezni(String nBolezni) { this.nBolezni = nBolezni; } @Column(name = "Data_postuplenija", nullable = true) public Timestamp getDataPostuplenija() { return dataPostuplenija; } public void setDataPostuplenija(Timestamp dataPostuplenija) { this.dataPostuplenija = dataPostuplenija; } @Column(name = "Otdelenie", nullable = true, length = 45) public String getOtdelenie() { return otdelenie; } public void setOtdelenie(String otdelenie) { this.otdelenie = otdelenie; } @Column(name = "Postuplenie", nullable = true, length = 45) public String getPostuplenie() { return postuplenie; } public void setPostuplenie(String postuplenie) { this.postuplenie = postuplenie; } @Column(name = "Postuplenie2", nullable = true, length = 255) public String getPostuplenie2() { return postuplenie2; } public void setPostuplenie2(String postuplenie2) { this.postuplenie2 = postuplenie2; } @Column(name = "Data_operatsii", nullable = true) public Timestamp getDataOperatsii() { return dataOperatsii; } public void setDataOperatsii(Timestamp dataOperatsii) { this.dataOperatsii = dataOperatsii;


} @Column(name = "Data_vypiski", nullable = true) public Timestamp getDataVypiski() { return dataVypiski; } public void setDataVypiski(Timestamp dataVypiski) { this.dataVypiski = dataVypiski; } @Column(name = "Dney_posle_operatsii", nullable = true) public Integer getDneyPosleOperatsii() { return dneyPosleOperatsii; } public void setDneyPosleOperatsii(Integer dneyPosleOperatsii) { this.dneyPosleOperatsii = dneyPosleOperatsii; } @Column(name = "Koyko_dni", nullable = true) public Integer getKoykoDni() { return koykoDni; }

Documents

Дипломна роботаbmc.fbmi.kpi.ua/uploads/diplom/bezruk-dmitro-pavlovich.pdf6 Розробка ПП 7 грудня 2015р. 7 Написання та оформлення