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

На правах рукописи

Михеев Александр Евгеньевич

ИССЛЕДОВАНИЕ И РАЗРАБОТКА ОСНОВНЫХ АРХИТЕКТУРНЫХ РЕШЕНИЙ СОВРЕМЕННЫХ МЕДИЦИНСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ

Специальность 05.13.11 - Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата технических наук

Переславль-Залесский - 2005

Работа выполнена в Медицинском Центре Банка России

Научные руководители:

член-корреспондент РАН, доктор медицинских наук, профессор Г.И. Назаренко

доктор физико-математических наук, профессор Г.С. Осипов

Официальные оппоненты:

доктор технических наук, профессор О.П. Кузнецов кандидат физико-математических наук В.Б. Бритков

Ведущая организация:

Московский энергетический институт (Технический университет)

Защита состоится " 29 " апреля 2005 г. в 14:00 час. на заседании диссертационного совета Д 002.084.01 в Институте программных систем РАН по адресу: 152020, г. Переславль-Залесский, м. "Ботик", ИПС РАН.

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

Автореферат разослан "29 " марта 2005 г.

Ученый секретарь диссертационного совета

кандидат технических наук

С.М.Пономарева

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

Глава 1. Роль стандартов в архитектуре современных МИС. В главе выполнен системный анализ роли стандартизации в медицинской информатике. Рассмотрены широко распространенные стандарты HL7, DICOM, предварительный европейский стандарт GEHR, связь стандартов с клиническими руководствами. Указывается на важность метода критических путей для создания клинических руководств. Осуществлен обзор исследовательских проектов поддержки исполнения клинических руководств. Сделан важный концептуальный вывод о необходимости разработки архитектуры, ориентированной на стандарты. Вместе с тем указывается на недостаточную разработанность имеющихся стандартов. Сделан вывод о возможном направлении развития стандартов и на его основе осуществляется важный концептуальный выбор архитектурный решений, связанных с представлением медицинской информации. Формулируются основные направлениями исследований для разработки систем поддержки медицинских технологических процессов.

Глава 2. Медицинские технологические процессы.

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

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

Абстракцией лечебных мероприятий (точнее их активной компоненты, приводящей к изменению состояния пациента), являются операторы Операторы будем обозначать через О и связывать с каждым из них моменты начала (tj) и окончания (t2), периодичность (Т), объем мероприятий (V) и их локализацию (Loc)

0 = 0(t„t2, Т, V, Loe).

Если ограничения и императивы описывают состояния, то операторы изменяют состояния, воздействуя на них

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

Это означает, что каждый элемент МТП (лечебное мероприятие) можно представить в виде упорядоченной тройки основных конструктов <Соп (t,), Imp (tj, 0(tnt,+h T„ V„ LocJ>.

означают некоторые конкретные ограничения, императивы и операторы, соответственно) Всякому этапу технологического процесса соответствует некоторое множество лечебных мероприятий Это означает, что 1-й этап технологического процесса можно представить некоторым множеством элементов, образующим подмножество Е декартова произведения Con (t,) xlmp (t,) xO(t, ,t,+i, T„ V„ Loe,) E с Con (t,) xlmp (t,) x 0(t, ,t1+r, T„ V„ Loe,),

где Con (t,) - множество ограничений Imp (t,) - множество императивов, 0(t, ,t1+1, T„ V„ Loe,) - множество операторов

Заметим здесь, что с операторами из семейства 0(t, ,t1+), Т„ V„ Loe,) могут

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

Для описания модели медицинского технологического процесса введем множество I с заданным на нем отношением линейного порядка <, множества CON, IMP и О и отображения CON1 I CON, IMP1 I -> IMP и О1 Int—> О, где Int с Ixl такие что,

Viel CON'(i) = Con (i),

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

Глава 1. Роль стандартов в архитектуре современных МИС. В главе выполнен системный анализ роли стандартизации в медицинской информатике. Рассмотрены широко распространенные стандарты HL7, DICOM, предварительный европейский стандарт GEHR, связь стандартов с клиническими руководствами. Указывается на важность метода критических путей для создания клинических руководств. Осуществлен обзор исследовательских проектов поддержки исполнения клинических руководств. Сделан важный концептуальный вывод о необходимости разработки архитектуры, ориентированной на стандарты. Вместе с тем указывается на недостаточную разработанность имеющихся стандартов. Сделан вывод о возможном направлении развития стандартов и на его основе осуществляется важный концептуальный выбор архитектурный решений, связанных с представлением медицинской информации. Формулируются основные направлениями исследований для разработки систем поддержки медицинских технологических процессов.

Глава 2. Медицинские технологические процессы.

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

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

Абстракцией лечебных мероприятий (точнее, их активной компоненты, приводящей к изменению состояния пациента), являются операторы Операторы будем обозначать через О и связывать с каждым из них моменты начала (ti) и окончания (t2), периодичность (Т), объем мероприятий (V) и их локализацию (Loc):

0 = 0(t„t2, Т, V, Loc). Если ограничения и императивы описывают состояния, то операторы изменяют состояния, воздействуя на них.

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

Это означает, что каждый элемент МТП (лечебное мероприятие) можно представить в виде упорядоченной тройки основных конструктов <Соп ftj, Imp (tj, 0(t,,tl+h T„ V„ LocJ>.

означают некоторые конкретные ограничения, императивы и операторы, соответственно) Всякому этапу технологического процесса соответствует некоторое множество лечебных мероприятий Это означает, что i-й этап технологического процесса можно представить некоторым множеством элементов, образующим подмножество Е декартова произведения Con (t,) xlmp (t,) xO(t, ,t,+i, T„ V„ Loe,) E ç Con (t,) /Imp (t,) x 0(t, ,t1+],

где Con (t,) - множество ограничений, Imp (t,) - множество императивов,

Заметим здесь, что с операторами из семейства 0(t, ,t1+1, Т„ V„ Loe,) могут

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

Для описания модели медицинского технологического процесса введем множество I с заданным на нём отношением линейного порядка <, множества CON. IMP и О и отобпажения: CON1 ' I -» CON, IMP1 ' I -> IMP и О : Int—> О, где Int çz Ixl такие что,

Viel CON'( i ) = Con (i),

Viel IMP '(i) = Imp (i),

V(i, ,i2) e Int 0'(i, ,i2) = 0(i, ,i2, T„ V„ Loc,).

Разумеется, Con (i), Imp (i) и 0(i| ,i2, T„ V,, Loe,) суть элементы CON, IMP и О, соответственно.

Тогда восьмерку

М= <1, Int, CON, IMP, О, CON1, IMP1,01 >

будем называть моделью медицинского технологического процесса. Опишем теперь каждую компоненту модели более точно. Ограничения Con (t) включают:

• требования на продолжительность этапа - L(t);

• наиболее важные показатели, требующие объективного исследования - P(t);

• критерии перевода в другое отделение - Ktr;

• критериальное подтверждение диагноза - Kds;

• критерии выписки из стационара - К;

критерии (условия) примененимости оператора - С. Иначе говоря, Con(t¡) = (L(t)&P(t)&K.tr(t) & Kds&K&C). Императивы Imp (t):

• указания по выбору специалистов - Ch (t);

• манипуляции - М (t);

• инструментальные и лабораторные исследования - Rch (t), т.е. Imp (t) = (Ch (t), M (t), Rch (t)) .

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

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

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

Процесс переноса экспертизы основан на использовании наборов сценариев и наборов стратегий.

Перечислим сценарии, которые могут быть использованы при переносе экспертизы:

• Сценарий выявления решений. Предназначен для извлечения из экспертов в интерактивном режиме лечебных и диагностических решений в процессе построения плана.

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

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

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

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

• стратегия "разбиения на ступени" - предназначена для построения концептуальной модели задачи;

• стратегия триад - предназначена для выявления различающих признаков элементарных действий и решений;

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

• стратегия деления пути - используется для выявления временных последовательностей решений и действий;

• стратегия упорядочения - используется для синтеза планов из частичных планов.

Общая архитектура системы построения лечебно-диагностических карт представлена на следующем рисунке.

Рис. 1. Общая архитектура системы построения лечебно-диагностических карт.

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

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

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

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

Рис. 2. Блок-схема подсистемы исполнения лечебно-диагностических планов

Модули, изображенные на блок-схеме осуществляют следующие функции:

• Listener - агент, осуществляющий «слушание» базы данных. Он «возбуждается» всякий раз, когда в базе данных происходит событие (например, постановка предварительного диагноза, выполнение врачебного назначение, изменение параметров состояния больного и т.д.). Listener передает сообщение о событии Менеджеру

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

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

• Контроллер исполнения отслеживает невыполненные в соответствующий интервал времени планы и элементы планов и передает эту информацию Исполнителю

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

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

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

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

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

1 Процедура SKELETON - создание (или выбор) скелетного плана для группы нозологии

2 Процедура NAME (Obj) - указать имя плана

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

3 Процедура OBJECT(Obj) - выбрать либо создать объект

Эксперт может выбрать один объект или несколько объектов Множественный выбор определяет подпланы данного плана В системе реализуются две стратегии поиска (выбора) объекта Эксперт может выбрать любую из них

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

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

4 Процедура TIME () - указать интервал времени

Стратегия TIME предлагает эксперту указать относительное время начала и конца текущего плана Время может отсчитываться от момента возникновения события в плане верхнего уровня Для выбора события применяется процедура EVENT Если событие не указано, то время задается относительно плана предыдущего уровня

5 Процедура EVENT (Obj, Level) - выбрать, либо создать событие Сначала запускается стратегия CHOICEEVENT Система предлагает два списка событий все возможные события и события данного плана Эксперту необходимо выбрать событие из числа возможных и добавить его в список событий данного плана

Если эксперт не находит нужного события, запускается стратегия CREATEVENT Стратегия создания события заключается в следующем Учитывая, что событие это объект + действия, система вызывает

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

Эксперт может указать относительную временную привязку события При этом происходит вызов процедуры TIME

6 Процедура CONDITION () - указать условия

Стратегия COND START предлагает эксперту определить условие запуска плана Эксперту надо перечислить события, приводящих к запуску плана Вызывается процедура EVENT

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

6 1 Стратегия CONDSTOP запускается для указания экспертом условия завершения плана Необходимо перечислить события, которые приводят к завершению плана (вызов процедуры EVENT)

7 Если план элементарный, то система предлагает эксперту конкретизировать действия (при этом запускается процедура ACTION (Obj)), иначе перейти к выполнению пунктов 8, 9

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

8 Процедура SUBPLAN=PLAN (Obj) - выбрать подплан либо ввести новое имя подплана

Эксперту предлагается выбрать подплан из имеющихся в системе подпланов После выбора имени подплана или ввода нового, вызывается стратегия OBJECT (пункт 3) и эксперту необходимо выполнить последовательность действий, указанную в пунктах 3-7 Если подпланы не определены экспертом, система задает вопрос о завершении сеанса работы

9 Процедура GOAL () - указать цель

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

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

диагностических карт.

Редактор концептуальной модели

Редактор концептуальной модели включает в себя следующие подсистемы (рис. 3):

• редактор справочника предметной области

• редактор справочника событий

я я

а 5 £

Б г X о а У п ю О а

Я О Я 5

а )Е а Ь

с о с

о X о ю

а а

о о о

£ Е г! (и Ё «

ч о.

и с О

Вн си

Редактор концептуальной модели лрсдчанои оашсл!

Рис. 3. Схема редактора концептуальной модели

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

Редактор справочника событий - программа для создания и редактирования простых (элементарных) и сложных (комплексов) событий предметной области.

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

• описание справочника и его структуры;

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

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

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

• описание простого события,

• описание сложного события

Редактор лечебно-диагностических карт Полуавтоматический режим создания лечебно-диагностических карт обеспечивается следующими компонентами (рис 4)

• интерактивный интерпретатор экспертизы,

• сценарий выявления компетентности,

• стратегии выявления компетентности

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

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

г/ ///.

Рис 4 Схема редактора лечебно-диагностических карт

Стратегия выявления, компетентности - программа, реализующая механизм выявления того или иного элемента плана

На рис. 5 показан внешний вид интерактивного редактора для построения лечебно-диагностических карт.

Рис. 5. Редактор лечебно-диагностических карт

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

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

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

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

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

3. Проведение в приемном отделении инструментальной и (экспресс-) лабораторной диагностики.

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

5. Проведение специализированного осмотра и опроса.

6. Постановка (уточнение) диагноза при поступлении.

7. Лечение в приемном отделении по результатам п.п. 3-6.

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

9. Госпитализация (в коечное отделение или в отделение реанимации и интенсивной терапии) либо отказ от госпитализации.

Рис. 6. Пример карты приема в приемном отделении.

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

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

2 Если верхнее артериальное давлении менее 90 или более 200 мм р ст или частота сердечных сокращений менее 50 или более 100 уд /мин или частота дыхания более 24 в минуту- вызов бригады интенсивной,

3 Проведение в ЭКГ - исследования,

4 Если данные ЭКГ критические - вызвать бригаду интенсивной терапии,

5 Выяснить - есть ли у больного ангинозные боли, нарушение ритма сердца или влажные хрипы,

6 Постановка (уточнение) диагноза при поступлении

7 Провести лечение больного в приемном отделении - при наличии ангинозных болей назначить нитроглицерин и промедол, при нарушениях систолического АД назначить мазатонин

8 Назначить анализы, входящие в панель "Анализы в приемном отделении при стенокардии"

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

Для построения конкретизированного плана, перехода от пунктов 1-9 к пунктам 01-09 соответственно (с учетом прилагаемых схем) необходимо провести следующие диалоговые группы

1 Уточнение входного условия для плана - Диагноз направившего учреждения="Ишемическая болезнь сердца"

2 Уточняется перечень функциональных показателей, необходимых для приема с данным диагнозом АД, ЧСС, ЧД

3 Определяются условия критических значений функциональных показателей при данном диагнозе для вызова бригады интенсивной терапии - АД до 90 и выше 200, ЧСС до 50 и выше 100,ЧДдо24

4 Определяются условия "Нарушение АД" (АД до 90), "Нарушение ЧД" (ЧД до 24) - для выполнения планов назначения соответствующих медикаментов - как подпланов плана "Лечение в ПО"

5 Уточняется перечень исследований, проводимых в приемном отделении при данном диагнозе - ЭКГ Для каждого исследования (в данном случае - для одного) задается множество показателей, значения которых необходимы при приеме Для данной карты -величина сегмента ST, зубца Т, ЖЭ, ЖТ, барикардия

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

7. Задаются условия на элементе плана "Проведение исследований в ПО" (ЭКГ), - "Норма" и "Выраженные нарушения" определяющие выполнения планов госпитализации в коечное отделение и в ОРИТ соответственно.

8. Определяется множество показателей специализированного осмотра - наличие ангинозных болей, нарушений ритма, влажных хрипов... Для элемента плана "Специализированный осмотр" создаются условие "Есть ангинозные боли" для запуска плана "Назначение нитроглицерина и промедола" (подплана плана "Лечение в приемном отделении").

9. Задается перечень анализов, назначаемых в ПО при данном диагнозе.

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

Основные результаты работы

• исследована роль стандартов в медицинской информатике и их влияние на развитие медицинской информатики

• разработана архитектура системы построения лечебно-диагностических карт

• разработана архитектура системы поддержки лечебно-диагностических процесса

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

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

• разработаны сценарии выявления симптомов, редактирования свойств плана, построения условий

• разработанные методы и алгоритмы системы построения лечебно-диагностических карт легли в основу, реализованной в Медицинском центре банка РФ системы ИНТЕРПЛАН.

Алимов Д В , Михеев А Е , Назаренко Г И , Хаткевич М И Визуализация и анализ потока пациентов в комплексном лечебно-профилактическом учреждении, Программные системы теория и приложения // Труды международной конференции "Программные системы теория и приложения", ИПС РАН, г Переславль-Залесский, май 2004 / Под редакцией С М Абрамова -М Физматлит, 2004 -С 103-116

Михеев А Е Автоматизация технологий управления лечебно-диагностическим процессом // Управление качеством медицинской помощи / Под ред Г И Назаренко, Е И Полубенцевой - М, 2000 -С 206-285

Назаренко Г И , Кишкун А А , Михеев А Е , Миколаускас В П , Коленкин С М , Арсенин С Л Практические подходы к созданию лабораторной информационной системы Научно-практич симпозиум «Организация, менеджмент и экономика клинической лабораторной службы», Москва, 6-9 октября 2003 г // Клиническая лабораторная диагностика - 2003 - №9 - С 24-25 Назаренко Г И, Михеев А Е Больничные информационные системы Разработка Внедрение Эксплуатация учебное пособие / Под ред Г И Савина - М Медицина XXI, 2003 - 320 с Профессиональное тестирование медицинского персонала Учеб -метод пособие / Г И Назаренко, Б Б Карочкин, В А Коротич, Н Ю Лобода, А Е Михеев, В Ф Паршин / Под ред Г И Назаренко - М ЦБ РФ, Мед центр, 2002 -73 с Yadulla Guliev, Gennady Osipov, Alfred Ailamazyan, Olga Bodrova, Sergey Komarov, Alexander Mikheev, Gerasim Nazarenko Specificity of Hospital Information System (HIS) Development in the Context of Forming Information Infrastructure and Economic Structure of Russia // Proc conf Medinfo-98 - Seoul, 1998

1

2

3

4

5

6

7 Задаются условия на элементе плана "Проведение исследований в ПО" (ЭКГ) - "Норма" и "Выраженные нарушения" определяющие выполнения планов госпитализации в коечное отделение и в ОРИТ соответственно

8 Определяется множество показателей специализированного осмотра - наличие ангинозных болей нарушений ритма влажных хрипов Для элемента плана "Специализированный осмотр" создаются условие "Есть ангинозные боли" для запуска плана "Назначение нитроглицерина и промедола" (подплана плана "Лечение в приемном отделении")

9 Задается перечень анализов, назначаемых в ПО при данном диагнозе

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

Основные результаты работы

• исследована роль стандартов в медицинской информатике и их влияние на развитие медицинской информатики

• разработана архитектура системы построения лечебно-диагностических карт

• разработана архитектура системы поддержки лечебно-диагностических процесса

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

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

• разработаны сценарии выявления симптомов, редактирования свойств плана, построения условий

• разработанные методы и алгоритмы системы построения лечебно-диагностических карт легли в основу, реализованной в Медицинском центре банка РФ системы ИНТЕРПЛАН

Алимов Д В , Михеев А Е , Назаренко Г И , Хаткевич М И Визуализация и анализ потока пациентов в комплексном лечебно-профилактическом учреждении, Программные системы теория и приложения // Труды международной конференции "Программные системы теория и приложения", ИПС РАН, г Переславль-Залесский, май 2004 / Под редакцией С М Абрамова -М Физматлит, 2004 -С 103-116

Михеев А Е Автоматизация технологий управления лечебно-диагностическим процессом // Управление качеством медицинской помощи / Под ред Г И Назаренко, Е И Полубенцевой -М, 2000 - С 206-285

Назаренко Г И , Кишкун А А , Михеев А Е , Миколаускас В П , Коленкин С М , Арсенин С Л Практические подходы к созданию лабораторной информационной системы Научно-практич симпозиум «Организация, менеджмент и экономика клинической лабораторной службы», Москва, 6-9 октября 2003 г // Клиническая лабораторная диагностика - 2003 - №9 - С 24-25 Назаренко Г И, Михеев А Е Больничные информационные системы Разработка Внедрение Эксплуатация учебное пособие / Под ред Г И Савина - М Медицина XXI, 2003 - 320 с Профессиональное тестирование медицинского персонала Учеб -метод пособие / Г И Назаренко, Б Б Карочкин, В А Коротич, Н Ю Лобода, А Е Михеев, В Ф Паршин / Под ред Г И Назаренко - М ЦБ РФ, Мед центр, 2002 -73 с Yadulla Guliev, Gennady Osipov, Alfred Ailamazyan, Olga Bodrova, Sergey Komarov, Alexander Mikheev, Gerasim Nazarenko Specificity of Hospital Information System (HIS) Development in the Context of Forming Information Infrastructure and Economic Structure of Russia//Proc conf Medinfo-98 -Seoul, 1998

1

2

3

4

5

6

Печ л 1,25 Тираж 100

os: tâ-os. S3

i г *

¿ : í -» e . » .

S54

Содержание.

1. Введение.

Актуальность темы.

Введение в проблематику построения архитектуры современной МИС.

Направления стандартизации в медицинской информатике.

Цель работы и задачи исследования.

Методы исследования.

Научная новизна.

Практическое значение работы.

Апробация работы.

Публикации.

Структура и объем диссертации.

Содержание работы.

Основные результаты работы.

2. Роль стандартов в архитектуре современных МИС.

2.1. Основные понятия и определения.

2.2. Направления стандартизации в медицинской информатике.

Стандартизация медицинской терминологии.

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

Стандартизация передачи медицинской информации.

2.3. Горизонтальная интеграция стандартов.

Интеграции стандартов HL7 и DICOM - архитектура PRA.

2.4. Стандартизация в здравоохранении России.

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

2.6. Стандарты и клинические руководства.

3. Медицинские технологические процессы.

3.1. Индикаторы и ограничения.

3.2. Технологическая информация и еЕ источники.

Источники информации.

Императивы.

Медицинская помощь. Операторы.

Операторы.

Пример.

3.3. Конструкты и элементы медицинского технологического процесса.

3.4. Состояния медицинского технологического процесса.

3.5. Модель медицинского технологического процесса.

3.6. Примеры.

4. i Основные архитектурные решения по поддержке технологии лечебно-диагностического процесса.

4.1. Основные понятия.

4.2. Архитектура системы построения лечебно-диагностических карт (планов).

4.3. Архитектура системы поддержки лечебно-диагностического процесса.

5. Система построения лечебно-диагностических карт (Интерплан).

5.1. Общая схема системы интерплан.

Элементы абстрактного плана.

Элементы конкретного плана.

Элементы элементарного плана.

5.2. Сценарий выявления и переноса компетентности эксперта в области технологии лечебно-диагностического процесса.

5.3. Интерактивные редакторы построения лечебных планов.

Редактор концептуальной модели.

Редактор лечебно-диагностических карт.

5.4. Взаимодействие системы ИНТЕРПЛАН с системой ИНТЕРИН.

5.5. Пример построения лечебно-диагностической карты.

АКТУАЛЬНОСТЬ ТЕМЫ

Актуальность автоматизации такой жизненно-важной области как медицина не вызывает сомнений. Во всем мире современные лечебные учреждения тратят на информационные технологии огромные средства, однако, при этом они не всегда уверены в целесообразности этих расходов и часто не могут получить должную отдачу. Одна из причин подобного положения в существенно более быстром развитии информационных технологий по отношению к самой медицине. Еще совсем недавно считалось приемлемым автоматизировать различные службы лечебного учреждения по отдельности - лаборатория, диагностика, лечебные отделения, аптека и т.п. Затем быстро пришло понимание, что будущее за интегрированными решениями. Отдельные не связанные друг с другом подсистемы не могут обеспечить ожидаемого эффекта. Но и сами масштабы интеграции тоже стали расти с огромной скоростью. Уже недостаточно обеспечить интегрированное решение для отдельного лечебного учреждения или группы учреждений. Интеграция уже поднялась на ведомственный уровень (МИС Центрального Банка России, Газпрома, Тюменьтрансгаза и т.п.) и явно тяготеет к общегосударственному и даже общемировому масштабу. Например, в работе [Jones, 2002], посвященной обсуждению национальной инфраструктуры «электронного здравоохранения» в США, речь идет о переходе на общенациональную электронную систему назначений. И таких примеров много. Перед руководителями лечебных учреждений, отвечающих за автоматизацию, и перед архитекторами современных МИС встает проблема - как обеспечить сохранение капиталовложений в информационную систему, как обеспечить ей долгий жизненный цикл и не потерять возможности адаптации и развития, как получить от системы реальную отдачу, выражающуюся в повышении качества медицинского обслуживания. Во многом - это проблемы архитектуры системы, без формулирования и решения которых дальнейшее эффективное продвижение в области автоматизации здравоохранения будет невозможным.

ВВЕДЕНИЕ В ПРОБЛЕМАТИКУ ПОСТРОЕНИЯ АРХИТЕКТУРЫ СОВРЕМЕННОЙ МИС

Архитектура. «Набор решений по организации программной системы: выбору элементов структуры этой системы; их интерфейсов и поведения, задаваемого кооперациями между элементами, объединению элементов в прогрессивно растущие подсистемы, а также выбору архитектурного стиля, задающего организацию программной системы, - элементы, их интерфейсы, кооперацию и объединение. Архитектура программ имеет отношение не только к структуре и поведению, но также и к способам использования, функциональности, производительности, гибкости, возможности повторного использования, постижимости, экономическим и технологическим ограничениям и компромиссам в вопросах эстетики», [Якобсон и др., 2002].

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

• необходимость вводить и анализировать все больший объем медицинской информации для оказания качественной медицинской помощи;

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

• постоянно расширяющаяся понятийная и концептуальная база предметной области (медицины);

• недостаточная формализация (концептуализация и стандартизация) предметной области;

• быстрый прогресс информационных технологий.

Медицинская информация становится все более сложной и все более важной. По данным [Ка1га аХ а1.], около 15% ресурсов лечебного медицинского учреждения расходуется на сбор данных. Врачи и медсестры затрачивают 25% своего рабочего времени на поиск нужной им информации. В качестве примера можно привести статистику из университетского госпиталя в Гейдельберге

University Hospital of Heidelberg) на 1 700 коек. В течение года в госпитале создается около 400 000 новых медицинских карт, содержащих в бумажном виде 6,3 млн. страниц. Выполняется 250 000 исследований и 20 000 процедур. По данным US Institute of Medicine Report, около 100 000 граждан США ежегодно умирают по причине медицинских ошибок (восьмое место в упорядоченных по частоте причинах смерти). Одна из основных причин ошибок - недостаточная или некачественная информация о пациенте. Объем медицинской литературы, необходимой для качественного лечения, удваивается каждые 10-15 лет уже в течение последних 300 лет. Ежегодно в области биомедицины выходят 20 000 журналов и 17 000 книг. Примерно половина концептов (500 000) из всех выработанных человечеством непосредственно относится к медицине. Многоязычный тезаурус UMLS (Унифицированная система медицинского языка) содержит 730 000 концептов и 1,5 млн. понятий.

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

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

Многие исследования последних десятилетий связаны с поиском концептуальных решений проблемы стандартизации медицинской информации. Большие надежды связываются с повышением уровня абстракции предлагаемых формальных моделей. Процитируем в качестве примера подобного подхода: «The solution is to use more abstract models with fewer, but more expressive, objects. The patient information model has to be simplified and clarified and a uniform and correct level of abstraction must be found. For example, items such as birth, weight or haemoglobin concentration should not be found included as named attributes of the model. The specific clinical entities should be represented in a concept/vocabulary data base that is separate from the data model» [Donald et al., 1998].

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

НАПРАВЛЕНИЯ СТАНДАРТИЗАЦИИ В МЕДИЦИНСКОЙ ИНФОРМАТИКЕ

К настоящему моменту практически все существующие стандарты медицинской информатики носят не обязательный, а рекомендательный характер. В США разработка стандартов медицинской информатики координируется соответствующими подкомитетами Американского национального института стандартизации ANSI, в Европе - подкомитетом ТС251 Европейского комитета по стандартизации CEN. Особенность стандартизации медицинской информатики ярко выражена следующей дилеммой: чем уже круг экспертов, тем сложнее сделать стандарт общепризнанным; чем он шире, тем дольше разрабатываются стандартные решения» [Емелин, 1998].

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

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

В настоящее время можно выделить два стандарта, ведущих свое происхождение из США, но получивших достаточно широкое признание и в других странах:

• стандарт электронного обмена текстовыми медицинскими документами Health Level Seven (HL7);

• стандарт электронного обмена изображениями лучевой диагностики Digital Imaging and Communication in Medicine (DICOM).

К сожалению, в России работа по стандартизации электронного обмена медицинскими документами в подобном объеме и с таким качеством не ведется» [Емелин, 1998].

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

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

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

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

Единственно верным стратегическим решением в этой ситуации представляется разработка архитектуры, ориентированной на стандарты. Чтобы ориентироваться на то, «чего еще нет», необходимо сделать некоторые предположения, интуитивно предугадать направление, в котором пойдет стандартизация в медицине. В настоящее время в развитии стандартизации на Западе просматриваются два основных течения. Первое, связанное с историей стандарта HL7, определяет жесткие нерасширяемые модели данных (концептов), пытаясь все многообразие медицинской информации свести к небольшому числу конкретных информационных сообщений. Второе, связанное с европейскими разработками прототипа стандарта GEHR (The Good European Health Record project), пытается лишь определить общие правила и ограничения конструирования произвольных информационных сообщений (структур) над словарями понятий предметной области. Если рассмотреть возможный синтез этих двух подходов, то можно предположить, что стандарт должен будет заключать в себе как жестко формализованные концепты предметной области, так и свободно конструируемые по заданным правилам информационные структуры.

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

ЦЕЛЬ РАБОТЫ И ЗАДАЧИ ИССЛЕДОВАНИЯ

Целью диссертационной работы является исследование и разработка отдельных архитектурных аспектов современных МИС. Основное внимание работы сосредоточено на следующих аспектах:

• роль стандартов в архитектуре современных МИС;

• медицинские технологические процессы;

• основные архитектурные решения по поддержке технологии лечебно-диагностического процесса;

• особенности реализации системы построения лечебно-диагностических карт.

МЕТОДЫ ИССЛЕДОВАНИЯ

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

НАУЧНАЯ НОВИЗНА

Основные научные результаты, полученные автором:

• разработан подход к формализации медицинских технологических процессов;

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

• разработана архитектура системы поддержки лечебно-диагностических процесса;

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

ПРАКТИЧЕСКОЕ ЗНАЧЕНИЕ РАБОТЫ

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

АПРОБАЦИЯ РАБОТЫ

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

• международной конференции Программные системы: Теория и приложения, ИПС РАН, Переславль-Залесский, 2004.

• неоднократно на семинарах Центра медицинской информатики ИПС РАН, Переславль-Залесский, 1996 - 2004.

ПУБЛИКАЦИИ

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

1. Алимов Д.В., Михеев А.Е., Назаренко Г.И., Хаткевич М.И. Визуализация и анализ потока пациентов в комплексном лечебно-профилактическом учреждении, Программные системы: теория и приложения // Труды международной конференции «Программные системы: теория и приложения», ИПС РАН, г. Переславль-Залесский, май 2004 / Под редакцией С.М. Абрамова. -М.:Физматлит, 2004. - С. 103116

2. Михеев А.Е. Автоматизация технологий управления лечебно-диагностическим процессом // Управление качеством медицинской помощи / Под. ред. Г.И. Назаренко, Е.И. Полубенцевой. - М, 2000. - С. 206-285.

3. Назаренко Г.И., Кишкун A.A., Михеев А.Е., Миколаускас В.П., Коленкин С.М., Арсенин C.JI. Практические подходы к созданию лабораторной информационной системы: Научно-практич. симпозиум «Организация, менеджмент и экономика клинической лабораторной службы», Москва, 6-9 октября 2003 г. // Клиническая лабораторная диагностика. - 2003. -№9. - С. 24-25

4. Назаренко Г.И., Михеев А.Е. Больничные информационные системы: Разработка. Внедрение. Эксплуатация: учебное пособие / Под ред. Г.И. Савина. - М.: Медицина XXI, 2003. - 320 с.

5. Профессиональное тестирование медицинского персонала: Учеб.-метод. пособие / Г.И. Назаренко, Б.Б. Карочкин, В.А. Коротич, Н.Ю. Лобода, А.Е. Михеев, В.Ф. Паршин / Под. ред. Г.И.Назаренко. - М.: ЦБ РФ, Мед.центр, 2002. -73 с.

6. Yadulla Guliev, Gennady Osipov, Alfred Ailamazyan, Olga Bodrova, Sergey Komarov, Alexander Mikheev, Gerasim Nazarenko. Specificity of Hospital Information System (HIS) Development in the Context of Forming Information Infrastructure and Economie Structure of Russia // Proc.conf. Medinfo-98. - Séoul, 1998.

СТРУКТУРА И ОБЪЕМ ДИССЕРТАЦИИ

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

ЗАКЛЮЧЕНИЕ

Основные результаты, полученные в диссертации, заключаются в следующем:

• исследована роль стандартов в медицинской информатике и их влияние на развитие медицинской информатики;

• разработан подход к формализации медицинских технологических процессов;

. • разработана архитектура системы построения лечебно-диагностических карт;

• разработана архитектура системы поддержки лечебно-диагностического процесса;

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

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

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

• разработанные методы и алгоритмы системы построения лечебно-диагностических карт легли в основу, реализованной в Медицинском центре банка РФ системы ИНТЕРПЛАН.

1. Предложить госпитализацию.

2. Продолжить ингаляции Р2-агонистов + ГКС перорально (преднизолон 30мг) + ингаляции атровента 40мгк с помощью дозированного аэрозоля или 0,5мг через небулайзер или эуфиллин 2,4%-10,0 внутривенно медленно.

3. Оксигенотерапия для достижения сатурации О2 > 90%.

4. Системные кортикостероиды, если нет ответа на лечение или больной недавно принимал стероиды.

5. Продолжить терапию в течение 2х часов, ожидая улучшения. При неполном ответе (ПСВ 50-70%, Sp02 < 90% в/в кортикостероиды (преднизолон 90мг, солюкортеф 100-200мг), эуфиллин в/в кап (мониторинг эуфиллина)).

6. СИСТЕМА ПОСТРОЕНИЯ ЛЕЧЕБНО-ДИАГНОСТИЧЕСКИХ КАРТ (ИНТЕРПЛАН)