Информационная система приема больных

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

38

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

Государственное образовательное учреждение

высшего профессионального образования

«Курский государственный университет»

Факультет информатики и вычислительной техники

Кафедра программного обеспечения и администрирования информационных систем

пояснительная записка к курсовой работе

по дисциплине

"Основы проектирования информационных систем"

Информационная система приема больных

Исполнитель:

студент группы 44

Гутенев В.

2011

СОДЕРЖАНИЕ

автоматизированная информационная система

Введение

Анализ требований к информационной системе

1.1 Описание и анализ предметной области

1.2 Обзор и анализ возможных альтернатив

1.3 Анализ функциональных и эксплуатационных требований

Проектирование информационной системы

Разработка архитектуры системы

Разработка модели предметной области

Разработка алгоритма функционирования системы

Проектирование интерфейса пользователя

Реляционная модель данных

Построение диаграммы классов

Реализация системы

3.1. Реализация программного обеспечения

3.2. Реализация технического обеспечения

Анализ результатов

4.1. Разработка тестов и тестирование системы

4.2. Анализ эффективности системы

Заключение

Список литературы

Приложение 1. Графический материал

Приложение 2. Текст программы

ВВЕДЕНИЕ

Разрабатываемый программный продукт является автоматизированной информационной системой здравоохранительного учреждения и носит название «Информационная система приема больных». Целью данной курсовой работы является создание информационной системы обслуживания пациентов, с помощью, которой упростится работа с данными для сотрудников учреждения здравоохранения.

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

Программный продукт разрабатывается с целью:

· организации достаточно быстрого и удобного варианта лечения;

· автоматизации работы с амбулаторными картами пациентов;

· автоматизации работы с распределением больных по отделениям и палатам.

С его помощью упростится распределение пациентов, формирование необходимых документов, а так же подбор наиболее удобной нагрузки для сотрудников учреждения. На данный момент в больницах города Курска используются устаревшие информационных систем, с помощью которых невозможно полностью обеспечить мобильную работу сотрудников. А пациенты зачастую не своевременно получают жизненно важную информацию. В данный программный продукт могут входить такие функции как выбор лечащего врача, выбор направления лечения и наиболее подходящего курса лечения, отправка необходимых документов непосредственно больному или врачу, а так же формирование электронных амбулаторных карт. Эта информационная система будет полезна для оперативного получения достоверных сведений по заданному вопросу.

Цель и назначение разработки

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

Основные задачи разработки

1. Обеспечить разделение доступа пользователей к информации.

2. Обеспечить просмотр требуемых документов и примеров их заполнения.

3. Обеспечить просмотр информации о свободных палатах в отделениях больницы.

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

5. Обеспечить составление отчетной документации для главного врача.

6. Реализовать накопление и обработку информации о поступивших в лечебное учреждение.

Для разработки программного продукта применяется среда визуального объектно-ориентированного программирования Borland Delphi 7 для создания информационной системы используется программа Rational Rose Enterprise Edition v2007.

1. АНАЛИЗ ТРЕБОВАНИЙ К ИНФОРМАЦИОННОЙ СИСТЕМЕ

1.1 Описание и анализ предметной области

В настоящее время запись на прием к врачу или приглашение пациента на обследование занимает весьма немалое время и требует личного участия всех задействованных лиц. В такой ситуации очевидны такие проблемы как большие очереди, накопление данных о больных, которые трудно хранить, частая потеря необходимой информации и ее необоснованное дублирование. Кроме того деятельность врачей затруднена. Это связано с необходимостью ведения большого числа документов и сопроводительных записей (выписка рецептов, оформление больничных, заполнение амбулаторных карт и др.). Предполагается, что амбулаторные карты пациентов должны обеспечивать контроль состояния пациента, а так же в полной мере информировать как самого пациента так и сотрудников больницы о всех показателях здоровья. Однако существующая практика показывает, что зачастую многие документы оказываются утеряны или устарели. Это приводит к разночтениям и зачастую сильно влияют на дальнейшее лечение пациента больницы.

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

Система позволит:

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

· оперативно формировать пакеты данных о пациентах и передавать их специалистам здравоохранения;

· оперативно взаимодействовать с пациентами, используя внутренние сервисы системы и внешние терминальные устройства;

· оперативно предоставлять и просматривать информацию по каждому пациенту.

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

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

Таким образом, разрабатываемая информационная система кинообслуживания должна выполнять следующие функции:

· просмотр данных о пациентах;

· просмотр расписания работы врачей;

· добавление, изменение и удаление данных по приему к врачам.

При приеме у врача пациент должен предоставить следующие документы:

· медицинскую карту;

· страховой медицинский полис;

· паспорт (в случае необходимости).

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

1.2 Обзор и анализ возможных альтернатив

При поиске альтернативных вариантов разрабатываемой информационной системы была найдена следующая информационная система - «МЕДИАЛОГ» [1].

Описание возможностей:

Опыт внедрения медицинских информационных систем обнаруживает две в равной степени важные потребности медицинских учреждений. С одной стороны, это необходимость комплексной автоматизации медучреждения, поскольку именно при комплексном подходе достигается максимальный эффект от использования медицинской информационной системы. С другой стороны, имеется ясно выраженная потребность в поэтапном внедрении с постепенным охватом разных служб и подразделений.

Медицинская информационная система «МЕДИАЛОГ», будучи комплексным решением, состоит из модулей и опций к этим модулям. Каждый модуль содержит определенную функциональность, которая позволяет медицинскому учреждению автоматизировать определенные виды своей деятельности. Каждая опция относится к одному из модулей и содержит дополнительную функциональность, отсутствующую в базовой поставке модуля.

Модули и опции являются функциональными единицами медицинской информационной системы «МЕДИАЛОГ». Кроме того, от состава приобретаемых модулей зависит стоимость лицензий.



Рис. 1.1 - Модульная структура системы «МЕДИАЛОГ»

Рассмотрим некоторые модули подробнее:

- электронная медицинская карта

Назначение:

· заполнение амбулаторной карты и истории болезни

· ввод разнородной информации

· настройка структуры базы данных и интерфейса ввода

· поиск информации о пациенте

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

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

- расписание

Список возможностей:

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

· автоматизация работы регистратуры и диспетчерской

· резервирование кабинетов

· планирование групповых мероприятий с резервированием помещений

· создание электронной медицинской карты пациента и заполнение титульного листа

· просмотр электронной медицинской карты (с учетом прав доступа к информации)

· удаленный доступ к расписаниям различных медицинских учреждений, входящих в единую сеть.

- системное ядро

Модуль решает следующие задачи:

· доступ к информации с любого компьютера локальной сети, а также с удаленных рабочих мест, в случае распределенной сети.

· формирование политики безопасности в рамках использования информационной системы.

Рис. 1.2 - Расписание отделения больницы в системе «МЕДИАЛОГ»



Рис. 1.3 - Планирование приемов у врачей в системе «МЕДИАЛОГ»

Недостатками рассмотренной выше информационной системы являются:

· большой объем занимаемой памяти;

· дублирование одних и тех же функций в различных модулях;

· высокая стоимость программного продукта;

· высокие системные требования.

1.3. Анализ функциональных и эксплуатационных требований

1.3.1 Стандарты

Программный продукт разрабатывается на основании следующих государственных стандартов:

1. ГОСТ 19.401-78. ЕСПД. Текст программы. Требования к содержанию и оформлению.

2. Международный стандарт ISO/IEC 12207. Информационные технологии. Процессы жизненного цикла программного обеспечения.

3. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.

4. ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

5. ГОСТ 34.603-92. Информационная технология. Виды испытаний автоматизированных систем.

1.3.2 Функциональные требования пользователя

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

· разделение доступа пользователей к информации;

· возможность просмотра и предоставления информации для пациентов;

· автоматизация работы регистратора;

· автоматизация работы врачей и доступ к необходимым данным.

1.3.3 Входные данные

Входными данными при работе с программным продуктом должны быть данные об учащихся, вводимые пользователем вручную. Входной язык приложения - русский.

Основные документы - это амбулаторные карты пациентов, талоны на посещение врачей и рецепты.

На пациентов оформляются следующие типы документов:

· амбулаторная карта (приложение 1);

· талон на прием к врачу;

· рецепт на лекарственные средства.

1.3.4 Выходные данные

Выходными данными при работе программы являются данные, выводимые на экран пользователя, и текстовые документы, составленные по запросам пользователя, в форматах doc. Язык выходных данных в приложении - русский.

1.3.5 Требования к интерфейсу

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

Главное меню программного продукта должно позволять пользователю выбрать категорию, к которой он относится (врач, пациент, регистратор), выводить подсказки для облегчения работы пользователя, а также иметь ссылку на автора приложения.

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

1.3.6 Требования к надежности

При работе с программным продуктом необходимо предусмотреть:

· контроль вводимой информации, т.е. возможность отслеживания ошибок, допускаемых пользователем, и последующей реакции программы на них;

· предусмотреть блокировку некорректных действий пользователя при работе с системой.

1.3.7 Требования к программной документации

В состав сопровождающей документации программного продукта должны входить следующие компоненты:

1. пояснительная записка на 55 - 60 листах, содержащая описание разработки;

2. исходные тексты модулей на языке Delphi;

3. откомпилированный EXE-файл на CD-диске.

1.3.8 Требования к составу и параметрам технических средств

Система должна работать на IBM совместимых персональных компьютерах. Минимальная конфигурация:

· тип процессора - Pentium;

· объем оперативного запоминающего устройства - 16 Мб;

· тип монитора - SVGA (15').

1.3.9 Модель вариантов использования

На основании анализа требований пользователя были выделены следующие варианты использования, представленные в таблице 1.1.

Таблица 1.1 - Описание вариантов использования

Термин	Значение
Login	Ввод пользователем логина и пароля для доступа к системе
View a receipt	Просмотр рецепта
View a patient card	Просмотр амбулаторной карты пациента
View a coupon	Просмотр талона
Create a receipt	Создание рецепта
Create a patient card	Создание карты пациента
Create a coupon	Создание талона
Changes a patient card	Внесение изменений в амбулаторную карту
Changes a coupon	Изменение данных талона
Delete a patient card	Удаление амбулаторной карты
Delete a coupon	Удаление талона

Действующие лица для диаграммы вариантов использования приведены в таблице 1.2.

Таблица 1.2 - Действующие лица

Термин	Значение
Doctor	Доктор
Patient	Пациент
Registrator	Работник регистратуры (регистратор)

На основании всех выше рассмотренных вариантов использования была составлена диаграмма вариантов использования, представленная на рис. 1.4.

Рис. 1.4 - Диаграмма вариантов использования

Описание варианта использования «Создание амбулаторной карты»

Действующие лица: регистратор

Заинтересованные лица и их требования:

· пациент, данные о котором должны быть занесены в базу данных;

· врач, который должен иметь доступ к точным данным по больным;

· регистратор, который должен создать амбулаторную карту пациента для дальнейшего ее использования.

Предусловия: клиент должен войти в систему

Постусловия: если вариант использования выполнен успешно, создаётся новая личная карточка, которой будет присвоен уникальный код. В противном случае состояние системы не изменяется.

Основной сценарий:

1. Система создаёт новый документ под названием «Амбулаторная карта больного»

2. В поле «№» генерируется код карты

3. Система предлагает заполнить карту

4. Пользователь заполняет карту

5. Система проверяет правильность введенных данных

6. Система спрашивает сохранить или не сохранить данные

7. Пользователь сохраняет данные

8. Вариант использования завершается

Альтернативные потоки:

5a. Если пользователь не заполняет все поля, система выводит сообщение «Заполните, пожалуйста, все поля»

5b. Если пользователь вводит неверные данные, система выводит сообщение «Проверьте правильность введенных данных»

7a. Если пользователь не сохраняет данные, состояние системы не меняется, вариант использования завершается

1.3.10 Глоссарий проекта

Основными понятиями проекта являются следующие:

· врач;

· пациент;

· регистратор;

· талон;

· амбулаторная карта;

· рецепт.

1.3.11 Проверка модели на полноту

Проверка на полноту диаграммы вариантов использования производится по операциям, выполняемым над основными объектами, представленными в таблице 1.3.

Основными объектами, упоминаемыми в модели вариантов использования являются: амбулаторная карта пациента, талон на посещение врача, рецепт.

Таблица 1.3 - Проверка на полноту

Варианты использования	Объекты
	Амбулаторная карта пациента	Талон	Рецепт
View a receipt			2
View a patient card	2
View a coupon		2
Create a receipt			1
Create a patient card	1
Create a coupon		1
Changes a patient card	3
Changes a coupon		3
Delete a patient card	4
Delete a coupon		4

В таблице 1.3 обозначены виды операций:

1 - создание;

2 - просмотр;

3 - изменение;

4 - удаление.

Над объектом «Рецепт» нет операций изменения и удаления (1, 4) так как рецепт выписанный врачом не подлежит изменению (может быть выписан только новый рецепт), а уничтожение рецепта происходит вне данной информационной системы, непосредственно при покупке лекарственных средств и не подлежит повторному использованию.

Результаты анализа полноты выполнения функциональных требований пользователя в модели вариантов использования приведены в табл. 1.4. Все функциональные требования пользователя отражены в основных вариантах использования.

Таблица 1.4 - Анализ полноты выполнения требований пользователя

Требования пользователя

Варианты использования

Login

View a receipt

View a patient card

View a coupon

Create a receipt

Create a patient card

Create a coupon

Changes a patient card

Changes a coupon

Delete a patient card

Delete a coupon

Разделение доступа к информации

+

Возможность просмотра и предоставления информации для пациентов

+

+

+

Автоматизация работы регистратора

+

+

+

+

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

+

+

+

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1Разработка архитектуры системы

Разрабатываемое приложение является клиент-серверным приложением.

В медицинском учреждении должны быть расположены персональные компьютеры для работы сотрудников (врачей и регистраторов) с приложением. У пациентов должен быть доступ к сети Интернет для возможности получения данных о возможных изменениях или к терминалам выдачи талонов. Все компьютеры в системе соединены локальной сетью, с сервером базы данных, где будет храниться база данных со всей информацией, а также должны быть расположены сетевые принтеры для распечатывания отчетов или другой информации, полученной от системы. Кроме того должен быть доступ к глобальной сети Интернет для передачи данных.

На рисунке 2.1. приведена предварительная диаграмма развертывания разрабатываемого приложения - архитектура технических средств системы.



Рис. 2.1 - Архитектура технических средств системы

2.2 Разработка модели предметной области

В результате анализа (раздел 1) были выделены категории концептуальных классов, представленные в таблице 2.1.

Таблица 2.1 - Список категорий концептуальных классов

Категория концептуальных классов	Примеры
Физические и материальные объекты	Пользователи Документы
Роли людей	Врач Регистратор Пациент
События	Создание, изменение, просмотр и удаление амбулаторных карт больных Создание, изменение, просмотр и удаление талонов Создание и просмотр рецептов
Процессы	Авторизация Работа с амбулаторной картой Работа с талонами Работа с рецептами

Пользуясь списком категорий и методом анализа словесного описания вариантов использования, составлен список кандидатур на роль концептуальных классов для предметной области. Он соответствует требованиям и принятым упрощениям для всей предметной области.

Список концептуальных классов:

· пациент (амбулаторная карта пациента);

· талон;

· рецепт;

· врач;

· регистратор.

На основании анализа словесного описания варианта использования, составлен список ассоциаций для предметной области, представленный в таблице 2.2.

Таблица 2.2 - Ассоциации для модели предметной области

Ассоциация	Описание ассоциации
Создаются	Регистратор создает для пациентов талоны на посещение
На прием	Талоны выдаются на прием к врачам
Заполняются	Амбулаторные карты заполняются регистраторами
Принадлежат	Пациентам принадлежат амбулаторные карты
Делает прием	Врачи делают прием по амбулаторным картам
Посещаются	Пациенты посещают врачей
Получают	Пациенты получают рецепты
Выдаются	Рецепты выдаются врачами

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

Таблица 2.3. - Атрибуты классов для модели предметной области

Название класса	Атрибуты класса
Пациент	Фамилия Имя Отчество Дата_рождения Домашний_адрес Телефон
Врач	Табельный_номер Фамилия Имя Отчество Адрес Телефон Специализация Квалификация №_отделения
Регистратор	Табельный_номер Фамилия Имя Отчество Адрес Телефон
Амбулаторная карта	№_карты Назначения
Талон	№_талона Время Кабинет
Рецепт	№_рецепта Дата Список_лекартсв

В результате объединения концептуальных классов, ассоциаций и атрибутов классов концептуальная модель предметной области имеет вид, показанный на рисунке 2.2.



Рис. 2.2 - Концептуальная модель предметной области

2.3 Разработка алгоритма функционирования системы

Для того чтобы предотвратить несанкционированный доступ, вход в систему осуществляется с проверкой имени и пароля.

Для этого необходимо разработать разделение одного интерфейса.

Алгоритм работы системы в виде диаграммы деятельностей приведен на рисунке 2.3.

Алгоритм работы регистратора в виде диаграммы деятельностей представлен на рисунке 2.4.

На рисунке 2.5 представлена деятельность регистратора с амбулаторными картами пациентов.

На рисунке 2.6 представлена деятельность регистратора при создании амбулаторной карты пациента.



Рис. 2.3 - Алгоритм работы системы

Рис. 2.4 - Диаграмма деятельностей регистратора



Рис. 2.5 - Диаграмма деятельностей работы с амбулаторными картами пациентов

Рис. 2.6 - Диаграмма деятельностей создания амбулаторной карты пациента

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

2.4 Проектирование интерфейса пользователя

2.4.1 Разработка диаграммы состояний интерфейса зрителя

На основании алгоритма функционирования и требований к интерфейсу (раздел 1) разработана диаграмма состояний (рис.2.7).

Рис. 2.7. Диаграмма состояний интерфейса заместителя директора

После запуска приложения на экране появляется форма. В специально отведенных полях ввода логина и пароля пользователь заносит свои данные. Если эти данные будут неправильными, система выводит ошибку, предложит ввести данные повторно. Если введенные пользователем данные будут верны, закроется окно авторизации и будет открыта главная форма с элементами, которые доступными пользователю.

2.5 Реляционная модель данных

На рис. 2.8 изображена реляционная модель данных.

Рис. 2.8. Реляционная модель данных

Реляционная модель данных разработана на основе концептуальной модели предметной области. Поскольку все связи имеют тип 1:М, они в реляционной модели данных реализуются добавлением внешнего ключа в таблицу со степенью связи М. Реляционная модель данных в дальнейшем служит для разработки БД. Информация о столбцах таблиц приведена в таблицах 2.4 ,2.5 ,2.6.

2.5.1 Построение диаграмм последовательностей для варианта использования «Создание амбулаторной карты пациента»

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



Рис. 2.9 - Диаграмма последовательностей создания амбулаторной карты для пациента

На рисунке 2.10. изображена кооперативная диаграмма создания амбулаторной карты пациента.

Рис. 2.10 - Кооперативная диаграмма Создание личной карты

2.6 Построение диаграммы классов

Диаграмма классов для варианта использования создания амбулаторной карты представлена на рисунке 2.11.



Рис. 2.11 - Диаграмма классов создания амбулаторной карты пациента

Таблица 2.4 - Атрибуты класса Амбулаторная карта

	Имя атрибута	Тип данных
1	№_карты	Double
2	Назначения	Memo
3	Табельный_номер	Double
4	Табельный_номер_врача	Double

Таблица 2.5. - Операции классов Form1 и Form2

Название формы	Имя опереции	Назначение
Form1	Открытие Form()	Открывает форму
Form2	Create personal card()	Создание записи о новом пациенте
	Delete personal card()	Удаление информации из базы данных.

3. РЕАЛИЗАЦИЯ СИСТЕМЫ

3.1 Реализация программного обеспечения системы

3.1.1 Разработка диаграммы компонентов

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

3.1.2 Объекты интерфейса пользователя

Система включает в себя несколько форм, каждая из которых реализована в своём компоненте на диаграмме компонентов (рис.3.1):

ь Больница - основная программа, предназначенная для запуска приложения;

ь Form1 - форма авторизации;

ь Form2 - главная форма, предлагает выбор объекта, над которым нужно производить операции ;

ь Form3 - выбор действия, в зависимости от прав пользователя ;

ь Form4 - форма создания амбулаторной карты;

ь Form5- форма удаления амбулаторной карты;

Рис. 3.1 - Диаграмма компонентов приложения

После запуска приложения на экране появляется форма авторизации. После ввода логина, пароля определяется правильность ввода, если такой пользователь существует, то выводится главная форма.

3.1.3 Классы и объекты интерфейса пользователя

Программный продукт состоит из нескольких форм: Form1, Form2, Form3, Form4, Form5, Form6.

Форма Form1

Внешний вид формы авторизации (Form1) представлен на рисунке 3.2.

1 2 3

Рис. 3.2 - Форма авторизации

В таблице 3.1 представлены расположенные на форме Form1 компоненты

Таблица 3.1. Компоненты формы Form1

№	Наименование компонента	Тип компонента	Назначение
1	ComboBox1	ComboBox	Поле ввода имени пользователя
2	ComboBox1	ComboBox	Поле ввода пароля
3	Ok	BitBtn1	Открывает главную форму

Форма Form2

Внешний вид формы главного меню (Form2) представлен на рисунке 3.3.

1 2

Рис. 3.3 - Форма главного меню

В таблице 3.2 представлены расположенные на форме Form1 компоненты

Таблица 3.2. Компоненты формы Form2

№	Наименование компонента	Тип компонента	Назначение
1	Выберите необходимое действие	RadioGroup1	Предназначено для выбора действия в системе
2	Продолжить	BitBtn1	Открывает форму, соответствующую выбранному действию

Форма Form3

Внешний вид формы «Выберите действие» (Form3) представлен на рисунке 3.4.



Рис. 3.4 - Форма главного меню

Форма Form4

Внешний вид формы «создание личной карточки» (Form4) представлен на рисунке 3.5

Рис. 3.5. - Форма Создание личной карты

3.2 Реализация технического обеспечения

Полная диаграмма развертывания информационной системы приведена на рис. 3.6.



Рис. 3.6. - Диаграмма развертывания информационной системы

В данной программе было проведено программирование на языке Delphi [10], а так же использовалась база данных в MS Access 2007 [6].

4. АНАЛИЗ РЕЗУЛЬТАТОВ

4.1 Разработка тестов и тестирование системы

Было проведено тестирование разработанного программного продукта.

При этом была проверена работоспособность системы на всех основных переходах диаграммы состояний интерфейса пользователя и на всех вариантах использования в соответствии с моделью вариантов использования.

4.1.1 Пример тестирования операции «Просмотр личной карточки»

Первоначально должна быть открыта форма авторизации (рис. 4.1).После чего откроется главная форма (рис. 4.2). Для работы с личной карточкой пользователь должен выбрать в меню «Личная карта». При нажатии этой кнопки открывается форма «Выберите действие над личной картой» (рис. 4.3). Для просмотра личной карточки пользователь должен нажать на кнопку «Просмотреть личную карту». При нажатии этой кнопки открывается форма «Просмотр личной карты» (рис. 4.4). Пользователь вводит нужную фамилию и нажимает кнопку «Просмотреть». После просмотра данных пользователь нажимает кнопку «возврат» для выхода в главное меню.

Рис. 4.1. - Форма авторизации



Рис. 4.2. - Главная форма

Рис. 4.3. - Форма выбора действия над личной картой

Рис. 4.4. - Форма просмотра личной карты

4.2 Анализ эффективности системы

Внедрение информационной системы приема больных позволит:

· уменьшить трудоемкость выполнения различных операций;

· автоматизировать работу врачей и регистраторов;

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

ЗАКЛЮЧЕНИЕ

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

В процессе создания системы в соответствии с заданием были разработаны: модель вариантов использования, концептуальная модель предметной области, диаграммы деятельности, реляционная модель данных, диаграмма состояний интерфейса, формы интерфейса, диаграмма компонентов и диаграмма развертывания. Была выполнена частично проверка и отладка системы.

Система позволяет:

· автоматизации работы с амбулаторными картами пациентов;

· регистратору и врачу редактировать необходимую информацию;

· автоматизации работы с распределением больных по отделениям и палатам.

В данной курсовой работе было проведено программирование на языке Delphi, для разработки информационной системы использовалась программа Rational Rose Enterprise Edition v2007, а также создана база данных в MS Access 2007. Программный продукт содержит форму авторизации пользователей, которая открывается после запуска приложения. Данная форма содержит поля для ввода пользователем своего логина и пароля.

СПИСОК ЛИТЕРАТУРЫ

1. Подробная информация об информационной системе «МЕДИАЛОГ» предоставлена на сайте http://www.pmtech.ru/

2. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. - М.: ДМК Пресс, 2001.

3. Вендров A.M. Проектирование программного обеспечения экономических информационных систем: Учеб. - М.: Финансы и статистика, 2000.

4. Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование. - М.: ДМК Пресс, 2001.

5. Ларман К. Применение UML и шаблонов проектирования. - М.: Издательский дом «Вильяме», 2001.

6. Бабкин Е.А. Базы данных: Практикум. Часть 1. СУБД Microsoft Access. Текст. - Курск: КГУ, 2006. - 83 с.

7. Леоненков А.В. Самоучитель UML. - СПб.: БХВ-Петербург, 2001.

8. Мандел Т. Разработка пользовательского интерфейса. - М: ДМК Пресс, 2001.

9. Мартин Дж. Организация баз данных в вычислительных системах. - М.: Мир, 1980.

10. Чен П. Модель «сущность-связь» - шаг к единому представлению данных // СУБД. 1995. №3. С. 137-158.

11. Бобровский С.И. Delphi 7. Учебный курс. - СПб.: Питер, 2007.

ПРИЛОЖЕНИЕ 1

Графический материал:

Медицинская карта амбулаторного больного

Рис. 5.1 - Амбулаторная карта

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