Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

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

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

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

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

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

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

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

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

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

Организационная модель предметной области (Портретная)

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 2

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

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

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

CDM

Рис.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)

Таблица 4

Подразделение (Department)

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

Таблица 5

Отделение (Division)

Наименование	Тип
id_division	int (KEY)
id_department	int (Foreign KEY)
name	varchar(128)

Таблица 6

Учетная запись (Account)

Наименование	Тип
id_account	int (KEY)
user_login	varchar(16)
user_password	varchar(16)
last_name	varchar(32)
first_name	varchar(32)
middle_name	varchar(32)
Email	varchar(64)
phone	varchar(64)
post	varchar(64)
work_place	varchar(128)
role	tinyint

Таблица 7

Администратор (Administrator)

Наименование	Тип
*id_account*	*int (KEY)* (Foreign KEY)
notes	varchar(255)

Таблица 8

Регистратор (Registrator)

Наименование	Тип
*id_account*	*int (KEY)* (Foreign KEY)
id_department	int (Foreign KEY)

Таблица 9

Врач (Doctor)

Наименование	Тип
*id_account*	*int (KEY)* (Foreign KEY)
id_division	int (Foreign KEY)
speciality	varchar(64)
room	varchar(8)

Таблица 10

Расписание приема (Schedule)

Наименование	Тип
id_interval	int (KEY)
id_account	int (Foreign KEY)
date_int	date
start_int	time
finish_int	time

Таблица 11

Талон (Coupon)

Наименование	Тип
id_coupon	int (KEY)
id_patient	int (Foreign KEY)
id_account	int (Foreign KEY)
date_coupon	date
start_coupon	time
finish_coupon	time
reg_state	bool
pat_state	bool
doc_state	bool
abandon_couse	varchar(255)

Таблица 12

Талон (Coupon)

Наименование	Тип
id_patient	int (KEY)
last_name	varchar(32)
first_name	varchar(32)
middle_name	varchar(32)
birth_date	date
address	varchar(255)
oms_series	varchar(8)
oms_number	varchar(8)
oms_company	varchar(255)
email	varchar(64)
phone	varchar(64)

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

PDM

Рис.3. Схема базы данных

Инструкции по работе с базой данных

Для создания базы данных сайта был использован PhpMyAdmin. Чтобы войти в эту панель, нужно набрать http://localhost/tools/phpmyadmin/.

Для создания базы данных, выбираем Базы данных, Создать.

Следующий этап – добавление пользователя.

Рис.4.Добавление пользователя

Рис.5. Добавление привилегий пользователя

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

Рис.6. Настройка конфигурации БД

6. Разработка интерфейса и реализация проекта

Главная страница предоставляет доступ к системе «Электронная регистратура». Главная страница интерфейса пользователя представлена на рис. 7.

Рис.7. Главная страница интерфейса пользователя

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

Каждый пункт меню (шаг, этап) имеет три состояния: пройденный, текущий и следующий. Каждое состояние этапа выделено визуально и функционально. Пройденный этап является ссылкой и имеет соответствующую визуальную акциденцию – подчеркивание. Текущий шаг не является ссылкой и имеет самое яркое и контрастное цветовое решение. Следующие шаги неактивны и имеют приглушенный серый цвет.

Рис.8. Основное пошаговое меню

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

На первом этапе пациент выбирает необходимое медицинское учреждение, получая информацию об адресе, телефонах и руководстве.

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

Рис. 9. Второй этап – выбор врача

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

Рис.10. Третий этап – просмотр расписания приема

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

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

Рис. 11. Пятый этап – печать талона

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

Рис. 12. Вид талона на печатном носителе

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

7. Оценка экономической эффективности проекта

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

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

К статье «Основная заработная плата» относятся зарплата инженерно-технических работников (ИТР), лаборантов и техников, непосредственно занятых выполнением конкретной разработки. Размер ОЗП устанавливается, исходя из численности различных категорий исполнителей, трудоемкостей, затраченных ими на выполнение отдельных видов работ и их ставки (средней зарплаты) за один рабочий день. Средняя зарплата за один рабочий день определяется для каждой категории работающих, исходя из месячного должностного оклада и количества рабочих дней в месяце.

В разработках принимало участие два исполнителя: руководитель (оклад 7000 руб.) и инженер-программист (оклад 5000 руб.). Руководителем затрачено на разработку 14 дней, а инженером-программистом - 68 дней при месячном фонде времени одного разработчика 22 дня. Основная заработная плата определяется по формуле:

где:

O_i - оклад i-ого исполнителя (руб.);

Т_i - время, затраченное i-ым исполнителем (дни);

F_i - месячный фонд времени i-ого исполнителя (дни);

N- число исполнителей.

С учетом вышесказанного, затраты на основную заработную плату составляют:

(руб.)

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

где

= 30%

(руб.)

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

(1)

где:

– затраты на амортизацию;

– затраты на электроэнергию;

– стоимость обслуживания оборудования.

Количество дней работы с ПЭВМ составляет 62 рабочих дней.

Амортизационные отчисления рассчитываются по формуле:

3_А=

где:

Ф_п - первоначальная стоимость оборудования;

Т_п – количество дней использования оборудования для проектирования;

а — норма амортизации (составляет 15%);

F_q — годовой действительный фонд времени работы оборудования.

Количество рабочих дней - 248.

Расчет амортизации ПЭВМ

Первоначальная стоимость ПЭВМ составляет 15 000 рублей.

Тогда амортизация ПЭВМ составляет:

(руб.)

Расчет амортизации лицензионного программного обеспечения.

В затраты на программное обеспечение (З_ПО) входят затраты на покупку лицензионных пакетов ПО.

Таблица 13

Стоимость программного обеспечения

Наименование ПО	Цена, руб.
Microsoft Windows XP Professional SP3	4 417
PHP 5.3, mySQL 5.0	Бесплатно
Microsoft Office 2007 Professional	15 800
Итого	20 217

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

где:

– стоимость лицензионного программного обеспечения;

– норма амортизационных отчислений для программного обеспечения – 20%;

– число дней, затраченных на разработку;

– число рабочих дней в году;

(руб.)

Расчет затрат на электроэнергию

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

где:

– потребляемая мощность – 0.5 кВт;

– фонд времени за период амортизации 62 дня по 8 часов ежедневно: 62*8 = 496 часов;

– стоимость 1 квт. энергии − 2.42 (руб.);

(руб.)

Расчет затрат на обслуживание оборудования

Составляют 20% от затрат на амортизацию и затрат на электроэнергию:

(руб.)
Итого, затраты на эксплуатацию оборудования и лицензионного ПО согласно формуле (6.1) составили:

(руб.)

Расходы на покупные материалы

Включают затраты на покупные полуфабрикаты и покупные изделия, необходимые для выполнения проекта с учетом НДС (18 %) (таблица 14).

Таблица 14

Затраты на покупные материалы

Наименование	Кол-во, шт.	Цена за единицу, руб.	Сумма, Руб.
Бумага А4 80 г/м	200	0.2	40
Печать	200	0.5	100
CD диски	3	15	45
Итого:			185

Накладные расходы

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

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

Накладные расходы составляют 20% от суммы всех статей затрат рассмотренных выше - .

(руб.)

Смета затрат приведена в табл. 15.

Таблица 15

Смета затрат

Статья затрат	Сумма, руб.
Основная заработная плата	19 909
Отчисления на социальные нужды	6 769
Расходы на эксплуатацию оборудования и лицензионное программное обеспечение	2 928
Расходы на покупные материалы	185
Накладные расходы	6 278
Итого	36 069

Нормативная прибыль (П_Н), включаемая в цену продукции, определяется исходя из норматива рентабельности. Норматив рентабельности равен 20 %, тогда нормативная прибыль:

где:

С - себестоимость изделия, руб.;

р - норматив рентабельности, %.

(руб.)

В итоге цена, складывающаяся из себестоимости разработки и прибыли, составляет:

(руб.)

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

Тем не менее, можно посчитать экономию времени на предварительное составление списка талонов. Выдача одного талона до внедрения системы занимает 2 минуты пациенту в живой очереди. После внедрения системы регистратор проверяет поступившие заявки, а именно корректность заполнения личных данных и полиса медицинского страхования, что занимает также около 2-х минут. Существенная экономия времени происходит на этапе составления предварительного списка талонов. В среднем, регистратор тратит 1 минуту на выписку одного талона для одного врача. На 6-ти часовую смену с интервалом в 15 минут выписывается 24 талона. Значит, на формирование предварительного списка талонов на одного врача составляет 24 талона * 1 минута = 24 минуты. Если в среднем 10 врачей в поликлинике, которые ведут прием, то формирование списка талонов занимает 240 минут (4 часа) рабочего времени сотрудников регистратуры. После внедрения системы формирование талонов занимает 5 минут, т.к. необходимо выполнить всего одну операцию: выделить список врачей и выбрать интервал дат. Средняя зарплата сотрудника регистратуры 15 000 рублей за 160 рабочих часов в месяц. Оплата сотрудника за 1 час – 93,75 рубля, за 4 часа – 375 руб, т.е. использование информационной системы в день экономит 375 руб. В году в среднем 248 рабочих дней при 40-часовой 5-ти дневной рабочей неделе. Таким образом, экономия за год 93 000 рублей (248 дней х 375 рублей). Стоимость разработки, рассчитанная в предыдущем разделе, составляет 43 283 рубля, которая окупается за 116 рабочих дней (43283х248/93000), или за 171 календарный день (116х365/248).

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

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

Заключение

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

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

Программное обеспечение «Электронная регистратура» удовлетворяет всем предъявленным к себе требованиям и реализует требуемые функции обеспечения основных стадий записи на прием к врачу.

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

Отличительные особенности данной системы реализованы в полном объеме.

Список литературы

Дейт К. Введение в системы баз данных / Пер. с англ. - М.:Наука, 1980. -463с.
Дженнингс P. Microsoft Access 97 - СПб.: БХВ - Санкт - Петербург, 2000. - 1270с.
Джерк Н. Разработка приложений для электронной коммерции. Библиотека программиста. - СПб.: Питер, 2001.-512 с.
Джерри Бранденбау. JavaScript: сборник рецептов для профессионалов. -СПб.: Питер, 2001. – 416 с.
Кастаньетто Дж., Рават Х., Шуман С., Сколло К., Велиаф Д. Профессиональное PHP программирование. – Пер. с англ. – СПб:Символ-Плюс, 2001. – 912 с., ил.
Костарев А.Ф. PHP в Web-дизайне. – Спб.: БХВ-Петербург, 2002. – 592 с.: ил
Томсон Л., Веллинг Л. Разработка Web-приложений на РНР и MySQL: пер с англ./Л. Томсон, Л. Веллинг. – К.: Издательство «ДиаСофт», 2002. – 672 с.
Фролов А.В., Фролов Г.В. Создание Web-приложений: Практическое руководство. – М.: Издательско-торговый дом «Русская редакция», 2001.-1040 с.
Фролов А.В.,Фролов Г.В. Базы данных в Интернете: практическое руководство по созданию Web-приложений с базами данных. М.: Издательско-торговый дом «Русская редакция», 2000.-765 с.
Хоумер А.,Улмен К. Dynamic HTML: справочник. – СПб.: Питер, 2000.-512 с.