Файл: Описание предметной области. Постановка задачи.pdf

Введение

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

В работе рассматривается система автоматизации записи на прием к врачу – «Электронная регистратура».

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

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

Информационная система «Электронная регистратура» позволяет:

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

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

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

Анализ предметной области сводится к рассмотрению организационной сущности задачи получения пациентом талона на прием к врачу при посещении лечебного учреждения (рис. 1).

Рис.1. Организационная модель предметной области

Организационная сущность задачи заключается в следующем.

1. Пациент обращается в регистратуру лечебного учреждения для получения талона на прием к нужному врачу, предъявляя страховой полис. При этом пациенту, как правило, приходится затратить немало времени стоя в очереди.
2. Регистратор рассматривает запрос пациента. В случае наличия свободных талонов на прием к требуемому специалисту, проверят наличие и подлинности страхового полиса, производит поиск амбулаторной карты и выписывает талон на прием.
3. Пациент, имея на руках амбулаторную карту и талон, следует на прием к врачу, где, как правило, приходится повторно стоять в очереди.
4. Врач проводит осмотр пациента, производит необходимые записи в амбулаторной карте и в случае необходимости, помимо назначений на лечение, выписывает рецепт на получение или изготовление лекарственных средств. Помимо этого врач производит дозаполнение талона на прием статистической информацией.
5. При необходимости и наличии рецепта пациент обращается в аптеку за получением лекарственных средств.
6. По окончании рабочего дня врач передает дозаполненные талоны в отдел статистики лечебного учреждения и возвращает амбулаторные карты в регистратуру.
7. Со строго определенной очередностью отдел статистики готовит статистический материалы и направляет их в управление здравоохранения.
8. Раз в месяц страховые компании предоставляют лечебному учреждению обновленные базы данных застрахованных лиц. Лечебное учреждение в свою очередь передает страховым компаниям отчеты об оказанных услугах пациентам.

---

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

1. Обеспечить реализацию всех базовых стадий получения талона на прием к врачу, связанных с оформлением заявки на прием, ее подтверждением и отметкой о явке.
2. Исходя из концепции деления системы на Front-офис и Back-офис, провести разделение проекта на две части: клиентское и администраторское приложение, причем клиентское приложение подразделено на 3 взаимозависимых интерфейса.
3. Предоставить средства для навигации по базе данных на нескольких уровнях доступа (регистратор, врач, пациент и администратор).
4. Реализовать специфические возможности системы.

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

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

2. Выбор средств / методологии проектирования. Выбор СУБД

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

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

---

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

Для хранения данных как нельзя лучше подойдёт СУБД MySQL – лёгкая, быстрая СУБД, в которой можно создать таблицы, хранящие все необходимые данные, и отношения между ними.

В качестве Web-сервера для связки PHP+MySQL традиционно используется Apache – проверенный и надёжный продукт.

Опишем указанные технологии более подробно.

РНР — это серверный язык создания сценариев (или стороны сервера), разработанный специально для Web. В HTML-страницу можно внедрить код РНР, который будет выполняться при каждом ее посещении. Код РНР интерпретируется Web-сервером и генерирует HTML или иной вывод, наблюдаемый посетителем страницы.

РНР — это продукт с открытым исходным кодом (Open Source). У пользователя имеется доступ к исходному коду. Его можно использовать, изменять и свободно распространять другим пользователям или организациям.

К числу конкурентов РНР относятся Perl, Active Server Pages (ASP) от Microsoft, Java Server Pages (JSP) и Allaire Cold Fusion.

PHP обладает множеством преимуществ по сравнению с этими продуктами, в числе которых:

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

MySQL — очень быстрая, надежная система управления реляционными базами данных (СУРБД). База данных позволяет эффективно хранить, искать, сортировать и получать данные. Сервер MySQL управляет доступом к данным, позволяя работать с ними одновременно нескольким пользователям, обеспечивает быстрый доступ к данным и гарантирует предоставление доступа только имеющим на это право пользователям. Следовательно, MySQL является многопользовательским, многопотоковым сервером. Он применяет SQL (Structured Query Language —язык структурированных запросов), используемый по всему миру стандартный язык запросов в базы данных. MySQL появился на рынке в 1996 г., но его разработка началась еще в 1979 г.

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

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

---

Web-сервер Apache называют самым главным сокровищем движения «Открытые программные системы». Его можно получить совершенно бес­платно. Он имеет отличные рабочие характеристики и поэтому используется более широко, чем все остальные Web-серверы вместе взятые. В настоящий момент более 65 процентов всех Web-узлов в мире созданы с использова­нием сервера Apache.

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

Достоинства Web-сервера Apache:

• модульность структуры, которая позволяет: подключать только необходимые модули, гибко регулируя со­отноше­ние между функциональностью и размером программы сервера; создавать дополнительные модули (яркий пример – модуль mod_charset, обеспечивающий обслуживание кириллических кодиро­вок);
• открытая архитектура (можно скачать как исходный код, так и от­компи­лированнный вариант);
• работоспособность под несколькими платформами: (Unix, Linux, Windows, Netware);
• бесплатное распространение;
• возможность использовать СУБД для аутентификации пользовате-лей, модифицировать сообщения об ошибках и так далее;
• поддержка IPv6.
• надёжность и гибкость конфигурации.

3. Проектирование логической структуры базы данных

Основным понятием РБД являются сущности.

Сущность – это множество экземпляров различимых между собой и каждый из которых характеризуется набором свойств.

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

Таблица 1

Перечень сущностей предметной области

Название и обозначение сущности	Ключ сущности и его обозначение	Атрибуты сущности и их обозначение
Учреждение (Учреждение)	Код учреждения (КодУч)	Наименование (НазвУч) Адрес (АдресУч) Телефон (ТелефонУч) Имя руководителя (ИмяРукУч) Должность руководителя (ДолжРукУч)
Подразделение (Подразделение)	Код подразделения (КодПд)	Наименование (НазвПд) Адрес (АдресПд) Телефон (ТелефонПд) Имя руководителя (ИмяРукПд) Должность руководителя (ДолжРукПд)
Отделение (Отделение)	Код отделения (КодОтд)	Наименование (НазвОтд)
Учетная запись (УчЗапись)	Код учетной записи (КодУЗ)	Имя входа (ИмяВхУЗ) Пароль (ПарольУЗ) Имя (ИмяУЗ) Фамилия (ФамУЗ) Отчество (ОтчУЗ) Электронная почта (ЭлПочтаУЗ) Телефон (ТелефонУЗ) Должность (ДолжУЗ) Место работы (МестоРабУЗ) Роль(РольУЗ)
Врач (Врач)	Код учетной записи (КодУЗ)	Специализация (СпецВр) Кабинет (КабВр)
Регистратор (Регистратор)	Код учетной записи (КодУЗ)
Администратор (Администратор)	Код учетной записи (КодУЗ)	Примечание (ПримАдм)
Расписание приема (Расписание)	Код интервала (КодИнт)	Дата (ДатаИнт) Время начала (ВрНачИнт) Время завершения (ВрЗавИнт)
Талон (Талон)	Код талона (КодТал)	Дата талона (ДатаТал) Время начала (ВрНачТал) Время завершения (ВрЗавТал) Статус регистратора (СтатРегТал) Статус пациента (СтатПацТал) Статус врача (СтатВрТал) Причина отказа (ПричОткТал)
Пациент (Пациент)	Код пациента (КодПац)	Имя (ИмяПац) Фамилия (ФамПац) Отчество (ОтчПац) Дата рождения (ДатаРождПац) Адрес (АдресПац) ОМС серия (ОМССерПац) ОМС номер (ОМСНомПац) ОМС компания (ОМСКомПац) Электронная почта (ЭлПочтаПац) Телефон (ТелефонПац)

---

Таким образом, схемы сущностей имею вид:

1. Учреждение (КодУч, НазвУч, АдресУч, ТелефонУч, ИмяРукУч, ДолжРукУч).
2. Подразделение (КодПд, НазвПд, АдресПд, ТелефонПд, ИмяРукПд, ДолжРукПд).
3. Отделение (КодОтд, НазвОтд).
4. УчЗапись (КодУЗ, ИмяВхУЗ, ПарольУЗ, ИмяУЗ, ФамУЗ, ОтчУЗ, ЭлПочтаУЗ, ТелефонУЗ, ДолжУЗ, МестоРабУЗ, РольУЗ).
5. Врач (КодУЗ, СпецВр, КабВр).
6. Регистратор (КодУЗ).
7. Администратор (КодУЗ, ПримАдм).
8. Расписание (КодИнт, ДатаИнт, ВрНачИнт, ВрЗавИнт).
9. Талон (КодТал, ДатаТал, ВрНачТал, ВрЗавТал, СтатРегТал, СтатПацТал, СтатВрТал).
10. Пациент (КодПац, ИмяПац, ФамПац, ОтчПац, ДатаРождПац, АдресПац, ОМССерПац, ОМСНомПац, ОМСКомПац, ЭлПочтаПац, ТелефонПац).

Анализ сущностей позволяет выделить связи между ними. Перечень связей между сущностями представлен в таблице 2.

Таблица 2

Перечень связей между сущностями

Связь	Идентификатор
Подразделение ОТНОСИТСЯ к учреждению	Подразделение_ОТНОСИТСЯ_Учреждение
Отделение ОТНОСИТСЯ к подразделению	Отделение_ОТНОСИТСЯ_Подразделение
Регистратор РЕГИСТРИРУЕТ в подразделении	Регистратор_РЕГИСТРИРУЕТ_Подразделение
Врач РАБОТАЕТ в отделении	Врач_РАБОТАЕТ_Отделение
Врач ПРИНИМАЕТ по расписанию приема	Врач_ПРИНИМАЕТ_Расписание_приема
Врач ПРИНИМАЕТ по талону	Врач_ПРИНИМАЕТ_Талон
Пациент ЗАПИСАН по талону	Пациент_ЗАПИСАН_Талон
Администратор ИМЕЕТ учетную запись	Администратор_ИМЕЕТ_Учетная_запись
Регистратор ИМЕЕТ учетную запись	Регистратор_ИМЕЕТ_Учетная_запись
Врач ИМЕЕТ учетную запись	Врач_ИМЕЕТ_Учетная_запись

Диаграмма ER-типа для рассматриваемой предметной области показана на рис.2.

Рис.2. Диаграмма ER-типа

4.Проектирование физической структуры базы данных

Каждое отношение трансформируется в таблицу. Имена отношений становятся именами таблиц, а имена атрибутов – именами колонок.

Таблица 3

Учреждение (Institution)

Наименование	Тип
id_institution	int (KEY)
name	varchar(128)
address	varchar(255)
phone	varchar(64)
director_post	varchar(32)
director_name	varchar(128)

---