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

– резервне копіювання даних.

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

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

Проектована система є багатоланковою (дивися рис. 4.1). У системі можна виділити дві основних ланки:

– СКБД;

– WEB сервер і сам додаток.

Подібний поділ обумовлений тим, що кожний з перерахованих компонентів може бути розміщений на окремому сервері.

Крім того, доцільно реалізувати систему web-орієнтованої. Вибір web-орієнтованої системи є обґрунтованим, по-перше, надалі планується інтеграція системи в корпоративний сайт ВНЗу, що б сам сайт і всі розроблені системи функціонували як єдине цілі. По-друге, однієї з основних причин є те, що філії ВНЗу будуть здійснювати роботу із системою через мережу Intranet/Internet, а при розробці системи орієнтованої на web взаємодія користувача й системи здійснюється за допомогою браузера, тобто не вимагає установки додаткового ПО клієнтській частині. Цей спосіб задовольняє всім необхідним нам вимогам. Тобто, всі інтерфейснї форми генеруються системою мовою HTML, що є стандартом і інтерпретується будь-якими браузерами на будь-яких платформах.

Отже, найбільш розумним і вірним рішенням є організація системи як web-орієнтованої.

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

Рис. 4.1 Архітектура системи

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

Система реалізується для операційних систем сімейства Windows, але так, же передбачена можливість повноцінної роботи під керуванням операційної системи UNIX (Linux, FreeBSD). Цей вибір обумовлений рядом причин:

– відповідність стандартам корпоративної політики ВНЗу;

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

– погодженість із web-сервером. При роботі, система дуже активно взаємодіє з web-сервером, через який організований користувальницький інтерфейс.

Як основна мова програмування була обрана мова програмування PHP. Причини вибору даної мови програмування наступні:

– політика розробки програмного забезпечення в ВНЗу;

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

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

– PHP, у цей час широке розповсюджений, гнучкий і простий для реалізації;

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

У якості цільовий СКБД обрана MySQL. Дана СКБД реалізована на платформах Linux/FreeBSD/Windows - це дає можливість уникнути придбання окремого сервера).

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

– підтримка SQL92, SQL99 і SQL2003;

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

– підтримка переглядів (VIEWS) - логічного виділення деякого набору даних з бази даних без його фізичного зберігання;

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

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

– створення схем даних;

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

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

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

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

Для побудови моделі системи скористаємося універсальною мовою моделювання (UML - Unified Modeling Language). Так повна й детальна специфікація всього проекту є занадто об'ємною для повного приведення, то зробимо специфікацію проекту на більше абстрактному рівні, виділяючи тільки найважливіші елементи моделі, чим припускає детальна специфікація, при цьому супроводжуючи специфікацію текстовими коментарями.

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

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

Як видно з діаграми, основними діючими особами (акторами) є підрозділи ВНЗу [16]:

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

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

– керівник;

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

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

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

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

– Виписка довідок. Виписка довідок за різними критеріями:

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

б) медична довідка для басейну (форма №1);

в) мед довідка 086/в - медичний лікарський професійно-консультативний висновок.

– виписка з медичної карти амбулаторного хворого (мед довідка за формою 027/у) - альтернатива лікарняному аркушу;

– виписка з медичної карти стаціонарного хворого (форма 027/у) - альтернатива лікарняному аркушу;

– медична довідка - звільнення від фізкультури. Даною функцією управляє керівник і медработник.

– Збір даних по формах. Угруповання даних по запитах. Даною функцією управляє керівник і медпрацівник;

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

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

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

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

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

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

– медична довідка для басейну (форма №1);

– система й СКБД перебувають на різних серверах.

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

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

У рамках створення проекту, для поліпшення ергономічних властивостей системи, а також непрямого збільшення її продуктивності було запропоновано для більшості базових операцій використовувати ActiveX компонент «Microsoft.XMLHTTP». Даний компонент дозволяє робити передачу даних зовсім непомітно для користувача (відновлення форми при передачі даних не відбувається), крім того, даний компонент в останні роки здобуває все більшу популярність, що дозволяє зробити додаток кроссбраузерным (зокрема Mozilla, Firefox і Opera починаючи з версії 8.0 мають власний внутрішній аналог об'єкта «XMLHttpRequest»).

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

Для користувачів подібна організація додатка (з використанням компонентів «схованої» передачі даних) ставати практично звичайним додатком Windows, а, крім того, подібна реалізація дозволяє уникнути повторного пересилання тих самих статичних даних.

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

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

– meduchet - каталог для зберігання файлів, що виконуються, і модулів системи, що складається із двох підкаталогів (серверна частина);

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

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

– exam - підкаталог містить форми й модель для роботи з обстеженнями;

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

– templates - підкаталог містить html сторінки;

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

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

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

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

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

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

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

Автоматизована підсистема повинна використовуватися в медичному відділі ВНЗу.

Кінцевим користувачем програми є працівник медичного відділу ВНЗу.

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

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

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

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

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

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

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

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

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

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

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

Мінімальні вимоги, пропоновані до термінала, на якому буде www-сервер і сам додаток:

– IBM - сумісний комп'ютер;

– частота процесора - від 600 Мгц;

– обсяг ОЗУ - від 128 Мб;

– обсяг вільного дискового простору - від 500 Мб;

– операційна система - сімейства Windows (FreeBSD 4.5 і вище) або Unix.

Даний термінал повинен завжди бути підключений до електроживлення й обов'язково повинен мати мережну карту.

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

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

– Система повинна використовувати СКБД MySQL для зберігання даних

– Система повинна мати можливість интегрироватся з ИС відділу кадрів ВНЗу.

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

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

– завдання, виконуване главою підрозділів: одержання звіту про підсистему.

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

– у перелік завдань, виконуваних керівником медичного відділу, повинні входити:

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

– облік користувачів, що мають доступ до підсистеми;

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

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

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

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

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

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

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

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

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

Визначити доступ до спеціальностей може адміністратор системи.

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

WEB-додаток запускається за допомогою використання будь-якого доступного інтернет браузера що виконується, переважно Internet Explorer, або його аналогом Opera.

Далі необхідно авторизуватися в підсистемі. Авторизацію в підсистемі необхідно пройти однократно. При повторному запуску додатка дане функція з'явиться лише в тому випадку, якщо ви не використовували додаток у плині 15 хвилин, або розривали з'єднання. Щоб авторизуватися в особі іншого користувача, потрібно завершити роботу браузера й зайти на дану сторінку знову, або, якщо додаток уже відкрито під яким або користувачем, вибрати в меню функцію «Вихід».

Рис. 5.1 Авторизація

При вході на сайт завантажується головна сторінка додатка (рис. 5.1).

Рис. 5.2 Головна сторінка

На головну сторінку додатка ми попадаємо після проходження авторизації на сторінці «Авторизація».

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

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

Для додавання даних до історії хвороби пацієнта скористайтеся функцією «Додати дані до історії хвороби». У діалозі, що з'явився (див. рис.5.3) вам має бути вибрати зі списку послуг необхідне обстеження.

Рис. 5.3 Додавання даних по обстеженнях

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

Рис. 5.4 Додавання даних по гепатиті

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

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

Рис. 5.5 Список пацієнтів

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

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

Рис. 5.6 Список користувачів підсистеми

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

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

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

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

ВИСНОВКИ

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

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

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

При реалізації системи її побудова велася з використанням актуального программного забезпечення. Для моделювання була задіяна мова UML. Для проектування бази даних використовувалися CASE-Засоби BpWin і ErWin. База даний виконана в MySQL. Інтерфейс розроблений мовою PHP.

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

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

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

1. Коннолли Т., Бегг К., Страчан А. Бази даних: проектування, реалізація й супровід. Теорія й практика, 2-е изд.: Пер з англ.: Уч. сел.: Видавничий будинок «Вільямс», 2000 - 1120 с.

2. Роберт Дж. Мюллер. Бази даних і UML. Проектування. - М.: Видавництво «ЛОРІ», 2002 - 420 с.

3. Г. Россум, Ф.Л.Дж. Дрейк, Д.С. Откидач. Мова програмування Python, 2001 - 454 c.

4. Вендров А.М. Проектування програмного забезпечення економічних інформаційних систем: Підручник. - М.: Фінанси й статистика, 2002. - 352 с.

5. Тамре Л. Введення в тестування програмного забезпечення: переклад з англ. - Київ.: Видавничий будинок «Вільямс», 2003. - 368 с.

6. Зайцев Н.Л. Економіка промислового підприємства: Підручник; 2-е изд., перераб. і доп. - Київ.: ИНФРА - М, 1998. - 56 с.

7. Руднєва Л.Н., Дисидентка Б.Я. Основи підприємницької діяльності. - Навчальний посібник. - Київ: 1997. - 42 с.

8. Джон Макгрегор, Девид Сайкс. Тестування об'єктно-орієнтованого програмного забезпечення. Практичний посібник: переклад з англ. - Київ: ТОВ «ТИД «ДС»», 2002. - 432 с.

9. Вирт Н. Алгоритми й структури даних: переклад з англ. - 2-е изд. - Спб.: Невський Діалект, 2001. - 352 с.

10. Гома Х. UML. Проектування систем реального часу, розподілених і паралельних додатків: переклад з англ. - Київ.: ДМК Пресс, 2002 - 704 с.

11. Стоунз Р., Метью Н. MySQL. Основи - Київ.: Видавництво « Символ-Плюс», 2002 - 565с.

12. Електронний ресурс Agile Testing: http://djangoproject.com.

13. Мейер Э. CSS - каскадні таблиці стилів. Докладне керівництво, 2-е видання Київ.: Видавництво «Символ-Плюс», 2005 - 685

Додаток А

DFD-діаграма

Рис. Б.1 - Контекстний рівень (SADT)

Рис. Б.2 - Декомпозиція контекстного рівня (SADT)

Додаток Б

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

Рис. В.1 - Діаграма варіантів використання

Додаток В

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

Рис. Д.1 - Діаграма розміщення компонентів системи

Додаток Г

Копії графічних матеріалів

Рис Е.1 ER-схема бази даних системи обліку паціентів

ПРОДОВЖЕННЯ Додатку Г

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

Рис. Е.2 Засоби доступу до системи

Додаток Д

HTML-код сайта списка пацієнтів

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=windows-

1251" />

<title>Список поциентов</title>

<style type="text/css">

<!--

.dsf {

font-weight: bold;

}

.dsf {

font-size: x-large;

}

.sad {

color: #FFF;

}

a {

font-size: medium;

font-weight: bold;

}

a:link {

text-decoration: none;

color: #333;

}

a:visited {

text-decoration: none;

color: #333;

}

a:hover {

text-decoration: none;

color: #333;

}

a:active {

text-decoration: none;

color: #333;

}

-->

</style>

</head>

<body>

<table align="center">

<tr>

<h1>Список поциентов </h1></tr></table>

<table border="0" align="center" bordercolor="#9FBAF2">

<tr bgcolor="#66FFFF">

<td>Номер</td>

<td>Дата рождения</td>

<td>Фамилия</td>

<td>Имя</td>

<td>Отчество</td>

<td>Данные паспорта</td>

<td>Адресс</td><td></td><td></td>

</tr>

<tr bgcolor="#CDFEF5">

<td>1</td>

<td>1986-06-03</td>

<td>Иванов</td>

<td>Иван</td>

<td>Иванович</td>

<td>СФ777666</td>

<td>Первая 11 </td><td><a href='1.php?id=1'

target='mainFrame'>Подробно</a></td> <td><a href='add_all.php?id=1'

target='mainFrame'>Добавить</a></td> </tr>

<tr bgcolor="#CDFEF5">

<td>2</td>

<td>1994-06-22</td>

<td>Петров</td>

<td>Пётр</td>

<td>Петрович</td>

<td>ШМ234543</td>

<td>Вторая 22 </td><td><a href='1.php?id=2'

target='mainFrame'>Подробно</a></td> <td><a href='add_all.php?id=2'

target='mainFrame'>Добавить</a></td> </tr>

<tr bgcolor="#CDFEF5">

<td>3</td>

<td>1995-06-06</td>

<td>qq</td>

<td>ee</td>

<td>ww</td>

<td>fd453243</td>

<td>fgsdgfd 34 </td><td><a href='1.php?id=3'

target='mainFrame'>Подробно</a></td> <td><a href='add_all.php?id=3'

target='mainFrame'>Добавить</a></td> </tr>

</table>

<table border="0" align="center">

<tr>

<td></td>

<td></td>

<td> <a

href="/spisok_poc.php?pageNum_Recordset1=1&totalRows_Recordset1=4"

><img src="./Next.gif" /></a>

</td>

<td> <a

href="/spisok_poc.php?pageNum_Recordset1=1&totalRows_Recordset1=4"

><img src="./Last.gif" /></a>

</td>

</tr>

</table>

</body>

</html>

Размещено на Allbest.ru

...