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

– порядок обращения пациента в организацию здравоохранения;

– порядок госпитализации и выписки пациента;

– права и обязанности пациента;

– порядок разрешения конфликтных ситуаций между организацией здравоохранения и пациентом;

– порядок предоставления информации о состоянии здоровья пациента;

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

– время работы организации здравоохранения и ее должностных лиц;

– информацию о перечне платных медицинских услуг и порядке их оказания;

– другие сведения, имеющие существенное значение для реализации прав пациента

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

Ниже приведены некоторые положения порядка госпитализации и выписки пациента в соответствии с постановлением Министерства здравоохранения Республики Беларусь

от 14.06.2002 № 32 «Об утверждении типовых правил внутреннего распорядка организации здравоохранения для пациентов».

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

– при выздоровлении больного;

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

– при необходимости перевода больного в другую организацию здравоохранения;

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

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

История болезни после выбытия пациента из стационара оформляется и сдается на хранение в медицинский архив организации здравоохранения.

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

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

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

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

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

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

Дети от 0 до 5 лет, беременные женщины госпитализируются в течение 48 часов с момента определения показаний.

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

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

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

Обеспечение однозначного толкования всеми категориями сотрудников учреждений здравоохранения медицинских документов достигается путем приведения их к единому виду и использования при их заполнении общепринятых справочников и кодификаторов, в том числе международных. На январь 2007 года Международная классификация болезней 10-го пересмотра (МКБ-10) является общепринятой классификацией для кодирования медицинских диагнозов, она разработана Всемирной организацией здравоохранения. МКБ-10 состоит из

21-го раздела, каждый из которых содержит подразделы с кодами заболеваний и состояний.

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

1.2 Описание существующих аналогов

На данный момент в мире разработано множество автоматизированных информационных систем различного назначения. Автоматизированную информационную систему в узком смысле рассматривают как программно-аппаратную систему, предназначенную для автоматизации целенаправленной деятельности конечных пользователей, обеспечивающую, в соответствии с заложенной в нее логикой обработки, возможность получения, модификации и хранения информации. Многие из них можно отнести к аналогам, так как они в некоторой степени выполняют функции, которые необходимо реализовать в разрабатываемой подсистеме. Например, они осуществляют сбор, хранение и управление информацией, позволяют осуществлять поиск в базе данных информации, запрашиваемой пользователем, формируют отчеты, многие из них предоставляют вполне удобный и понятный интерфейс. В силу того, что реализовывать и сопровождать проекты комплексной автоматизации системы здравоохранения в республике одна организация физически не способна, в Республике Беларусь функционируют порядка десяти таких организаций. На данный момент часть из них уже имеют подсистему, выполняющую те же функции, что и разрабатываемая в данном дипломном проекте. Однако, для верного функционирования подсистемы необходимо, чтобы она была согласована с другими подсистемами и всей структурой системы, функциональность которой расширяется. Такая согласованность достигается главным образом на уровне внутренней реализации автоматизированной информационной системы, что для ГУ «Республиканский центр медицинских технологий, информатизации, управления и экономики здравоохранения» обуславливает необходимость разработки своей собственной подсистемы. В сущности, разрабатываемая подсистема «Автоматизированное средство учета госпитализированных больных» будет отличаться от аналогов лишь интерфейсом приложения, частично структурой БД и внутренней реализацией.

1.3 Цели и задачи создания ПО

Целью создания подсистемы «Автоматизированное средство учета госпитализированных больных» является накопление, хранение и многоаспектная обработка формализованной информации о субъекте госпитализации (пациенте), данных о причинах и течении процесса госпитализации взрослого и детского населения Республики Беларусь.

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

– учет и накопление в базе данных паспортно-демографических сведений о госпитализированных пациентах;

– учет и накопление данных о динамике процесса лечения во время нахождения в стационаре по каждому пациенту;

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

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

– формирование и печать отчета о заболеваемости населения, зарегестрированного в амбулаторно-поликлиническом учреждении, как в рамках всего учреждения, так и в разрезе его отделений, участков;

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

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

2 Проектирование задачи

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

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

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

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

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

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

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

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

– каждый описательный реквизит должен функционально полно зависеть от ключа, т.е. каждому значению ключа соответствует только одно значение описательного реквизита;

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

– каждый описательный реквизит не может зависеть от ключа транзитивно, т.е. через другой промежуточный реквизит [12].

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

Упрощенная структура базы данных представлена на рисунке 2.1 в виде модели данных «Сущность - связь».

Рисунок 2.1 - Модель данных «Сущность - связь»

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

2.2 Проектирование приложения

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

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

МКБ-10, характера заболевания.

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

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

Принцип работы программы отображен на диаграмме деятельности (приложение Б).

3 Реализация

3.1 Выбор среды реализации БД

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

При разработке отечественных комплексных медицинских информационных систем (КМИС) в основном применяются следующие СУБД: Oracle, IBM DB 2 и Informix, MS SQL Server, Cache, Lotus Notes / Domino, MySQL и некоторые другие. Преимущественно используется СУБД Microsoft SQL Server, чья доля составляет 62%.

В 2004 году Гусев А.В., кандидат технических наук, старший инженер-программист ОАО "Кондопога" и Дмитриев А.Г., инженер-программист ОАО "Кондопога" проводили исследования, целью которых было изучение на практике двух наиболее ярких представителей СУБД в медицинской предметной области и определение преимуществ и недостатков коммерческих и свободно-распространяемых СУБД. При этом в качестве образца коммерческой СУБД было выбрано программное обеспечение Microsoft SQL Server версий 7.0 и 2000, а в качестве свободно-распространяемой СУБД была выбрана MySQL версии 4.0.21.

Рассмотрим результаты исследования. Для этого процитируем важнейшие из предложенных показателей и их особенности для КМИС:

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

MySQL версии 4.0.21, в отличие от Microsoft SQL Server, не поддерживает ни триггеры, ни хранимые процедуры, что значительно усложняет ее использование, так как в приложениях системы большую часть необходимых проверок введенных данных и всевозможных блокировок, а также обеспечение целостности базы данных приходится выполнять на уровне клиентского приложения, что очень усложняет процесс создания и эксплуатации КМИС.

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

Таблица 3.1 - Особенности разработки приложений

В этом разделе MySQL версии 4.0.21, по сравнению с Microsoft SQL Server, также значительно проигрывает. Такие возможности Microsoft SQL Server, как схема БД, более качественная многоязыковая поддержка, развитые средства визуального проектирования значительно облегчают процесс моделирования БД и создание приложений для нее. Это, в свою очередь, ведет к повышению качества КМИС и снижению себестоимости ее производства.

Перечень операционных систем, под управлением которых способна работать СУБД. В этом разделе, безусловно, лидирует MySQL, которая способна работать на большинстве из имеющихся на настоящее время операционных систем: Linux, Windows 95/98/NT/2000/XP, Solaris 2.9, FreeBSD 4.x ELF, Mac OS X v10.2, Novell NetWare 6, SCO OpenUnix 8.0. Некоторые из них имеют значительно более низкую стоимость, чем продукты фирмы Microsoft, что, конечно, ведет к снижению затрат при внедрении КМИС. Тогда как MS SQL Server способна работать лишь на Windows NT, 2000.

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

Как видно из таблицы 3.2, требования к технической характеристике сервера у MySQL значительно ниже, чем у Microsoft SQL Server. За счет этого стоимость внедрения КМИС может быть в некоторой степени снижена.

Таблица 3.2 - Минимальные требования к серверу

Производительность. Этот показатель является одним из основных факторов, влияющих на качество работы КМИС. Специфика медицинской информационной системы состоит в применении объектно-реляционного подхода. При этом реляционной составляющей отведена второстепенная роль. В ходе изучения практического опыта использования этого подхода было выявлено, что реляционная СУБД редко обслуживает сразу несколько запросов от пользователей, чаще все в единицу времени выполняются запросы от 1-2 пользователей, крайне редко - 3-4 пользователей. Применение качественного проектирования модели реляционной БД и современных СУБД позволяет выполнять запросы даже на больших таблицах с очень малым временем отклика. Специфика медицинской деятельности приводит к тому, что в системе редко исполняются запросы вида select * from <tablename>, когда необходима обработка всей таблицы и передача по сети больших объемов данных. Чаще всего используются либо запросы за агрегированной информацией, либо запросы к определенной выборке. Все вышесказанное определило основной интерес исследования: изучить, насколько быстро исполняются запросы, являющиеся наиболее показательными представителями основных видов запросов в медицинских информационных системах, а также изучить зафиксированные в моменты исполнения запросов показатели загрузки процессоров. В результате исследований был сделан вывод о том, что практически по всем видам запросов СУБД MS SQL Server выполняет их значительно быстрее, причем эта разница возрастает в случае применения настоящих серверных платформ, особенно - последних версий [13].

По результатам этого исследования, разумеется, нельзя однозначно судить о приоритете СУБД MS SQL Server над MySQL. Однако изучение результатов, полученных в данном тестировании, позволяет сделать вывод о значительно более высокой скорости работы СУБД MS SQL Server, как наиболее распространенного представителя коммерческих СУБД. Кроме того, следует отметить выдающиеся возможности администрирования и обслуживания СУБД MS SQL Server. Аналогичные по функциональному назначению средства, имеющиеся для СУБД MySQL, значительно уступают в своих возможностях средствам MS SQL Server. Однако не следует забывать, что СУБД MySQL - полностью бесплатный продукт, готовый к использованию на абсолютно законных основаниях. Анализируя все вышесказанное, можно сделать вывод о том, что в настоящее время решающую роль в медицинской предметной области может играть не какие-то конкретные параметры СУБД, такие как устойчивость или производительность, а совсем другие, относящиеся скорее к сфере субъектных моментов. Основные из них - это доступность технической поддержки, регулярность появления новых версий и выпуска так называемых пакетов исправлений, наличие (в том числе в сети Internet) русскоязычной и подробной документации, профессионализм разработчиков.

Таким образом, в качестве средства проектирования базы данных была выбрана СУБД MS SQL Server 2000. Эта СУБД поддерживает: тиражирование данных, параллельную обработку, создание и обработку больших баз данных на недорогих аппаратных платформах, отличается простотой управления и использования.

Средством, связывающим клиента с сервером, является язык SQL (Structured Query Language) - язык структурированных запросов. Он позволяет:

– создавать базы данных и таблицы с полным описанием их структуры;

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

– выполнять простые и сложные запросы.

3.2 Физическая структура БД

База данных состоит из 19 таблиц, из которых 14 являются справочными. Таблицы-справочники отличаются минимальным количеством внешних ключей (чаще всего не имеют внешних ключей вообще) и характером содержащейся в них информации. К ним относятся следующие таблицы: spr_city (справочник городов), spr_street (справочник улиц), spr_region (список областей), spr_busy (список занятостей пациентов), spr_office (список учреждений здравоохранения РБ), spr_otdel (список отделов лечебно-поликлинических учреждений), spr_otdel_stac (список отделов стационаров), spr_uch (справочник участков, внутри отделов поликлиники), spr_doctor (справочник врачей поликлиники), spr_class (список классов заболеваний по МКБ-10), spr_mkb (список заболеваний и их кодировок по МКБ-10), spr_char_bol (список типов заболеваний), spr_close_case (справочник причен закрытия карт пациентов), spr_case_hosp (виды госпитализации).

Другие таблицы БД: pacient_inf (содержит информацию о пациентах поликлиники), pacient_disp (содержит информацию о пациентах, находящихся на диспансерном учете), pacient_hosp (содердит информацию о случаях госпитализации пациентов), pacient_hosp_diag (содержит информацию о поставленных госпитализированному пациенту диагнозах), pacient_kategor (содержит информацию о пациентах, относящихся к определенной социальной категории).

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

Таблица 3.3 - Структура таблицы pacient_inf

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

Таблица 3.4 - Структура таблицы pacient_hosp

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

Таблица 3.5 - Структура таблицы pacient_hosp_diag

3.3 Выбор среды реализации приложения

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

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

– качеством визуальной среды разработки;

– скоростью работы компилятора и быстродействием откомпилированных программ;

– мощностью языка программирования и его сложностью;

– гибкостью и масштабируемостью используемой архитектуры баз данных;

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

Обычно, визуальная среда разработки состоит из трех взаимосвязанных компонентов: редактора, отладчика и конструктора форм. В любом из современных инструментов ускоренной разработки приложений (Rapid Application Development - RAD) эти три компонента должны гармонично взаимодействовать друг с другом. При работе в конструкторе форм IDE Delphi неявно генерирует программный код тех компонентов, которые размещаются или на них обрабатываются. В окне редактора в код автоматически созданной программы можно внести необходимые дополнения, определяющие специфическое поведение данного приложения. Здесь же, в окне редактора, можно отладить код, внося точки останова, точки просмотра (watches).

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

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

В Delphi определены шесть открытых интерфейсов: Tool Interface, Design Interface, Expert Interface, File Interface, Edit Interface и Version Control Interface.

Design Interface (модуль DsgnIntf.pas) предоставляет средства для создания редакторов свойств и редакторов компонентов. Редактор свойств контролирует поведение инспектора объектов при попытке изменить значение соответствующего свойства, а редактор компонента активизируется при двойном нажатии левой кнопки мыши на изображении помещенного на форму компонента.

Version Control Interface (модуль VCSIntf.pas) предназначен для создания систем контроля версий. Начиная с версии 2.0, Delphi поддерживает интегрированную систему контроля версий Intersolv PVCS, поэтому в большинстве случаев в разработке собственной системы нет необходимости.

File Interface (модуль FileIntf.pas) позволяет переопределить рабочую файловую систему IDE, что дает возможность выбора собственного способа хранения файлов.

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

Tool Interface (модуль ToolIntf.pas) предоставляет разработчикам средства для получения общей информации о состоянии IDE и выполнения таких действий, как открытие, сохранение и закрытие проектов и отдельных файлов, создание модуля, получение информации о текущем проекте (число модулей и форм, их имена и так далее), регистрация файловой системы, организация интерфейсов к отдельным модулям и другие действия. Кроме того, Tool Interface предоставляет средства доступа к главному меню IDE Delphi, позволяя встраивать в него дополнительные пункты.

Expert Interface (модуль ExptIntf.pas) представляет собой основу для создания экспертов - программных модулей, встраиваемых в IDE c целью расширения ее функциональности. В качестве примера эксперта можно привести входящий в Delphi Database Form Wizard, выполняющий генерацию формы для просмотра и изменения содержимого таблицы БД.

Программы, написанные на языке Delphi (Object Pascal), являются объектно-ориентированными. В этих программах происходит обработка событий, наступающих в ходе выполнения, создаются объекты.

Для построения отчетов был выбран набор компонентов FastReport 4 VCL, который представляет собой сочетание дизайнера, генератора и средства просмотра отчетов. На сегодняшний день FastReport стал фактическим стандартом для создания отчётности как в узкоспециализированных областях, так и в программах для корпораций, малого и среднего бизнеса. Его преимуществами являются:

? встроенный дизайнер диалогов для запроса параметров перед построением отчета, а также интерпретатор макроязыков (C++Script, PascalScript, BasicScript, JScript) для нестандартной обработки данных, которые позволяют разрабатывать отчеты любой сложности;

? создание отчётов для матричных принтеров и дальнейшего скоростного вывода, что особо востребовано в корпоративных задачах;

? рекордно высокая скорость формирования отчетов;

? малый размер - FastReport добавляет к приложению меньше килобайт, чем любой другой генератор отчетов со сравнимой функциональностью;

? FastReport не требует дополнительных DLL и органично встраивается в .EXE-приложение;

? FastReport поставляется с полным исходным кодом. Вы можете адаптировать его под собственные нужды;

? FastReport содержит полный набор документации (руководство пользователя, руководство программиста, руководство разработчика компонентов, руководство по встроенному языку) на русском языке общим объемом свыше 400 страниц.

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

3.4 Физическая структура приложения

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

Разработанное ПС состоит из cледющих модулей:

– DBModule (осуществляет подключение к БД);

– UhospMenu (главная форма программы, отображающаяся при загрузке);

– UsettingForm (форма, позволяющая подключать другие БД из приложения);

– UpacientCardCab (предоставляет удобный доступ к информации о пациентах, зарегистрированных в поликлинике);

– DBPacientCardCab (содержит набор компонентов, связанных с процедурами и функциями БД, необходимых для работы модуля UPacientCardCab);

– Uhospital (предоставляет удобный доступ к информации о фактах госпитализации пациентов поликлиники);

– DBHospital (содержит набор компонентов, связанных с процедурами и функциями БД, необходимых для работы модулей Uhospital, UhospitalSelect);

– UhospitalSelect (позволяет добавлять и редактировать данные в журнале госпитализации);

– UhospitalDiag (позволяет осуществить удобный ввод диагноза согласно кодировке МКБ-10 и характера заболевания);

– UMKB (предоставляет список заболеваний по МКБ-10);

– UhospRepZabol (позволяет создавать отчеты о числе заболеваний, зарегистрированных в стационарах);

– UhospQuery (обрабатывает запросы пользователя к БД);

– Uwait ();

– UMKBInputFrame;

– UperiodFrame.

Наиболее важными модулями являются: UpacientCardCab, Uhospital, UhospitalSelect, UrepZabol, UhospQuery.

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

– procedure FormCreate(Sender: TObject); //создает объект класса Tf_PacientCardCabinet и TDMPacientCardCab, описание которого содержится в модуле DBPacietnCardCab;

– function GetPacient(var Pacient_id:int64):TmodalResult; //функция вывода формы выбора пациента, выходной параметр Pacient_id ? идентификатор выбранного пациента;

– procedure btn_FindPacientClick(Sender: TObject); //реагирует на нажатие кнопки «Поиск», проверяет корректность введенных параметров поиска, запускает поиск, после осуществления поиска очищает поля ввода данных;

– procedure FillParams; //заполняет параметры хранимой процедуры БД pacient_inf_search значениями из полей ввода данных;

– procedure Tf_PacientCardCabinet.Search; //после заполнения параметров запускает хранимую процедуру БД pacient_inf_search, выводит результаты поиска;

– procedure Tf_PacientCardCabinet.SelectPacient; //записывает в поле pacient_id рассматриваемого класса значение идентификатора пациента, выбранного из списка пациентов, сформированного по критериям поиска, создает объект класса TfHospital.

В модуле Uhospital содержится описание класса TfHospital. Форма модуля содержит поле, в котором отображается информация из картотеки о выбранном пациенте, таблицу, содержащую информацию о случаях госпитализации пациента, две таблицы, в которых отображаются поставленные пациенту диагнозы по каждому случаю госпитализации, и кнопки «Новый», «Изменить», «Удалить». Ниже перечислены наиболее значительные для работы модуля процедуры и функции:

– procedure FormCreate(Sender: TObject); //создает объект класса TDMHospital;

– procedure btn_deleteClick(Sender: TObject); //реагирует на нажатие кнопки «Удалить», заполняет параметры и выполняет хранимую процедуру БД pacient_hosp_delete;

– procedure btn_newClick(Sender: TObject); // реагирует на нажатие кнопки «Новый», создает пустую запись в таблице БД pacient_hosp, вызывает функцию HospitalSelectShow модуля UhospitalSelect и передает ей идентификатор созданной пустой записи в таблице;

– procedure TfHospital.btn_editClick(Sender: TObject); //реагирует на нажатие кнопки «Изменить», вызывает функцию HospitalSelectShow модуля UhospitalSelect и передает ей идентификатор выбранного случая госпитализации;

– procedure TfHospital.btn_searchClick(Sender: TObject); //возвращает к списку пациентов.

В модуле UhospitalSelect содержится описание класса TfHospitalSelect. Форма модуля содержит поля, необходимые для регистрации случая госпитализации, таблицу, в которой отображаются уже поставленные диагнозы, и кнопки «Сохранить», «Добавить», «Отмена», «Удалить», «Изменить», «Диагноз (Код МКБ-10)». Ниже перечислены наиболее значительные для работы модуля процедуры и функции:

– function HospitalSelectShow(pac_id:Int64; hosp_id:integer; typ:Integer):integer; //создает объект класса TfHospitalSelect, присваивает его полям значения, передаваемые из модуля Uhospital;

– procedure TfHospitalSelect.FormShow(Sender: TObject); //открывает процедуры БД, необходимые для заполнения компонентов формы, вызывает процедуры DiagnozSelect, FillComponents, EnableButtons (регулирует доступность компонентов на форме);

– procedure TfHospitalSelect.DiagnozSelect; //вызывает процедуру БД pacient_hosp_diag_select, передавая ей параметр @hosp_id, необходимую для отображения поставленных диагнозов во течение времени нахождения в стационаре по данному случаю госпитализации пациента;

– procedure TfHospitalSelect.FillComponents; //заполняет компоненты формы значениями из БД по выбранному факту госпитализации;

– procedure btn_saveClick(Sender: TObject); //реагирует на нажатие кнопкки «Сохранить», проверяет на корректность введенные параметры, заполняет и выполняет хранимую процедуру БД pacient_hosp_update;

– procedure TfHospitalSelect.btn_DiagDelClick(Sender: TObject); //реагирует на нажатие кнопки «Удалить», удаляет выбранный диагноз из списка поставленных диагнозов;

– procedure TfHospitalSelect.btn_cancelClick(Sender: TObject); //реагирует на нажатие кнопки «Отмена», не сохраняет изменений и удаляет пустую запись из таблицы БД pacietn_hosp, если она была создана.

4 Описание применения

Для того, чтобы начать пользоваться программой, нужно щелкнуть по ее ярлыку или исполняющему файлу «Hospital.exe». После этого будет открыта главная форма программы, отображающая главное меню программы (рисунок 4.1).

Рисунок 4.1 - Главная форма программы

При переходе в пункт главного меню «Журнал» отображается электронная картотека пациентов, зарегистрированных в амбулаторно-поликлиническом учреждении здравоохранения (рисунок 4.2).

Рисунок 4.2 - Картотека пациентов

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

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

Рисунок 4.3 - «Журнал госпитализации» выбранного пациента

Кнопки «Новый», «Изменить», «Удалить» выполняяют соответствующие их названиям действия над записями в «Журнале госпитализации» пациента. При добавлении нового случая госпитализации или изменении уже существующего (например, необходимо внести дополнительный диагноз) отображается форма, содержащая поля-критерии, которые неоходимо заполнить (рисунок 4.4). Некоторые поля имеют значение по умолчанию, например, в поле «Направляющее медицинское учреждение» по умолчанию устанавливается наименование поликлиники, база данных которой подключена к приложению, поле «Дата госпитализации» устанавливается в текущую дату. Однако, эти поля можно изменять. Значение по умолчанию предусмотрено лишь для удобства, чтобы ускорить процесс регистрации/изменения случая госпитализации.

Рисунок 4.4 - Добавление/редактирование данных в «Журнале госпитализации»

Кнопка «Удалить диагноз» предназначена для удаления одного из диагнозов. При ее нажатии появится сообщение, запрашивающее подстверждение на удаление. Кнопка «Диагноз (Код МКБ-10)» предназначена для добавления в список нового диагноза. При ее нажатии на экране монитора отображается форма (рисунок 4.5), компоненты которой позволяют внести в БД характиристики заболевания.

Рисунок 4.5 - Форма ввода характеристик поставленного диагноза

В верхней части формы имеется поле «Код МКБ диагноза», в которое необходимо ввести код заболевания. Для выбора наименования заболевания и его кодировки из списка заболеваний классификатора МКБ-10 предусмотрена форма, отображенная на рисунке 4.6. Доступ к ней осуществляется путем нажатия на изображение справочника, расположенного справа от поля ввода диагноза.

Рисунок 4.6 - Встроенный справочник МКБ-10

При нажатии в главном меню на пункт «Отчеты» пользователю предоставляется два вида отчетов: «Отчет о числе заболеваний, зарегистрированных в поликлинике» (рисунок 4.7), который содержит перечень заболеваний, зарегестрированных в поликлинике за отчетный период и количество болеющих этими заболеваниями, разбитое по возрастным группам, и «Запросы по госпитализации» (рисунок 4.8).