Модернизация информационно-аналитической системы предприятия здравоохранения

Деструктор

Освобождает память, занимаемую экземпляром класса.

Выбор

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

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

Таблица 2.7 Описание класса шаблоны медицинских документов

Наименование	Назначение
Свойства
Медицинский документ	Ссылка на медицинский документ, с которым осуществляется работа
Первичный	Признак, по которому определяется посещение: первичный или повторный прием.
Ортопед	Признак, по которому осуществляется проверка - работает ли с ШМД врач-ортопед.
Методы
Конструктор	Создает экземпляр класса, который содержит в себе все свойства класса и методы, которыми данный экземпляр класса может пользоваться в своем контексте.
Деструктор	Освобождает память, занимаемую экземпляром класса.
Сохранит	Данный метод производит поиск в объекте базы данных записи соответствующей экземпляру класса по уникальному идентификатору, если он ее не находит, то создает новую запись и записывает в нее экземпляр класса из памяти. Если запись существует, то метод просто записывает в существующую запись в объекте базы данных изменения. При выполнении этого метода изменяется только сам объект базы данных, движения по регистрирующим таблицам не производятся. Создается медицинский документ человеко-читаемого вида.
Провести	Производит необходимые проверки заполнения свойств экземпляра класса, записывает свойства в объект базы данных. После записи объекта выполняются движения (регистрация действия) в таблицах Статусы Услуг, Сменное Задание. Создается медицинский документ человеко-читаемого вида.
Отмена проведения	Выполняет отмену регистрации действий в таблицах Статусы услуг, Сменное задание и создает об этом соответствующие записи в этих таблицах.

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

Диаграмма описанных основных классов системы «Медицина. Поликлиника» представлена на рисунке 2.3.

Рис. 2.3 - Диаграмма взаимодействия основных классов подсистемы «Медицина. Поликлиника»

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

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

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

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

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

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

2.3 Характеристика нормативно-справочной, входной и результативной информации

Нормативно-справочная информация, используемая подсистемой «Медицина. Поликлиника». КЛАДР (классификатор адресов Российской Федерации) -- ведомственный классификатор ФНС России, созданный для распределения территорий между налоговыми инспекциями и автоматизированной рассылки корреспонденции. В КЛАДР есть почтовые индексы и коды ОКАТО (Общероссийский классификатор объектов административно-территориального деления) для всех населённых пунктов, однако он содержит много неточностей и ошибок (чаще всего в

Номенклатура медицинских услуг далее - номенклатура) представляет собой перечень медицинских услуг. Схема кодирования медицинской услуги в номенклатуре представлена на рисунке 2.4

Рис. 2.4 - Схема кодирования медицинской услуги в номенклатуре

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

Рис. 2.5 - Схема определения входной документации

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

Рис. 2.6 - Виды отчетности на основе протокола приема пациента

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

2.4 Информационная модель подсистемы «Медицина. Поликлиника» и ее описание

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

Таблица 2.8 Структура справочника «Пользователи»

Наименование реквизита	Тип	Длина
Код	УИД	32
Наименование	Строка	20
Пометка Удаления	Булево	1
Ссылка	УИД	32
Предопределенный	Булево	1
Идентификатор Пользователя ИБ	УИД	32

Справочник «Готовые фразы» предназначен для задания фраз, используемых для быстрого заполнения медицинского документа, их состава и принадлежности пользователю и полю формы ШМД. Структура справочника «Готовые фразы» представлена в таблице 2.9

Таблица 2.9 Структура справочника «Готовые фразы»

Наименование реквизита	Тип	Длина
1	2	3
Код	УИД	32
Наименование	Строка	20
Пометка Удаления	Булево	1
Ссылка	УИД	32
Предопределенный	Булево	1
Тело	Строка	-
Принадлежность	Ссылка	32
В Виде Структуры	Булево	1
Использовать Родителя	Булево	1
Привязка К Полю	Строка	50

Справочник «Картотека» хранит данные пациентов. Структура справочника «Картотека» представлена в таблице 2.10

Таблица 2.10 Структура справочника «Картотека»

Наименование реквизита	Тип	Длина
Код	УИД	32
Наименование	Строка	20
Пометка Удаления	Булево	1
Ссылка	УИД	32
Предопределенный	Булево	1
Дата Выбытия	Дата Время	-
Документ Выбытия	Ссылка	32
СНИЛС	Строка	14

Справочник «Медицинские карты» хранит данные медицинских карт пациентов. Структура справочника «Медицинские карты» представлена в таблице 2.11

Таблица 2.11 Структура справочника «Медицинские карты»

Наименование реквизита	Тип	Длина
1	2	3
Код	УИД	32
Наименование	Строка	20
Пометка Удаления	Булево	1
Ссылка	УИД	32
Предопределенный	Булево	1
Дата	Дата Время	-
Дата Закрытия	Дата Время	-
Документ Закрытия	Ссылка	32
Документ Карты	Ссылка	32
Номер Карты Номер	Число	10
Номер Карты Освобожден	Булево	1
Номер Карты Представление	Строка	220
Номер Карты Префикс	Строка	100
Номер Карты Суффикс	Строка	100
Нумератор	Ссылка	32
Пациент	Ссылка	32
Период Нумератора	Дата Время	-
Тип Медицинской Карты	Ссылка	32
Шаблон Номера	Ссылка	32

Справочник «МКБ-10» предназначен для хранения диагнозов международного классификатора болезней 10 версии. Используется в подсистеме Контроль исполнения для постановки диагнозов при выполнении услуг. Структура справочника «МКБ -10» представлена в таблице 2.12.

Таблица 2.12 Структура справочника «МКБ -10»

Наименование реквизита	Тип	Длина
1	2	3
Код	УИД	32
Наименование	Строка	20
Пометка Удаления	Булево	1
Ссылка	УИД	32
Предопределенный	Булево	1
Идентификатор На Диске	Число	10

В справочнике «Сотрудники» перечисляются все сотрудники медицинской организации. Не обязательно, чтобы все они являлись пользователями программы. Структура справочника «Сотрудники» представлена в таблице 2.13.

Таблица 2.13 Структура справочника «Сотрудники»

Наименование реквизита	Тип	Длина
Код	УИД	32
Наименование	Строка	20
Пометка Удаления	Булево	1
Ссылка	УИД	32
Предопределенный	Булево	1
Актуальность	Булево	1
Должность	Ссылка	32
Подразделение	Ссылка	32
Физическое Лицо	Ссылка	32
Код По ОМС	Строка	16
Ставка	Число	10

Объект «Заказ Пациента» предназначен для регистрации заказа на медицинские услуги, которые пациент оформил в регистратуре. Структура объекта «Заказ Пациента» представлена в таблице 2.14

Таблица 2.14 Структура объекта «Заказ Пациента»

Наименование реквизита	Тип	Длина
Ответственный	Ссылка	32
Медицинская Карта	Ссылка	32
Внешний Входящий Номер Направления	Строка	20
Направившая Организация	Ссылка	32
Уникальный Идентификатор Сеанса	УИД	32
Сумма Документа	Число	15
Организация	Ссылка	32
Основание	Ссылка	32
Канал Первичного Интереса	Ссылка	32
Источник Первичного Интереса	Ссылка	32
Медицинские Услуги	Табличные Данные	-
Скидки Наценки	Табличные Данные	-
Дополнительные Реквизиты	Табличные Данные	-

В объекте «Реестр Оказанных Услуг. Выполненные Услуги» хранятся непосредственно услуги, оказанные в лечебном учреждении. Объект привязан к объекту «Реестр Оказанных Услуг». Структура объекта «Реестр Оказанных Услуг. Выполненные Услуги» представлена в таблице 2.15.

Таблица 2.15 Структура «Реестр Оказанных Услуг. Выполненные Услуги»

Наименование реквизита	Тип	Длина
Уникальный Идентификатор Услуги	УИД	32
Номенклатура	Ссылка	32
Дата Выполнения	Дата Время	-
Медицинская Карта	Ссылка	32
Цена	Число	15
Сумма	Число	15
Процент Автоматической Скидки	Число	5

Объект «Листок Нетрудоспособности» хранит информацию о документах, удостоверяющий временную нетрудоспособность граждан и подтверждающий их временное освобождение от работы.

Имея полное представление об объектах базы данных с которыми, мы в дальнейшем будем работать, необходимо узнать взаимодействие этих объектов в подсистеме «Медицина. Поликлиника», для чего необходимо построить нотацию UML для моделирования баз данных. Взаимодействие объектов базы данных показано на рисунке 2.7.

Рис. 2.7 - Взаимодействие объектов базы данных

2.5 Подготовка к модификации подсистемы «Медицина. Поликлиника»

Первый этап модификации подсистемы будет затрагивать инфологическую модель. На данном этапе необходимо создать дополнительный справочник «Состояния зубов» и четыре объекта базы данных - «Зубная Формула», «Схема Протеза», «Первичные И Санированные» и «Льготное Протезирование».

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

Таблица 2.16 Структура справочника «Состояния зубов»

Наименование реквизита	Тип	Длина
Код	УИД	32
Наименование	Строка	20
Пометка Удаления	Булево	1
Ссылка	УИД	32
Предопределенный	Булево	1
Краткое Наименование	Строка	10

Объект «Зубная Формула Пациента» позволяет хранить в себе информацию о состоянии зубов конкретного пациента. Структура объекта «Зубная Формула Пациента» представлена в таблице 2.17.

Таблица 2.17 Структура объекта «Зубная Формула Пациента»

Наименование реквизита	Тип	Длина
Пациент	Ссылка	32
Номер Зуба	Ссылка	32
Тип Зуба	Строка	2
Состояние Основное	Строка	2
Состояние Вспомогательное	Строка	2
Подвижность	Строка	2
Глубина	Строка	2
Оголение	Строка	2
Возрастная Группа Зубов	Ссылка	32
Пользователь	Ссылка	32

Объект «Первичные И Санированные» позволяет хранить в себе отметки о первичном приеме, санации полости рта и законченно случае лечения для каждого пациента. Структура объекта «Первичные И Санированные» представлена в таблице 2.18.

Таблица 2.18 Структура объекта «Первичные и санированные»

Наименование реквизита	Тип	Длина
Пациент	Ссылка	32
Медицинский Документ	Ссылка	32
Санирован	Булево	1
Первичный	Булево	1
Направлен На Госпитализацию	Булево	1
Эпикриз	Булево	1
Период	Дата Время	-

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

Таблица 2.19 Структура объекта «Льготное Протезирование»

Наименование реквизита	Тип	Длина
Пациент	Ссылка	32
Медицинский Документ	Ссылка	32
Использование	Булево	1
Период	Дата Время	-

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

Таблица 2.20 Структура объекта «Схема Протеза»

Наименование реквизита	Тип	Длина
1	2	3
Пациент	Ссылка	32
Медицинский Документ	Ссылка	32
Номер Зуба	Строка	2
ПР	Строка	2
Тип Зуба	Строка	2
Пользователь	Ссылка	32
Количество Мостов	Число	3
Коронка В Протезе	Число	3
Литок В Протезе	Число	3
Фасетка В Протезе	Число	3
Отдельная Коронка	Число	3
Период	Дата Время	-

Взаимодействие данных объектов базы данных можно увидеть на рисунке 2.8.

Рис. 2.8 - Создаваемые объекты базы данных

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

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

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

3. Модернизация подсистемы «Медицина. Поликлиника»

3.1 Обоснование использования языка программирования и выбор СУБД

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

Классификация СУБД по модели данных представлена на рисунке 3.1

Рис. 3.1 - Классификация СУБД по модели данных

Иерархическая модель данных -- представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.

Классификация СУБД по степени распределенности представлена на рисунке 3.2.

Рис. 3.2 - Классификация СУБД по степени распределенности

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

Классификация по способу доступа к БД представлена на рисунке 3.3.

Рис. 3.3 - Классификация СУБД по способу доступа к БД

Платформа «Предприятие» поддерживает работу с пятью СУБД, одна из которых является файл-серверным вариантом. Поддерживаемые платформой СУБД представлены на рисунке 3.4.

Рис. 3.4 - Поддерживаемые платформой СУБД

При выборе СУБД Microsoft SQL Server, необходимо определиться с редакцией и вариантом лицензирования. Существует 2 варианта лицензирования - «на сервер» и «на ядро». Также СУБД выпускается в нескольких редакциях, наиболее применяемые из которых представлены на рисунке 3.5.

Рис. 3.5 - Редакции MS SQL Server

Редакция Expressраспространяется бесплатно, в расширенном варианте имеет графический инструмент настройки и управления - Management Studio и является идеальным вариантом для начинающих разработчиков и учебных учреждений. Она имеет ограничения на 1 используемое физическое ядро процессора и размер базы данных не более 4 Гб.

Редакции Standard имеет ограничение на 16 используемых физических ядер и не имеет ограничений на размеры БД. Использование ядер подключается на основе лицензирования, и цена на лицензию возрастает пропорционально количеству ядер - 1 ядро 28 000 рублей, 2 ядра - более 100 000 рублей.

Entеr price редакция не имеет ограничений на количество используемых ядер и размер базы данных, но имеет слишком высокую цену - более 400 000 рублей.

ПО Microsoft в варианте поставки Runtime поставляются по программе лицензирования Microsoft Independent Software Vendor (ISV) Royalty. Она действует для некоторых независимых разработчиков программного обеспечения, которые включают продукты и технологии Microsoft в свои программные решения. Одним из таких разработчиков является компания разработчик платформы «Предприятие». Функциональность продуктов компании Microsoft, входящих в интегрированное решение (вариант поставки Runtime), полностью аналогична функциональности ПО в обычной поставке. Все ограничения касаются только правил приобретения и использования лицензий конечным пользователем. Вариант редакции Runtime оказывается самым дешевым и эффективным применимо к задаче по сравнению со Standartи Enterprice[10].

Встроенный язык программирования в платформе «Предприятие» - язык программирования, который используется в семействе программ «Предприятие». Данный язык является предварительно компилируемым предметно-ориентированным языком высокого уровня. Средой исполнения языка является программная платформа «Предприятие». Визуальная среда разработки («Конфигуратор») является неотъемлемой частью пакета программ «Предприятие». Платформой предоставляется фиксированный набор базовых классов, ориентированных на решение типовых задач прикладной области: справочник, документ, журнал документов, перечисление, отчет, регистр и др. рисунке 3.6.

Рис. 3.6 - Базовые классы платформы «Предприятие»

На основании базовых классов средствами визуального конфигурирования можно создавать любое количество порождённых классов (возможность определить новый класс программно -- отсутствует). В терминах встроенного языка программирования такие классы называются объектами метаданных.

Основными видами объектов метаданных являются: Справочники, Документы, Отчеты, Обработки, Планы видов характеристик, Планы счетов, Планы видов расчета, Регистры сведений, Регистры накопления, Регистры расчета, Бизнес-процессы, Задачи[13].

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

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

Алгоритм обработки записи информации в форме зубной формулы представлен на рисунке 3.7.

Рис. 3.7 - Алгоритм работы модуля зубная формула

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

Схема интерфейса ввода текстовой информации (объективное исследование, назначенное лечение) представлена на рисунке 3.8.

Рис. 3.8 - Схема интерфейса ввода текстовой информации

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

На рисунке 3.9 представлена схема интерфейса для печати договора на платные услуги, на основе услуг, введенных в интерфейс для ввода списка услуг.

Рис. 3.9 - Схема интерфейса для печати договора на платные услуги

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

Алгоритм инициализации интерфейса шаблона медицинского документа изображен в диаграмме активности на рисунке 3.10.

Рис. 3.10 - Алгоритм инициализации интерфейса шаблона медицинского документа

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

Рис. 3.11 - Алгоритм работы пользователя в форме шаблона медицинского документа

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

Рис. 3.12 - Алгоритм выполнения проведения медицинского документа в форме шаблона медицинского документа

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

3.3 Руководство программиста

Платформа «Предприятие» поддерживает работу с MS SQL Server 2005 и 2008, однако рекомендуется использовать 2008R2. Можно использовать 32-х и 64-х разрядные версии. Рекомендуется базу данных размещать на дисковом массиве RAID10, из соображений отказоустойчивости и скорости записи/чтения.

Перед началом установки SQL 2008 скачайте и установите:

1. .Net Framework 3.5sp1

2. Windows Installer 4.5 (kb942288)

3. Power shell 2.0 (только для Windows XP/2003 - kb968930)

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

3.4 Руководство пользователя

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

Рис. 3.13 - Окно авторизации

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

Структура основного окна рабочего места врача рисунок 3.14 включает:

- панель навигации;

- панель разделов;

- панель действий;

- панель системных команд;

- рабочую область;

- информационную панель.

Рис. 3.14 - Вид основного окна рабочего места врача

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

Переход к форме «Формирование заказов» осуществляется через панель навигации формы обработки «Карта пациента» рисунок 3.15.

Рис. 3.15 - Общий вид формы «Формирование заказов»

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

Рис. 3.16 - Окно обработки «Сменное задание»

При первоначальном запуске «Контроля исполнения» необходимо произвести настройки при помощи обработки «Настройки контроля исполнения» рисунок 3.17.

Рис. 3.17 - Окно настройки контроля исполнения

После того как будут заданы врач, СМП и кабинет, дата планирования необходимо «Записать и закрыть», в верхней части формы "Сменное задание" надпись «<Врач не задан> + <СМП не задан> + <кабинет не задан>» заменится на заданные значения настроек рисунок 3.18.

Рис. 3.18 - Окно обработки «Сменное задание» после настройки

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

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

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

Рис. 3.19 - Окно планирования

Заключение

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

А также были решены основные задачи ВКР:

Проведен анализ технологических процессов на медицинском предприятии.

Проведен анализ базовой МИС «Медицина. Поликлиника».

Определены требования к МИС «Медицина. Поликлиника» (экономические, технические, социальные).

Выбрано и обосновано типовое аппаратно-программное обеспечение для МИС «Медицина. Поликлиника».

Разработано специальное алгоритмическое и программное обеспечение для необходимых программных средств для МИС «Медицина. Поликлиника».

Разработана инструкция пользователя и программиста для работы в ИС.

Список использованных источников

1. Гусев А.В. «Радиотехника» [Текст] / Гусев А.В. ежемес. журн. / -М: Изд. «Роспечать», вып: Медицинские информационные системы в России: текущее состояние, актуальные проблемы и тенденции развития. 2012. - 123 с.

2. Лебедев Г.С. Классификация медицинских информационных систем [Текст] / Г.С. Лебедев, Ю.Ю. Мухин, - «Информационные технологии в медицине. 2011-2012», 2012 - 402 с.

3. Лищук В.А «Медицинская и биологическая информатика» [Текст] / В.А. Лищук, С.В. Калин; РАМН - М: 2009 - 56 с.

4. Хирт А. Подробное руководство по SQL Server 2008 R2 для администраторов баз данных [Текст] / А. Хирт. -М: Microsoft, ISBN: 978-0-7695-4747-3, 2010 - 805 c.

5. 2-ая Стоматологическая поликлиника [Электронный ресурс]: - Электрон. текстовые дан. - Режим доступа: http://www.persons56.ru/article/515, свободный - Загл. с экрана.

6. Unified Modeling Language -- унифицированный язык моделирования [Электронный ресурс]: - Электрон. текстовые дан. и табл. дан. - Режим доступа: http://ru.wikipedia.org/wiki/UML, свободный - Загл. с экрана.

7. Информационно-аналитическая система «Антибиотик+» [Электронный ресурс]: - Электрон. текстовые дан. - Режим доступа: http://antibiotic-plus.ru/about_programm.php, свободный - Загл. с экрана.

8. КЛАДР -- ведомственный классификатор ФНС России [Электронный ресурс]: - Режим доступа: http://ru.wikipedia.org/wiki/КЛАДР - Загл. с экрана.

9. Медицина. Поликлиника [Электронный ресурс]: - Электрон. текстовые дан. - Режим доступа: http://solutions.1c.ru/catalog/clinic, свободный - Загл. с экрана.

10. МИС «Пациент» [Электронный ресурс]: - Электрон. текстовые дан. - Режим доступа: http://www.medotrade.ru/MIS-Patsiyent, свободный - Загл. с экрана.

11. О клинике [Электронный ресурс]: - Электрон. текстовые дан. и граф. дан. - Режим доступа: http://www.stomclinic2.ru/about/, свободный - Загл. с экрана.

Приложения

Приложение А

(обязательное)

Листинг программы

DROP PROCEDURE Recalculation;

-- SELECT recalculation

CREATE PROCEDURE Recalculation(IN NumberContractbigint UNSIGNED)

BEGIN

DECLARE done int DEFAULT 0;

DECLARE Value, pAllDept, pAllVolume, PayService, Pay float DEFAULT NULL;

DECLARE DateNow date;

DECLARE Contract bigint UNSIGNED;

DECLARE CounterValue CURSOR FOR (

SELECT

ROUND(SUM(c.Value) - r.AllVolume,

c.NumberContract

FROM

counter c,

receipt r

WHERE

r.NumberContract = c.NumberContract AND --

c.NumberContract = IFNULL(NumberContract, r.NumberContract)

GROUP BY

c.NumberContract);

DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1;

DECLARE EXIT HANDLER FOR SQLEXCEPTION

BEGIN

ROLLBACK;

SELECT END;

SELECT DATE_FORMAT(CURDATE(), '%Y-%m-%d') INTO DateNow FROM dual;

SELECT

IFNULL(MAX(p.PayOfPeriod), 0)

INTO

Pay

FROM

payofperiod p

WHERE

DateNow BETWEEN STR_TO_DATE(p.BeginPeriod, '%Y-%m-%d')

AND STR_TO_DATE(p.EndPeriod, '%Y-%m-%d');

IF Pay > 0 THEN

OPEN CounterValue;

REPEAT

FETCH CounterValue INTO Value, Contract;

IF NOT done THEN

SELECT IFNULL(SUM(tbl.payy), 0) INTO PayService FROM (SELECT p.CostService AS payy

FROM priceservice p,

bid b

WHERE p.NumberService NOT IN (SELECT p.NumberService FROM priceservice p, serviceanddetail s1 WHERE s1.NumberService = p.NumberService)

AND b.NumberService = p.NameService

AND b.NumberContract = 2

AND b.StatusPay = 0 --

AND b.StatusCheck = 0

UNION ALL

SELECT (p.CostService + SUM(p1.CostDetail * s.CountDetails)) AS payy

FROM priceservice p, serviceanddetail s, pricedetail p1, bid b

WHERE p.NumberService = s.NumberService

AND s.NumberDetail = p1.NumberDetail

AND b.NumberService = p.NumberService

AND b.NumberContract = 2

AND b.StatusPay = 0

AND b.StatusCheck = 0

GROUP BY p.NumberService) AS tbl;

UPDATE

receipt r

SET

r.DateLastPayment = DateNow,

r.AllVolume = r.AllVolume + Value,

r.AllDept = r.AllDept + Pay * Value + PayService

WHERE

r.NumberContract = Contract;

INSERT INTO receiptlog (NumberReceipt, DateLastPayment, AllVolume, AllDept)

SELECT r.NumberReceipt, r.DateLastPayment, r.AllVolume, r.AllDept FROM receipt r Where r.NumberContract = Contract;

IF (Pay * Value) > 0 THEN

INSERT INTO checkofperiod (NumberContract, Period, SumPeriod, VolumePeriod)

VALUES (Contract, DateNow, (Pay * Value), Value);

END IF;

UPDATE bid SET StatusCheck = 1 WHERE NumberContract = Contract;

END IF;

UNTIL done END REPEAT;

END IF;

Приложение Б

Листинг создания базы данных на My SQL

CREATE TABLE Contract (

NumberContractbigint UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,

LastNamevarchar(255) NOT NULL,

Name varchar(255) NOT NULL,

Patronymic varchar(255),

Indexx integer,

PhoneNumbervarchar(17) UNIQUE,

DateCreatedatetime NOT NULL,

DateEnddatetime NOT NULL,

CountPeople integer NOT NULL DEFAULT 1,

ID_Streetbigint UNSIGNED NOT NULL,

NumberHouse integer UNSIGNED NOT NULL,

Housing varchar(2),

NumberRoom integer UNSIGNED

) character SET utf8;

CREATE TABLE Street (

ID_Streetbigint UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,

NameStreetvarchar(255) NOT NULL

) character SET utf8;

-- USE `armcounters`;

CREATE TABLE CheckOfPeriod (

NumberCheckbigint UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,

NumberContractbigint UNSIGNED NOT NULL,

Period date NOT NULL,

SumPeriod float NOT NULL,

VolumePeriod float NOT NULL

) character SET utf8;

CREATE TABLE PayOfPeriod (

idint AUTO_INCREMENT PRIMARY KEY,

PayOfPeriod float NOT NULL,

BeginPeriod date NOT NULL,

EndPeriod date NOT NULL

) character SET utf8;

CREATE TABLE Counter (

NumberCounterbigint UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,

NumberContractbigint UNSIGNED NOT NULL,

DateInstall date NOT NULL,

DateCheck date NOT NULL,

Testimony int NOT NULL DEFAULT 0,

Code varchar(20) NOT NULL,

Value float UNSIGNED not null default 0

) character SET utf8;

CREATE TABLE Receipt (

NumberReceiptbigint UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,

NumberContractbigint UNSIGNED NOT NULL,

DateLastPayment date,

AllVolume float NOT NULL,

AllDept float NOT NULL DEFAULT 0

) character SET utf8;

CREATE TABLE Bid (

NumberBidbigint UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,

NumberContractbigint UNSIGNED NOT NULL,

NumberServicebigint UNSIGNED NOT NULL,

DateCreateBiddatetime NOT NULL,

StatusWork bool NOT NULL DEFAULT FALSE,

StatusPay bool NOT NULL DEFAULT FALSE,

StatusCheck bool NOT NULL DEFAULT FALSE

) character SET utf8;

CREATE TABLE PriceService (

NumberServicebigint UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,

NameServicevarchar(255) NOT NULL,

Description varchar(1000) NOT NULL DEFAULT '',

CostService float NOT NULL DEFAULT 0

) character SET utf8;

CREATE TABLE PriceDetail(

NumberDetailbigint UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,

NameDetailvarchar(255) NOT NULL,

CostDetail float NOT NULL DEFAULT 0,

RestDetailint(11) NOT NULL DEFAULT 0

) character SET utf8;

CREATE TABLE ContractLog (

Log bigint NOT NULL PRIMARY KEY AUTO_INCREMENT,

-- Date datetime NOT NULL DEFAULT NOW(),

Date TIMESTAMP DEFAULT CURRENT_TIMESTAMP not NULL,

NumberContractbigint UNSIGNED NOT NULL,

LastNamevarchar(255),

Name varchar(255),

Patronymic varchar(255),

Indexx integer,

PhoneNumbervarchar(17) UNIQUE,

DateCreatedatetime,

DateEnddatetime,

CountPeople integer,

ID_Streetbigint UNSIGNED,

NumberHouse integer UNSIGNED,

Housing varchar(2),

NumberRoom integer UNSIGNED

) character SET utf8;

CREATE TABLE ReceiptLog (

Log bigint NOT NULL PRIMARY KEY AUTO_INCREMENT,

-- Date datetime NOT NULL DEFAULT NOW(),

Date TIMESTAMP DEFAULT CURRENT_TIMESTAMP not NULL,

NumberReceiptbigint UNSIGNED NOT NULL,

DateLastPayment date,

AllVolume float,

AllDept float

) character SET utf8;

CREATE TABLE CounterLog (

Log bigint NOT NULL PRIMARY KEY AUTO_INCREMENT,

-- Date datetime NOT NULL DEFAULT NOW(),

Date TIMESTAMP DEFAULT CURRENT_TIMESTAMP not NULL,

NumberCounterbigint UNSIGNED NOT NULL,

DateInstall date,

DateCheck date,

Code varchar(20),

Value float UNSIGNED

) character SET utf8;

ALTER TABLE Contract ADD FOREIGN KEY (ID_Street) REFERENCES Street(ID_Street);

ALTER TABLE CheckOfPeriod ADD FOREIGN KEY (NumberContract) REFERENCES Contract(NumberContract);

-- ALTER TABLE CheckOfPeriod ADD FOREIGN KEY (Period) REFERENCES PayOfPeriod(Period);

ALTER TABLE Counter ADD FOREIGN KEY (NumberContract) REFERENCES Contract(NumberContract);

ALTER TABLE Receipt ADD FOREIGN KEY (NumberContract) REFERENCES Contract(NumberContract);

ALTER TABLE Bid ADD FOREIGN KEY (NumberContract) REFERENCES Contract(NumberContract);

ALTER TABLE Bid ADD FOREIGN KEY (NumberService) REFERENCES PriceService(NumberService);

ALTER TABLE ServiceAndDetail ADD FOREIGN KEY (NumberService) REFERENCES PriceService(NumberService) ON DELETE CASCADE;

Приложение В

Демонстрационный материал

Рис.В. 1 - Титульный лист

Рис. В.2 - Постановка цели и задач

Рис. В.3 - Схема последовательности действий при предоставлении государственной услуги

Рис. В.4 - Основные процессы работы поликлиники

Рис. В. 5 - Сравнительный анализ функциональных возможностей обзорных МИС

Рис. В.6. - Алгоритм формирования протокола «Медицина. Поликлиника»

Рис. В.7 - Конфигурация сервера

Рис. В.8 - Конфигурация рабочих станций

Рис. В.9 - Конфигурация беспроводной точки доступа

Рис. В.10 - Схема размещения оборудования

Рис. В.11 - Интерфейс модуля зубной формулы

Рис. В.12 - Схема интерфейса ввода текстовой информации

Рис. В.13 - Диаграмма взаимодействия основных классов подсистемы «Медицина. Поликлиника»

Рис. В.14 - Взаимодействие объекта базы данных

Рис. В.15 - Создаваемые объекты баз данных

Рис. В.16 - Алгоритм работы модуля зубная формула

Рис. В.17 - Вид основного окна рабочего места врача

Рис. В.18 - Общий вид «Формирование заказов»

Размещено на Allbest.ru

...