ПРЕДЛОЖЕНИЯ

по обеспечению информационная совместимости медицинских компьютерных систем

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

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

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

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

- возможность формирования запросов на основе информации из банков данных любых интегрированных систем (2-й этап); например, найти всех мужчин старше 40 лет с систолическим АД больше 140 (компьютерная система «Функциональные исследования») и изменениями на ЭКГ (компьютерная система «Анализ ЭКГ»)

 

Главный регистр пациентов медучреждения

Рассматривалось несколько вариантов алгоритма формирования главного регистра пациентов:

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

Плюсы:

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

Минусы:

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

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

- несмотря на смысловую идентичность регистров прикрепленного населения, создаваемых страховыми компаниями (например, в Москве в сфере ОМС работают страховые компании МАКС-М, РОСНО-МС, Медстрах, Спасские Ворота), их конкретные реализации - типы баз данных (FoxPro, Paradox), имена полей и их типы - различны; это создает дополнительные трудности при унификации программных средств «привязки» к этим регистрам,

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

Вариант 2. Главный регистр формируется путем первоначального копирования существующего регистра прикрепленного населения страховой компании с последующей «подкачкой» информации при появлении в регистре страховой компании новых записей (пациентов) и (или) добавлением информации из интегрированных систем («ЭКГ», «Лаборатория», «Флюорография» и т.д.)

 

Главный регистр пациентов и банки данных интегрированных систем должны включать, как минимум, набор полей, обеспечивающих полноценную идентификацию пациента, как в системе медучреждения в целом, так и в интегрированной системе. Предлагаемый список полей приведен в прил. - www.armit.ru/standard/fields_reg.html

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

Плюсы:

- интегрированные системы полностью «отвязаны» от регистров страховых компаний,

- главный регистр может формироваться по нескольким «линиям»: как из регистра страховой компании, так и интегрированными системами,

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

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

- вместо связи «всех со всеми» (каждой интегрированной системы с каждым регистром страховой компании) мы приходим к существенному упрощению задачи: «перекачка» данных «регистр страховой компании à главный регистр» и связь «интегрированные системы ß à главный регистр».

Минусы:

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

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

Алгоритм работы с главным регистром пациентов

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

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

3. «Привязка» данных в интегрированных системах к главному регистру пациентов осуществляется по PIN-коду пациента. В качестве PIN-кода может использоваться любой уникальный идентификатор пациента: номер полиса ОМС (что, к сожалению, не всегда и не везде возможно), уникальный идентификатор, внешний идентификатор (например, табельный номер пациента для медсанчасти предприятия), уникальный PIN автоматически формируемый в данном медучреждении. Основное требование к PIN-коду – гарантия его уникальности в пределах главного регистра. В идеале им мог бы быть общегосударственный идентификатор (код социального страхования и т.п.).

При таком алгоритме:

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

    - отпадает необходимость в создании «единой» базы данных,

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

    - не изменяется алгоритм работы с интегрированной системой; она «остается» самодостаточной.

Формирование интегральной медицинской карты.

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

 

Разделы интегральной медицинской карты	Программа, «обслуживающая» раздел данных
Паспортные данные	Анкета
Лабораторные исследования	Labor
ЭКГ	ECG
Флюорография	Flu
УЗИ	Ultra Sonic

2. В запросе на формирование интегральной медкарты выбранного пациента задаются его PIN-код, а также дополнительные характеристики исследования: фиксированная дата, временной интервал (например, последняя неделя, последний год), последнее или единственное исследование и т.д.

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