Модель автоматизации деятельности отделения реанимации

Содержание

Введение

Постановка задачи

I. Создание модели информационной системы с ALL FUSION PROCESS MODELER 4.1 (BPwin 4.1)

1.1 Создание модели в стандарте IDEFO

1.2 Создание модели в стандарте DFD

II. Построение модели в программе ERwin и генерация проекта в MS Access

Заключение

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

Введение

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

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

Использование системного подхода позволяет принять во внимание множество факторов самого различного характера, выделить из них те, которые оказывают самое большое влияние с точки зрения имеющихся общесистемных целей и критериев, и найти пути и методы эффективного воздействия на них. Системный подход основан на применении ряда основных понятий и положений, среди которых можно выделить понятия системы, подчиненности целей и критериев подсистем общесистемным целям и критериям и т.д. Системный подход позволяет рассматривать анализ и синтез различных по своей природе и сложности объектов с единой точки зрения, выявляя при этом важнейшие характерные черты функционирования системы и учитывая наиболее существенные для всей системы факторы. Значение системного подхода особенно велико при проектировании и эксплуатации таких систем, как автоматизированные системы управления (АСУ), которые по существу являются человеко-машинными системами, где человек выполняет роль субъекта управления. Классическими примерами являются банковские системы, системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т.д. Не является исключением и проектируемая АСУ «Отделение реанимации».

Постановка задачи

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

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

Представленная в курсовом проекте АСУ предназначена реализовать следующие функции:

· прием и обработку поступающей ежедневно информации (регистрация больного)

· формирование и передачу необходимой информации ее пользователю (уведомление дежурного врача о закреплении за ним больного)

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

· формирование отчетов (больной переведен или умер).

Основным достоинством подобной системы является то, что благодаря ей повышается качество функционирования управляемого объекта.

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

· прием исходной информации;

· обработку информации;

· получение и анализ результатов;

· выдачу управляющих воздействий.

I. СОЗДАНИЕ МОДЕЛИ ИНФОРМАЦИОННОЙ СИСТЕМЫ С ALL FUSION PROCESS MODELER 4.1 (BPWIN 4.1)

All Fusion Process Modeler (BPwin) - CASE-средство верхнего уровня, позволяющее моделировать бизнес-процессы. BPwin поддерживает три методологии - IDEF0, IDEF3 и DFD. Наиболее удобным языком моделирования бизнес-процессов является IDEF0.

1.1 СОЗДАНИЕ МОДЕЛИ В СТАНДАРТЕ IDEF0

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

* контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

* диаграммы декомпозиции;

* диаграммы дерева узлов;

* диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. Для ее построения:

Запустите Computer Associates BPwin.

Если появляется диалог ModelMart Connection Manager, нажмите на кнопку Cancel.

3. Щелкните по кнопке. Появится диалог I would like to. Внесите имя

модели «Деятельность компании» и выберите Type - IDEF0. Нажмите ОК. В открывшемся окне Properties for New Models, нажмите ОК.

4. Автоматически создается контекстная диаграмма.

Чуть ниже меню располагается панель инструментов программы (Рис. 1).

Рис. 1

С помощью этой панели создаем первый уровень проекта. На Рис. 2 представлен типичный пример контекстной диаграммы с граничными рамками - ИС «Отделение реанимации», которые называются каркасом диаграммы. Каркас содержит заголовок (верхняя часть рамки) и подвал (нижняя часть). Заголовок каркаса используется для отслеживания диаграммы в процессе моделирования. Нижняя часть используется для идентификации и позиционирования в иерархии диаграмм.

Рис.2

Здесь управляющая информация входит в блок сверху («Указания дежурного врача»), в то время как входная информация, которая подвергается обработке, показана с левой стороны блока («Пациенты»), а результаты (выход) - справа («Занесение данных в архив», «Заполненная карта пациента»). Механизм (человек или автоматизированная система), которым осуществляется операция, представляется стрелкой, входящей снизу. Все эти термины описывают взаимодействие системы с окружающей средой.

Дважды щелкаем по объекту, в появившемся диалоговом окне в графе Name прописываем имя объекта, в закладке Purpose следует внести цель и точку зрения, а в закладку Definition - определение модели и описание области.

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

С помощью треугольника направленного вниз, мы создаем второй уровень. Появляется следующее окно: где IDEF0 - свойство потока, Number of Activities in this - количество объектов. В нашем случае система разбивается на три фрагмента: «Прием пациентов», «Лечение» и «Выписка».

«Прием пациентов» - размещение больных в палатах и их регистрация.

«Лечение» - комплекс мероприятий и процедур, направленных на улучшение самочувствия пациента.

«Выписка» - врач заполняет формы о смерти или выписке.

Далее проводим декомпозицию до достижения нужного уровня подробности описания. Декомпозируемая работа изображается без черты в левом верхнем углу. Так же как и в первом случае в меню Number of Activities in this ставим 3 - количество действий: «Регистрация», «Врачебный осмотр» и «Оказание медикаментозного лечения» (Рис. 3).

Рис.3

Заполняем все названия потоков и объектов. В ходе нашего проектирования мы будем автоматизировать работу «Регистрация», поэтому снова проводим декомпозицию. Этот процесс разбивается на 2 - «Оформление истории болезни » и «Передача документов врачу». Опишем диаграмму с помощью отчета, сгенерированного BPwin:

Report for Diagram: A11, Регистрация

Activity Name: Оформление истории болезни

Activity Definition: Заполнение карты медицинской сестрой со сведениями о пациенте, его предварительном диагнозе.

Activity Status: WORKING

Activity Author: Еремеева

Object Type: Activity

Activity Number: A111

Activity Name: Передача документов врачу

Activity Definition: Передача медицинской карты и истории болезни

дежурному врачу для организации лечения.

Activity Status: WORKING

Activity Author: Еремеева

Object Type: Activity

Activity Number: A112

1.2 СОЗДАНИЕ МОДЕЛИ В СТАНДАРТЕ DFD

Создаем четвертый уровень проекта: выбираем объект «Оформление истории болезни », в окне Activity Box Count - DFD, количество действий - 3. Диаграммы потоков данных (DFD) используются для описания документооборота и обработки информации. Нотация DFD включает в себя такие понятия, как «внешняя ссылка» и «хранилище данных», что делает ее более удобной (по сравнению) с IDEF0 для моделирования документооборота. Рядом с меню появляется немного видоизмененная панель инструментов (Рис. 4).

Рис 4

С ее помощью добавляем нужные нам объекты и заполняем все названия потоков.

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

Рис 5

Щелкаем несколько раз мышкой по потоку данных «Регистрационная карта», в окне Arrow Properties заполняем вкладку Definition. В Arrow Data прописываем данные таблиц будущей базы данных (Рис. 6).

Рис 6

В меню File выбираем Export ERwin (BPX) и экспортируем наш проект в программу ERwin.

II. Построение модели в программе ERwin и генерация проекта в MS Access

Заходим в программу ERwin и создаем новый файл (File New). В окне Create Model-Select Template ставим флажок для создания логико-физической модели. Здесь же внизу из раскрывающегося списка Database выбираем Access для дальнейшего экспорта модели в MS Access. Снова заходим в меню File Import BPwin и открываем уже сохраненный нами файл Отделение.bpx.

Щелкая по каждой сущности в диалоге Entities определяем имя, описание и комментарии сущности, а в диалоге Attributes определяем тип атрибутов и задаем первичные ключи (Рис. 7).

Рис. 7

Ставим связи между сущностями. Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases). Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы.

По умолчанию имя связи на диаграмме не показывается. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Relationship Display и в контекстном меню включить опцию Verb Phrase.

При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK) (Рис. 8).

Рис. 8

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

Заранее создадим приложение Microsoft Office Access и назовем его «Реанимация».

В Erwin в меню Tools выбираем Forward Engineer/Schema Generation/… В открывшемся окне Access Schema Generation нажимаем кнопку Generate… . В окне Access Connection пишем имя компьютера и путь к заранее созданному приложению Microsoft Office Access. Нажимаем кнопку Connect и таким образом наш проект экспортируется в Access (Рис. 9).

Рис. 9

Заходим в приложение MS Access «Реанимация». Здесь представлены три таблицы: «Пациенты», «Дежурный врач» и «Проводимые мероприятия». Заполняем каждую из них (Рис. 10).

Рис. 10

В таблицу «Пациенты» мы добавили дополнительный столбец - дата поступления - для его дальнейшего вывода в отчете.

С помощью мастера создадим запрос. Выбираем поля, которые будут представлены в будущей форме: Из таблицы «Пациенты» - ФИО, номер страхового полиса, адрес, дата рождения, предварительный диагноз, порядковый номер; из таблицы «Дежурный врач» - ФИО; а из «Проводимые мероприятия» - лабораторные исследования, инструментальные исследования и интенсивная терапия.

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

Рис. 11

Изменим цвет фона и шрифта. Теперь у нас получилась рабочая форма. Есть возможность перехода по записям, печати, добавления и удаления записей (Рис. 12).

Рис. 12

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

Рис. 13

Заключение

База данных «Реанимация» была реализована на СУБД Microsoft Access в среде Microsoft Windows XP. В качестве руководства по генерации таблиц, экранных форм, запросов, отчетов, по программированию макрокоманд и программных модулей использовалась (2).

База данных вместе с таблицами данных, экранными формами, запросами, отчетными формами в Microsoft Access представляется в одном файле.

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

При разработке АСУ использовалось следующее программное обеспечение:

Операционная система Windows ХР

СУБД Access 2003

CASE - средство BPwin 7.0

CASE - средство ERwin

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

1. Смирнова Г. Н., Сорокин А.А, Тельнов Ю. Ф. Проектирование экономических информационных систем. Учебник для ВУЗов. М.: «Финансы и статистика», 2005.

2. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебник - М.: Форум, 2003.

3. Маклаков С.В. BPWin, Erwin. CASE-средства разработки информационных систем. М.: ДИАЛОГ - МИФИ, 1992.

4. Автоматизация управления предприятием / В.В. Баронов, Г.Н.Калянов, Ю.Н. Попов и др. - М.: Инфра-М, 2000.

5. Буч Г. Объектно-ориентированное проектирование с примерами применения: Пер. с англ. - М.: Конкорд, 1992.