Software & Systems

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

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

1. Офисные медицинские системы.

2. Системы для лабораторных исследований.

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

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

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

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

Обеспечение информационной поддержки работы ЛУ:

· регистрация пациентов;

· ведение БД по всем аспектам пребывания пациентов в ЛУ;

· автоматизированное ведение историй болезни;

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

· формирование и выдача медицинских заключений;

· составление графиков работы врачей;

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

· планирование и учет использования помещений и оборудования;

· назначение больным времени приема у врача;

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

· проведение анализа работы отделения;

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

· учет больных;

· учет лекарственных препаратов;

· бухгалтерский учет;

· учет расходов;

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

Обеспечение информационной поддержки лабораторных исследований:

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

¨ввод в систему и хранение данных лабораторных исследований;

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

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

Информационная поддержка диагностики, прогнозирования, мониторинга и лечения:

· интеллектуальные системы диагностики, прогнозирования и мониторинга;

· интеллектуальные системы поддержки принятия решений;

· интерфейсы с БД и системами для лабораторных исследований.

Таким образом, речь идет о создании ИНТЕгрированной Распределенной ИНформационной системы (ИНТЕРИН).

Архитектура системы

На аппаратном уровне ИНТЕРИН состоит из компьютеров или локальных сетей структурных подразделений ЛУ, соединенных в глобальную сеть.

Структурные подразделения в зависимости от решаемых задач могут использовать различные типы компьютеров и сетевых средств. В частности, возможно использование станций на базе Intel Pentium (ОС WindowsNT) или станции Sun SPARC (ОС Solaris) в качестве серверов, сети Ethernet 10/100 Мбит/с, ATM, FDDI. Поддерживаются сетевые протоколы TCP/IP, NetBIOS, DECNet, SPX/IPX, Named Pipes, AppleTalk, Banyan Vines и др. Возможно использование сетевых ОС WindowsNT, Windows for Workgroups, Novell NetWare, IBM PC LAN, Microsoft LAN Manager.

С точки зрения цена/производительность и удобства эксплуатации наиболее целесообразным оказалось использование сети на базе рабочих станций (Sun/Solaris или Pentium/ WindowsNT) и персональных компьютеров (DOS–Windows). Сеть строится на базе Ethernet 10(100) Мбит/с или ATM. Рабочие места разрабатываются под Windows for Workgroups (Windows-95).

При использовании различных аппаратных и сетевых платформ возникает проблема межсетевого взаимодействия. Такая проблема может быть решена с помощью технологии прозрачной сети (TNS) фирмы “Oracle”, которая обеспечивает интерфейс ко всем перечисленным сетевым протоколам.

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

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

Программное обеспечение каждого узла сети состоит из:

· универсального рабочего места пользователя с механизмом автоматической настройки на пользователя;

· программ поддержки распределенной базы данных;

· программ обработки данных, поступающих от лабораторно-медицинского оборудования (при необходимости);

· программ поддержки распределенной базы знаний;

· интеллектуальных систем.

Распределенность БД, баз знаний и возможность взаимодействия различных компонент программного обеспечения узла сети, например БД, экспертных систем и программ обработки данных, обеспечивает взаимодействие различных структурных подразделений ЛУ.

В качестве базовой СУБД для построения системы ИНТЕРИН авторами выбрана Oracle7 фирмы “Oracle Corp”. Перечислим кратко ее особенности.

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

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

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

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

Таблицы могут быть многоузловыми. Это означает, что таблицы данных на одном узле объединяются с таблицами на других узлах.

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

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

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

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

Реализация системы

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

Построение информационной модели ЛУ. Реализация проекта ИНТЕРИН предполагает создание полной информационной модели крупного ЛУ. Источниками информации для построения информационной модели явились документооборот ЛУ и специалисты в предметной области – эксперты.

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

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

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

Анализ имеющихся инструментальных средств разработки и требований к модели побудил нас выбрать в качестве средства моделирования современный продукт корпорации Oracle Designer-2000.

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

Моделирование заключалось в реализации электронных аналогов документов диаграммами сущность-связь.

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

Реализация основывается на понятии информационного объекта (ИО) как некоторой (логически взаимосвязанной) совокупности информации. Будем различать атомарные и составные ИО.

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

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

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

Паспортную часть можно подразделить на две группы полей:

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

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

В системе выделены три основные класса документов:

- справочники,

- медицинские и медицинские специализированные,

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

Заголовки документов бывают следующих типов:

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

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

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

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

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

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

Можно предложить следующие принципы реализации документов при помощи ИО.

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

2. Если документ содержит произвольное количество однородных элементов (какой-либо список), то эти элементы реализуются отдельным ИО (связь "один ко многим").

3. Если документ состоит из фрагментов, вводимых либо в разное время, либо разными пользователями, то фрагменты реализуются в виде отдельных ИО.

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

5. Если документ содержит элементы, для которых уже существуют ИО. Например, если есть ИО с адресами, то в документах, содержащих адрес, можно поставить ссылку на этот ИО и все это не дублировать.

6. В противном случае документ реализуется атомарным ИО.

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

При реализации информационной модели нужно учитывать следующее.

1. Все документы содержат информацию о праве доступа.

2. Большинство документов имеют состояние (как минимум, актуальный документ или нет; административно/хозяйственные – создан, завизирован, подписан, отправлен на доработку и т.п.).

3. Большинство документов содержит информацию об авторе.

4. В некоторых классах (медицинских) документов авторство двоякое – кто вводил документ (оператор) и кто является источником информации (автором).

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

На следующем этапе системного дизайна были определены описания объектов БД и описания программных модулей, получаемые на основе ИО предыдущего этапа.

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

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

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

В настоящее время авторами завершена разработка первой версии типовой модели ЛУ. Средствами Designer-2000 типовая модель может быть легко адаптирована для конкретного ЛУ. Информационная модель должна сопровождать каждую конкретную реализацию системы. При необходимости внесения в работающую систему изменений их следует согласованно отражать в информационной модели. Это позволит всегда иметь актуальную информационную модель, решит вопросы документирования работающей системы и предоставит возможности быстрой адаптации системы к меняющимся требованиям пользователей.

Для реализации клиентской части системы нами выбраны инструментальные средства корпорации “Oracle” Developer-2000. В пользу этого выбора свидетельствует следующее.

1) Designer-2000 позволяет по описаниям модулей клиентской части в информационной модели системы автоматически создавать модули-заготовки, которые далее дорабатываются с помощью средств Developer-2000.

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

3) Автоматическая генерация программного кода клиентской части (триггеры клиентской части) и использование одного языка для клиентской и серверной частей значительно ускоряют процесс программирования.

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

- вся вводимая информация должна быть авторизована;

- система не должна позволять изменять ранее введенную информацию;

- система должна иметь развитые средства защиты от несанкционированного доступа к медицинской и немедицинской информации;

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

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

Смысловой уровень	реализация информационной модели
Системный уровень	реализация общесистемных понятий и механизмов
Базовый уровень	СУБД (в нашем случае СУБД Oracle)

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

Лечебная деятельность предполагает наличие объекта и субъекта. Объект лечебной деятельности – пациент, а субъектом является персонал ЛУ. Системный уровень решает задачу уникальной идентификации пациента и персонала. Персонал идентифицируется кодом, который связывает три элемента:

– общая информация о человеке (ФИО и др.),

– структурное подразделение,

– должность.

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

Авторизация информации осуществляется путем добавления к вводимой информации пары {КТО, КОГДА}. Это производится автоматически на сервере, что гарантирует достоверность информации авторизации. Два дополнительных поля для этой пары содержатся в паспортной части каждого информационного объекта системы.

КТО – это уникальный код производящего запись,

КОГДА – это время на момент записи.

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

1. Полномочия на выборку информации имеют непосредственное отношение к требованиям секретности информации.

Пример:

· читать медицинскую информацию всех пациентов медицинского центра,

· читать медицинскую информацию всех пациентов отделения,

· читать медицинскую информацию всех пациентов, ассоциированных с данным врачом.

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

Пример:

· вносить запись консультанта для всех пациентов медицинского центра,

· вносить запись консультанта для всех пациентов отделения,

· вносить любую медицинскую информацию всех пациентов, ассоциированных с данным врачом;

· вносить всю медицинскую информацию всех пациентов отделения.

3. Полномочия на подпись имеют непосредственное отношение к семантической целостности информации. С момента подписания информация становится актуальной для системы в целом.

Пример:

· подпись заместителя директора по лечебной части,

· подпись заведующего отделением,

· подпись лечащего врача.

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

Пример:

· заместитель директора по лечебной части,

· заведующий лечебным отделением,

· врач лечебного отделения,

· медсестра лечебного отделения,

· заведующий отделением консультативного центра,

· врач отделения консультативного центра,

· медсестра отделения консультативного центра.

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

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

Такие информационные объекты всегда должны иметь некоторый актуальный срез информации и хранить всю историю "жизни" отображаемого объекта. Для этого было введено понятие информационных объектов реального времени (ОРВ). Такие объекты имеют две временные засечки – начало и конец. Пока не проставлено время второй временной засечки, объект считается актуальным, в момент проставления этой засечки объект перестает быть актуальным.

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

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

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

Остановимся кратко лишь на основных идеях, проясняющих концепцию "Боткинского листа".

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

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

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

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

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

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

Приведем примеры для стандартных групп. В физиологические параметры включим показатели из температурного листа – температуру, пульс, давление и т.д. Клинические признаки заболевания – степень одышки, желтушность, интенсивность боли некоторой локализации и т.п. Лабораторные показатели – результаты конкретных тестов. Данные инструментальных исследований – результаты УЗИ, ЭКГ, рентгенографии и т.п. Проводимое лечение – лекарственные средства и отметки об их введении, операции, процедуры. Врач может также сформировать новую группу и конфигурировать ее, как было показано выше.

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

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

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

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

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

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

И наконец, "Боткинский лист" как средство контроля.

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

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

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

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

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

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

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

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

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

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

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

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

Множество функций, выполняемых в ИС, организовано иерархически. В основе группировки лежат сущности, которые обрабатываются функциями, то есть вместе объединяются функции, работающие с одинаковыми сущностями (например поддерево функций для работы с приказами: инициация, подготовка, замечания, подпись, печать, ознакомление, отмена). Для каждой функции определяется, какую информацию она использует (к каким таблицам обращается) и в каком режиме – для чтения, записи, поиска или удаления. Подобные функции необходимы (и должны быть реализованы) независимо от способа их компоновки в рабочие места. Таким образом, выбран подход, известный из технологии программирования как "снизу вверх", когда вначале реализуются отдельные функции (в нашем смысле), из которых затем компонуется готовая программа – рабочее место (например: функции для работы с приказами входят в несколько рабочих мест – кто инициирует, кто готовит, кто подписывает; функция ознакомления с приказом входит во все рабочие места всех сотрудников).

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

Что такое пользователь? Это не должность (на одной должности может работать несколько человек) и не человек (он может работать на трех ставках в различных подразделениях ЛУ). Это некоторая ипостась пользователя, идентификатор (account), под которым пользователь входит в систему. Тем более, что серьезные ОС и БД осуществляют идентификацию пользователя. Следовательно, разделяются моменты: запуск приложения, идентификация пользователя, конфигурирование рабочего места, а затем его использование. До идентификации нет связи с БД, и возможно использование только ресурсов, никак не связанных с БД. Только после идентификации происходит конфигурирование рабочего места. Информация о конфигурации рабочих мест может храниться только в БД и извлекаться оттуда по имени (коду) пользователя (эта информация доступна всем пользователям БД только для чтения), то есть в БД для каждого пользователя хранится информация о том, какие функции он может выполнить. В меню конкретного рабочего места остается доступ только к тем функциям, на которые пользователь имеет право. Более того, эта информация используется на сервере БД для контроля и ограничения прав доступа пользователя.

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

Пример.

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

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

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

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

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

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

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

Перспективы развития

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

В настоящее время ведутся работы по созданию и интеграции механизмов multimedia-технологий, телемедицины, удаленного доступа к системе ИНТЕРИН. Одним из наиболее интересных направлений оказалось создание информационного хранилища с разработкой и внедрением средств интеллектуального анализа эффективности деятельности ЛУ.

Система ИНТЕРИН на первой стадии разработки и реализации является типичной OLTP-системой (On-line Transaction Processing Systems), в ходе работы с которой многочисленные пользователи выполняют типовые операции вставки, модификации и удаления информации из БД. Предусмотрены возможности архивирования неактуальной с точки зрения оперативной работы информации. Чтобы получить доступ к информации, находящейся в архиве, необходимо выполнить специальные процедуры загрузки этой информации в БД. В силу специфики назначения системы большой объем поступающей в БД информации связан с работой механизмов авторизации, защиты от несанкционированного доступа, организации прохождения документов в системе и хранения истории.

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

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

2) проблему оценки работы ЛУ в целом;

3) задачу мониторинга санитарно-эпидемиологической обстановки в ЛУ.

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

В настоящее время для решения такого круга задач предлагается технология информационных хранилищ (Data Warehouse). Суть ее заключается в том, что одновременно с хранением оперативной информации в различных OLTP-системах создается информационная OLAP-система (On-line Analytical Processing) аналитической обработки данных в реальном времени. Существенная информация, с которой оперирует OLAP-система, хранится в информационном хранилище. Хранилище открыто только для загрузки новой информации и ее чтения. База данных, на основе которой построено хранилище, должна быть оптимизирована не для выполнения транзакций, а для реализации запросов.

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

В заключение отметим, что отличительными чертами создаваемой системы можно считать:

· переход от локальных подсистем документооборота и работы с медицинской информацией, связанных электронной почтой, к интегрированной системе, где вся информация, проходящая через ЛУ, хранится в общей БД и является доступной;

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

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

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

· возможность быстрого создания подобных информационных систем для конкретного ЛУ;

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

· возможность интеграции практически любых специализированных медицинских систем.

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