Автоматизированная система дистанционного обслуживания клиентов поликлиник

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

1. КОНСТРУКТОРСКАЯ ЧАСТЬ

1.1 ВНЕШНЕЕ ПРОЕКТИРОВАНИЕ

1.1.1 Постановка задачи проектирования

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

1.1.2.1 Естественно-языковая модель предметной области

1.1.2.2 Перечень функций, подлежащих автоматизации

1.1.2.3 Уменьшение времени обслуживания пациентов за счёт автоматизации

1.1.2.4 Сущности и отношения между ними

1.1.3 Сравнение с аналогами

1.1.4 Перечень задач, подлежащих решению в процессе проектирования

1.1.5 Разработка структуры

1.2 ВНУТРЕННЕЕ ПРОЕКТИРОВАНИЕ

1.2.1 Проектирование баз данных

1.2.2 Описание инфологической модели

1.2.3 Связи между сущностями

1.2.4. Выбор СУБД

1.2.5 Разработка даталогической модели

1.2.6 Разработка архитектуры АСОИУ

1.2.6.1 Выбор архитектуры

1.2.6.1.1 Архитектура «Файл-сервер».

1.2.6.1.2 Архитектура «Клиент-сервер».

1.2.6.1.3Трёхуровневая архитектура

1.2.6.2 Выбор языка сценариев

2. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Задание входных/выходных данных

2.2 Разработка графа диалога

2.3 Разработка экранных форм.

2.4 Руководство пользователю

2.4.1 Создание нового пациента, изменение его данных, удаление пациента

2.4.2 Работа с системой пользователем «Пациент»

2.4.3 Работа с системой пользователем «Медсестра кабинета приёма анализов» и «Работник лаборатории»

2.4.4 Работа с системой пользователем «Медсестра процедурного кабинета»

2.4.5 Работа с системой пользователем «Работник аптеки»

3. ИССЛЕДОВАТЕЛЬСКАЯ ЧАСТЬ

3.1 Оптимизация логической схемы БД

3.1.1 Понятие «хорошей» схемы БД

3.1.2 Алгоритм построения «хорошей» схемы БД

3.2 Доказательство «хорошей» схемы БД

4. ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКИЙ РАЗДЕЛ

4.1 Экономическое обоснование внедрения АСДО клиентов поликлиник

4.1.1 Обоснование сметы затрат на разработку программного продукта АСДО клиентов поликлиник

4.1.1.1 Расчет затрат на расходные материалы

4.1.1.2 Расчет затрат на оборудование

4.1.1.3 Расчет затрат на оплату труда

4.1.1.4 Расчет затрат на единый социальный налог

4.1.1.5 Расчет затрат на услуги сторонних организаций

4.1.1.6 Расчет затрат на накладные расходы

4.1.1.7 Расчет прочих расходов

4.1.1.8 Расчет себестоимости

4.1.1.9 Расчет прибыли

4.1.1.10 Расчет цены (без НДС)

4.1.1.11 Расчет отпускной цены (с учетом НДС)

4.2 Расчет стоимости оборудования, которое следует закупить для создания АСДО клиентов поликлиник

4.3 Расчет стоимости программного обеспечения, которое следует закупить для создания АСДО клиентов поликлиник

4.4 Расчет стоимости установки и монтажа АСДО клиентов поликлиник

4.5 Расчет экономии стоимости затрат на содержание и эксплуатацию АСДО после ее внедрения за месяц

4.6 Расчет срока окупаемости АСДО после ее внедрения

5. ПРОМЫШЛЕННАЯ ЭКОЛОГИЯ И БЕЗОПАСНОСТЬ

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

5.2 Характеристика условий труда

5.3 Эргономические требования к рабочему месту.

5.4 Расчёт освещённости

5.4.1 Комната 1 (два программиста).

5.4.2 Комната 2 (руководителя) ЗАКЛЮЧЕНИЕ Список использованных источников Приложение А. Графические листы

НОРМАТИВНЫЕ ССЫЛКИ В дипломном проектировании использованы следующие стандарты:

1. ГОСТ 19.502−78. Единая система программной документации. Описание применения. Требования к содержанию и оформлению.

2. ГОСТ 19.404−79. Единая система программной документации. Поясительная записка. Требования к содержанию и оформлению.

3. ГОСТ 19.104−78. Единая система программной документации. Основные надписи.

4. ГОСТ 19.001−77. Единая система программной документации. Общие положения.

5. ГОСТ 19.101−77. Единая система программной документации. Виды программ и программных документов.

6. ГОСТ 19.106−78. Единая система программной документации. Требования к программным документам, выполненным печатным способом.

7. ГОСТ 34.320−96. Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы.

8. ГОСТ 12.2.032−78. Система стандартов безопасности труда. Рабочее место при выполнении работ сидя. Общие эргономические требования.

9. ГОСТ 19.506−79. Единая система программной документации. Описание языка. Требования к содержанию и оформлению.

10. ГОСТ 22 269–76. Система «Человек — машина». Рабочее место оператора. Взаимное расположение элементов рабочего места. Общие эргономические требования.

11. СНиП 23−05−95 Естественное и искусственное освещение.

12. СанПин 2.2.1./2.1.1. 1278−03 Гигиенические требования к естественному, искусственному и совмещенному освещению жилых и общественных зданий.

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

Клиент — физическое или юридическое лицо, пользующееся услугами компании.

Заказ — перечень товаров, которые хочет приобрести клиент. Также включает информацию о клиенте.

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

БД — база данных.

СУБД — система управления базами данных.

ПК — персональный компьютер.

ПЭВМ — персональная электронно-вычислительная машины.

SQL — Structured Query Language, структурированный язык запросов.

ПО — программное обеспечение.

ОС — операционная система.

НДС — налог на добавленную стоимость.

URLUniversal Resource Locator, адрес страницы в сети интернет.

СНиП — Строительные нормы и правила.

СанПин — Санитарные правила и нормы.

ГОСТ — Государственный стандарт.

3НФ — третья нормальная форма

SQL — Structured Query Language, структурированный язык запросов

ВВЕДЕНИЕ

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

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

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

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

1. КОНСТРУКТОРСКАЯ ЧАСТЬ

1.1 ВНЕШНЕЕ ПРОЕКТИРОВАНИЕ

1.1.1 Постановка задачи проектирования

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

· Возможность формирование запроса на выдачу online, с домашнего компьютера клиента;

· Возможность формировать запрос с компьютера оператора;

· Должна быть реализована функция поиска груза;

· статистика

· функция загузки и размещения на складе

· рекомендация размещения

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

1.1.2.1 Естественно-языковая модель предметной области

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

Рассмотрим полностью процесс обслуживания клиентов на складском предприятии:

1. Запись на выдачу. Клиент имеет возможность предварительно заказать свой груз на сайте удаленно либо осуществить заказ по телефону, либо с помощью оператора по прибытию на склад.

2. Работа с оператором. Если заказ был сделан предварительно с сайта, либо по телефону, то по прибытию на пункт выдачи клиент получает свой заказ. Если же у клиента отсутствует

3. работник склада выдает груз клиенту. Если же зака После этого врач выписывает, в случае необходимости, направления на анализы или процедуры, рецепты на лекарства, направления к другим врачам и в другие реабилитационные центры;

4. Сдача анализов и прохождение процедур. Пациент приходит к строго отведённому ему времени, врач или медсестра производят необходимую процедуру.

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

1. Несмотря на указанное при записи время, пациенты приходят гораздо раньше и образуют «живую» очередь. Разработанная автоматизированная система предоставляет возможность записи сведений о приёме и выписки направлений только в течение времени приёма, т. е. только во время, на которое пациент был записан. Запись и выписка в другое время возможна только с указанием причины, почему не удалось выполнить их вовремя. Эти причины должны анализироваться соответствующими лицами в поликлинике.

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

1.1.2.2 Перечень функций, подлежащих автоматизации

1. Запись к врачу. Пациент должен иметь возможность записи online, через свой домашний компьютер, подключённый к сети Internet, либо через специальные терминалы, установленные в поликлинике;

2. Приём у врача. Запись в карту производится врачом с компьютера, подключённого к локальной сети. Кроме того, врач имеет возможность выписывать различного рода электронные направления;

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

4. Запись результатов анализов и отметок в процедурную карточку. При сдаче анализов и прохождении процедур все данные заносятся напрямую в автоматизированную систему;

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

6. Учёт работы врачей. Он производится ответственным лицом путём просмотра записей в картах соответствующим врачом в определённый день.

1.1.2.3 Уменьшение времени обслуживания пациентов за счёт автоматизации

Рассмотрим основные процессы обслуживания пациентов и определим, каким образом можно уменьшить время обслуживания за счёт автоматизации:

1. Запись к врачу. В настоящий момент запись производится одним из следующих способов

· Запись по телефону Определим, из чего состоит данный процесс и на что тратится время:

Рис. 1.2. Блок-схема записи по телефону Таким образом, мы видим, что итерации повторов набора номера могут происходить неопределённое время, которое, на практике, доходит до получаса. Вместе с этим, большое количество времени теряется при поиске работником регистратуры информации о записи в журнале врача.

· Запись самим пациентом в карту Определим, из чего состоит данный процесс и на что тратится время:

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

Представим запись пациента к врачу с домашнего компьютера:

На заполнение формы и отправку её на сервер тратится не более минуты.

2. Приём у врача.

При приёме врач производит одно или несколько из следующих действий:

· Запись в карту;

· Выдача направлений на анализы;

· Выдача направлений на процедуры;

· Выдача направлений к другим врачам;

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

· Выписка рецептов на лекарства.

На поиск нужного места для записи в карте или бланка для выписки направлений тратится 1−2 минуты. В системе же достаточно открыть нужное окно и переключаться между вкладками:

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

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

Необходимо отметить ещё одно преимущество автоматизированной системы в данном контексте: каждый день медсестра ищет карты записавшихся на приём в регистратуре, на что уходит от 10 до 20 минут. Кроме того, возможны и такие случаи, когда пациент был на приёме у другого специалиста, и после этого карту забыли отнести в регистратуру. В случае использования системы такие ситуации невозможны, пациенту не нужно беспокоиться о местонахождении своей карты.

Таким образом, представим схему приёма:

· Без автоматизации Рис. 1.8. Блок-схема приёма пациента

· С автоматизацией Рис. 1.9. Блок-схема автоматизированного приёма пациента

3. Выдача различных направлений.

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

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

1.1.2.4 Сущности и отношения между ними Представим схему сущностей и связей между ними:

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

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

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

1.1.3 Сравнение с аналогами

На данный момент существует два типа систем медицинского обслуживания:

1) Системы типа «Электронная история болезни» (пример — http://www.med-soft.net/). Данные системы предназначены для врачей различных поликлиник, которые работают с ними непосредственно при приёме пациента. Они обладают широким функционалом для персонала, в них существуют отдельные модули для различных врачей и других работников поликлиник. Модулей для пациентов в таких системах не предусмотрено, запись к врачу осуществляет работник поликлиники (модуль регистратора) при обращении пациента;

2) Системы типа «Электронная регистратура» (пример — https://www.medkirov.ru/e-reg/docid/kgb2pk1). Данные системы предназначены для записи пациентов к врачам. Пациент может удалённо, со своего домашнего компьютера записаться к врачу на приём. Для врачей в таких системах функционала не предусмотрено, они только могут получить информацию о том, кто и когда к ним записался на приём.

Проведём сравнительный анализ этих двух типов систем и разрабатываемой нами АСДО клиентов поликлиник по следующим критериям (используемые сокращения: ЭБ — системы типа «Электронная история болезни», ЭР — системы типа «Электронная регистратура»):

1. Возможности для персонала.

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

· В ЭР представлена только возможность просмотра врачами пациентов, записавшихся к ним. По данному показателю системе ставим 0.5 балла;

· В АСДО существуют основные функции для персонала поликлиники, которых меньше по сравнению с ЭБ. По данному показателю системе ставим 3 балла.

2. Возможности для пациентов.

· В ЭБ пациент может только записаться на приём к врачу через специального регистратора. Это единственное возможное действие пациента в этой системе. По данному показателю системе ставим 0.5 балла;

· В ЭР пациент может записаться к любому врачу по сети Internet. Это, собственно, главная функция данной системы. По данному показателю системе ставим 2 балла;

· В АСДО пациент может не только записаться к врачу через Internet, но и просмотреть все записи врачей в своей карте, увидеть направления на процедуры, на анализы, просмотреть результаты своих анализов. По данному показателю системе ставим 5 баллов.

3. Простота будущего внедрения.

· При внедрении ЭБ в ту или иную поликлинику возникнут большие трудности, поскольку в системе нет возможностей для «плавного» перехода от неавтоматизированного процесса, связанного с заполнением бумажных карт и иных документов, к автоматизированному. По данному показателю системе ставим 0 баллов;

· В процессе внедрения ЭР сложности могут возникнуть при взаимодействии с отдельным модулем, предназначенным для врачей, где они видят всех записавшихся к ним пациентов. Данный модуль должен быть прост в обращении, понятен врачу настолько, чтобы на его внедрение ушло не более 2-х недель. По данному показателю системе ставим 2 балла;

· В АСДО предусмотрены возможности печати бумажных версий записей в карту, различного рода направлений и рецептов, что поможет более плавно перейти от «бумажной» организации процесса к автоматизированной. По данному показателю системе ставим 5 баллов.

4. Связь с другими поликлиниками и диагностическими центрами.

· В ЭБ предполагается, что все процедуры, анализы и пр. будут происходить в одной и той же больнице, где установлена система (выписка направлений в другие диагностические центры не предусмотрена), однако это не всегда так — зачастую, пациентов посылают на обследование в другие места. По данному показателю системе ставим 0 баллов;

· В ЭР такая связь не очень важна, т.к. врачи ей не пользуются. Поскольку пациент может записаться в любую поликлинику, данные о врачах которой присутствуют в системе, ставим по данному показателю 5 баллов;

· В АСДО у врачей имеется возможность направить пациента в другой диагностический центр на прохождение определённой процедуры. По данному показателю системе ставим 5 баллов.

5. Простота интерфейса.

· В ЭБ интерфейс довольно сложен за счёт большого функционала системы. Это осложнит работу с системой на начальном этапе, потребуется много времени, пока сотрудники поликлиники научатся с ней работать. По данному показателю системе ставим 3 баллов;

· В ЭР интерфейс довольно прост, запись к врачу не должна вызвать сильные затруднения у пациента. По данному показателю системе ставим 5 баллов;

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

Итоговая таблица с поставленными оценками:

Обоснование поставленных оценок (будем прибавлять баллы за имеющиеся функции):

1. Возможности для персонала:

· ЭБ: претензий нет (+5 баллов);

· ЭР: просмотр записавшихся пациентов (+0.5 балла);

· АСДО: просмотр записавшихся пациентов (0.5), выписка направлений на анализы и процедуры (1), выписка рецептов (0.5), проведение процедур (0.5), исследование анализов (0.5). Итого: 3 балла.

2. Возможности для пациентов:

· ЭБ: запись на приём к врачу через специального регистратора (+0.5 балла);

· ЭР: запись на приём к врачу через Internet (+2 балла);

· АСДО: запись на приём к врачу через Internet (+2 балла), просмотр результатов анализов (+1 балл), просмотр выписанных рецептов (+1 балл), просмотр принимаемых процедур (+1 балл). Итого: 5 баллов.

3. Простота будущего внедрения:

· ЭБ: нет возможностей для «плавного» перехода к автоматизации (0 баллов);

· ЭР: проблемы при взаимодействии с модулем, предназначенным для врачей (-3 балла). Итого: 2 балла;

· АСДО: модуль врачей является составной частью системы (+ 3 балла), имеется возможность печати бумажных направлений (+2 балла). Итого: 5 баллов.

4. Связь с другими поликлиниками:

· ЭБ: таких возможностей нет (0 баллов);

· ЭР: пациент может записаться в любую доступную поликлинику (+5 баллов);

· АСДО: имеется возможность выписать направление на обследование в другую поликлинику (+5 баллов).

5. Простота интерфейса:

· ЭБ: интерфейс довольно сложен, очень много полей для заполнения (+3 балла);

· ЭР: претензий нет (+5 баллов);

· АСДО: претензий нет (+5 баллов).

1.1.4 Перечень задач, подлежащих решению в процессе проектирования

Для создания проекта необходимо:

· Разработать техническое задание;

· Разработать структурную схему;

· Разработать инфологическую модель;

· Разработать даталогическую модель;

· Разработать граф диалога;

· Разработать требования по промышленной экологии и безопасности;

· Оценить экономическую эффективность.

1.1.5 Разработка структуры

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

Разрабатываемая система имеет модульную структуру. Количество и состав модулей зависит от требований к системе. В составе системы присутствуют следующие модули:

· Модуль пациента;

· Модуль врача;

· Модуль администратора системы;

· Модуль кабинета приёма анализов;

· Модуль процедурного кабинета;

· Модуль лаборатории.

1. Модуль пациента.

Данный модуль позволяет пациенту:

· Записаться к врачу;

· Просматривать все записи к различным врачам;

· Просматривать записи в своей карте;

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

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

2. Модуль врача.

Данный модуль позволяет врачу:

· Просматривать всех записавшихся к нему пациентов;

· Проводить приём пациентов:

o Осуществлять запись в карте;

o Выписывать направления на анализы и процедуры;

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

o Выписывать рецепты;

· Просматривать своё расписание.

3. Модуль администратора системы.

Данный модуль позволяет администратору:

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

· Добавлять в базу новых врачей поликлиники и пациентов, прикреплённых к данной поликлинике;

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

· Составлять расписание работы врачей.

4. Модуль кабинета приёма анализов.

Данный модуль позволяет санитарному врачу:

· Производить отметки о приёме анализов;

· Передавать данные о сданном анализе в лабораторию.

5. Модуль процедурного кабинета.

Данный модуль позволяет медсестре:

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

· Заносить данные о результатах проведённой процедуры.

6. Модуль лаборатории.

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

· Заносить данные об исследованном анализе соответствующего пациента.

1.2 ВНУТРЕННЕЕ ПРОЕКТИРОВАНИЕ

1.2.1 Проектирование баз данных

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

На этапе инфологического проектирования используется неформальная модель предметной области типа «сущность-связь». Эта модель позволяет моделировать объекты ПО, взаимоотношения объектов. Основное назначение неформальной модели «сущность-связь» является семантическое описание предметной области и представление информации для обоснования выбора видов и моделей и структур данных, которые в дальнейшем будут использоваться в системе. Для построения модели типа «сущность-связь» используются три основных конструктивных элемента для представления составляющих предметную область — сущность, атрибут и связь.

1.2.2 Описание инфологической модели

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

Спецификация инфологической модели:

Поликлиника

Отделение

Врач

Расписание

Пациент

Направление к врачу

Анализ

Направление на анализ

Лаборатория

Результат анализа

Процедура

Направление на процедуру

Процедурный лист

Лекарство

Рецепт

1.2.3 Связи между сущностями

1.2.4 Выбор СУБД

Для интернет-приложений используются множество различных баз данных: MySQL, PostgreSQL, MS SQL Server и другие. Для анализа воспользуемся некоторыми из них.

Сравнение аналогов СУБД

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

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

Помимо Windows (поддерживаются версии от Windows95 до Windows Vista) и Unix ОС MySQL портирована на большое количество платформ, таких как Mac OS X, OpenBSD и др.

В 5 версии поддерживаются вложенные запросы и производные таблицы, триггеры, обработчики ошибок, представления.

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

1.2.5 Разработка даталогической модели

Таблица «Поликлиника»

Таблица «Отделение»

Таблица «Врач»

Таблица «Расписание»

Таблица «Пациент»

Таблица «Направление к врачу»

Таблица «Анализ»

Таблица «Направление на анализ»

Таблица «Лаборатория»

Таблица «Результат анализа»

Таблица «Процедура»

Таблица «Направление на процедуру»

Таблица «Процедурный лист»

Таблица «Лекарство»

Таблица «Рецепт»

1.2.6 Разработка архитектуры АСОИУ

1.2.6.1 Выбор архитектуры

1.2.6.1.1 Архитектура «Файл-сервер»

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

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

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

1.2.6.1.2 Архитектура «Клиент-сервер»

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

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

1.2.6.1.3Трёхуровневая архитектура

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

Трёхуровневая архитектура представляет собой:

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

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

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

Достоинствами трёхуровневой архитектуры являются:

· Масштабируемость

· конфигурируемость — изолированность уровней друг от друга быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней.

· высокая безопасность

· высокая надежность

· низкие требования к скорости канала (сети) между терминалами и сервером приложений.

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

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

Учитывая вышеизложенное, в качестве архитектуры для разработки интернет-магазина была выбрана трёхуровневая архитектура.

1.2.6.2 Выбор языка сценариев

Необходимо выбрать язык сценариев для реализации проекта. Язык сценариев (скриптовый язык) — язык программирования, разработанный для записи «сценариев», последовательностей операций, которые пользователь может выполнять на компьютере.

Самыми распространёнными языками сценариев являются PHP и Perl, поэтому они и будут сравниваться для нахождения оптимального варианта реализации проекта интернет-магазина.

Таблица 1.34. Сравнительный анализ языков сценария

PHP — язык программирования, созданный для генерации HTML-страниц на веб-сервере и работы с базами данных. Входит в LAMP — «стандартный» набор для создания веб-сайтов (Linux, Apache, MySQL, PHP).

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

В результате проведённого сравнения было принято решение использовать для реализации проекта язык PHP.

2. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Задание входных/выходных данных Входными данными является информация, вводимая в систему администратором системы, врачами, пациентами, медсёстрами и санитарами посредством клавиатуры и манипулятора мыши в специальные формы для ввода.

Информация, вводимая администратором:

· Логин и пароль;

· Личные данные врача:

o ФИО;

o Должность;

o Расписание работы;

o Год рождения;

· Личные данные пациента:

o ФИО;

o Год рождения;

o Данные полиса.

Информация, вводимая врачом:

· Логин и пароль;

· Запись в карте пациента (данные о приёме);

· Соответствующие поля направлений на анализы и процедуры;

· Соответствующие поля направлений к другим врачам и в другие реабилитационные центры;

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

Информация, вводимая пациентом:

· Логин и пароль;

· Дата и время записи к врачу на приём.

Информация, вводимая медсестрой кабинета приёма анализов:

· Логин и пароль;

· Отметка о приёме анализа;

· Выбор лаборатории, в которую направляется анализ для исследований.

Информация, вводимая медсестрой процедурного кабинета:

· Логин и пароль;

· Отметка о прохождении процедуры.

Информация, вводимая работником лаборатории:

· Логин и пароль;

· Данные о результате анализа.

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

В состав основного меню для пользователя «Врач» входят следующие пункты:

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

1.1. Приём. Данное окно предоставляет врачу следующие возможности:

1.1.1. Запись в карте. Врач производит запись данных о приёме в карте пациента.

1.1.2. Направление на анализ. Врач выдаёт пациенту направления на анализы.

1.1.3. Направление на процедуру. Врач выдаёт пациенту направления на процедуры.

1.1.4. Направление к другому врачу. Врач выдаёт пациенту направления к другому врачу (к которому пациент не имеет возможности записаться самостоятельно).

1.1.5. Выписка рецептов. Врач выписывает пациенту рецепт на лекарство.

2. Расписание. Врач может просматривать своё расписание на текущее время.

В состав основного меню для пользователя «Пациент» входят следующие пункты:

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

1.1. Запись в карте. Пациент имеет возможность просмотреть записи врачей в своей карте.

1.2. Запись к врачу. Пациент может записаться к нужному ему врачу на определённую дату и время.

2. Процедуры. Пациент может просмотреть все назначенные ему процедуры.

1.1. Процедурный лист. Пациент имеет возможность посмотреть, какое количество процедур он посетил и сколько ему ещё осталось.

3. Анализы. Пациент может просмотреть все назначенные ему анализы.

1.1. Результат. Пациент имеет возможность посмотреть результат сданного анализа.

В состав основного меню пользователя «Администратор» входят следующие пункты:

1. Врачи. Администратор видит всех врачей, зарегистрированных в данной системе.

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

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

1.3. Составить расписание. Администратор вводит расписание врача, дни и часы его работы.

2. Пациенты. Администратор видит всех пациентов, зарегистрированных в данной системе.

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

2.2. Сгенерировать логин и пароль. Логин и пароль автоматически генерируется для выбранного пациента.

В состав основного меню пользователя «Медсестра кабинета анализов» входят следующие пункты:

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

В состав основного меню пользователя «Сотрудник лаборатории» входят следующие пункты:

1. Результат анализа. Пользователь вводит данные о результате сданного анализа.

В состав основного меню пользователя «Медсестра процедурного кабинета» входят следующие пункты:

1. Процедура. Пользователь ставит отметку о прохождении или пропуске пациентом процедуры.

Рис 2.1. Граф диалога

2.3. Разработка экранных форм При открытии сайта, пользователь попадает на страничку авторизации:

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

1. Пользователь «Врач»

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

Рис. 2.3. Список записавшихся пациентов Когда пациент приходит на приём, врач нажимает на соответствующую пиктограмму и делает запись в карте пациента:

Рис. 2.4. Запись в карте на приёме Помимо этого, врач может давать различные направления пациенту:

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

Пользователь «Пациент»

После авторизации пациент попадает в форму, где выводятся все его записи к врачам:

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

Для записи к определённому врачу пациент открывает соответствующую ссылку, после чего появляется окно записи:

После перехода по ссылке «Процедуры», пациент попадает в форму, где отображаются все прописанные ему процедуры:

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

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

2. Пользователь «Администратор»

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

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

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

3. Пользователь «Медсестра кабинета приёма анализов»

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

Когда пациент приходит на сдачу, медсестра делает соответствующую отметку о приёме.

4. Пользователь «Работник лаборатории»

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

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

5. Пользователь «Медсестра процедурного кабинета»

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

2.3 Руководство пользователю

2.4.1 Создание нового врача, изменение его данных, удаление врача