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

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

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

Реферат

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

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

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

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

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

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

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

Содержание

• Нормативные ссылки
• Определения, обозначения и сокращения
• Введение
• 1. Конструкторская часть
• 1.1 Внешнее проектирование
• 1.1.1 Постановка задачи проектирования
• 1.1.2 Описание предметной области
• 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 Разработка архитектуры АСОИУ
• 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.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. ГОСТ 22269-76. Система “Человек - машина”. Рабочее место оператора. Взаимное расположение элементов рабочего места. Общие эргономические требования.

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

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

Определения, обозначения и сокращения

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

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

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

Пользователь - лицо, работающее с системой.

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

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

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

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

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

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

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

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

URL -Universal Resource Locator, адрес страницы в сети интернет.

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

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

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

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

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

Введение

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

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

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

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

инфологический архитектура автоматизация

1. Конструкторская часть

1.1 Внешнее проектирование

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

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

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

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

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

· статистика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Запись по телефону

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



Рис. 1.1. Запись по телефону

Рис. 1.2. Блок-схема записи по телефону

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

· Запись самим пациентом в карту

Рис. 1.3. Запись в карту

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

Рис. 1.4. Блок-схема записи в карту

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

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

Рис. 1.5. Запись с домашнего компьютера

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

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

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

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

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

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

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

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

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

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

Рис. 1.7. Окно приёма пациента

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

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

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

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

· Без автоматизации

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

· С автоматизацией

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

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

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



Рис. 1.10. Распределение талонов между врачами

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

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

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

Описание сущностей

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



Рис. 1.11. Схема сущностей и связей

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

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

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

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

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

2) Системы типа «Электронная регистратура». Данные системы предназначены для записи пациентов к врачам. Пациент может удалённо, со своего домашнего компьютера записаться к врачу на приём. Для врачей в таких системах функционала не предусмотрено, они только могут получить информацию о том, кто и когда к ним записался на приём.

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

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.1. Итоговая таблица с поставленными оценками:

Показатель	ЭБ	ЭР	АСДО
1. Возможности для персонала	5	0.5	3
2. Возможности для пациентов	0.5	2	5
3. Простота будущего внедрения	0	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. Поликлиника

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
Название	Полное название учреждения
Адрес	Юридический адрес учреждения
Телефон	Контактный телефон учреждения

Таблица 1.3. Отделение

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
ID_поликлиники	Идентификатор соответствующей записи в таблице «Поликлиника»
Название	Полное название отделения

Таблица 1.4 Врач

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
ID_отделения	Идентификатор отделения, в котором работает врач
ФИО	Фамилия, имя и отчество врача
Специализация	В какой должности работает врач
Дата рождения	Дата рождения врача
№ кабинета	№ кабинета, в котором принимает врач

Таблица 1.5.Расписание

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
ID_врача	Идентификатор врача
День	День недели
Начало	Время начала работы
Окончание	Время окончания работы

Таблица 1.7 Пациент

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
ФИО	Фамилия, имя и отчество пациента
Дата рождения	Дата рождения пациента
Полис	Номер страхового полиса
Адрес	Адрес места жительства пациента
Дата учёта	Дата постановки на учёт в поликлинику

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

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
ID_пациента	Идентификатор записавшегося пациента
ID_врача	Идентификатор врача, к которому записался пациент
Дата	Дата, на которую записался пациент
Время	Время, на которое записался пациент
Прохождение	Отметка о прохождении

Таблица 1.9 Анализ

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
Название	Название анализа
Номер кабинета	Номер кабинета, где принимается анализ
Часы работы	Часы работы данного кабинета

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

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
ID_анализа	Идентификатор сдаваемого анализа
ID_врача	Идентификатор врача, выписавшего направление
ID_пациента	Идентификатор пациента, сдающего (сдавшего) анализ
ID_лаборатории	Идентификатор лаборатории, где будет исследоваться анализ
Дата	Дата сдачи анализа
Время	Время сдачи анализа

Таблица 1.11 Лаборатория

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
Название	Название лаборатории
Адрес	Юридический адрес лаборатории
Телефон	Телефон лаборатории

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

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
ID_направления	Идентификатор направления на анализ
Дата	Дата исследования
Результат	Результат исследования

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

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
Название	Название анализа
Номер кабинета	Номер кабинета, где принимается анализ
Часы работы	Часы работы данного кабинета

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

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
ID_процедуры	Идентификатор проходимой процедуры
ID_врача	Идентификатор врача, выписавшего направление
ID_пациента	Идентификатор пациента, проходящего (прошедшего) процедуру
Количество	Количество процедур, прописанных врачом пациенту

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

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
ID_направления	Идентификатор направления на процедуру
Дата	Дата прохождения
Время	Время прохождения
Отметка	Отметка о прохождении

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

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
Название	Название лекарства
Лечение	Описание данного лекарства, от каких болезней помогает
Побочный эффект	Описание побочного эффекта лекарства

Таблица 1.17 Рецепт

Описание атрибута	Название атрибута
ID	Уникальный идентификатор записи
ID_лекарства	Идентификатор лекарства
ID_врач	Идентификатор врача, выписавшего рецепт
ID_пациент	Идентификатор пациента, которому был выписан рецепт
Дата	Дата выписки рецепта

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

Таблица 1.18

Родительская сущность	Дочерняя сущность	Описание	Тип связи
Поликлиника	Отделение	Поликлиника имеет несколько отделений	1:М
Отделение	Врач	В отделении работает несколько врачей	1:М
Врач	Расписание	Врач работает по расписанию	1:М
Врач	Направление на анализ	Врач выдаёт направления на анализы	1:М
Врач	Направление на процедуру	Врач выдаёт направления на процедуры	1:М
Врач	Направление к врачу	Врач принимает по направлению к врачу	1:М
Врач	Рецепт	Врач выписывает рецепт	1:М
Пациент	Направление на анализ	Пациент получает направление на анализ	1:М
Пациент	Направление на процедуру	Пациент получает направление на процедуру	1:М
Пациент	Направление к врачу	Пациент получает направление к врачу	1:М
Пациент	Рецепт	Пациент получает рецепт	1:М
Анализ	Направление на анализ	Направление выдаётся на определённый анализ	1:М
Процедура	Направление на процедуру	Направление выдаётся на определённую процедуру	1:М
Лекарство	Рецепт	Рецепт выписывается на определённое лекарство	1:М
Лаборатория	Направление на анализ	Анализ, сданный по определённому направлению, исследуется в лаборатории	1:М
Лаборатория	Результат анализа	Результат анализа получается после исследования анализа в лаборатории	1:М
Результат анализа	Направление на анализ	Результат анализа соответствует определённому направлению	1:1
Направление на процедуру	Процедурный лист	Направлению на процедуру соответствует запись в процедурном листе	1:М

1.2.4 Выбор СУБД

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

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

Аналоги Критерии сравнения	Весовой коэффициент	PostgreSQL	MySQL	MS SQL Server
Скорость работы	0,25	4	4	5
Настройка	0,15	4	5	4
Простота БД	0,2	4	5	5
Поддержка хостинг-провайдерами	0,2	4	5	3
Максимальный размер БД	0,1	5	5	4
Платформа	0,1	Unix	Unix, Windows	Windows
Итого	1	4,2	4,75	4,25

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.19 «Поликлиника»

Поле	Физическое имя	Тип	Длина	Примечание
ID	ID	int	-	Первичный ключ
Название	Name	VarChar	20	-
Адрес	Address	VarChar	50	-
Телефон	Phone	VarChar	15	-

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

Поле	Физическое имя	Тип	Длина	Примечание
ID	ID	int	-	Первичный ключ
ID_поликлиники	ID_hospital	int		Вторичный ключ
Название	Name	VarChar	20	-

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

Поле	Физическое имя	Тип	Длина	Примечание
ID	ID	int	-	Первичный ключ
ID_отделения	ID_department	int	-	Вторичный ключ
ФИО	FIO	VarChar	100	-
Специализация	Specialization	VarChar	20	-
Дата рождения	Birthdate	Date	-	-
№ кабинета	Number	int	2	-

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

Поле	Физическое имя	Тип	Длина	Примечание
ID	ID	int	-	Первичный ключ
ID_врача	ID_doctor	int	-	Вторичный ключ
День	Day	VarChar	11	-
Начало	Begin	Time	-	-
Окончание	End	Time	-	-

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

Поле	Физическое имя	Тип	Длина	Примечание
ID	ID	int	-	Первичный ключ
ФИО	FIO	VarChar	100
Дата рождения	Birthdate	Date	-	-
Полис	Polis	VarChar	100	-
Адрес	Address	VarChar	100	-
Дата учёта	BeginDate	Date	-	-

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

Поле	Физическое имя	Тип	Длина	Примечание
ID	ID	int	-	Первичный ключ
ID_пациента	ID_patient	int	-	Вторичный ключ
ID_врача	ID_doctor	int	-	Вторичный ключ
Дата	Date	Date	-	-
Время	Time	Time	-	-
Прохождение	Check	VarChar	20	-

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

Поле	Физическое имя	Тип	Длина	Примечание
ID	ID	int	-	Первичный ключ
Название	Name	VarChar	20	-
Номер кабинета	Cabinet	int	1	-
Часы работы	Time	Time	-	-

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

Поле	Физическое имя	Тип	Длина	Примечание
ID	ID	int	-	Первичный ключ
ID_анализа	ID_analiz	int	-	Вторичный ключ
ID_врача	ID_doctor	int	-	Вторичный ключ
ID_пациента	ID_patient	int	-	Вторичный ключ
ID_лаборатории	ID_lab	int	-	Вторичный ключ
Дата	Date	Date	-	-
Время	Time	Time	-	-

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

Поле	Физическое имя	Тип	Длина	Примечание
ID	ID	int	-	Первичный ключ
Название	Name	Varchar	20	-
Адрес	Address	Varchar	50	-
Телефон	Phone	Varchar	15	-

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

Поле	Физическое имя	Тип	Длина	Примечание
ID	ID	int	-	Первичный ключ
ID_направления	ID_aiming	int	-	Вторичный ключ

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

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

  Естественно-языковая модель предметной области. Уменьшение времени обслуживания пациентов за счет автоматизации. Описание инфологической модели. Проектирование баз данных. Разработка графа диалога и экранных форм. Оптимизация логической схемы базы данных.
  
  дипломная работа [4,2 M], добавлен 20.05.2012
  

• Автоматизация системы кредитования банка

  Разработка автоматизированной системы кредитования банка: концептуальная модель предметной области. Построение инфологической и даталогической модели средствами MySQL; таблицы и схемы базы данных; формулировка запросов для отображения данных их таблиц.
  
  курсовая работа [8,7 M], добавлен 18.01.2012
  

• Разработка базы данных "Кадры"

  Автоматизация подсистемы управления кадрами на ОАО Судостроительный завод "Лотос". Описание предметной области, построение инфологической и даталогической модели. Проектирование базы данных и разработка приложения. Взаимосвязь командных файлов в проекте.
  
  дипломная работа [326,9 K], добавлен 02.10.2013
  

• Проект базы данных "Стоматологическая клиника"

  Разработка базы данных на основе MS Access, позволяющей регистратору стоматологической клиники записывать клиентов на прием, формировать отчетность. Построение инфологической и даталогической модели. Создание макросов для выполнения рутинных операций.
  
  курсовая работа [989,7 K], добавлен 09.12.2014
  

• Разработка автоматизированной системы тестирования знаний по дисциплине "Русский язык"

  Функциональная модель системы. Проектирование схемы базы данных. Проектирование архитектуры системы. Принцип технологии клиент-сервер. Построение схемы ресурсов. Выбор программных средств. Разработка базы данных с использованием Microsoft SQL Server.
  
  дипломная работа [1,1 M], добавлен 30.03.2015
  

• Проектирование базы данных для автоматизированной системы

  Проектирование базы данных для автоматизированной системы "Склад". Разработка концептуальной модели (ER-диаграмма). Преобразование в реляционную модель и ее нормализация. Разработка запросов к базе данных на языке SQL. Скрипт для создания базы данных.
  
  курсовая работа [161,8 K], добавлен 07.10.2013
  

• Корпоративная информационная система "МТО"

  Разработка корпоративной информационной системы, использующей несколько баз данных, содержащих информацию о наличии товара на складе, ходе ремонта компьютерной техники и данных о персонале. Разработка инфологической и даталогической моделей базы данных.
  
  дипломная работа [1009,2 K], добавлен 01.05.2015
  

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

  Разработка информационно-аналитической системы агентства недвижимости. Обоснование выбора архитектуры базы данных и СУБД. Моделирование потоков данных (DFD диаграмм). Проектирование инфологической модели данных с использованием модели "сущность-связь".
  
  дипломная работа [5,4 M], добавлен 06.06.2013
  

• Создание базы данных парикмахерской

  Разработка базы данных с информацией о сотрудниках, товарах, со справочником типов товаров средствами системы управления базами данных MySQL с помощью SQL-запросов. Разработка инфологической модели предметной области. Структура таблиц, полей базы данных.
  
  контрольная работа [648,7 K], добавлен 13.04.2012
  

• Разработка базы данных и программного приложения для справочной службы кинотеатров города

  Рассмотрение инфологической и даталогической модели базы данных кинотеатров города. Разработка базы данных в программе MS Access. Описание структуры приложения и интерфейса пользователя. Изучение SQL-запросов на вывод информации о кинотеатре и о фильме.
  
  курсовая работа [1,1 M], добавлен 04.09.2014
  

• Разработка базы данных "Служба АТС"

  Освоение сервисной системы управления базами данных Microsoft SQL. Разработка базы данных "Служба АТС" в среде Microsoft SQL Server Management Studio и создание запросов на языке SQL. Апробация инфологической модели "сущность - связь" базы данных.
  
  курсовая работа [2,9 M], добавлен 29.06.2015
  

• Проект базы данных "Дневной стационар"

  Создание инфологической и даталогической модели базы данных, которые отображают сущности и атрибуты, отношения и поля. Разработка информационной системы учета пролеченных в дневном стационаре (DSP) с помощью СУБД MS Access и среды разработки Delphi 7.
  
  курсовая работа [1,5 M], добавлен 03.07.2012
  

• Проектирование и разработка базы данных автоматизированной информационной системы предприятия

  Схема взаимодействия подразделений предприятия. Выбор и обоснование технологии проектирования базы данных. Описание объектов базы данных. Разработка запросов на выборку, изменение, обновление и удаление данных. Интерфейсы взаимодействия с базой данных.
  
  курсовая работа [1,4 M], добавлен 25.05.2023
  

• Создание базы данных сотрудников

  Этапы создания и разработки базы данных. Построение модели предметной области. Разработка даталогической и физической моделей данных, способы обработки данных о сотрудниках организации. Проектирование приложений пользователя. Создание кнопочной формы.
  
  курсовая работа [2,1 M], добавлен 14.02.2011
  

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

  Построение инфологической концептуальной модели предметной области. Структура базы данных Microsoft Office Access. Формы, запросы и отчеты. Создание форм, запросов и отчетов в базах данных. Схема данных физической и логической сущности в Erwin 4.0.
  
  курсовая работа [5,1 M], добавлен 13.12.2011
  

• Автоматизированная информационная система формирования счетов в группе газет "Из рук в руки"

  Создание автоматизированной информационной системы отдела приема объявлений и рекламы в группе газет "Из рук в руки": предметная область, разработка программного обеспечения и реализация; построение инфологической и даталогической моделей базы данных.
  
  курсовая работа [9,8 M], добавлен 11.01.2012
  

• Разработка АИС по принятию и обработке заявок

  Проектирование базы данных системы принятия, обработки и учёта заявок в отдел информационных технологий; разработка инфологической и даталогической моделей, реализация физической модели. Создание приложений для визуализации работы с базой данных.
  
  дипломная работа [2,8 M], добавлен 25.01.2013
  

• Разработка автоматизированной информационной системы по оформлению и учету историй болезней пациентов в больнице

  Разработка информационной системы для отдела учета приема пациентов и медицинского секретариата. Описание исходной (входной) информации и пользовательского интерфейса, логической структуры и технических средств. Построение реляционной базы данных.
  
  дипломная работа [1,9 M], добавлен 16.04.2012
  

• Проектирование базы данных тренера спортивного клуба

  Описание предметной области разрабатываемой базы данных для теннисного клуба. Обоснование выбора CASE-средства Erwin 8 и MS Access для проектирования базы данных. Построение инфологической модели и логической структуры базы данных, разработка интерфейса.
  
  курсовая работа [3,8 M], добавлен 02.02.2014
  

• Моделирование предметной области базы данных АИС деканата "Учет студентов"

  Разработка проектных решений по созданию подсистемы учета студентов в деканате различных форм и видов обучения, диагностический анализ системы управления. Проектирование информационной базы данных, построение инфологической и датологической модели.
  
  дипломная работа [1,1 M], добавлен 24.06.2011
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам