Розробка автоматизованої системи роботи диспетчерської швидкої допомоги

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

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

Вступ

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

1. Дослідження і аналіз предметної галузі диспетчерської. Постановка задачі

Аналіз предметної галузі.

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

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

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

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

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

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

Постановка задачі.

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

Розробити програмне забезпечення БД диспетчерської швидкої для автоматизації та пришвидшення її роботи. Програмне забезпечення повинно реалізовувати автоматизацію наступних процесів:

· реєстрація пацієнта,

· направлення бланку бригаді,

· облік лікарів бригад швидкої допомоги,

· облік спеціалізованих бригад,

· створення звіту.

2. Розробка програмного забезпечення і БД для диспетчерської швидкої допомоги

2.1 Концептуальна модель даних

Після аналізу предметної галузі було створено концептуальну модель бази даних, що зображена на рисунку 1 у вигляді діаграми «Сутність - зв'язок». Концептуальна модель містить в собі такі сутності:

Пацієнт.

Пацієнт має атрибути: номер пацієнта, прізвище, ім'я, по батькові, дата народження, адреса, телефон.

Бланк.

Бланк виклику має такі атрибути : номер бланку, прізвище викликаючого, ім'я викликаючого, по батькові викликаючого, телефон, адреса, час, дата, скарги.

Звіт о препаратах.

Звіт має такі атрибути : використано препарату.

Препарати.

Препарати має такі атрибути : номер препарату, назва, міра виміру.

Бригада.

Бригада має такі атрибути : номер бригади, спеціалізацію.

Медичні працівники.

Медичні працівники має такі атрибути : номер працівника, прізвище, ім'я, по батькові, кваліфікація.

Рисунок 1 - Діаграма «Сутність - зв'язок»

2.2 Специфікація програмних модулів

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

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

DFD нульового рівня.

DFD нульового рівня є узагальненим представленням функціонуючої системи, на ній показаний головний процес та зовнішні сутності, що працюють з системою. DF діаграма нульового рівня була створена за допомогою Erwin Process Modeler та показана на рисунку 2.

DFD першого рівня.

На першому рівні діаграми потоків даних головний процес ділиться на підпроцеси, які його утворюють, показуються потоки даних, що приходять ззовні та потоки даних що йдуть до головного сховища даних. DFD першого рівня була створена за допомогою Erwin Process Modeler та показана на рисунку 3.

Опис потоків даних поданий в таблиці 1, створеній як Data usage report в Erwin Process Modeler.

Рисунок 2 - DFD нульового рівня

Рисунок 3 - DFD першого рівня

2.3 Логічна модель даних

Логічна модель БД є узагальненою схемою даних, яка не залежить від реалізації на конкретній СУБД, на ній показані таблиці даних диспетчерської, та зв'язки між ними. Логічна модель складається з 6 таблиць: Пацієнт, виклик, бригада, медичний працівник, препарати та звіт о препаратах. Логічна модель була створена за допомогою Erwin Data Modeler та зображена на рисунку 4.

Рисунок 4 - Логічна модель БД реєстратури

2.4 Алгоритм та графічний інтерфейс програмних модулів

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

Рисунок 5 - Форма «Препарати»

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

Рисунок 6 - Форма «Пацієнт»

На рисунку 6 зображено форму «Пацієнт», во призначена для оформлення виклику пацієнта. Для того, щоб оформити виклик потрібно заповнити представлені на рисунку 7 поля, якщо виклик реєструється не від пацієнта, то доцільніше скористуватися додатковою таблицею «Додаткова інформація». Не всі поля відкриті для заповнення, такі поля як: номер бланку, номер пацієнта, час, дата заблоковані для користувача, за для забезпечення цілісності даних.

Рисунок 7 - Форма «Медичний працівник»

На рисунку 7 представлено форму «Медичний працівник», ця форма призначена для додавання нових працівників. Поле номер працівника заблоковане і не може змінюватися користувачем. Для введення нового представника достатньо лише заповнити всі незаповнені поля форми.

Рисунок 8 - Форма «Звіт о препаратах»

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

2.5 Фізична модель даних

В якості фізичної реалізації баз даних було вибрано СУБД Microsoft Access 2013. Для цієї СУБД було створено фізичну модель даних за допомогою Erwin Data Modeler для диспетчерської швидкої допомоги яка зображена на рисунку 9.

Рисунок 9 - фізична модель бази даних

2.6 Розробка робочих документів

програмний інтерфейс алгоритм

Програмні форми були створені за допомогою інструменту Microsoft Access майстер форм. Були створені такі форми: звіт о препаратах, медичний працівник, пацієнт та препарати для роботи з базою даних. Редагування БД доступне зі створених форм.

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