Арм регистратура.
Разработчик: MedTime.
Описание: АРМ регистратура поликлиники предоставляет следующие возможности:
1. Возможность автоматизировать рутинные операции, осуществляемые сотрудниками регистратуры поликлиники, позволяя им выполнять свою работу более быстро и эффективно.
2. Возможность более эффективно и оперативно организовать процедуру приема пациентов и запись их к врачам-специалистам.
3. Возможность оптимально составлять расписание приема врачей, исключая возможность совершения ошибок.
4. Формировать и распечатывать медицинскую документацию необходимую для работы регистратуры.
5. Автоматизирует процесс поступление больного в клинику, формирует дневное движение больных по лечебному учреждению.
6. В состав модуля АРМ регистратуры приемного покоя входят различные справочники и специально разработанные формы, позволяющие значительно уменьшить время затрачиваемое на оформление госпитализации пациента.
7. В АРМ регистратуры приемного покоя можно сформировать список больных обратившихся за медицинской помощью, а также посмотреть движение больных по стационару за интересующий период.
Формируемые документы:
Лицевая сторона медицинской карты больного (Форма № 003у);
Сопроводительный вкладыш к истории болезни;
Информативные согласия на обследование и лечение;
Справка;
Статистическая карта выбывшего из стационара (форма № 066/у);
Талон амбулаторного пациента (форма 025-7 у-89); (полный и сокращенный вариант);
Медицинская справка;
Список поступивших больных в стационар;
Движение больных по стационару.
2 – ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗ И ПРОЕКТИРОВАНИЕ ИС
Для исследования предметной области на 3 курсе я использовала методологию функционального моделирования IDEF0 (Рисунок 1), а для построения модели баз данных нотацию IDEF1х (Рисунок 2).
Эту методологию функционального моделирования я использовала для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования системы.
Рисунок 1. Методология функционального моделирования IDEF0.
Рисунок 2. Нотация IDEF1х.
После построения диаграмм я определила следующие потоки данных:
Входные потоки данных:
Информация о врачах, работающих в больнице;
Информация о пациентах, поступивших в больницу;
Информация о лекарствах, выписываемых пациентам;
Информация о процедурах, проводимых пациентам;
Информация о справках и больничных листах, выписываемых пациентам.
Выходные потоки данных:
Журнал приема пациентов;
Журнал выписываемых лекарств;
Журнал проводимых процедур;
Журнал выписываемых справок и больничных листов;
Различные отчеты и запросы.
В результате обследования предприятия мною определены следующие объекты:
1.Врачи (хранится информация о работающих в больнице врачах).
2.Пациенты (хранится информация о пациента, поступивших на лечение).
3.Лекарства (хранятся наименования лекарств).
4.Процедуры (хранятся наименования процедур).
5.Диагнозы (хранятся наименования диагнозов).
6.Справки (хранятся наименования справок и больничных листов).
7.Журнал приема (хранится информация о приеме пациентов врачами).
8.Журнал лекарств (хранится информация о выписываемых пациентам лекарств).
9.Журнал процедур (хранится информация о назначаемых пациентам процедурах).
10.Журнал справок (хранится информация о выписываемых пациентам справок и больничных листов).
Исходя из информационных потоков, моя программа выполняет две основные функции: ввод данных и анализ данных.
Описание требований к реализации этих функция можно представить в виде списков реализуемых прецедентов моей программы (Таблица 1).
Таблица 1. Описание требований к информационной системе в контексте модели прецедентов.
Номер варианта |
Назначение варианта |
Применение |
1 |
Меню |
Работа с БД |
1.1 |
Подключиться к БД |
Подключение к БД |
1.2 |
Отключиться от БД |
Отключение от БД |
1.3 |
Выход |
Закрытие приложения |
2 |
Ввод данных |
Ввод данных в таблицы БД |
2.1.1 |
Врачи |
Ввод данных в таблицу «Врачи» |
2.1.2 |
Пациенты |
Ввод данных в таблицу «Пациенты» |
2.1.3 |
Лекарства |
Ввод данных в таблицу «Лекарства» |
2.1.4 |
Процедуры |
Ввод данных в таблицу «Процедуры» |
2.1.5 |
Справки |
Ввод данных в таблицу «Справки» |
2.1.6 |
Диагнозы |
Ввод данных в таблицу «Диагнозы» |
2.2 |
Навигация по вводу данных в таблицы |
Выполнение функций по навигации ввода данных |
2.2.1 |
Поля ввода данных |
Ввод информации |
2.2.2 |
«Предыдущая» |
Переход на предыдущую запись |
Таблица 1 (Продолжение)
2.2.3 |
«Следующая» |
Переход на следующую запись |
2.2.4 |
«Добавить запись» |
Добавление введённой в поля информации в запись |
2.2.5 |
«Удалить запись» |
Удаление выбранной записи |
2.2.6 |
«Обновить» |
Обновление выбранной записи |
2.2.7 |
«Очистить» |
Очистки полей ввода информации |
3 |
Анализ данных |
Анализ введённой информации |
3.1 |
Отчёт по врачам |
Вывод отчёта по врачам на основе информации в БД |
3.2 |
Статические запросы |
Показ сформированных запросов без возможности изменения самого запроса |
3.2.1 |
Запрос 1 |
Выполнение запроса на выборку пациентов, которым диагноз поставил хирург |
3.2.2 |
Запрос 2 |
Выполнение запроса на выборку пациентов, которым врачи выписали лекарство Абитаксел |
3.2.3 |
Запрос 3 |
Выполнение запроса на выборку пациентов, которым процедуры назначил врач-терапевт |
Таблица 1 (Продолжение)
3.2.3 |
Запрос 3 |
Выполнение запроса на выборку пациентов, которым процедуры назначил врач-терапевт |
3.2.4 |
Запрос 4 |
Выполнение запроса на выборку пациентов, которым были выданы справки 2011-04-01. |
3.3 |
Динамические запросы |
Показ и формирование запросов из выбранных таблиц |
3.3.1 |
Запрос 1 |
Выполнение запроса на выборку диагноза и принимающих врачей по фамилии и имени пациента |
3.3.2 |
Запрос 2 |
Выполнение запроса на выборку лекарства и даты его выписывания по фамилии врача |
3.3.3 |
Запрос 3 |
Выполнение запроса на выборку процедуры и даты ее проведения по фамилии и имени пациента |
3.3.4 |
Запрос 4 |
Выполнение запроса на выборку даты выписывания справки и ее вида по фамилии пациента |
4 |
Справка |
Информация и помощь о программе |
4.1
|
О программе
|
Вызов окна справочной системы |
Представим сценарий реализации прецедента № 3.1 (Таблица 2).
Таблица 2. Сценарий реализации прецедента 3.1.
Действие пользователя: |
Выполнение программой: |
||
1)Нажатие кнопки «Отчёт по врачам» |
1)Открытие формы с отчётом |
||
3.1.2 |
«Zoom to fit» |
Развернуть отчёт по высоте экрана |
|
3.1.3 |
«100%» |
Полный вид отчёта |
|
3.1.4 |
«Zoom to width» |
Развернуть отчёт по ширине экрана |
|
3.1.5 |
«First page» |
Переход на первую страничку |
|
3.1.6 |
«Previous page» |
Переход на предыдущую страничку |
|
3.1.7 |
«Next page» |
Переход на следующую страничку |
|
3.1.8 |
«Last page» |
Переход на последнюю страничку |
|
3.1.9 |
«Print setup» |
Включение настроек принтера |
|
3.1.10 |
«Print» |
Печать странички |
|
3.1.11 |
«Save» |
Сохранение странички |
|
3.1.12 |
«Open» |
Открытие странички |
|
3.1.13 |
«Close» |
Закрытие отчёта |
|
3 – ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ЛИЕНТСКОМУ ПРИЛОЖЕНИЮ ИС.
Исходя из того, что я определила в проектировании модели прецедентов можно определить следующие требования:
1.Требования к системе и ее частям:
создаваемая АСУ должна повысить скорость работы с информацией, т.е. ускорить ввод данных в таблицы, удаление данных из таблиц, формирование различных отчетов и запросов.
2.Требования к структуре АСУ и входящим в нее частям:
АСУ должна содержать базу данных, целью которой является хранение данных в структурированном виде;
АСУ должна содержать приложение для работы с этой базой данных, целью которого является модификация данных в таблицах базы данных (ввод и удаление данных) и формирование отчетов.
3.Требования к режиму работы АСУ:
АСУ должна будет работать только во время работы регистратуры приемного покоя больницы.
4.Требования к качеству выполнения функций АСУ:
создаваемая БД должна содержать всю необходимую информацию для формирования отчетов и документов;
создаваемое приложение должно формировать все необходимые отчеты.
4 – ОПИСАНИЕ ИСПОЛЬЗУЕМОЙ БАЗЫ ДАННЫХ.
4.1. ER-диаграмма и описание физической модели.
На рисунке 3 показана ER-диаграмма базы данных. Она предназначена для графического представления модели данных разрабатываемой программной системы и предлагает набор стандартных обозначений для определения данных и отношений между ними. С помощью этого вида диаграмм можно описать отдельные компоненты концептуальной модели данных и совокупность взаимосвязей между ними.
Рисунок 3. ER-диаграмма.
Я не привожу таблицу сущностей и атрибутов, т.к. на рисунке 3 отчетливо видны названия сущностей и атрибутов, а также отмечены первичные и вторичные ключи.
Генерация физической модели производилась в программе Erwin. После
документирования логической модели получили физическую модель БД представленную на рисунке 4. Физическая модель данных это модель БД предназначенная для конкретной СУБД.
Рисунок 4. Физическая модель БД.