Приложение В (справочное). Обоснование структуры расширенных клинических данных

Приложение В
(справочное)

Обоснование структуры расширенных клинических данных

В.1 Введение

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

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

Пластиковые карты пациентов в комплексе с соответствующим карточным приложением (карточной системой) могут считаться передаточными агентами в соответствии с терминологией ENV 13607. См. рисунок В.1.

Рисунок В.1 - Пластиковая карта пациента как компонент передаточного агента

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

Рисунок В.2 - Агент как посредник между запрашивающим и отвечающим поставщиками

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

В.2 Построение структуры расширенных клинических данных

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

ENV 1613 Medical informatics - Messages for exchange of laboratory information;

ENV 12538 Medical informatics - Messages for patient referral and discharge;

ENV 12539 Medical Informatics - Request and report messages for diagnostic service departments;

HL7 Version 2 Chapter 4 Order Entry, Chapter 7 Observation Reporting, Chapter 11 Patient Referral;

HL7 Clinical Document Architecture;

UN/EDIFACT Messages MEDREQ and MEDRPT;

DICOM 3.0.

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

Рисунок В.3 - Уровни структуры сообщения

Несколько лет назад комитет ASC X12N столкнулся с аналогичной проблемой конструирования структуры клинических данных при формировании приложений к счетам на оплату. Комитет принял решение использовать отображения сообщения клинического заказа стандарта HL7 версии 2 на первом уровне, уровне сообщения: сообщение ORU (Observational Report Unsolicited - отчет о результатах обследования) встраивался в сегмент двоичных данных BIN. Такой подход существенно упростил задачу внедрения и поддержания стандарта.

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

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

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

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

Пластиковая карта пациента может также содержать кодированный список проблем пациента, диагнозов или процедур. Такой список расширяет основные клинические данные, определенные в ИСО 21549-3. Он также может быть полезен при оказании скорой и неотложной помощи. Каждая запись такого списка содержит кодированную фразу, построенную с помощью подходящей клинической классификации или системы кодирования, например, ICD, СРТ, SNOMED International, SNOMED RT, SNOMED СТ. Определение типа данных ConceptDescriptor является производным от типа данных CD, определенного в ИСО 21090.