Информационно-аналитическая система обработки данных вакцинации населения

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 27.06.2012
Размер файла 3,8 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ, МОЛДЕЖИ И СПОРТА УКРАИНЫ

ЧЕРНИГОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ

КАФЕДРА ИНФОРМАЦИОННЫХ И КОМПЬЮТЕРНЫХ СИСТЕМ

Квалификационная работа специалиста по специальности 7.091502 “Системное программирование”

Информационно-аналитическая система обработки данных вакцинации населения

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

студент гр. СП-061

И.С. Харченко

Руководитель:

к.ф.-м.н., доцент

А.Н. Акименко

Чернигов 2011

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Предполагаемые технические и эксплуатационные результаты работы

Спроектировать и разработать информационно-аналитическую систему (ИАС) обработки данных вакцинации населения, а также оконное приложение для отображения объектов системы.

Система является комплексом приложений, в основе которой лежит единая центральная СУБД.

Комплекс приложений состоит из следующих компонентов, связанных через СУБД: системы управления справочниками; отчетная система.

Система должна обеспечивать легкий интерактивный контроль версионности и применения обновлений.

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

Объем текстовой и графической документации

Работа объемом 100с. формата А4.

Предполагаемая трудоемкость работы - 1000 чел-часов.

Плановые сроки по этапам

Предзащита с полным представлением чистовых распечаток текстов и иллюстративного материала 24.05.2011.

Плановый срок защиты работы

Работа планируется к защите на заседании ГЭК 08.06.2011.

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

Руководитель работы - доцент Акименко А.Н., консультант по аппаратной части - кандидат технических наук, доцент Вервейко А.И., консультант по охране труда - доц. к.ф.-м.н., Никитенко Е.В.

РЕФЕРАТ

Объектом разработки являлась информационно-аналитическая система обработки данных вакцинации населения.

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

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

– архитектура информационно-аналитической системы;

– структура и реализация программной подсистемы;

– локальная вычислительная сеть.

Для реализации информационно-аналитической системы обработки данных вакцинации населения использовались технологии Embarcadero RAD Studio 2010, Fast Reports Inc. Для развертывания системы необходима СУБД Firebird 2.1 или выше. Работа информационно-аналитической системы возможна в операционной системе Windows, версия не ниже версии Windows XP.

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

Работа внедрена в Черниговскую городскую больницу №2.

Работа имеет практическую ценность. Расчет экономической ценности не производился.

FIREBIRD, SQL, TCP/IP, C++, ИАС, RAD Studio 2010.

СОДЕРЖАНИЕ

  • Введение
  • 1. Анализ задачи создания ИАС учреждения обработки данных вакцинации населения
    • 1.1 Анализ предметной области
    • 1.2 Построение базовой модели предметной области
    • 1.3 Изучение существующих систем
      • 1.3.1 Система «Журнал пациентов»
      • 1.3.2 Система «Учет пациентов»
      • 1.3.3 Система «Профилактические прививки»
      • 1.3.4 Система «Поликлиника»
    • 1.4 Сравнительный анализ существующих систем
    • 1.5 Требования к системе и ее функциональности
      • 1.5.1 Требования к программной подсистеме
      • 1.5.2 Требования к аппаратной подсистеме
  • 2. Разработка ИАС учреждения обработки данных вакцинации населения
    • 2.1 Выбор технических средств построения системы
    • 2.2 Разработка архитектура ИАС
    • 2.3 Разработка структуры программной подсистемы
    • 2.4 Разработка базы данных
    • 2.5 Разработка аппаратной подсистемы
      • 2.5.1 Проектирование архитектуры локальной вычислительной сети
      • 2.5.2 Разделение сети на сегменты и размещение серверов
      • 2.5.3 Выбор топологии и среды передачи данных
      • 2.5.4 Проектирование СКС
      • 2.5.5 Журнал кабельных соединений
      • 2.5.6 Выбор оборудования
      • 2.5.7 Моделирование сети
      • 2.5.8 Выводы
  • 3. Реализация
    • 3.1 Реализация программной подсистемы
      • 3.1.1 Результат реализации базы данных
      • 3.1.2 Результат реализации интерфейса пользователя
  • 4. Охрана труда и окружающей среды
    • 4.1 Характеристика условий труда программиста
    • 4.2 Требования к производственным помещениям
      • 4.2.1 Окраска и коэффициенты отражения
      • 4.2.2 Освещение
      • 4.2.3 Параметры микроклимата
      • 4.2.4 Шум и вибрация
      • 4.2.5 Электромагнитное и ионизирующее излучения
    • 4.3 Эргономические требования к рабочему месту
    • 4.4 Противопожарная безопасность
    • 4.5 Расчет освещенности
    • 4.6 Расчет уровня шума
  • Выводы
  • Перечень использованных источников
  • ВВЕДЕНИЕ
  • На сегодняшний день почти в каждой поликлинике или отделении используется информационная система управления данными о вакцинах или пациентов, для ведения учета материалов и контроля выполнения прививок.
  • На сегодняшний день существует множество специализированных компьютерных систем для управления данными о вакцинации. Существующие информационные компьютерные системы для управления данными о вакцинации охватывают вид всех поставленных перед ними задач для отдельной инфраструктуры или организации и обладают большим количеством недостатков и плюсов для каждой организации соответственно. Поэтому была поставлена задача создать уникальную информационно-аналитическую систему обработки данных вакцинации населения.
  • Целью разработки являлось получение программного проекта состоящего из двух приложений для управления данными о вакцинации, а также проект локальной вычислительной сети. Разработанная система является хорошим инструментом для управления данными о вакцинации, что включает в себя контроль и обработку данных.
  • В данной работе поставлена задача разработки информационно-аналитической системы (ИАС) обработки данных вакцинации населения и вывод всех данных через отчетную форму.
  • Необходимость в разработке такого рода системы вызвана индивидуальными потребностями организации вакцинации населения, а так же управления большим объемом данных. К данным необходимым для выполнения вакцинации можно отнести информацию о пациенте, враче, тип вакцины, учет сделанных и предстоящих вакцин и т.д. Для правильного функционирования программы и учета вакцин нужно хранить данные о сделанных вакцинах, предстоящих вакцинах, а так же людей, которые прошли вакцинацию и прочую внутреннюю документацию.
  • В качестве основной причины создания ИАС обработки данных можно выделить устаревание и несоответствие предъявляемым требованиям аналогичных систем по обработке данных.
  • Недостатки в существующих такого рода программах выделить сложно, так как каждая программа такого рода имеет свою поставленную задачу, свои особенности и методы реализации.

При проектировании новой ИАС был добавлен ряд новых индивидуальных функций для реализации этого приложения.

1. АНАЛИЗ ЗАДАЧИ СОЗДАНИЯ ИАС учреждения обработки данных вакцинации населения

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

Поставленной задачей является разработка информационно-аналитической системы обработки данных вакцинации населения. Для того чтобы спроектировать приложение необходимо знать о структурных единицах учреждения, а также их функциональных назначениях, для этого сперва рассмотрим виды деятельности учреждения, а затем перейдем к рассмотрению структурных единиц. Основными видами деятельности являются: ведение учета выполнения прививок (наличие вакцины, квалифицированные врачи, наличие вакцины на складах); контроль списка пациентов; контроль справочников; создание отчетов.

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

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

1.2 Построение базовой модели предметной области

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

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

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

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

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

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

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

Как видно с рисунка 1.1 между сущностями присутствуют отношения «один к одному», «один ко многим» и «многие ко многим».

Так как у пациента может быть большое количество прививок, то у одной прививки может быть только один пациент, то между сущностями «Пациент» и «Прививка» отношение «один ко многим».

У пользователя может быть только одна роль, поэтому между сущностями «Роль» и «Пользователь» отношение «один к одному».

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

Между сущностями «Прививка» и «Справочники», «Справочники» и «Паспорт вакцины» организовано отношение «многие ко многим», потому что там аналогичная схема взаимосвязи, как в сущностях «Пациент» и «Справочники».

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

информационный аналитический данные вакцинация

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

1.3 Изучение существующих систем

1.3.1 Система «Журнал пациентов»

Программа «Журнал пациентов» позволяет хранить амбулаторные карты пациентов и вести учёт пациентов в электронном виде. В программе хранится вся необходимая информация о пациентах: фамилия, имя, отчество, пол, дата рождения, адрес, телефоны, анамнез жизни. При каждом приёме добавляется информация о жалобах, диагнозах, статусах, вмешательствах и рекомендациях. Амбулаторную карту пациента можно распечатать на принтере или сохранить в Word для редактирования.

Есть два способа использования программы:

а) Врач при приёме ищёт и знакомится с амбулаторной картой в электронном виде. Затем заполняет амбулаторную карту на бумаге в традиционном виде. Затем медсестра или секретарь заносит информацию в программу.

б) Врач при приёме использует информацию из электронной амбулаторной карты пациента. В процессе приёма пациента врачом добавляется новая информация.

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

Как было видно из анализа она не решила ряд проблем, такие как: формирование отчетности; наличие более полной информации о сделанной прививке; наличие справочников для облегчения ввода информации.

На рисунке 1.2 изображена архитектура системы «Журнал пациентов».

Рисунок 1.2 - Архитектура системы «Журнал пациентов»

1.3.2 Система «Учет пациентов»

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

Рисунок 1.3 - Архитектура системы «Учет пациентов»

1.3.3 Система «Профилактические прививки»

Данная программа « Профилактические прививки» предназначена для автоматизации учета профилактических прививок и позволяет:

- хранить различную информацию по пациентам, включая адрес, место работы и другие реквизиты;

- прикреплять к каждому пациенту прививки;

- все карточки для ввода данных используют справочники для быстрого и удобного ввода данных;

- быстро находить нужную информацию благодаря поиску и режиму быстрого просмотра прививок пациента;

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

- формировать отчеты (план прививок, список пациентов, прививки пациента и статистической информации по прививкам) с возможностью фильтрации.

На рисунке 1.4 изображена архитектура системы.

Рисунок 1.4 - Архитектура системы «Профилактические прививки»

1.3.4 Система «Поликлиника»

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

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

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

Представляемая информационная система реализована на основе СУБД FoxPro 2.6 for Dos, и может эксплуатироваться на IBM-совместимых компьютерах 486DX RAM 16Mb и старше.

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

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

Перечень личных данных пациента:

Фамилия, имя, отчество;

Дата рождения;

Пол;

Адрес прописки;

Адрес фактического проживания;

Телефон;

Идентификационные данные документов, удостоверяющих личность;

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

Группа здоровья;

Место работы и должность или организованность для детского населения;

Категории и особые отметки;

ЛПУ, к которому пациент прикреплен;

Структурное подразделение для ЛПУ, имеющих в своем составе несколько амбулаторно-поликлинических подразделений.

Для постоянно проживающего населения лечебно-профилактического учреждения также фиксируются:

Дата прибытия (прикрепления);

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

Для большинства личных данных пациентов поддерживается возможность накопления истории их изменения.

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

Заболеваемость. Данные заболеваемости не требуют специального ввода, а формируются на основе информации о посещениях, что позволяет осуществлять доступ как к статистическим талонам учета заболеваемости, так к данным динамики течения заболеваний. Диспансерное наблюдение. Ведомости осуществленного диспансерного наблюдения формируются на основе информации о посещениях. Предусмотрены средства для персонального планирования лечебно-профилактических мероприятий, а именно: врачебных осмотров и обследований пациентов, состоящих на диспансерном учете. Группа здоровья таких пациентов определяется автоматически, как наихудшая из выставленных групп диспансерного наблюдения. Система предлагает средства для анализа эффективности диспансеризации. Количество уровней качества диспансеризации не ограничивается и определяется в соответствии с организационной структурой ЛПУ.

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

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

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

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

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

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

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

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

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

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

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

1.4 Сравнительный анализ существующих систем

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

– наличие СУБД;

– работа по сети;

– формирование отчетов;

– фильтрация данных при поиске;

– удобный интерфейс;

– использование справочников;

– связность прививка-пациент;

– оповещение пациентов о новых прививках;

– многопользовательский режим;

Наличие или отсутствие этих требований в каждой из рассмотренных систем проанализировано в таблице 1.1. В ней “-” означает отсутствие реализации данного требования у рассматриваемой системы; “+” означает наличие реализации данного требования у рассматриваемой системы.

Таблица 1.1 - Таблица оценки существующих систем

Критерии оценки

Система «Журнал пациентов»

Система «Учет пациентов»

Система «Поликлиника»

Система «Профилактические прививки»

Разрабатываемая система

1

2

3

4

5

6

Наличие СУБД

+

+

+

+

+

1

2

3

4

5

6

Работа по сети

+

+

+

-

+

Формирование отчетности

+

+

+

+

+

Фильтрация данных при поиске

-

+

+

+

+

Удобный интерфейс

-

+

+

+

+

Использование справочников

-

+

+

+

+

Связность прививка-пациент

-

+

-

+

+

Оповещение пациентов о новых прививках

-

-

+

-

+

Многопользовательский режим

-

+

-

-

+

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

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

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

1.5 Требования к системе и ее функциональности

1.5.1 Требования к программной подсистеме

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

– система должна обеспечивать наличие центральной СУБД;

– система должна работать как локально, так и по сети;

– система должна формирование отчетов;

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

– система должна обеспечить возможность просмотра данных по главным связующим таблицам;

– система должна обеспечить возможность связки прививка-пациент;

– система должна обеспечить оповещения пациентов о предстоящих ему прививках;

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

– система должна разграничивать доступ к информации и сервисам системы, в зависимости от «роли» пользователя (медсестра, редактор, администратор);

На рисунке 1.5 -1.8 приведены диаграммы вариантов использования ИАС учреждения обработки вакцинации данных населения.

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

Рисунок 1.5 - Диаграмма наследования ролей пользователей

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

Рисунок 1.6 - Диаграмма вариантов использования для медсестры

На рисунке 1.7 изображена диаграмма вариантов использования для редактора.

Рисунок 1.7 - Диаграмма вариантов использования для редактора

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

На рисунке 1.8 изображена диаграмма вариантов использования для администратора.

Рисунок 1.8 - Диаграмма вариантов использования для администратора

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

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

1.5.2 Требования к аппаратной подсистеме

Всего учреждение содержит 17 рабочих, расположены все на одном этаже.

Требования к сети:

- ограничить доступ разных отделов между собой;

- скорость передачи данных по сети не больше 100 Мбит;

- выход в Интернет;

- разделение сети на виртуальную локальную сеть (VLAN);

- наличие в сети служб доменных имен, файлового сервера, сервера БД.

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

2 РАЗРАБОТКА ИАС учреждения обработки данных вакцинации населения

2.1 Выбор технических средств построения системы

Для проектирования программных комплексов необходимо наличие интегрированной среды(IDE). На данный момент существует широкий выбор сред для разработки программ. Для решения поставленных целей определенных в техническом задании были выбраны следующие среды разработки:

Embarcadero RAD Studio 2010 - среда быстрой разработки приложений (RAD) для Microsoft Windows фирмы Embarcadero Technologies.

Текущая версия Embarcadero RAD Studio XE объединяет Delphi XE и C++ Builder XE в единую интегрированную среду разработки. В данной версии также реализована поддержка таких технологий.NET, как WinForms, WPF, ADO.NET, ASP.NET и LINQ.

Дополнительная поддержка фреймворка Mono обеспечивает возможность создания кросс-платформенных приложений, которые работают под операционными системами Windows, Linux и Mac OS X.

RAD Studio включает в себя широкий набор дополнительных программ:

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

Rave Reports компании Nevrona - набор решений для создания отчетов.

TeeChart Standard компании Steema - компоненты для создания диаграмм.

VCL для веб-решений (IntraWeb) компании Atozed Software - платформа веб-приложений RAD.

FinalBuilder Embarcadero Edition служит для автоматизации процесса сборки.

CodeSite Express - средства ведения журнала для сборки приложений.

AQTime Standard компании SmartBear - создание профилей производительности.

Beyond Compare Text Compare - сравнение файлов исходного кода.

RemObjects Internet Tools и Oxfuscator - дополнительная функциональность для веб-разработки и «запутывания» кода в Delphi Prism;

Fast Reports, Inc - российская компания по разработке программного обеспечения для формирования отчетов.

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

Firebird (FirebirdSQL) - компактная, кроссплатформенная, свободная система управления базами данных (СУБД), работающая на Linux, Microsoft Windows и разнообразных Unix платформах.

В качестве преимуществ Firebird можно отметить многоверсионную архитектуру, обеспечивающую параллельную обработку оперативных и аналитических запросов (это возможно потому, что читающие пользователи не блокируют пишущих), компактность (дистрибутив 5Mb), высокую эффективность и мощную языковую поддержку для хранимых процедур и триггеров;

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

2.2 Разработка архитектура ИАС

Архитектура ИАС учреждения обработки данных вакцинации населения по трехуровневому принципу:

а) первый компонент представляет собой видимую для пользователя часть - интерфейс типа «человек-машина» - «клиентское приложение», с помощью которого пользователь осуществляет ввод, изменение и удаление данных, дает запросы на выполнение операций и запросы на выборку данных (получение отчетов);

б) второй компонент (скрытая от пользователей часть системы) - сервер базы данных, осуществляет хранение и обработку данных. Пользователь через клиентское приложение инициирует процедуру запроса на выборку, ввод, изменение или удаление данных в базе данных (БД);

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

В общем случае ИАС учреждения может иметь архитектуру, представленную на рисунке 2.1 и 2.2.

Рисунок 2.1 - Архитектура ИАС учреждения обработки данных вакцинации населения

Рисунок 2.2 - Архитектура программной подсистемы ИАС учреждения обработки данных вакцинации населения

Хранение данных обеспечивает firebird-сервер. Кроме хранения собственно данных и обеспечения их целостности, на сервер возложено также хранение настроек машины операций и обеспечение обмена с внешними приложениями. Еще одной функцией сервера базы данных является планирование работ.

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

Кроме сервера приложений в системе также работает сервер печати. Сервер печати - это сервис, который ожидает от сервера приложений данные, отправляемые на печатные устройства, отвечает за формирование отчетов.

Клиентские устройства это стандартные персональные компьютеры.

2.3 Разработка структуры программной подсистемы

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

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

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

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

Аутентификация заключается в получении роли пользователя. В зависимости от роли пользователю будет доступна та или иная информация и разрешены взаимодействия с системой, доступные лишь для этой роли. Так в зависимости от роли будет открыта именно та стартовая страница, которая соответствует полученной роли.

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

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

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

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

– основной модуль работы с данными;

– модуль управления данными прививки;

– модуль управления данными пациента;

– модуль ведения справочников;

– модуль формирования отчетов;

– модуль управления данными о вакцине;

– модуль управления данными паспорта вакцины;

– модуль управления данными врачей;

– модуль управлении данными улиц.

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

Модуль управления данными прививки позволяет клиенту руководить данными о прививке, добавлять, редактировать, удалять данные о прививке.

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

Рисунок 2.3 - Изображена структура программной подсистемы ИАС обработки данных вакцинации населения

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

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

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

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

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

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

2.4 Разработка базы данных

На основании концептуальной модели предметной области были созданные следующие базовые таблицы базы данных: «USER», «ROLE», «ANATOKSIM», «DELPRIVIVKA», «DOCTOR», «JOB», «KATEGORIA», «KATEGREAK», «KATEGVAC», «NAMEPRIVIVKA», «NOTPRIVITO», «OTDEL», «OTDELUCH», «PACIENT», «PASPORTVAC», «POLIKLINIKA», «PRIVITO», «PRIVIVKA», «PROIZVODITEL», «STREET», «VACCINE», «VERSION». Рассмотрим подробнее все созданные таблицы.

Для всех таблиц базы дынных поля служащие первичными или внешними ключами имеют тип данных «integer».

Таблица «user» предназначена для хранения информации о пользователях системы. В ней храниться информация для авторизации в системе. Она состоит из 5 колонок:

– id - первичный ключ;

– login - логин пользователя для авторизации;

– passwd - пароль пользователя для авторизации;

– role_id - внешний ключ для связи с таблицей «role».

Поскольку логин пользователя не будет длиннее чем 15 символов, а пароль не длиннее чем 10 символов, то типы данных для этих полей будут varchar(15) и varchar(10) соответственно.

Таблица «role» хранит информацию о ролях пользователей системы. Состоит из 2 колонок:

– id - первичный ключ;

– role - роль пользователя в системе.

Поле «role» имеет тип данных varchar(12), поскольку роль пользователя не будет длиннее, чем 12 символов.

Таблица «anatoksim» это справочная таблица, предназначена для хранения возможных видом анатоксина. Данная таблица состоит из 2 колонок:

– id - первичный ключ;

– name - название тура;

Поле «name» имеет тип данных varchar(40).

Таблица «DELPRIVIVKA» и таблица «PRIVIVKA» предназначена для хранения информации о прививках. Только таблица «DELPRIVIVKA» хранит информацию об удаленных прививках, а таблица «PRIVIVKA» хранит информацию о существующих прививках. Поля в этих таблицах одинаковы, это сделано для того, если вдруг надо будет восстановить удаленную прививку, чтоб её данные не пропали. Количество полей в таблицах равно 22 а именно:

– id - первичный ключ;

– dateprivivk - дата прививки;

– harakvaccin - характер вакцины;

– doza - доза вакцины;

– dataRPGA - дата РПГА;

– datamedotvod - дата м.отвода;

– TITR - титр РПГА;

– Reaksianapriv - реакция на прививку;

– Primechanie - примечание;

– Medotvod - м. Отвод;

– NotPrivito - ссылка на ID из справочника «не привито»;

– kategReakcii - категория реакции;

– anatoksim_ID - ссылка на ID из справочника «анатоксин»;

– pacient_ID - ссылка на ID из таблицы «пациент»;

– doctor_ID - ссылка на ID из таблицы «врач»;

– privito - ссылка на ID из справочника «привито»;

– vaccine_ID - ссылка на ID из справочника «вакцина»;

– nameprivivka_ID - внешний ключ для связи с таблицей «NAMEPRIVIVKA»;

– serial - серия;

– control - контроль;

– kateg - категория;

– proizvod - производитель.

Поля такие как «id», «Reaksianapriv», «Medotvod», «NotPrivito», «kategReakcii», «anatoksim_ID», «pacient_ID», «doctor_ID», «privito», «vaccine_ID», «nameprivivka_ID» имеют тип данных integer. Поля, которые связаны с датой соответственно будут иметь тип DATE а именно: «dateprivivk»,« dataRPGA»,« datamedotvod». Остальные поля имеют тип данных varchar, приведем пример таких полей: «harakvaccin»(50), «TITR»(50), «Primechanie»(10), «serial»(20), «control»(10), «kateg»(40), «proizvod»(40). И лиш поле «doza» имеет тип данных char(3).

Таблица « DOCTOR » предназначена для хранения информации о врачах системы. Эта таблица состоит из 9 колонок:

– id - первичный ключ;

– name - ФИО врача;

– birsday - дата рождения;

– house - № дома;

– apartment - № квартиры;

– adress - улица;

– homenumber - дом. телефон;

– officenumber - раб. телефон;

– otdel_id - ссылка на ID из справочника «отдел».

Проведем описание полей написанных выше: поле «id» является первичным ключом таблицы «DOCTOR» а также кодом данного врача, «name» это ФИО врача, имеет тип varchar(100). Поле «birsday» дата рождения врача, имеет тип DATE, а поля «apartment», «homenumber», «officenumber», «otdel_id» имеют тип integer, а вот поле «house» имеет тип varchar(5) поскольку в номере дома могут содержатся буквы. Поле «adres» содержит адрес врача и имеет тип varchar(100).

Таблица «JOB» - это справочник мест работы, который предназначен для хранения информации о месте работы. Состоит из 2 колонок:

– id - первичный ключ;

– name - наименование места работы;

Проведем описание полей перечисленных выше: поле «id» является первичным ключом таблицы «JOB» а так же кодом места работы, имеет тип integer. Поле «name» имеет тип varchar(50).

Таблица «KATEGORIA» это справочник категорий. Здесь содержится список категорий, например: студент, мед. Работник, безработный. Состоит из 2 колонок:

– id - первичный ключ;

– name - наименование категории;

Описание полей: поле «id» является первичным ключом таблицы «KATEGORIA» а так же шифром(кодом) категории, имеет тип integer. Поле «name» имеет тип varchar(40).

Таблица «KATEGREAK» это справочник категорий реакции. Здесь содержится список категорий реакции возможных на прививку. Состоит из 2 колонок:

– id - первичный ключ;

– name - наименование категории реакции;

Описание полей: поле «id» является первичным ключом таблицы «KATEGREAK» а так же шифром(кодом) категории реакции, имеет тип integer. Поле «name» имеет тип varchar(40).

Таблица «KATEGVAC» это справочник категорий вакцин. Здесь содержится список возможных категорий вакцин. Состоит из 2 колонок:

– id - первичный ключ;

– name - наименование категории;

Описание полей: поле «id» является первичным ключом таблицы «KATEGVAC» а так же шифром(кодом) категории вакцины, имеет тип integer. Поле «name» имеет тип varchar(40).

Таблица «NAMEPRIVIVKA» это справочник наименований прививок. Здесь содержится перечень наименований прививок. Состоит из 2 колонок:

– id - первичный ключ;

– name - наименование прививки;

Описание полей: поле «id» является первичным ключом таблицы «NAMEPRIVIVKA», имеет тип integer. Поле «name» это наименование прививки, имеет тип varchar(40).

Таблица «NOTPRIVITO» это справочник причин, по которым не была сделана прививка. Здесь содержится перечень наименований. Состоит из 2 колонок:

– id - первичный ключ;

– name - наименование;

Описание полей: поле «id» является первичным ключом таблицы «NOTPRIVITO», имеет тип integer. Поле «name» это перечень причин, по которым не была сделана прививка, имеет тип varchar(40).

Таблица «OTDEL» это справочник отделений. Здесь содержится перечень отделений. Состоит из 2 колонок:

– id - первичный ключ;

– name - наименование отделения;

Описание полей: поле «id» является первичным ключом таблицы «OTDEL», имеет тип integer. Поле «name» это перечень наименований отделения, имеет тип varchar(40).

Таблица «OTDELUCH» это связующая таблица. Она не заполняется вручную а служит для связки отделения с номером участка Здесь содержится возможные связки. Состоит из 3 колонок:

– id - первичный ключ;

– idOtdel - ID отделения;

– idUch - ID участка;

Описание полей: поле «id» является первичным ключом таблицы «OTDELUCH», имеет тип integer. В поле «idOtdel» содержится ID отделения нужного для связки, имеет тип integer. В поле «idUch» содержится № участка, который будет участвовать в связке, имеет тип integer.

Таблица «PACIENT» это список всех пациентов, которые находятся на учете у данного учреждения. Здесь содержится вся необходимая информация о нужном пациенте. Состоит из 15 колонок:

– id - первичный ключ;

– Fio - ФИО пациента;

– Bornday - дата рождения;

– Adress - адрес пациента;

– House - № дома;

– Korpys - № корпуса;

– Apartment - № квартиры;

– Nuchastka - № участка;

– Sex - пол;

– Poliklinika_ID - ссылка на ID из справочника «POLIKLINIKA»;

– Kategoria_ID - ссылка на ID из справочника «KATEGORIA»;

– Street_ID - ссылка на ID из справочника «STREET»;

– Job_ID - ссылка на ID из справочника «JOB»;

– Otdel_ID - ссылка на ID из справочника «OTDEL»;

– Street_OLD - старое место проживания пациента.

Описание полей: поле «id» является первичным ключом таблицы «PACIENT», имеет тип integer. Поле «Fio» это ФИО пациента, имеет тип varchar(100). Поле «Bornday» содержит в себе дату рождения пациента и имеет тип DATE. Такие поля как: «Apartment», «Nuchastka», «Sex» имеют тип integer, и, соответственно, в них хранится информация о № квартиры, № участка и пол пациента. В поле «House» указывается номер дома, в котором проживаем пациент, тип поля varchar(5). Поле «Street_OLD» содержит в себе место старого проживания или прописки пациента, имеет тип varchar(150). Такие поля как: «Poliklinika_ID», «Kategoria_ID», «Street_ID», «Job_ID», « Otdel_ID » это поля связки с нужними справочниками, в токорых будет хранится ID нужной записи с данного справочника, соответсветнно название справочников: поликлиника, категория, улица, место работы, отдел. Все эти поля имеют тип integer.

Таблица «PASPORTVAC» это справочник паспортов вакцин. Здесь содержатся более подробные данные о вакцине. Состоит из 7 колонок:

– id - первичный ключ;

– serial - серия;

– s_god - срок годности вакцины;

– control - контроль;

– anatoksim_ID - ссылка на ID из справочника «ANATOKSIM»;

– proizvod_ID - ссылка на ID из справочника «PROIZVODITEL»;

– vaccine_ID - ссылка на ID из справочника «VACCINE»

Описание полей: поле «id» является первичным ключом таблицы «PASPORTVAC», имеет тип integer. В поле «serial» и «contro» имеют тип varchar(20) и varchar(10) соответственно. Поля «anatoksim_ID», «proizvod_ID», «vaccine_ID», это поля - связки с нужными справочниками, имеют тип integer.

Таблица «POLIKLINIKA» это справочник наименований поликлиник. Здесь содержится перечень наименований поликлиник. Состоит из 3 колонок:

– id - первичный ключ;

– name - наименование поликлиники по укр.;

– doc - наименование по рус.

Описание полей: поле «id» является первичным ключом таблицы «POLIKLINIKA», имеет тип integer. Поле «name» и «doc» это наименование поликлиники, имеют тип varchar(40).

Таблица «PRIVITO» это справочник в котором содержится наименование причин по котором были привиты. Состоит из 2 колонок:

– id - первичный ключ;

– name - наименование причины;

Описание полей: поле «id» является первичным ключом таблицы «PRIVITO», имеет тип integer. Поле «name» это наименование причины, по поводу которой была сделана вакцина, имеет тип varchar(40).

Таблица «PROIZVODITEL» это справочник производителей. Здесь содержится перечень производителей. Состоит из 2 колонок:

– id - первичный ключ;

– name - наименование производителя;

Описание полей: поле «id» является первичным ключом таблицы «PROIZVODITEL», имеет тип integer. Поле «name» это перечень наименований производителя, имеет тип varchar(40).

Таблица «STREET» это справочник улиц. Здесь содержится перечень улиц, домов находящихся на данной улице и номеров участков. Состоит из 4 колонок:

– id - первичный ключ;

– name - наименование производителя;

– house - перечень домов;

– nuchastka - № участка;

Описание полей: поле «id» является первичным ключом таблицы «STREET», имеет тип integer. Поле «name» это перечень наименований улиц, имеет тип varchar(50). Поле «house» это перечень домой которые находятся на данной улице, тип varchar(150). Поле «nuchastka» это номер участка который назначен на данную улицу, имеет тип integer.

Таблица «VACCINE» это справочник вакцин. Здесь содержится перечень наименований вакцин. Состоит из 4 колонок:

– id - первичный ключ;

– name - наименование производителя;

– kateg - ссылка на ID из справочника «KATEGVAC»

– nameprivivka_ID - ссылка на ID из справочника «NAMEPRIVIVKA»

Описание полей: поле «id» является первичным ключом таблицы «VACCINE», имеет тип integer. Поле «name» это перечень наименований производителя, имеет тип varchar(40). Поля «kateg», «nameprivivka_ID» имеют тип integer.

Таблица «VERSION» это таблица, которая содержит информацию о версии программы. В таблице есть 1 поле «code» которое содержит информацию о версии системы, тип поля - double precision.


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.