Содержание Введение ................................................................................................................... 3 Глава I. Объектно-ориентированное проектирование информационной системы «Регистратура рыбницкого диагностического центра»....................... 5 1.1. Описание предметной области ..................................................................... 5 1.2. Деятельность регистратуры ГУ «РДЦ» ..................Ошибка! Закладка не определена. 1.3. Разработка информационной системы «Регистратура рыбницкого диагностического центра» средствами RationalRose .....Ошибка! Закладка не определена. Глава II. Функциональное проектирование информационной системы «Регистратура рыбницкого диагностического центра» .Ошибка! Закладка не определена. 2.1. Функциональное проектирование с помощью BPwin ................ Ошибка! Закладка не определена. 2.2. Создание диаграмм средсвом BPWin .....................Ошибка! Закладка не определена. Заключение ............................................................................................................ 19 Список использованной литературы ................................................................... 20 2 Введение В век информационных технологий стало реально все документы преобразовывать в электронный вид, и регистратура городской поликлиники в считанные минуты может найти сведения о принятых пациентах, вызовах, кабинетах. Актуальность создания диагностическом центре системы электронного документооборота в обусловлена сегодня необходимостью использования больших, и постоянно растущих, объемов информации при решении диагностических, терапевтических, статистических, управленческих и других задач. Цель курсового проекта состоит в разработке системы электронного документооборота для регистратуры ГУ «Рыбницкий диагностический центр», включающую в себя данные о врачах, пациентах, кабинетах и вызовах, которые необходимые для работы данного медицинского учреждения. Требуется создание полнофункциональной информационной системы, использование которой будет способствовать повышению эффективности работы центра, переходу на качественно новый уровень обслуживания и лечения пациентов. Прохождение лечения пациента в диагностическом центре подразумевает: оформление личной карточки пациента; хранение личной карточки пациента, историй всех болезней, поставленных диагнозов, результатов проведения исследований / анализов; направление пациента к врачу, на проведение исследования, сдачу анализов; оформление справок / больничных листов. В данном курсовом проекте поставлена задача разработки системы электронного документооборота для обслуживания пациентов, 3 использование которой позволит решить следующие задачи: упрощение доступа к персональным данным пациента; быстрое доведение результатов проведения исследований / анализов пациента до лечащего врача; сокращение штатной численности отдела регистратуры, расходов на зарплату и сокращение людских и временных затрат на обработку информации; централизованное хранение всех данных о пациенте; уменьшение количества противоречивых данных; упрощение постановки диагноза пациенту. Объект и предмет исследования 4 Глава I. Проектирование информационной системы регистратуры 1.1. Описание предметной области ГУ «Рыбницкий диагностический центр» был открыт 21 ноября 2014 года. Главной целью данного лечебного учреждения является предоставление высококачественных услуг по профилактике, диагностике, реабилитации и лечению пациентов. ГУ «Рыбницкий диагностический центр» мощностью в 1600 посещений в смену включает в себя противотуберкулезный диспансер на 25 посещений в смену, 8 сельских врачебных амбулаторий общей мощностью 470 посещений в смену и 21 фельдшерско-акушерских пунктов. В настоящее время учреждение имеет в своем составе следующее структурные подразделения: регистратура; терапевтическое отделение №1; терапевтическое отделение №2; консультативное отделение; отделение профилактики; отделение дневного стационара; отделение амбулаторной хирургии; отделение восстановительного лечения; кожно-венерологическое отделение; медицинский центр дружественный к молодежи; клинико-диагностическое отделение; диагностическое отделение; аптека; противотуберкулезный диспансер. Работа осуществляется коллективом медицинских работников, 5 насчитывающим более 350 человек в т.ч. 82 врача, 174 среднего медицинского персонала, 100 младшего и обслуживающего персонала. В коллективе работают 3 Заслуженных врача Приднестровской Молдавской Республики, 29 Отличников здравоохранения Приднестровской Молдавской Республики, 22 врача с высшей и первой квалификационной категорией и более 40 аттестованных средних медицинских работников. За этот год коллектив диагностического центра пополнился на 8 врачей и 19 средних медицинских работников. Отделение восстановительного лечения ГУ «РЛДРЦ» предоставляет следующие услуги: светолечение, магнитолечение, лазеротерапию, вакуумный и вибромассаж, рефлексо- и иглотерапию. В состав отделения входит водолечебница. Виды процедур: подводное вытяжение, душ шарко, подводный гидромассаж, бассейн для взрослых и детей, гидроколенотерапия, мини-сауна, спа-капсула и многие другие процедуры. Основная деятельность регистратуры диагностического центра – это сбор и хранение информации о врачах и пациентах, обработка информации, выдача справок и больничных листов, выдача расписаний работы врачей. Информация, хранимая в базе данных информационной системы регистратуры: Сведения о приемах Врач; дата приема; пациент; жалобы; диагноз; назначение; обследование. Информация о пациентах Информация о пациенте хранится в его карточке. Карточка имеет 6 номер. В карточке указывается: фамилия; имя; отчество пациента; возраст; пол; домашний адрес. В карточку заносится информация о каждом посещении поликлиники пациентом: дата посещения, жалобы, предварительный диагноз, назначения, выписан или нет, больничный лист, имя врача и специальность. Расписание работы врачей В расписании работы врачей указывается: на каком участке работает врач (если врач участковый); дни и часы приема; номер кабинета; специальность. Регистрация пациентов производится работниками регистратуры, которые заполняют первую страницу карточки. Информацию о болезнях и посещениях вносят врачи. Время приема одного больного нормировано и зависит от лечебного профиля. Больные назначаются врачу определенного профиля с учетом нормы приема. Однако, в исключительных случаях возможно внеочередное назначение с корректировкой остальных назначений. Одновременно врач обслуживает только одного больного. Больной может записаться к нескольким врачам, однако, время назначения должно быть различно с учетом норм приема. Отдельные категории врачей (терапевты, хирурги и др.) закреплены за определенными адресами, это учитывается при назначении. Врачи дают сведения о фактической явке больных на прием. Регистратор составляет список больных с указанием ФИО, времени 7 назначения, записавшихся на прием к определенному врачу на конкретную дату. Врач указывает ФИО, полный возраст и домашний адрес больных старше определённого возраста, записавшихся на прием к врачам определенного профиля в указанный период. Таблица 1 Термин Поликлиника Определение Многопрофильное профилактическое или специализированное учреждение для оказания лечебно- амбулаторной медицинской помощи пациентам. Регистратура Регистратура является поликлиники обеспечивающим структурным формирование и подразделением, распределение потоков пациентов, своевременную запись и регистрацию больных на прием к врачу, в том числе с применением информационных технологий. Работник Человек, осуществляющий регистрацию пациентов в поликлинике регистратуры используя специальное программное обеспечение. Врач Специалист с высшим медицинским образованием, занимающийся лечебно профилактической деятельностью. Пациент Больной, лечащийся у врача. Отделение Стационарное отделение в поликлинике, предназначенное для оказания неотложной медицинской помощи. График приема Данные о днях и времени приема у врачей . График загруженности Графически иллюстрированный показатель зависимости врача от количества пациентов. Талон на прием Подтверждение очередности записи к врачу в поликлинике. 1.2. Разработка функциональной модели системы средствами BPwin 8 BPwin – CASE-средство верхнего уровня, помогающее проводить анализ и реорганизацию предназначена для бизнес-процессов. описания Функциональная существующих модель бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей – того, к чему надо стремиться (модель TO-BE). Процесс построения информационной модели в BPwin состоит из следующих шагов: построить контекстную диаграмму; провести функциональную декомпозицию; после каждого сеанса декомпозиции провести сеанс экспертизы. CASE-cредство BPWin предназначено для проведения анализа и реорганизации бизнес-процессов. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. Такая технология построения модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. На основе модели BPwin строится модель данных, в программе поддерживается связь с ERwin. Функциональность BPwin заключается не только в рисования диаграмм, но и в проверке целостности и согласованности модели. BPwin обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами. Инструмент обеспечивает коррекцию наиболее часто встречающихся ошибок при моделировании, таких, как "зависание" связей при переходе от диаграммы к диаграмме, нарушение ассоциации связей в различных диаграммах модели и т.п. Кроме того, BPwin поддерживает пользовательские свойства, которые применяются к элементам диаграммы для описания специфических свойств, присущих данному элементу. 9 BPwin имеет широкие возможности по представлению диаграмм. Графическое представление модели может быть изображено при помощи различных цветов, шрифтов и прочих параметров представления, которые выделяют важные или, наоборот, тушируют незначительные аспекты модели. Эта, незначительная на первый взгляд, возможность является ключевой во время представления и обсуждения модели с заказчиком или экспертами предметной области, т.к. правильно подобранное графическое представление позволяет им быстрее сориентироваться в модели. BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEFO); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы: Почему этот процесс должен быть смоделирован? Что должна показывать модель? Что может получить заказчик? Формулировка цели позволяет команде аналитиков сфокусировать усилия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: проблемы, сделать "Идентифицировать возможным анализ и определить потенциальных текущие улучшений", "Идентифицировать роли и ответственность служащих для написания должностных инструкций", "Описать функциональность предприятия с целью написания спецификаций информационной системы" и т. д. На начальных этапах создания ИС необходимо понять, как работает организация. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области, 10 следовательно, она должна содержать в себе знания всех участников бизнеспроцессов организации. Наиболее удобным языком моделирования бизнеспроцессов является IDEF0. В методологии IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной т.е. функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Под моделью в методологии IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Описание системы с помощью методологии IDEF0 называется функциональной моделью. Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие. Модель может содержать четыре типа диаграмм: контекстную диаграмму А0 (в каждой модели может быть только одна контекстная диаграмма); диаграммы декомпозиции; диаграммы дерева-узлов; диаграммы только для экспозиции (FEO). Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. Рассмотрим, на примере процесса записи пациента к врачу построение контекстной диаграммы, что позволит нам рассмотреть взаимосвязь системы с окружающей средой. 11 Рис. 1. Контекстная диаграмма «Регистратура РДЦ» Как видно на контекстной диаграмме на вход подаются исходные данные о пациенте, они регламентируются пожеланиями пациента и загруженностью врачей, исполнителем является работник регистратуры, а оборудованием – рабочая платформа. В этом процессе происходит обработка входных данных, после чего обработанные данные передаются на выход в виде талона на прием и/или графика приёма врачей. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. Диаграмма верхнего уровня создается путем декомпозиции основной функции контекстной диаграммы. На диаграмме декомпозиции функции нумеруются автоматически слева направо. Номер функции показывается в правом нижнем углу. В левом верхнем исчезает небольшая диагональная 12 черта, которая показывает, что данная функция была декомпозирована. В ходе работы была создана диаграмма верхнего уровня, путем проведения декомпозиции контекстной диаграммы, результат которой представлен на рисунке 2. Рис. 2. Диаграмма декомпозиции «Регистратура РДЦ» В ходе декомпозиции процесса записи пациента к врачу в регистратуре РДЦ процесс был разбит на 3 процесса: 1) обработка данных; 2) выбор врача; 3) запись на прием. В первом процессе на вход поступают данные о пациенте, а после обработки этих данных на выход поступают уже обработанные данные. Данный процесс регламентируется пожеланиями пациента и загруженностью врачей, а для выполнения данного процесса необходима рабочая платформа и регистратор, который будет следить за тем, чтобы система работала 13 правильно. Далее обработанные данные поступают на вход второго процесса «Выбор врача». Данный процесс также регламентируется пожеланиями пациента и загруженностью врачей и для выполнения процесса, также необходима рабочая платформа и регистратор. Последний процесс «Запись на приём» на входе принимает обработанные данные, полученные во втором процессе, а на выходе выдает талон на приём и/или график приёма врачей. Для выполнения данного процесса необходима рабочая платформа и регистратор, а регламентируется процесс пожеланиями пациента и загруженностью врачей. Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает: функции обработки информации (работы); документы (стрелки, arrow), объекты, сотрудников или отделы, которые учавствуют в обработке информации; внешние интерфейс с ссылки внешними (external references), объектами, которые находящимися обеспечивают за границами моделируемой системы; таблицы для хранения документов (хранилище данных, data store). Рассмотрим на примере процесса «Составление расписания» диаграмму потоков данных: 14 Рис. 3. Диаграмма потоков данных процесса «Составление расписания» Внешние сущности изображают входы в систему и/или выходы из системы. Как видно на рисунке 3, внешней сущностью является Регистратура. Из нее поступают обработанные данные на вход процесса «Составление графика приемов». Данный процесс регламентируется различной документацией, гостами, а также «Нагруженностью врача». «Нагруженность врача» - это хранилище данных. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов. Результатом процесса является черновой вариант расписания, который поступает на вход процесса «Корректировка чернового варианта расписания». Этот процесс регламентируется документацией и стандартами, а для его выполнения необходимы рабочая платформа и персонал. В результате выполнения данного процесса получаем готовое расписание приемов, которое отправляется во внешнюю сущность «Регистратура», а далее в хранилище «База данных». 15 Также была построена диаграмма потоков данных для процесса «Запись на прием»: Рис. 4. Диаграмма потоков данных процесса «Запись на прием» Процесс «Запись на прием к врачу-специалисту» был разбит на 5 подпроцессов: 1) заполнение 1-й страницы медицинской карты; 2) запись к участковому врачу; 3) прием участковым врачом; 4) заполнение медицинской карты; 5) запись к специалисту. На прием к специалистам узкого профиля (эндокринологу, кардиологу, ревматологу, неврологу, гастроэнтерологу, гематологу, нефрологу) граждане, состоящие на диспансерном учете у профильного специалиста и внесенные в регистр диспансерных больных, могут быть записаны без предварительного посещения участкового врача. Запись должна быть обеспечена в течение 5 16 дней с момента обращения. Если гражданин не состоит на диспансерном учете у профильного специалиста, запись осуществляется к участковому врачу для решения вопроса о необходимости консультации узкого специалиста и ее организации в срок до 5 дней. На прием к специалистам узкого профиля (окулисту, хирургу, отоларингологу, травматологу, урологу, онкологу, физиотерапевту, андрологу, инфекционисту и пр.) запись осуществляется в день обращения, на следующий день или на любой другой день по желанию пациента. На вход первого процесса поступают обработанные данные о пациенте. После выполнения этого процесса получаем медицинскую карту с данными о пациенте. Медицинская карта с данными о пациенте поступает на вход второго процесса «Запись к участковому врачу». На прием к участковому врачу запись осуществляется в день обращения, на следующий день или на любой другой день по желанию пациента. Если прием участкового врача закончен или нет свободного времени для записи, при получении согласия, пациент может быть направлен к другому терапевту. После записи пациенту выдается направление на прием к участковому врачу, который поступает на вход третьего процесса «Прием участковым врачом». В ходе приема участковый врач заполняет лист опроса (жалобы пациента и другие показатели), который поступает на вход четвертого процесса – заполнение медицинской карты. Здесь регистратор переносит всю информацию с листа опроса в медицинскую карту, все медицинские карты хранятся в базе данных. После заполнения карты, регистратор выдает пациенту направление на прием к врачу-специалисту, происходит запись к врачу специалисту и больному выдается талон на прием. 17 Глава II. Проектирование системы с использованием платформы «1С: Документооборот» 18 Заключение В результате курсового проектирования была разработана информационная система отдела регистратуры "Рыбницкого лечебнодиагностического центра". Основой для создания информационной системы послужили проблемы предметной области. В качестве среды разработки было выбрано – Rational Rose 2006 и BPWin, предназначенное для автоматизации этапов анализа и проектирования предметной области. После изучения принципов использования среды Rational Rose и BPWin, были построены объектно-ориентированная и функциональная модели информационной системы. Использование данной ИС упрощает доступ к персональным данным пациента, централизует хранение всех данных о пациенте и уменьшает количество противоречивых данных. Благодаря этому представляется возможность сократить численности административно-управляющего персонала и расходов на зарплату, избежать снижение пропускной способности сети поликлиник при увеличении количества пациентов, повысить уровень качества обслуживания и лечения. В данном проекте были поставлены и решены следующие задачи: упрощение доступа к персональным данным пациента; быстрое доведение результатов проведения исследований / анализов пациента до лечащего врача; сокращение штатной численности отдела регистратуры, расходов на зарплату и сокращение людских и временных затрат на обработку информации; централизованное хранение всех данных о пациенте; 19 уменьшение количества противоречивых данных; упрощение постановки диагноза пациенту. Результаты проектирования могут являться основой для разработки конечного продукта информационной системы РДЦ. Список использованной литературы 1. Боггс У., Боггс М. UML и Rational Rose. М.: "Лори", 2000 г. – 582с. 2. Трофимов С.А., CASE-технологии: Практическая работа в Rational Rose. - 2-е изд. - М.: Бином-Пресс, 2002. - 288 с. 3. Буч Г., Рамбо Д., Джекобсон А., Язык UML. Руководство пользователя: Пер. с англ. - М.: ДМК, 2000. - 432с. 4. Леоненков А., Самоучитель UML. - СПб: Питер, 2001. - 158 с. 5. Грехем И. Объектно-ориентированные методы. Принципы и практика - М.: "Вильямс", 2004. - 880 с. 6. Кьоу Дж., Джеанини М. Объектно-ориентированное программирование. Учебный курс - СПб: "Питер", 2005. - 238 с. 7. Ларман К. Применение UML и шаблонов проектирования - М.: "Вильямс", 2001. - 496 с. 8. Ларман К. Применение UML и шаблонов проектирования.2-е издание - М.: "Вильямс", 2002. - 624 с. 9. Леоненков А.В. Самоучитель UML - СПб.: "БХВ - Петербург", 2001. - 304 с. 10. Леоненков А.В. Самоучитель UML.2-е издание - СПб.: "БХВПетербург", 2004. - 432 с. 11. http://www.interface.ru/home.asp?artId=4447 – BPwin 4.0: пришел, увидел, реорганизовал. 12. http://www.minzdravpmr.org/node/178 – открытие лечебно- диагностического реабилитационного центра. 13. http://specialf.narod.ru/bpwin/urok.html – BPwin 4.0 уроки примеры задачи 20 14. http://www.intuit.ru/studies/courses/2195/55/lecture/15043–Создание контекстной диаграммы 21
