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

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

РЕФЕРАТ

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

Рисунков - 18.

Таблиц - 40.

Литературных источников - 38.

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

ГЛАВА 1. ОБЗОР МЕДИЦИНСКИХ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1 Классификация медицинских автоматизированных информационных систем

1.1.1 Административно-хозяйственные медицинские системы

1.1.2 Системы информационного и библиографического поиска

1.1.3 Системы для лабораторных и диагностических исследований

1.1.4 Экспертные медицинские системы

1.1.5 Обучающие системы

1.1.6 Интегрированные системы

1.2 Обзор медицинских систем

1.3 Система управления госпиталем MedTrak

1.3.1 Обзор системы MedTrak

1.3.2 Основные особенности системы MedTrak

1.3.3 Электронная медицинская карта системы MedTrak

1.4 Техническое задание

ГЛАВА 2. АНАЛИЗ И МОДЕЛИРОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ «РЕГИСТРАТУРА

2.1 Выбор модели данных

2.2 Разработка структуры баз данных

2.3 Анализ и выбор инструментальных средств

2.3.1 Требования к составу и параметрам вычислительной системы

2.3.2 Требования к информационной программной совместимости

2.3.3 Обоснование выбора среды программирования

2.3.4 Обоснование выбора системы управления базами данных

ГЛАВА 3. ИСПЫТАНИЕ И ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ «РЕГИСТРАТУРА»

3.1 Испытание и тестирование АС «РЕГИСТРАТУРА

3.2 Инструкция пользователя

3.3 Экономическое обоснование эффективности внедрения АС "Регистратура"

3.3.1 Описание характеристик продукта

3.3.2 Особенности товара

3.3.3 Система сервиса

3.3.4 Гарантии и защита потребительских прав

3.3.5 Исследование и анализ рынков сбыта

3.3.5.1 Маркетинговые исследования рынка сбыта АС «Регистратура»

3.3.5.2 Параметрическая сегментация рынка

3.3.5.3 Стратегия маркетинга

3.3.6 Оценка риска и страхование

3.3.7 Оценка затрат на разработку программного продукта

3.3.7.1 Определение потребности в материальных и трудовых ресурсах

3.3.7.2 Расчет себестоимости и договорной цены программного продукта

3.3.7.3 Разработка финансового плана

3.3.8 Безопасность жизнедеятельности. Характеристика ВЦ

3.3.9 Гражданская оборона

ЗАКЛЮЧЕНИЕ

АННОТАЦИЯ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

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

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

ГЛАВА 1. ОБЗОР МЕДИЦИНСКИХ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1 Классификация медицинских автоматизированных информационных систем

Административно-хозяйственные медицинские системы

Системы информационного и библиографического поиска

Системы для лабораторных и диагностических исследований

Экспертные системы

Обучающие системы

Интегрированные системы (учреждения)

1.1.1 Административно-хозяйственные медицинские системы

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

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

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

К административно-хозяйственным медицинским системам относятся:

бухгалтерские системы;

системы учета лекарственных препаратов

системы регистрации пациентов;

системы регистрации медицинской документации;

системы автоматизации делопроизводства;

системы клинического обследования;

другие.

Каждая система предусматривает решение определенных задач.

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

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

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

обработка медицинских и хозяйственных статистических данных.

Системы автоматизации делопроизводства направлены на решение задач:

возможность рассылки электронных документов;

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

подготовка отчетных документов.

1.1.2 Системы информационного и библиографического поиска

Системы информационного и библиографического поиска призваны решать следующие задачи:

создание и ведение электронного каталога;

автоматическая идентификация изданий и читателей;

подготовка реферативной информации;

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

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

1.1.3 Системы для лабораторных и диагностических исследований

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

В связи с бурным развитием в последние годы коммуникационных технологий особенно распространенными среди диагностических систем становятся так называемые РАСS-системы (Рiсture Archiving and Control Systems - системы, предназначенные для обработки, хранения и получения удобного доступа к изображениям). Достижения электроники предоставляют врачам широкий спектр различного специализированного медицинского оборудования, разработанного для диагностики и мониторинга состояния пациента и данных биопсий. Это направление выделило науку «телепатологию».

Так, например, система лабораторных анализаторов решает задачи:

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

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

1.1.4 Экспертные медицинские системы

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

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

1.1.5 Обучающие системы

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

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

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

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

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

1.1.6 Интегрированные системы

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

задач административно-хозяйственного и финансового характера;

задач поддержки лечебно-диагностических мероприятий;

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

задач информационной поддержки оценки эффективности лечения;

задачи справочно-информационного и библиографического обслуживания медицинского персонала.

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

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

1.2 Обзор медицинских систем

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

Система управления госпиталем «MedTrak»[13];

Госпитальная информационная система «Авиценна»[14];

Программный комплекс «Управление поликлиникой»[15];

Медицинская информационная система «Амулет-клиника»[16];

Система «MedWork» компании Master Labs[17].

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

1.3 Система управления госпиталем MedTrak

1.3.1 Обзор системы MedTrak

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

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

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

Таблица 1.1

Подсистемы системы управления госпиталем MedTrak

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

* требует адаптации к украинским стандартам

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

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

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

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

Среда разработки, выбранная фирмой Trak Systems для продукта MedTrak, называется Cache'. Cache' - продукт фирмы InterSystems Corporation, США. Это постреляционная Система Управления Базами Данных, которая эволюционировала из М-технологии. Интересно заметить, что более 80% всех программных разработок для медицины было сделано на базе М-технологии.

1.3.2 Основные особенности системы MedTrak

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

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

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

1.3.3 Электронная медицинская карта системы MedTrak

Врачи, медсестры и другой персонал - все они заносят данные в электронную медицинскую карту(ЭМК). ЭМК состоит из различных разделов, вот основные из них:

Данные о госпитализации пациента

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

История болезни пациента

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

MedTrak поддерживает множество типов диагнозов для каждого обращения пациента - Диагноз при Госпитализации, Предполагаемый Диагноз, Конечный (Заключительный) Диагноз и т.д. Диагнозы могут быть основаны на ICD-9, ICD-10 (международный классификатор диагнозов) или каком-либо другом определенном пользователем справочнике.

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

Хирургические отчеты

Записи о хирургических вмешательствах, включая все хирургические процедуры, также вводятся в карту. Основой этих данных может служить ICD-9CM, ICD-10, CPT или другой определяемый пользователем справочник. Могут вводиться записи об использованных материалах и пост-операционном периоде.

Акушерские отчеты

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

Записи дантиста

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

Основные жалобы

Основные жалобы пациента могут быть зарегистрированы в ЭМК. Делается это путем выбора из списка сначала нужной части тела, а затем вида жалобы. Характер, начало и/или продолжительность жалобы также могут быть зарегистрированы. Врач может также делать примечания, касающиеся данной жалобы.

Текущее заболевание

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

Субъективные наблюдения

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

Анамнез

Секция анамнеза ЭМК фиксирует информацию о том, были ли у пациента операции, аллергии, о предыдущих видах лечения и заболеваниях (информация основывается на выбранном справочнике заболеваний, например, ICD9-CM или ICD-10) вместе с датой начала, продолжительностью и примечаниями в свободной текстовой форме.

Семейная история болезни

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

Социальная история

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

Физические измерения

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

Осмотр жизненных систем

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

Объективные результаты обследования

Отдел объективных результатов исследования в ЭМК позволяет пользователю вводить их в свободной текстовой форме.

Заметки о перемещениях

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

Результаты назначений

Все назначения, которые требуют результатов (например, анализы), отображены в этой секции ЭМК. Назначения перечислены с одной строкой для результатов. Если результаты уже получены, отображается отметка о выполнении. Выбрав из списка назначение с отметкой “результат получен”, Вы сможете просмотреть полный результат на экране.

Диагноз

Диагноз, поставленный пациенту, регистрируется в секции диагноза в ЭМК. Диагноз может быть выбран из списка диагнозов. Напротив диагноза может быть сделана запись о стадии заболевания (например, в случае рака), о протекании заболевания и типе диагноза (начальный диагноз, диагноз при поступлении больного, окончательный диагноз и т.д.). Все типы диагнозов собраны в пользовательском справочнике. Также могут быть добавлены комментарии, если недостаточно данных из справочников.

Жизненные функции организма

Температура тела, кровяное давление, пульс и объем легких записываются и отображаются на дисплее в этой секции ЭМК.

Прием/отторжение

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

Перемещения

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

Отсутствие

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

Кровь

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

Примечания

Здесь медсестры могут осуществлять запись примечаний в ЭМК, основываясь на диагнозе врача.

Лечение

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

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

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

1.4Техническое задание

Основными задачами работы являются:

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

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

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

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

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

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

Предлагается разработать программное обеспечение для ведения автоматизированного учета пациентов в регистратуре поликлиники(в дальнейшем АС «Регистратура»). Эта программа должна выполнять следующие задачи:

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

Просмотр и редактирование информации о пациенте.

Быстрый поиск данных о пациенте.

Хранение лечебно-диагностической информации полученной в результате осмотра пациента.

Подготовка и выдача медицинских заключений о состоянии здоровья пациентов;

Иметь интуитивно-понятный интерфейс;

Защита информации от несанкционированного доступа;

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

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

Выводы по разделу

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

ГЛАВА 2. АНАЛИЗ И МОДЕЛИРОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ «РЕГИСТРАТУРА»

2.1 Выбор модели данных

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

Иерархические СУБД

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

Одной из наиболее популярных иерархических СУБД была Information Management System (IMS) компании IBM, появившаяся в 1968 году. Ниже перечислены преимущества IMS и реализованной в ней иерархической модели.

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

Использование отношений предок/потомок. СУБД IMS позволяла легко представлять отношения предок/потомок, например: "А является частью В" или "А владеет В".

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

СУБД IMS все ещё является одной из наиболее распространённых СУБД для больших ЭВМ компании IBM. Доля мэйнфреймов этой компании, на которых используется данная СУБД, превышает 25%

Сетевые базы данных

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

В связи с этим для таких приложений, как обработка заказов, была разработана новая сетевая модель данных. Она являлась улучшенной иерархической моделью, в которой одна запись могла участвовать в нескольких отношениях предок/потомок. В сетевой модели такие отношения назывались множествами. В 1971 году на конференции по языкам систем данных был опубликован официальный стандарт сетевых баз данных, который известен как модель CODASYL. Компания IBM не стала разрабатывать собственную сетевую СУБД и вместо этого продолжала наращивать возможность IMS. Но в 70-х годах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность.

Сетевые базы данных обладали рядом преимуществ:

Гибкость. Множественные отношения предок/потомок позволяли сетевой базе данных хранить данные, структура которых была сложнее простой иерархии.

Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.

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

Конечно, у сетевых баз данных были недостатки. Как и иерархические базы данных, сетевые базе данных были очень жесткими. Наборы отношений и структуру записей приходилось задавать наперёд. Изменение структуры базы данных обычно означало перестройку всей базы данных.

Как иерархическая, так и сетевая база данных были инструментами программистов. Чтобы получить ответ на вопрос типа "Какой товар наиболее часто заказывает компания Acme Manufacturing?", программисту приходилось писать программу для навигации по базе данных. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.

Реляционная модель данных

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

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

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

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

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

Таблицы

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

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

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

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

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

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

Первичные ключи

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

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

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

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) не была обеспечена явным образом их поддержка. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи, однако в самих СУБД не было возможности определить для таблицы первичный ключ. И только в СУБД DB2 Version 2, появившейся в апреле 1988 года, компания IBM реализовала поддержку первичных ключей. После этого подобная поддержка была добавлена в стандарт ANSI/ISO.

Отношения предок/потомок

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

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

Внешние ключи

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

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

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

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

Внешние ключи являются неотъемлемой частью реляционной модели, поскольку реализуют отношения между таблицами базы данных. К несчастью, как и в случае с первичными ключами, поддержка внешних ключей отсутствовала в первых реляционных СУБД. Она была введена в системе DB2 Version 2 и теперь имеется во всех коммерческих СУБД.

Двенадцать правил Кодда

В статье, опубликованной в журнале "Computer World", Тэд Кодд сформулировал двенадцать правил, которым должна соответствовать настоящая реляционная база данных. Двенадцать правил Кодда приведены в табл. 2.1. Они являются полуофициальным определением понятия реляционная база данных. Перечисленные правила основаны на теоретической работе Кодда, посвященной реляционной модели данных.

Таблица 2.1

Двенадцать правил Кодда, которым должна соответствовать реляционная СУБД

Правило	Пояснения
1. Правило информации.	Вся информация в базе данных должна быть предоставлена исключительно на логическом уровне и только одним способом - в виде значений, содержащихся в таблицах.
2. Правило гарантированного доступа.	Логический доступ ко всем и каждому элементу данных (атомарному значению) в реляционной базе данных должен обеспечиваться путём использования комбинации имени таблицы, первичного ключа и имени столбца.
3. Правило поддержки недействительных значений.	В настоящей реляционной базе данных должна быть реализована поддержка недействительных значений, которые отличаются от строки символов нулевой длинны, строки пробельных символов, и от нуля или любого другого числа и используются для представления отсутствующих данных независимо от типа этих данных.
4. Правило динамического каталога, основанного на реляционной модели.	Описание базы данных на логическом уровне должно быть представлено в том же виде, что и основные данные, чтобы пользователи, обладающие соответствующими правами, могли работать с ним с помощью того же реляционного языка, который они применяют для работы с основными данными.
5. Правило исчерпывающего подъязыка данных.	Реляционная система может поддерживать различные языки и режимы взаимодействия с пользователем (например, режим вопросов и ответов). Однако должен существовать, по крайней мере, один язык, операторы которого можно представить в виде строк символов в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает следующие элементы: -- определение данных; -- определение представлений; -- обработку данных (интерактивную и программную); -- условия целостности; -- идентификация прав доступа; -- границы транзакций (начало, завершение и отмена).
6. Правило обновления представлений.	Все представления, которые теоретически можно обновить, должны быть доступны для обновления.
7. Правило добавления, обновления и удаления.	Возможность работать с отношением как с одним операндом должна существовать не только при чтении данных, но и при добавлении, обновлении и удалении данных.
8. Правило независимости физических данных.	Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.
9. Правило независимости логических данных.	Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при внесении в базовые таблицы любых изменений, которые теоретически позволяют сохранить нетронутыми содержащиеся в этих таблицах данные.
10. Правило независимости условий целостности.	Должна существовать возможность определять условия целостности, специфические для конкретной реляционной базы данных, на подъязыке реляционной базы данных и хранить их в каталоге, а не в прикладной программе.
11. Правило независимости распространения.	Реляционная СУБД не должна зависеть от потребностей конкретного клиента.
12. Правило единственности.	Если в реляционной системе есть низкоуровневой язык (обрабатывающий одну запись за один раз), то должна отсутствовать возможность использования его для того, чтобы обойти правила и условия целостности, выраженные на реляционном языке высокого уровня (обрабатывающем несколько записей за один раз).

Правило 1 напоминает неформальное определение реляционной базы данных, приведенное ранее.

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL).

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

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

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

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

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

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

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

2.2 Разработка структуры баз данных

В данной главе будут выделены все сущности АС «Регистратура».

Сущность «Карта»(Karta)

Сущность «Карта» предназначена для хранения личных данных о пациенте, структура ее показана в табл. 2.2.

Таблица 2.2

Структура таблицы Karta

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
IDEN	NUMDER	10	Идентификационный номер
P_SER	CHAR	2	Серия паспорта
P_NUM	NUMDER	6	Номер паспорта
F	CHAR	30	Фамилия пациента
I	CHAR	30	Имя пациента
O	CHAR	30	Отчество пациента
POL	NUMDER	1	Пол
RD	DATE	8	Дата рождения
GR_ID	NUMDER	4	Гражданство
P_DATE	DATE	8	Дата выдачи паспорта
P_VIDAN	CHAR	50	Кем выдан паспорт
ID_ST	NUMDER	4	Улица, где проживает пациент
PR_BUILD	NUMDER	4	Дом
PR_FLATE	NUMDER	4	Квартира
ID_PROF	NUMDER	4	Профессия
RF	NUMDER	4	Резус-фактор
GR	NUMDER	4	Группа крови
NUMKART	NUMDER	4	Номер амбулаторной карты
WORK_PLACE	CHAR	250	Место работы

Сущность «Справочник врачей»(NsiVrach)

Сущность «Справочник врачей» содержит список всех врачей, структура показана в табл.2.3.

Таблица 2.3

Структура таблицы NsiVrach

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
FIO	CHAR	20	Код ФИО врача

Сущность «Справочник названия анализов»(NsiAnaliz)

Сущность «Справочник названия анализов» содержит названия анализов, структура показана в табл.2.4.

Таблица 2.4

Структура таблицы NsiAnaliz

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
NAME	CHAR	200	Название анализа

Сущность «Справочник улиц»(NsiStreet)

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

Таблица 2.5

Структура таблицы NsiStreet

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
NAME	CHAR	50	Название улицы

Сущность «Справочник сотрудников»(NsiPeople)

Сущность «Справочник сотрудников» содержит список всех сотрудников, которые работают с АС «Регистратура», структура показана в табл. 2.6.

Таблица 2.6

Структура таблицы NsiPeople

Название	Тип	Размер	Описание
ID	NUMDER	10	Уникальный идентификатор
F	CHAR	50	Фамилия сотрудника
I	CHAR	50	Имя
O	CHAR	50	Отчество
LOGIN	CHAR	30	Логин
PASS	CHAR	30	Пароль
DTYPE	NUMDER	1	Должность

Сущность «Справочник болезней»

Сущность «Справочник болезней» представляет собой Международный классификатор болезней 10-го пересмотра, структура которого приведена в табл. 2.7.

Таблица 2.7

Структура таблицы MKB

Название	Тип	Размер	Описание
ID	NUMDER	10	Уникальный идентификатор
DKOD	CHAR	7	Код болезни
DNAME	CHAR	222	Название болезни
PARENTID	NUMDER	10	Код предка для данного узла
ITEMTYPE	NUMDER	1	Тип узла

Сущность «Периодический осмотр»(Periodosm)

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

Таблица 2.8

Структура таблицы Periodosm

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата прохождения
ID_NERVOP	NUMDER	4	Код ФИО врача
REZ_NERVOP	CHAR	200	Результат обследования
ID_OKYL	NUMDER	4	Код ФИО врача
RES_OKYL	CHAR	200	Результат обследования
ID_HIRURG	NUMDER	4	Код ФИО врача
REZ_HIRURG	CHAR	200	Результат обследования
ID_STOMAT	NUMDER	4	Код ФИО врача
REZ_STOMAT	CHAR	200	Результат обследования
ID_OTOL	NUMDER	4	Код ФИО врача
REZ_OTOL	CHAR	200	Результат обследования
ID_TERAP	NUMDER	4	Код ФИО врача
REZ_TERAP	CHAR	200	Результат обследования

Сущность «Флюорография»(Flurka)

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

Таблица 2.9

Структура таблицы Flurka

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата
REZ	CHAR	254	Результат

Сущность «Жизненные функции организма»(Lifefun)

Сущность «Жизненные функции организма» содержит данные о температуре, давлении пациента, структура показана в табл. 2.10.

Таблица 2.10

Структура таблицы Lifefun

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата проведения осмотра
TEMPER	NUMDER	8	Температура
AD_S	NUMDER	8	Давление систолическое
AD_D	NUMDER	8	Давление диастолическое

Сущность «Рентгеновские исследования»(Rengen)

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

Таблица 2.11

Структура таблицы Rengen

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата рентгена
NAME	CHAR	254	Название органа
REZ	CHAR	254	Результат рентгена

Сущность «Направления на анализы»(NaprAnaliz)

Сущность «Направления на анализы» хранит информацию о направлениях на анализы и их результатах, структура приведена в табл. 2.12.

Таблица 2.12

Структура таблицы NaprAnaliz

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата сдачи анализа
NAME	CHAR	200	Название анализа
REZ	CHAR	200	Результат анализа
ID_VRACH	NUMDER	4	Код ФИО врача

Сущность «Операции»(Operat)

Сущность «Операции» предназначена для фиксирования данных о перенесенных пациентом операций, структура показана в табл. 2.13.

Таблица 2.13

Структура таблицы Operat

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата проведения операции
NAME	CHAR	254	Название операции
ID_VRACH	NUMDER	4	Код ФИО врача

Сущность «Данные физического развития»(VesRost)

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