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

Размещено на http://www.allbest.ru/

РЕФЕРАТ

Кваліфікаційна робота: 74 сторінок, 24 рисунка, 5 таблиць, 15 джерел, 5 додатків.

Об'єктом розробки є підсистеми автоматизованого обліку результатів медичного обстеження студентів і співробітників ВНЗу.

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

Методи дослідження - вивчення джерел, спостереження, опис, порівняння.

Методом розробки обрано технологію «клієнт - сервер», інтеграцію баз даних в Інтернет, використання скриптових серверних мов програмування.

Було зроблене проектування підсистеми й часткова реалізація її функціонала з використанням мови PHP і СКБД MySQL і сучасних засобів багато користувальницької розробки систем.

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

автоматизація процесу, хронологія, клієнт-сервер, MySQL, браузер, кросбраузерна підсистема, web-додаток, персона, адреса, обстеження

ЗМІСТ

ВСТУП

РОЗДІЛ 1. Аналіз предметної області

1.1 Розробка моделі бізнес-прецедентів

1.2 Розробка моделі бізнес-об'єктів

1.3 Розробка концептуальної моделі даних

1.4 Розробка вимог до системи

1.5 Аналіз вимог і попереднє проектування системи

1.6 Розробка моделей бази даних і додатків

1.7 Проектування фізичної реалізації системи

1.8 Одержання прав доступу вхід у підсистему

1.9 Характеристика комплексу завдань

1.10 Вихідна інформація

1.11 Вхідна інформація

РОЗДІЛ 2 . Огляд аналогів проектованої підсистеми

2.1 Огляд системи «1С-АНАЛИТ: Медицинское учреждение»

2.1.1 Функціональні можливості конфігурації, особливості обліку

2.1.2 Основні можливості конфігурації

2.1.3 Регламентована звітність

2.2 Огляд системи «Комп'ютерна реєстратура поліклініки»

2.3 Порівняння аналогів

РОЗДІЛ 3. Розробка інформаційного забезпечення

3.1 Проектування інформаційного забезпечення

3.2 Тестування інформаційної моделі

3.3 Состав інформаційного забезпечення

3.4 Постановка завдання

РОЗДІЛ 4. Розробка програмного забезпечення

4.1 Вимоги до програмного забезпечення. Нефункціональні вимоги

4.2 Архітектура системи

Вибір базового програмного забезпечення

4.3 Вибір цільовий СКБД

4.4 Модель системи

4.4.1 Опис варіантів використання системи

4.4.2 Діаграма розміщення компонентів системи

4.4.3 Загальна схема взаємодії клієнта й сервера

4.5 Структура каталогів

РОЗДІЛ 5. Посібник користувача

5.1 Призначення посібника користувача

5.2 Состав функцій

5.3 Вимоги до конфігурації системи

5.4 Мінімальний состав програмних засобів

5.5 Вимоги до персоналу

5.6 Виконання програми

5.7.1 Додавання даних до історії хвороби

5.7.2 Список пацієнтів

5.7.3 Користувачі підсистеми

5.8 Завершення автоматизованої підсистеми

ВИСНОВКИ

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

Додаток А. DFD-Діаграма

Додаток Б. Діаграма варіантів використання

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

Додаток Г. Копії графічних матеріалів

Додаток Д. HTML-КОД САЙТА СПИСКА ПАЦІЄНТІВ

ВСТУП

Тематика роботи є актуальною, вона відповідає напрямкам, визначеним у Державній програмі інформатизації охорони здоров'я України на 2006-2010 роки, пріоритетним напрямам розвитку науки і техніки, визначеним Міністерством освіти і науки України, технічному завданню на виконання кафедрою ПІТ ЕІДМУ "КПУ" науково-дослідного проекту за темою "Створення програмних засобів і технологій забезпечення комп'ютерного інформаційного середовища".

На даний момент в інституті процес обліку результатів медичного обстеження є автоматизованим, але результати не вносяться в загальну базу даних, також програма для даного обліку застаріла й не є WEB програма Раніше медичний облік вівся письмово, такі архіви займали величезний простір і не були зручними в плані додавання яких або змін, а так само більшим мінусом була трудомісткість пошуку необхідної інформації. Ведення обліку за допомогою передові технології й WEB розробок дозволить домогтися швидкості роботи з архівом, легкістю пошуку даних. Великий плюс - зручний інтерфейс для користувача із середніми знаннями ПК і Інтернету. Так само можна відзначити той факт, що за допомогою WEB додатка медичному співробітникові можна вести облік з будь-якого робочого місця ВНЗу, що має доступ у локальну мережут ВНЗу.

Рішення даної проблеми у вигляді автоматизованої підсистеми забезпечило б найбільш ефективну роботу медичного підрозділу, а впровадження системи дозволило б істотно підвищити оперативність, вірогідність і швидкість обробки й обміну інформацією між підрозділами ВНЗу. Метою даної роботи є проектування ефективного й зручного варіанта автоматизованої підсистеми для обліку результатів медичного обстеження студентів і співробітників ВНЗу.

РОЗДІЛ 1. Аналіз предметної області

UML (Unified Modeling Language) забезпечує підтримку всіх етапів життєвого циклу ІС та надає для цих цілей ряд графічних засобів - діаграм.

На етапі створення концептуальної моделі для опису бізнес-діяльності використовуються моделі бізнес-прецедентів і діаграми видів діяльності, для опису бізнес-об'єктів - моделі бізнес-об'єктів і діаграми послідовностей.

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

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

Нижче наведено визначення і описується призначення перерахованих діаграм і моделей стосовно завдань проектування ІС (в дужках наведені альтернативні назви діаграм, що використовуються в сучасній літературі).

Діаграми прецедентів (діаграми варіантів використання, use case diagrams) - це узагальнена модель функціонування системи в навколишньому середовищі.

Діаграми видів діяльності (діаграми діяльності, activity diagrams) - модель бізнес-процесу або поведінки системи в рамках прецеденту.

Діаграми взаємодії (interaction diagrams) - модель процесу обміну повідомленнями між об'єктами, представляється у вигляді діаграм послідовностей (sequence diagrams) або кооперативних діаграм (collaboration diagrams).

Діаграми станів (statechart diagrams) - модель динамічної поведінки системи та її компонентів при переході з одного стану в інший.

Діаграми класів (class diagrams) - логічна модель базової структури системи, відображає статичну структуру системи та зв'язки між її елементами.

Діаграми бази даних (database diagrams) - модель структури бази даних, відображає таблиці, стовпці, обмеження і т.п.

Діаграми компонентів (component diagrams) - модель ієрархії підсистем, відображає фізичне розміщення баз даних, програм і інтерфейсів ІС.

1.1. Розробка моделі бізнес-прецедентів

Модель бізнес-прецедентів описує бізнес-процеси з точки зору зовнішнього користувача, тобто відображає погляд на діяльність організації ззовні.

Проектування системи починається з вивчення та моделювання бізнес-діяльності організації. На цьому етапі вводиться і відображається в моделі ряд понять, властивих об'єктно-орієнтованому підходу.

Виконавець (Діюча особа, Actor) - особистість, організація або система, що взаємодіє з ІС; розрізняють зовнішнього виконавця (який використовує або користовується системою, тобто породжує прецеденти діяльності) та внутрішнього виконавця (який забезпечує реалізацію прецедентів діяльності всередині системи). На діаграмі виконавець представляється стилізованою фігуркою людини.

Прецедент - закінчена послідовність дій, ініційована зовнішнім об'єктом (особистістю або системою), яка взаємодіє з ІС і отримує в результаті деяке повідомлення від ІС. На діаграмі представляється овалом з написом, що відображає зміст дії.

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

Асоціація - зв'язок між двома елементами моделі. На діаграмі представляється лінією.

Узагальнення - зв'язок між двома елементами моделі, коли один елемент (підклас) є приватним випадком іншого елементу (суперкласса). На діаграмі представляється стрілкою.

Агрегація - відношення між елементами моделі, коли один елемент є частиною іншого елементу (агрегату). На діаграмі представляється стрілкою з ромбовидним кінцем.

Для ілюстрації етапів розробки проекту використані адаптовані матеріали проекту ІС медичного центру (рис. 1.1). Призначення ІС - автоматизація ведення та використання клінічних записів про пацієнтів. В даний час ця робота виконується вручну персоналом центру. На рис. 1.2 представлена загальна модель діяльності центру у вигляді діаграми прецедентів. Прецедент "Обслуговування пацієнта" реалізується через безліч інших, більш обмежених прецедентів (рис. 1.2), що відображають деталізацію представлення функціонування центру.

Рис. 1.1 Загальна діаграма діяльності медичного центру обслуговування пацієнта

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

1) прецедент повинен описувати, ЩО треба робити, а не ЯК;

2) прецедент повинен описувати дії з точки зору ВИКОНАВЦЯ;

3) прецедент повинен повертати виконавцю деяке ПОВІДОМЛЕННЯ;

4) послідовність дій всередині прецеденту повинна являти собою один НЕРОЗДІЛЬНИЙ ланцюжок.

Рис. 1.2 Модель бізнес-прецедентів, що складають обслуговування пацієнта

Виходячи з мети створення системи, для подальшого дослідження та моделювання відбираються тільки ті бізнес-прецеденти, які пов'язані з використанням клінічних записів.

Виконання прецеденту описується за допомогою діаграм видів діяльності, які відображають виконавців і послідовність виконання відповідних бізнес-процесів (рис. 1.3).

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

Загальне поле діаграми діяльності поділяється на декілька "плавальних доріжок", кожна з яких містить опис дій одного з виконавців. Основними елементами діаграм видів діяльності є позначення стану ( "вгору", "кінець"), дії (овал) і моменту синхронізації дій (лінійка синхронізації, на якій сходяться або розгалужуються кілька стрілок).

Рис. 1.3 Діаграма видів діяльності для прецеденту "Надання медичної допомоги"

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

Етап завершується після розробки діаграм видів діяльності для всіх виділених в моделі бізнес-прецедентів. Природно, на наступних етапах аналізу і проектування будуть виявлені якісь важливі подробиці в описі діяльності об'єкта автоматизації. Тому розроблені на даному етапі моделі будуть ще неодноразово коректуватися.

1.2. Розробка моделі бізнес-об'єктів

Наступним етапом проектування ІС є розробка моделі бізнес-об'єктів, що показує виконання бізнес-процесів організації її внутрішніми виконавцями. Основними компонентами моделей бізнес-об'єктів є зовнішні і внутрішні виконавці, а також бізнес-сутності, що відображають все, що використовують внутрішні виконавці для реалізації бізнес-процесів. Приклад моделі бізнес-об'єктів для прецеденту "Відповідь на запит" наведено на рис. 1.4.

Рис. 1.4 Модель бізнес-об'єктів прецеденту "Відповідь на запит"

У цій діаграмі з'явилася нова дійова особа - відправник запиту. Насправді ж, із запитом про стан пацієнта можуть звертатися в систему багато хто з дійових осіб: юрист, страхова компанія, технічний персонал і навіть сам пацієнт. Таким чином, поняття "Відправник запиту" служить для узагальненого представлення всіх цих дійових осіб при описі прецеденту "Відповідь на запит" (рис. 1.5). "Відправник запиту" стає суперклассом по відношенню до узагальнюємих понять (підкласів).

Рис. 1.5 Узагальнення класів

Для детального опису виконання бізнес-процесів зазвичай використовуються діаграми послідовностей (рис. 1.6).



Рис. 1.6 Діаграма послідовностей для прецеденту "Відповідь на запит"

Основними елементами діаграми послідовностей є позначення об'єктів (прямокутники), вертикальні лінії, що відображають плин часу при діяльності об'єкта, і стрілки, що показують виконання дій об'єктами.

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

1.3 Розробка концептуальної моделі даних

Потім на основі інформації, виявленої на етапах бізнес-моделювання, виконується розробка концептуальної моделі даних, які будуть використовуватися в розроблюваній системі. На рис. 1.7 представлена модель даних для об'єкта "Клінічні записи" у вигляді діаграми класів.

Рис. 1.7 Концептуальна модель даних

Модель показує, що клінічні записи включають (агрегують) ряд блоків. При цьому "мінімальний набір даних" і "план лікування" можуть бути включені в кожен клінічний запис в єдиному екземплярі, а блоки "результати аналізів", "приписи лікаря", "хід лікування" можуть повторюватися необмежену кількість разів.

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

Оскільки пацієнт може попередньо проходити лікування в інших установах, або кілька разів проходити лікування в центрі, з'являються додаткові різновиди (підкласи) клінічних записів: зовнішні, старі внутрішні, нові внутрішні.

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

1.4 Розробка вимог до системи

На етапі формування вимог, перш за все, необхідно визначити область дії системи, що розробляється, та отримати точне уявлення про бажані можливості системи. Основою розробки вимог є модель системних прецедентів, що відбиває виконання конкретних обов'язків внутрішніми і зовнішніми виконавцями з використанням ІС.

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

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

- короткий опис прецеденту;

- обмеження;

- передумови (необхідний стан системи або умови, за яких повинен виконуватися прецедент);

- післяумови (можливий стан системи після виконання прецеденту);

- припущення;

- основна послідовність дій;

- альтернативні послідовності дій і умови, що їх ініціюють;

- точки розширення і включення прецедентів.

У процесі створення моделі системних прецедентів здійснюється перетворення і перенесення компонентів бізнес-моделей на нові діаграми. На рис. 1.8 представлена модель системних прецедентів для бізнес-прецеденту "Надання медичної допомоги". Виходячи з мети створення системи, в моделі системних прецедентів відображені тільки ті дії виконавців, які пов'язані з наданням доступу та оновленням клінічних записів.

Рис. 1.8 Модель системних прецедентів

Функції, що описуються моделлю, характерні тільки для одного виду діяльності - надання медичної допомоги, і в основному не використовуються в інших видах діяльності Центру. Це дозволяє об'єднати виділені функції в якусь єдину підсистему проектованої ІС.

Внутрішній виконавець "Персонал центру" (рис. 1.3, рис. 1.6) і виконуємий ним ручний процес, перетворений в системний прецедент "Надання доступу до клінічних записів".

Зовнішні виконавці (наприклад, "Виробник медичного обладнання") безпосередньо взаємодіють з проектованої системою, тобто перетворюються на виконавців.

У моделі відображено два спеціальні типи зв'язку між прецедентом (на рис. 1.8 відповідні прецеденти виділені тінню):

– "включає" - один прецедент в процесі свого виконання обов'язково виконує певний блок дій, що становлять інший прецедент;

– "розширює" - коли прецеденти подібні за своїми діями, але один несе трохи більшу функціональну нагрузку.

Прецедент "Перевірка прав доступу" вперше з'явився на діаграмах і реалізується засобами ІС, що розробляється. Тому для нього доводиться розробляти діаграму послідовностей, що описує його виконання (рис. 1.9). В результаті в проектованій ІС з'являються два нових об'єкти - програмний модуль "Менеджер захисту" та інформаційний блок "Набір прав".

Рис. 1.9 Діаграма послідовностей для прецеденту "Перевірка прав"

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

1.5 Аналіз вимог і попереднє проектування системи

Основні завдання етапу:

– визначити проект системи, який буде відповідати всім бізнес-вимогам;

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

Основним інструментом на даному етапі є діаграми класів системи, які будуються на основі розробленої моделі системних прецедентів. Одночасно на цьому етапі уточнюються діаграми послідовностей виконання окремих прецедентів, що призводить до змін у складі об'єктів і діаграмах класів. Це природне відображення засобами UML Ітеративний процесу розробки системи.

Діаграми класів системи заповнюються об'єктами з моделі системних прецедентів. Вони містять опис цих об'єктів у вигляді класів та опис взаємодії між класами.

Діаграма класів, що описує процедури захисту доступу до даних, наведено на рис. 1.10.

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

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

Рис. 1.10 Діаграма класів "Захист доступу"

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

1.6 Розробка моделей бази даних і додатків

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

– класи відображаються в таблиці;

– атрибути - в стовпці;

– типи - в типи даних СKБД;

– асоціації - у зв'язки між таблицями (асоціації "багато-до-багатьох" перетворюються в асоціації "один-до-багатьох" шляхом створення додаткових таблиць зв'язків);

– додатки - в окремі класи з остаточно визначеними і пов'язаними з даними в базі методами та атрибутами.

Оскільки моделі бази даних і додатків будуються на основі єдиної логічної моделі, автоматично забезпечується зв'язність цих проектів (рис. 1.11).



Рис. 1.11 Зв'язок між проектами бази даних і додатків

У моделі бази даних відображаються тільки перманенті класи, з яких видаляються атрибути, що не відображаються в стовпцях (наприклад, атрибут типу "Загальний обсяг продажів", який отримується шляхом підсумовування вмісту безлічі полів бази даних). Деякі атрибути (наприклад, АДРЕСА) можуть відображатися в безліч стовпців (країна, місто, вулиця, будинок, поштовий індекс).

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

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

– одна таблиця на клас;

– одна таблиця на суперклас;

– одна таблиця на ієрархію.

У першому випадку для кожного з класів створюється окрема таблиця, між якими потім встановлюються необхідні зв'язку. У другому випадку створюється таблиця для суперкласса, а потім у кожну таблицю підкласів включаються стовпці для кожного з атрибутів суперкласу. У третьому - створюється єдина таблиця, яка містить атрибути як суперкласса, так і всіх підкласів (рис. 1.12). При цьому для виділення вихідних таблиць підкласів в результуючу таблицю додається один або більше додаткових стовпців (на рисунку показаний курсивом).



Рис. 1.12 Перетворення ієрархії в таблицю

Розробка проекту бази даних здійснюється з використанням спеціального UML-профілю (Profile for Database Design), який включає такі основні компоненти діаграм:

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

– стовпчик - елемент таблиці, що містить значення одного з атрибутів таблиці;

– первинний ключ (РК) - атрибут, що однозначно ідентифікує рядок таблиці;

– зовнішній ключ (FK) - один або група атрибутів однієї таблиці, які можуть використовуватися як первинний ключ іншої таблиці;

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

– необов'язковий зв'язок - зв'язок між таблицями, при якій кожна з таблиць може існувати незалежно від іншої;

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

– збережувальна процедура - функція обробки даних, виконувана на сервері;

– домен - безліч допустимих значень для стовпця таблиці.

Представлений фрагмент моделі бази даних - дві таблиці, що відповідають класам "пацієнт" (рис. 1.3, рис. 1.6) та "мінімальний набір даних" (рис. 1.8). Зв'язок між ними обов'язковий, оскільки "мінімальний набір даних" не може існувати без "пацієнта".

Рис. 1.13 Фрагмент моделі бази даних

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

– обмеження - визначають допустимі значення даних у стовпці або операції над даними (ключ (PK, FK) - обмеження, що визначає тип ключа та його стовпець; перевірка (Check) - обмеження, що визначає правило контролю даних; унікальність (Unique) - обмеження, що визначає , що в стовпці містяться неповторювані дані);

– тригер - програма, що виконує за певних умов визначені дії з базою даних;

– тип даних і т.ін.

Результатом етапу є детальний опис проекту бази даних і додатків системи.

1.7 Проектування фізичної реалізації системи

На цьому етапі проектування моделі баз даних і додатків доповнюються позначеннями їх розміщення на технічних засобах для розробників системи. На рис.1.14 наведено зображення поділу таблиці "пацієнт" на три екстента (<<Tablespace>>) у відповідності з першою літерою прізвища пацієнта.

Рис. 1.14 Екстенти таблиці "Пацієнт"

Основними поняттями UML, які використовуються на даному етапі, є наступні:

1) компонент - самостійний фізичний модуль системи;

2) залежність - зв'язок між двома елементами, при якому зміни в одному елементі викликають зміни іншого елемента;

3) пристрій - вузол, що не обробляє дані;

4) процесор - вузол, що виконує обробку даних;

5) з'єднання - зв'язок між пристроями і процесорами.

Діаграми розгортання дозволяють відобразити на єдиній схемі різні компоненти системи (програмні та інформаційні) та їх розподіл по комплексу технічних засобів (рис. 1.15).

Рис. 1.15 Фрагмент діаграми розгортання ІС

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

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

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

1.8 Одержання прав доступу вхід у підсистему

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

– глава підрозділів;

– адміністратор системи;

– керівник;

– медпрацівник.

Користувач, що авторизувався як «Глава підрозділів» обмежується можливістю одержання медичного звіту по заданому тимчасовому періоді, групі й інституту, а також одержує статистичні дані обстежень.

Користувач, що авторизувався як «Адміністратор системи» обмежується правами ведення обліку користувачів підсистеми.

Користувач, що авторизувався як «Керівник» одержує повний перелік прав і привілеїв стосовно інших груп:

– одержання медичного звіту по заданому тимчасовому періоді, групі, інституту;

– одержання статистичних даних обстежень;

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

– виписка довідок;

– збір даних по формах;

– облік карт хворого.

Користувач, що авторизувався як «Медпрацівник» одержує найбільш повний перелік прав і привілеїв стосовно інших груп:

– виписка довідок;

– збір даних по формах;

– облік карт хворого.

1.9 Характеристика комплексу завдань

Не дуже давно вся рутинна робота з ведення обліку медичного обстеження проводилася працівниками медичної установи при ВНЗ. Основними мінусами такої роботи можна назвати ряд яскраво виражених факторів:

– повільна швидкість виконання робіт;

– трудомісткий пошук необхідної інформації;

– невикористання можливості централізованої бази даних всіх підрозділів ВНЗу для обліку;

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

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

Підсистема повинна забезпечувати рішення наступних завдань:

– формування звітів;

– зберігання всієї інформації, що стосується медичної сторони;

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

– збір даних по формах;

– облік карт хворого;

– виписка довідок;

– хронологічний облік зміни даних;

– забезпечення розмежованого доступу до даних.

Програмне забезпечення повинне являти собою web-додаток. Програмна одиниця, що функціонує за допомогою програми перегляду web-сторінок (браузер/навігатор).

Функціональний состав програми може бути розширений за допомогою зміни коду програми, що розташовується на сервері. Система повинна підтримувати роботу з базою даних в архітектурі «клієнт-сервер».

1.10 Вихідна інформація

У таблиці 1.1 наведені перелік і опис вихідних повідомлень, видаваних підсистемою.

Таблиця 1.1

Опис і перелік вихідних даних

Характеристика повідомлення	Значення й зміст
Ідентифікатор	1
Найменування	Медичний звіт по тимчасовому періоді, групі, інституту
Частота надходження	По запиті
Джерело
Состав	ФІП, група, інститут, дані обстежень
Ідентифікатор	2
Найменування	Статистика обстежень
Частота надходження	По запиті
Джерело
Состав	Процентне співвідношення даних обстежень
Ідентифікатор	3
Найменування	Медична довідка
Характеристика повідомлення	Значення й зміст
Частота надходження	По запиті
Джерело
Состав	Дані пацієнта, дані обстеження
Ідентифікатор	4
Найменування	Карта хворого
Частота надходження	По запиті
Джерело
Состав	Дані пацієнта, дані по всіх обстеженнях

1.11 Вхідна інформація

Таблиця 1.2

Опис і перелік вхідних даних

Характеристика повідомлення	Значення й зміст
Ідентифікатор	1
Найменування	ДАНІ ДЛЯ ПРОЦЕСУ АВТОРИЗАЦІЇ
Частота надходження	По запиту
Джерело
Состав	Логін і пароль користувача
Ідентифікатор	2
Найменування	ДАНІ ПАЦІЄНТА
Частота надходження	По запиту
Джерело
Состав	Прізвище, ім'я та по батькові пацієнта, посада, інститут, група, дата народження
Ідентифікатор	3
Найменування	ДАНІ ОБСТЕЖЕНЬ ПО ДИФТЕРІЇ Й КОКЛЮШУ
Частота надходження	По запиту
Джерело
Состав	Вік, доза, дата, серія, результат, відвід.
Характеристика повідомлення	Значення й зміст
Ідентифікатор	4
Найменування	ДАНІ ОБСТЕЖЕНЬ ПО КЛІЩОВОМУ ЕНЦЕФАЛІТІ
Частота надходження	По запиту
Джерело
Состав	Вік, доза, дата, серія, результат, відвід.
Ідентифікатор	5
Найменування	ДАНІ ОБСТЕЖЕНЬ ПО КОРИЕВОЙ КРАСНУСІ
Частота надходження	По запиту
Джерело
Состав	Вік, доза, дата, серія.
Ідентифікатор	6
Найменування	ДАНІ ОБСТЕЖЕНЬ ПО КОРІ
Частота надходження	По запиту
Джерело
Состав	Вік, доза, дата, серія, результат, відвід.
Ідентифікатор	7
Найменування	ДАНІ ОБСТЕЖЕНЬ ПО ПАРОТИТІ
Частота надходження	По запиту
Джерело
Состав	Вік, доза, дата, серія, результат, відвід.
Ідентифікатор	8
Найменування	ДАНІ ОБСТЕЖЕНЬ ПО ПОЛІОМІЄЛІТІ
Частота надходження	По запиту
Джерело
Состав	Вік, доза, дата, серія, результат, відвід.
Характеристика повідомлення	Значення й зміст
Ідентифікатор	9
Найменування	ДАНІ ОБСТЕЖЕНЬ ПО ТУЛЯРЕМІЇ
Частота надходження	По запиту
Джерело
Состав	Вік, доза, дата, серія, результат, відвід.
Ідентифікатор	10
Найменування	ДАНІ ОБСТЕЖЕНЬ ПО ТУБЕРКУЛЬОЗІ
Частота надходження	По запиту
Джерело
Состав	Вік, доза, дата, серія.
Ідентифікатор	11
Найменування	ДАНІ ОБСТЕЖЕНЬ ПО РЕАКЦІЇ МАНТУ
Частота надходження	По запиту
Джерело
Состав	Дата, результат.
Ідентифікатор	12
Найменування	ДАНІ ПО ФЛЮОРОГРАФИЧНОМУ ОБСТЕЖЕННЮ
Частота надходження	По запиту
Джерело
Состав	Курс, дата, серія, результат.
Ідентифікатор	13
Найменування	ДАНІ ПО ОБСТЕЖЕННЮ ТЕРАПЕВТА/ПЕДІАТРА
Частота надходження	По запиту
Джерело
Состав	Код спеціальності, дата, оцінка якості.
Ідентифікатор	14
Найменування	ДАНІ ПО ОБСТЕЖЕННЮ НЕВРОЛОГА
Характеристика повідомлення	Значення й зміст
Частота надходження	По запиту
Джерело
Состав	Код спеціальності, дата, оцінка якості.
Ідентифікатор	15
Найменування	ДАНІ ПО ОБСТЕЖЕННЮ ОФТАЛЬМОЛОГА
Частота надходження	По запиту
Джерело
Состав	Код спеціальності, дата, оцінка якості.
Ідентифікатор	16
Найменування	ДАНІ ПО ОБСТЕЖЕННЮ ОТОЛАРИНГОЛОГА
Частота надходження	По запиту
Джерело
Состав	Код спеціальності, дата, оцінка якості.
Ідентифікатор	17
Найменування	ДАНІ ПО ОБСТЕЖЕННЮ ХІРУРГА
Частота надходження	По запиту
Джерело
Состав	Код спеціальності, дата, оцінка якості.
Ідентифікатор	18
Найменування	ДАНІ ПО ОБСТЕЖЕННЮ УРОЛОГА/ГІНЕКОЛОГА
Частота надходження	По запиту
Джерело
Состав	Код спеціальності, дата, оцінка якості.
Ідентифікатор	19
Найменування	ДАНІ ПО ОБСТЕЖЕННЮ ЕНДОКРИНОЛОГА
Частота надходження	По запиту
Джерело
Состав	Код спеціальності, дата, оцінка якості.
Ідентифікатор	20
Найменування	ДАНІ ПО ОБСТЕЖЕННЮ СТОМАТОЛОГА
Частота надходження	По запиту
Джерело
Состав	Код спеціальності, дата, оцінка якості.
Ідентифікатор	21
Найменування	ДАНІ ПО ОБСТЕЖЕННЮ ОТОЛАРИНГОЛОГА
Частота надходження	По запиту
Джерело
Состав	Код спеціальності, дата, оцінка якості.

На етапі створення логічної моделі ІС задається у вигляді моделі та опису системних прецедентів, а попереднє проектування здійснюється з використанням діаграм класів, діаграм послідовностей і діаграм станів. Основною метою автоматизації процесу ведення обліку медичного обстеження є повна ліквідація рутинної роботи з паперами, швидкий доступ до необхідної інформації, редагування дані обстеження й легкість складання звітів обстежень.

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

РОЗДІЛ 2. Огляд аналогів проектованої підсистеми

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

2.1 Огляд системи «1С-АНАЛИТ: Медицинское учреждение»

Конфігурація «1С-АНАЛИТ: Медицинское учреждение» призначена для автоматизації роботи медперсоналу лікувальної установи, реєстрації зроблених медичних послуг, організації статистичного медичного обліку, а також обліку й контролю ліжкового фонду. Дана конфігурація є розвитком раніше випущених окремих медичних конфігурацій «1С-АНАЛИТ: Медичні послуги» і «1С-АНАЛИТ: Поліклініка».

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

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

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

– облік результатів зроблених послуг.

2.1.1 Функціональні можливості конфігурації, особливості обліку

Дану конфігурацію можна розділити на чотири функціональні частини:

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

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

Стаціонар - для обліку ліжкового фонду, планування госпіталізації й переміщення хворих. Медстатистика - для організації статистичного обліку по захворюваності, непрацездатності й іншим напрямкам.

2.1.2 Основні можливості конфігурації

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

– реєструвати захворювання, де виявлялася медична допомога вперше або повторно;

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

– резервувати й змінювати стан ліжкового фонду стаціонару;

– оформляти заявки на прийом планового хворого;

– оформляти, як екстрену, так і планову госпіталізацію, реєструвати внутрішні переклади пацієнтів, оформляти виписку;

– вести диспансерний облік населення;

– вести розклад прийому лікарів;

– вести нормований облік матеріалів.

2.1.3 Регламентована звітність

У конфігурації реалізоване формування регламентної звітності:

– про захворювання злоякісними новотворами;

– про захворювання активним туберкульозом;

– про грибкові шкірні захворювання;

– про число захворювань і диспансеризації;

– про діяльність стаціонару;

– про число захворювань і причини смерті;

– про дітей-інвалідах;

– про число осіб із уперше встановленими професійними захворюваннями.

Реалізовані в програмі звіти дозволяють аналізувати й контролювати:

– взаєморозрахунки із клієнтами;

– перелік наданої медичної допомоги;

– облік і показники відвідувань;

– пацієнтів, що перебувають на лікуванні;

– стан ліжкового фонду;

– надходження пацієнтів на лікування за звітний період;

– причини відмов від госпіталізації;

– перелік зроблених послуг пацієнтам;

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

2.2 Огляд системи «Комп'ютерна реєстратура поліклініки»

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

Система «Комп'ютерна реєстратура» може використовуватися в установах, що роблять медичні, косметичні й оздоровчі послуги населенню. У системі передбачені наявні й безготівкові розрахунки з пацієнтами, а також розрахунок зі страховими компаніями. Кількість робочих місць системи - від одного (у кабінеті лікаря), - до декількох десятків (у локальній обчислювальній мережі поліклініки).

Простий інтерфейс системи з користувачем забезпечує швидке освоєння медичним персоналом навичок роботи. Інформаційна безпека забезпечується паролем доступу до деяких функціональних можливостей системи, наприклад до фінансової звітності.

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

Рис. 2.1 Аналог підсистеми «Комп'ютерна реєстратура поліклініки»

Рис. 2.2 Список послуг прейскуранта «Комп'ютерна реєстратура»

Основні можливості:

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

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

– розподіляти час відвідування пацієнта й заносити їх у базу;

– вести диспансерний облік населення;

– вести розклад прийому лікарів;

– вести нормований облік матеріалів.

2.3 Порівняння аналогів

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

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

– кроссплатформенность - значимість критерію 0.05;

– універсальність - значимість критерію 0.3;

– ступінь складності засвоєння - значимість критерію 0.15;

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

Тепер визначимо шкалу балів, що буде являти собою трибальну систему з балами 1,2,3. Чим вище бал, тим більше значимо показник (для критерію вартість, чим менше вартість, тим більше бал). Таким чином, оцінка для обраного критерію буде розраховуватися за формулою 2.1:

, (2.1)

де, S_i - оцінка системи по i-му критерії;

p_iк - бал системи по i-му критерії;

w_iк - вага i-го критерію.

З таблиці 2.1 видно, що лідером порівняння є система «1С-АНАЛИТ: Медицинское учреждение» не дивлячись те, що система дорожче аналогів.

Таблиця 2.1

Порівняння систем

Системи	Критерії - значимість	Сума оцінок
	Вартість - 0,3	Кросс-платформен-ність - 0,05	Універсальність - 0,3	Ступінь складності засвоєння - 0,15	Гнучкість системи - 0,2
	б	о	б	о	б	о	б	о	б	о
1С-АНАЛИТ: Медицинское учреждение	2	0,6	3	0,15	3	0,9	3	0,45	2	0,4	2,5
Комп'ютерна реєстратура поліклініки	3	0,9	1	0,05	1	0,3	3	0,45	1	0,2	1,9
Розроблювальна система	3	0,9	2	0,1	2	0,6	3	0,45	2	0,4	2,45

Безумовно, ця система є найбільш повноцінної, також фірма-виготовлювач відмінно зарекомендувала себе на ринку програмних пакетів і вже не перший рік є лідером. Але варто відзначити, що розроблена система теж має високу оцінку, усього на 0,05 менше «1С-АНАЛИТ: Медицинское учреждение» і розробляється спеціально для ВНЗу, ураховуються вимоги, що стосуються інтерфейсу.

РОЗДІЛ 3. Розробка інформаційного забезпечення

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

3.1 Проектування інформаційного забезпечення

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

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

Проектування структури бази даних було зроблено за допомогою CASE-засобу «Erwin 4.0». Що дозволило значно розширити кількість цільових серверів для проектованої бази даних.

Також слід зазначити, що CASE засіб «Erwin 4.0» підтримує досить велику кількість СКБД, але, у той же час, при конкретній реалізації, наведена нижче схема структури бази даних буде незначно відрізняється від свого реального прототипу. Крім того, у зазначеному CASE засобі на довжину найменування таблиць і атрибутів накладене обмеження, тому далі назви таблиць і атрибутів будуть приводитися без додаткових застережень.

Було зроблено проектування бази даних методом «сутність-зв'язок». Для цього виділимо базові сутності із предметної області:

– персона;

– адреса;

– обстеження.

Також етап проектування методом сутність зв'язок не дозволяє відразу й повною мірою виділити всі довідники, які доцільно створити в рамках системи.

Сутність «Персона» містить наступну інформацію людині:

– прізвище;

– ім'я;

– по батькові;

– дата народження;

– паспортні дані;

– документ про утворення;

– адреса проживання.

Сутність «Адреса» містить наступну інформацію про адресу:

– країна;

– область;

– місто або населений пункт;

– район (якщо місто);

– вулиця;

– будинок;

– квартира.

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

– вік пацієнта;

– дата обстеження;

– серія;

– доза;

– результат;

– дата відводу за медичними показниками;

– персона.



Рис. 3.1 Первісний варіант діаграми сутність-зв'язок

автоматизований медичний база даний

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

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

Безумовно, надалі в спроектовану модель відбудеться додавання переглядів (VIEW) і збережених процедур для скорочення тексту SQL запитів системи й збільшення продуктивності, формування набору переглядів і збережених процедур буде відбуватися в міру створення системи виходячи з винесення загальних частин запитів різних методів системи.

3.2 Тестування інформаційної моделі

Тестування створеної моделі даних буде вироблятися за допомогою спеціалізованого CASE-засобу «ERwin Examiner 4.0», призначеного для тестування інформаційних моделей побудованих за допомогою CASE-засобу «Erwin 4.0».

Створена модель була імпортована в ERwin Examiner, після чого був запущений загальний тест схеми бази даних, що містить у собі діагностику:

– атрибутів;

– індексів і обмежень;

– нормалізації;

– зв'язків.

По закінченні тестування був отриманий звіт. Результат загальної діагностики інформаційної моделі представлений на рис. 3.2.

Рис. 3.2 Звіт тестування вихідної моделі

Продуктивність (дивися рис. 3.2)

Як зауваження по продуктивності в ході діагностики були запропоновані наступних 8 зауважень у категорії індексів - не призначені індекси для атрибутів, а так само не визначені кластеризованні індекси для різних сутностей;

Застереження (дивися рисунок 3.2)

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

Відсутність індексів усього лише справа часу й у ході експлуатації БД найбільш вузькі ділянки з погляду продуктивності обов'язково будуть доповнені індексами, з іншої сторони надмірна кількість індексів також може погано відбитися на продуктивності БД, тому розміщення додаткових індексів варто робити пізніше.

Так само варто відзначити, що наявність однакових імен атрибутів різних таблиць не є істотним недоліком. А стосовно до розглянутого СКБД це не може бути недоліком взагалі, тому що MySQL у випадку неоднозначного тлумачення запиту видає помилку із вказівкою найменування неоднозначного атрибута. Для коректного написання подібних запитів необхідно вказати ім'я таблиці для кожного неоднозначного атрибута.

Крім того, однієї з помилок при проектуванні БД є зайві зв'язки. Як видно з наведеної схеми структура БД містить кільцеві посилання. Це також не є помилкою при проектуванні, тому що «коренем» всіх подібних посилань є словники.

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

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

3.3 Состав інформаційного забезпечення

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

– персона;

– адреса;

– гепатит;

– паротит;

– поліомієліт;

– флюорографія;

– реакція манту;

– кліщовий енцефаліт;

– кір;

– корева краснуха;

– терапевт/педіатр;

– невролог.

– офтальмолог;

– отоларинголог;

– хірург;

– уролог/гінеколог;

– ендокринолог;

– стоматолог;

...