ГОСТ ISO 13606-5-2013. Межгосударственный стандарт. Информатизация здоровья. Передача электронных медицинских карт. Часть 5. Спецификация интерфейсов

(введен в действие Приказом Росстандарта от 03.06.2014 № 494-ст)

Введен в действие

ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ

1 июля 2015 года

Предисловие

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены в ГОСТ 1.0-2015 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2015 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Порядок разработки, принятия, обновления и отмены»

Сведения о стандарте

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Корпоративные электронные системы», ФБУ «Консультационно-внедренческая фирма в области международной стандартизации и сертификации — „Фирма „ИНТЕРСТАНДАРТ“ и Федеральным государственным учреждением „Центральный научно-исследовательский институт организации и информатизации здравоохранения Росздрава“ (ЦНИИОИЗ Росздрава) на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 5»

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 468 «Информатизация здоровья» при ЦНИИОИЗ Минздрава — постоянным представителем ИСО ТК 215

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 5 ноября 2013 г. № 61-П)

Введение

В настоящем стандарте описаны интерфейсы, с помощью которых можно запрашивать и передавать объект выписки из электронной медицинской карты (EHR_EXTRACT), архетип (ARCHETYPE) или информацию журнала аудита (EHR_AUDIT_LOG_EXTRACT).

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

• описать те интерфейсы, которые уникальны для контекста ISO 13606, и не включать описание более общих коммуникационных интерфейсов, которые могут принадлежать к области применения других стандартов и спецификаций;
• описать интерфейсы способами, совместимыми со стандартом HISA (ISO 12967). В частности, представить эти интерфейсы как специализации тех интерфейсов, что описаны в ISO 12967-3;
• описать интерфейсы на уровне вычислительной точки зрения в терминах эталонной модели открытой распределенной обработки (ЭМ-ОРО), обеспечивая поддержку широкого диапазона инженерных точек зрения, которые могут быть приняты индивидуальными поставщиками или программами «электронного здоровья» (eHealth) (следует учесть, что ISO 13606-1, ISO 13606-2 и ISO 13606-4 определяют соответствующую информационную точку зрения, а ISO/TC 18303 — соответствующую корпоративную точку зрения);
• сконструировать интерфейсы таким образом, чтобы их было легко реализовать как специализацию стандартных интерфейсов, реализуемых с помощью широко распространенных языков программирования и спецификации, например, Java, Visual Basic, .NET, SOAP, ebXML;
• совместно с Группой объединенных инициатив разработчиков стандартов (Joint SDO Initiative) и ее Совета (Council) разработать руководства по применению инженерной точки зрения, определяющие детали реализации этих интерфейсов (например, в стандарте HL7 версии 3); эти руководства будут опубликованы отдельно от настоящего стандарта, чтобы обеспечить более динамичное сопровождение и изменение (отражающие практический опыт реализации), чем это предусмотрено процедурой разработки стандартов ISO;
• учесть, что передача электронной медицинской карты (ЭМК) реализуется в коммуникационной инфраструктуре здравоохранения, обычно национальной, которая определяет общий подход к реализации многих других дополнительных и необходимых сервисов, например, демографических регистров пациентов, регистров поставщиков медицинской помощи, политик и сервисов аутентификации и авторизации и т.д.; поэтому эти сервисы не являются частью формальной области применения настоящего документа, предполагающего их существование;
• учесть, что для управления сервисами безопасности может быть применена архитектура ролевого контроля доступа, описанная в ISO/TC 2600 или ее эквиваленты, и не дублировать или переопределять описания этих сервисов в настоящем стандарте;
• в целях обеспечения более высокого уровня конфиденциальности данных пациента не предоставлять возможность выявления, исключена ли поставщиком данных какая-либо информация при возвращении ответа на запрос;
• обеспечить возможность местных расширений каждого интерфейса и набора терминов, отражающих особые обстоятельства передачи ЭМК, в которых могут быть применены дополнительные требования ограничений.

Настоящий стандарт определяет комплекс интерфейсов, с помощью которых можно запрашивать и передавать артефакты, описанные в ISO 13606-1, ISO 13606-2 и ISO 13606-4:

b) в ISO 13606-2 описана информационная модель архетипа ARCHETYPE, а также необязательная упорядоченная форма представления архетипа на языке определения архетипов ADL (Archetype Definition Language);

c) в ISO 13606-4 описана информация журнала аудита (EHR_AUDIT_LOG_EXTRACT), предназначенная для передачи истории действий, относящихся ко всей ЭМК или ее части и зарегистрированных в этом журнале (ISO 13606-3 определяет списки терминов и эталонные архетипы, к которым прямой интерфейс не требуется; ISO 13606-4 описывает модель доступа, к которой прямой интерфейс также не требуется).

В настоящем стандарте определены три интерфейса, по одному для каждого обмена данными, указанного выше в перечислениях a) - c). Они обеспечивают взаимодействие между сервисом EHR_requester, запрашивающим ЭМК (который инициирует и авторизует передачу артефакта); сервисом EHR_provider (сервисом хранилища, которое содержит артефакты и может предоставить запрошенный артефакт) и сервисом EHR_recipient, который авторизован для получения запрошенного артефакта (обычно совпадает с инициатором запроса EHR_requester, но не всегда). В терминах стандарта HISA (ISO 12967), все эти интерфейсы являются специализацией детальных базовых методов, определенных в ISO 12967-3.

Все эти интерфейсы представлены с помощью спецификаций уровня вычислительной точки зрения в терминах модели ОРО, что позволяет реализовать их с помощью различных (транспортных) формализмов на уровне инженерной точки зрения, например, протоколов передачи сообщений (например, EDIFACT, HL7 версии 3) или протоколов сервисов (например, SOAP, Java RMI). Поэтому настоящий документ специфицирует только «полезную нагрузку», передаваемую при вызове каждого интерфейса. Такие атрибуты, как идентификаторы сообщения, штамп даты и времени, версия сообщения обычно определены и обрабатываются в каждом виде транспортного протокола по-своему, и в настоящем документе не определяется собственный вариант этого вида данных. При этом следует отметить, что и в ISO 13606-1, определяющем структуру объекта EHR_EXTRACT, и в ISO 13606-2, определяющем структуру объекта ARCHETYPE, и в ISO 13606-4, определяющем структуру объекта EHR_AUDIT_LOG_EXTRACT, описаны штампы даты и времени, а также приведена информация об авторстве и управлении версиями как часть информационных моделей этих объектов.

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

Сервис EHR_requester, инициировавший запрос, должен быть аутентифицирован сервисом EHR_provider, выполняющим запрос. Способы аутентификации, а также предоставления удостоверений авторизации также не входят в область применения настоящего стандарта. Они описаны в ISO 22600. В некоторых случаях сервис EHR_requester может указать сервису EHR_provider, что объект EHR_EXTRACT должен быть передан третьей стороне. Настоящий документ может быть применим в архитектуре делегирования, в соответствии с которой сервис EHR_requester действует от имени другой стороны, но представление и передача иерархии авторизаций по пути делегирования являются предметом архитектуры управления привилегиями и контроля доступа и не имеют прямого отношения к настоящему документу. С другой стороны, местные правила могут разрешать безопасную передачу третьей стороне уникальной ссылки на любой конкретный компонент записи электронной медицинской карты (RECORD_COMPONENT) (например, на конкретное направление или выписку из медицинской карты, используя идентификаторы ehr_id и rc_id, содержащиеся в композиции COMPOSITION), рекомендованный третьей стороне. В этом случае третья сторона должна получить прямой доступ к этим данным, если обладает необходимыми разрешениями, и делегирование привилегий не требуется.

На стадии разработки находится ряд руководств, определяющих, как требования настоящего стандарта должны быть реализованы в конкретном протоколе коммуникации/транспорта. Ожидается, что одними из первых будут разработаны руководства для стандарта HL7 версии 3.0, которые будут публиковаться и сопровождаться комитетом Health Level Seven.

1 Область применения

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

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

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

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

• выписка EHR_EXTRACT данного субъекта медицинской помощи в соответствии с ISO 13606-1;
• один или несколько архетипов ARCHETYPE в соответствии с ISO 13606-2;
• информация журнала аудита EHR_AUDIT_LOG_EXTRACT, относящаяся к данному субъекту медицинской помощи, в соответствии с ISO 13606-4.

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

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

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

2 Соответствие

2.1 Сообщение или вызов интерфейса сервиса, предназначенные для запроса всей или части ЭМК субъекта медицинской помощи, должны включать в себя всю информацию, которая в 6.1 приведена как обязательная, и могут содержать любую информацию, изложенную в 6.1 в качестве рекомендуемой. Сервис EHR_provider должен быть способен обработать всю обязательную и необязательную информацию, переданную в запросе. Предоставление выписки EHR_EXTRACT в ответ на такой запрос либо отказ в предоставлении этой информации должны соответствовать требованиям 6.1.

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

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

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

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 контроль доступа (access control): Совокупность средств, обеспечивающих доступ к ресурсам системы обработки данных только авторизованным субъектам авторизованными способами.

[ISO/IEC 2382-8:1998, определение 08.04.01]

3.2 отчетность (accountability): Свойство, обеспечивающее однозначное отслеживание действий субъекта.

[ISO/IEC 2382-8:1998, определение 08.04.10]

3.3 экземпляр архетипа (archetype instance): Экземпляр класса метаданных модели архетипов, определяющий медицинское понятие и ограничения значений, применяемые к одному классу экземпляров элементов в выписке из электронной медицинской карты.

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

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

3.6 аттестующий (attester): Сторона (лицо), сертифицирующая и регистрирующая юридическую ответственность за конкретную единицу информации.

3.7 аттестация (attestation): Процесс сертификации и регистрации юридической ответственности за конкретную единицу информации.

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

[ISO 13606-1:2008, определение 3.9]

3.9 аутентификация (authentication): Процесс надежной идентификации субъекта информационной безопасности путем защищенной ассоциации, установленной между идентификатором и субъектом.

3.10 авторизация (authorization): Предоставление прав.

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

[ISO 13606-1:2008, определение 3.14]

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

[ISO 13606-1:2008, определение 3.15]

3.13 конфиденциальность (confidentiality): Состояние информации, при котором она недоступна неавторизованным лицам, субъектам или процессам.

[ISO 7498-2:1999, определение 3.3.16]

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

[ISO 7498-2:1999, определение 3.3.26]

3.15 распределенная обработка (distributed processing): Обработка информации, при которой дискретные компоненты могут быть расположены в разных местах, или при которой связь между компонентами может допускать задержки или пропадать.

3.16 выписка из электронной медицинской карты (electronic health record extract): Вся электронная медицинская карта субъекта медицинской помощи или ее часть, передаваемая в соответствии с настоящим стандартом.

3.17 информационная архитектура электронной медицинской карты (electronic health record information architecture): Спецификация информационной точки зрения на электронную медицинскую карту в терминах открытой распределенной обработки (ОРО).

3.18 поставщик электронной медицинской карты (electronic health record provider): Легитимный обладатель электронной медицинской карты, передающий ее другому заинтересованному субъекту.

3.19 получатель электронной медицинской карты (electronic health record recipient): Субъект, которому поставщик электронной медицинской карты передает электронную медицинскую карту.

3.20 инициатор запроса электронной медицинской карты (electronic health record requester): Объект, инициирующий запрос на передачу электронной медицинской карты от поставщика к получателю электронной медицинской карты.

3.21 система ведения электронных медицинских карт (electronic health record system): Система, предназначенная для записи, извлечения и преобразования информации в электронных медицинских картах.

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

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

3.24 медицинский агент (healthcare agent): Лицо, прибор или программное обеспечение, выполняющее определенную роль в оказании медицинской помощи.

[EN 13940-1:2007]

3.25 медицинский прибор (healthcare device): Прибор или оборудование, прямо или косвенно участвующие в оказании медицинской помощи отдельному лицу или населению.

3.26 медицинское учреждение (healthcare organization): Учреждение, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или населению.

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

3.27 участник сферы здравоохранения (healthcare party): Лицо, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или населению.

3.28 медицинская услуга (healthcare service): Услуга, предоставляемая с целью прямо или косвенно улучшить состояние здоровья отдельного лица или населения, которым она предоставляется.

3.29 неоспоримость (non-repudiation): Служба, обеспечивающая любой из участвующих сторон подтверждение целостности и происхождения данных (неразрывно друг от друга).

[ISO 17090-1:2008, определение 3.2.21]

3.30 постоянные данные (persistent data): Данные, хранящиеся на постоянной основе.

3.31 конфиденциальность (privacy): Свобода от вмешательства в частную жизнь или дела отдельного лица, если такое вмешательство является следствием неправомочного или незаконного сбора и использования сведений о данной личности.

[ISO/IEC 2382-8:1998, определение 08.01.23]

3.32 элемент записи (record component): Часть выписки из электронной медицинской карты одного субъекта медицинской помощи, представленная как узел в иерархической структуре данных, соответствующей ISO 13606.

3.33 роль (role): Совокупность образов действий, связанная с решаемой задачей.

Примечание - Адаптировано из ISO 17090-1.

3.34 совместно используемая электронная медицинская карта (shareable electronic health record): Электронная медицинская карта со стандартизованной информационной моделью, не зависящая от систем ведения электронных медицинских карт и доступная многим авторизованным пользователям.

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

[ISO/IEC Guide 2:2004, определение 3.2]

3.36 состояние (процесса) [state (of a process)]: Условие или ситуация, в которых находится объект в период его жизненного цикла, и при которых данный объект удовлетворяет некоторому условию, выполняет некоторое действие или ожидает некоторого события.

[ISO/TC 18308:2004, определение 3.39]

3.37 субъект медицинской помощи (subject of care): Лицо, которому запланировано оказание медицинской помощи, получающее или получившее медицинскую помощь.

4 Условные обозначения и сокращения

CEN — Comite Europeen de Normalisation (Европейский комитет по стандартизации);

ЭМК — электронная медицинская карта (electronic health record, EHR);

HISA — Health Informatics Service Architecture (архитектура сервисов информатизации здоровья — акроним для обозначения EN 12967);

HL7 — Health Level Seven (организация — разработчик стандартов информатизации здоровья);

ISO — Международная организация по стандартизации (International Organization for Standardization);

ОРО — открытая распределенная обработка (Open Distributed Processing, описана в ISO/IEC 10746-4).

5 Взаимодействия

В пяти частях ISO 13606 определены способы передачи следующей информации:

• вся ЭМК или ее часть (объект EHR_EXTRACT, определенный в ISO 13606-1);
• архетип (объект ARCHETYPE, определенный в ISO 13606-2);
• журнал аудита (объект EHR_AUDIT_LOG_EXTRACT, определенный в ISO 13606-4).

В ISO 13606-1 — ISO 13606-4 описаны информационные модели и терминология, которые вместе взятые определяют информационную точку зрения на передачу ЭМК. В настоящем стандарте описан комплекс коммуникационных интерфейсов (на уровне вычислительной точки зрения).

Эта вычислительная точка зрения намеренно выражена обобщенным способом, позволяющим на ее основе строить различные инженерные точки зрения, которые можно использовать для реализации этих интерфейсов, например, используя обмен сообщениями или вызовы сервисов, соответствующие таким стандартам, как HL7 версии 3, EDIFACT, ebXML, Java, CORBA, SOAP и т.д. Настоящий стандарт является обобщенным и по отношению к формально поддерживаемым сценариям взаимодействия пользователей. В здравоохранении существует множество вариантов взаимодействия, требующих передачи (или совместного использования) ЭМК, в которых могут участвовать различные типы действующих лиц (например, медицинские специалисты, пациенты, семьи и лица, занятые уходом, менеджеры, исследователи и официальные представители) и систем (например, клинические приложения, приложения для смартфонов, системы ведения ЭМК, системы обеспечения принятия медицинских решений, системы выдачи отчетов, системы обеспечения информационной безопасности или аудита). Взаимодействие может иметь место внутри организации и между организациями и пересекать границы вычислительной сети здравоохранения.

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

• лечащему врачу пациента, госпитализированного в районную больницу, необходимо ознакомиться с последними экземплярами композиций COMPOSITIONS, созданными в системе ведения ЭМК семейного врача этого пациента. В этом случае параметры запроса могут включать в себя диапазон дат;
• семейному врачу пациента необходимо ознакомиться со всеми экземплярами композиций COMPOSITIONS, документирующими недавний прогресс в управлении лечением онкологического заболевания этого пациента в системе ведения ЭМК местной больницы. В этом случае параметры запроса могут включать в себя диапазон дат и задавать выборку определенного типа клинических данных по кодированному термину (используя параметр meaning) или определенных архетипов (используя параметр archetype_ids);
• медицинской сестре отделения экстренной помощи, выполняющей сортировку пациентов, необходимо получить информацию обо всех лекарственных назначениях субъекту медицинской помощи, сделанных в прошлом году во всех медицинских организациях. В этом случае требуется запрос к национальному хранилищу ЭМК или к национальной системе ведения виртуальной ЭМК для получения выписок EHR_EXTRACT, содержащих информацию о лекарственных назначениях;
• чтобы завершить переход пациента от одного семейного врача к другому, принимающий врач извлекает всю ЭМК пациента, хранящуюся в системе ведения ЭМК другого семейного врача (включая все версии каждой композиции COMPOSITION);
• физиотерапевту необходимо извлечь композицию COMPOSITION (которой нет в местной системе), являющейся целью связи LINK с композицией, хранящейся в местной системе ведения ЭМК, например, чтобы получить информацию о результате консультации по поводу травмы, которая послужила основой для направления пациента на физиотерапию. Соответствующий запрос будет включать в себя конкретный идентификатор rc_id элемента RECORD_COMPONENT в качестве значения параметра rc_ids;
• администратору клинической информационной системы, которому требуется разработать новую экранную форму и отчеты о ведении пациентов с диабетическим кетоацидозом, необходимо запросить и загрузить последние версии архетипов, предназначенных для представления этой информации, из сертифицированного хранилища архетипов, эксплуатируемого национальной профессиональной организацией специалистов по лечению диабета;
• субъекту медицинской помощи, который в то же время является сотрудником больницы, необходимо просмотреть записи журнала аудита, относящиеся к его последней госпитализации, чтобы определить, кто имел доступ к его ЭМК.

Все эти сценарии имеют то общее, что данные ЭМК (объекты EHR_EXTRACT, ARCHETYPE и EHR_AUDIT_LOG_EXTRACT) запрашиваются одним процессом и предоставляются другим процессом, который может и отклонить запрос на предоставление данных. В настоящем стандарте запрашивающая сторона обозначается как EHR_requester, сторона или служба, способная предоставить данные ЭМК способом, определенным в настоящем стандарте, обозначается как EHR_provider, а сторона или служба, которая должна получить запрошенные данные, обозначается как EHR_recipient. Хотя для передачи ЭМК существует большое число разных конкретных сценариев, на логическом уровне все они могут быть описаны диаграммой последовательности, показанной на рисунке 1.

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

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

Сервис EHR_provider должен или заранее иметь информацию об аутентификации и авторизации (привилегиях) инициатора запроса EHR_requester, либо располагать средствами ее проверки в момент запроса.

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

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

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

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

Хотя подписки на уведомления, триггеры или условия, при которых сервис EHR_provider отправляет данные ЭМК заинтересованной стороне, например, используя делегирование или сервис обновления, не входят в область применения настоящего стандарта, его вполне можно использовать и для такой архитектуры.

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

6 Интерфейсы

6.1 Интерфейс REQUEST_EHR_EXTRACT

Назначение

Этот интерфейс должен использоваться для запроса данных конкретной выписки из медицинской карты EHR_EXTRACT (определенной в ISO 13606-1), передаваемого сервису, который предположительно может ее предоставить. Запрашивающий сервис обозначается как EHR_requester. Сервис, который предположительно может предоставить выписку EHR_EXTRACT, обозначается как EHR_provider, а сервис, которому должна быть направлена эта выписка, — EHR_recipient.

Описание

Этот интерфейс описывает информацию, которую сервис EHR_requester должен представить сервису EHR_provider, чтобы как можно точнее специфицировать данные ЭМК, включаемые в выписку EHR_EXTRACT. В этой информации могут быть указаны такие ограничения на данные, извлекаемые из ЭМК, как интервал дат, определенный список архетипов, включаемых в выписку, и т.д. Если указано несколько ограничений, то извлекаемые данные должны удовлетворять им всем (то есть формируется пересечение данных).

В запросе должен быть указан субъект медицинской помощи, к которому относится требуемая выписка EHR_EXTRACT. Настоящий стандарт не содержит требований к тому, должны ли сервисы EHR_requester и EHR_provider согласовать общий демографический идентификатор субъекта медицинской помощи или же они должны воспользоваться системным идентификатором субъекта, получаемым по демографическим данным до вызова данного интерфейса. Эти вопросы, однако, должны быть урегулированы до начала использования интерфейса.

Политики безопасности, применяемые к данному запросу, включая авторизацию сервиса EHR_requester и все конкретные информированные согласия, относящиеся к этому запросу, должны быть согласованы заранее или переданы параллельно с данным запросом. Способ передачи политик безопасности не входит в область применения настоящего стандарта, но для его выбора можно воспользоваться ISO/TC 22600-1, ISO/TC 22600-2 и ISO/TC 22600-3. В настоящем стандарте предполагается и требуется, чтобы для передачи всех необходимых политик (или для общего доступа к ним) такие способы были предоставлены.

Список функций

Функция REQUEST_EHR_EXTRACT

Для извлечения требуемой выписки из ЭМК сервис EHR_requester должен вызвать функцию REQUEST_EHR_EXTRACT, предоставляемую интерфейсом сервиса EHR_provider. По этому запросу сервис EHR_provider может выполнить следующие действия:

• возвратить сервису EHR_requester сообщение REJECT_EXCEPTION, указывающее причину, по которой запрошенная выписка EHR_EXTRACT не может быть предоставлена (если возможность такого возврата имеется). Возврат может быть реализован как специализация метода обработки исключений, используемого в конкретном транспортном протоколе;
• передать сервису EHR_recipient сообщение RETURN_VALUE_EHR_EXTRACT, содержащее запрошенную выписку EHR_EXTRACT. Передача может быть реализована как специализация метода обработки возвращаемого значения, используемого в конкретном транспортном протоколе.

Параметры функции REQUEST_EHR_EXTRACT

Параметры сообщения RETURN_VALUE_EHR_EXTRACT

6.2 Интерфейс REQUEST_ARCHETYPES

Назначение

Этот интерфейс должен использоваться для запроса одного или нескольких архетипов ARCHETYPE (определенных в ISO 13606-2), передаваемого сервису, который предположительно может их предоставить. Запрашивающий сервис обозначается как EHR_requester. Сервис, который предположительно может предоставить архетипы ARCHETYPE, обозначается как EHR_provider, а сервис, которому должны быть направлены эти архетипы — EHR_recipient.

Описание

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

• возвратить сервису EHR_requester сообщение REJECT_EXCEPTION, указывающее причину, по которой запрошенные архетипы ARCHETYPE не могут быть предоставлены (если возможность такого возврата имеется). Возврат может быть реализован как специализация метода обработки исключений, используемого в конкретном транспортном протоколе;
• передать сервису EHR_recipient сообщение RETURN_VALUE_ARCHETYPES, содержащее запрошенные архетипы ARCHETYPE. Передача может быть реализована как специализация метода обработки возвращаемого значения, используемого в конкретном транспортном протоколе.

Параметры функции REQUEST_ARCHETYPES

Параметры сообщения REJECT_EXCEPTION

Параметры сообщения RETURN_VALUE_ARCHETYPES

6.3 Интерфейс REQUEST_EHR_AUDIT_LOG_EXTRACT

Назначение

Этот интерфейс должен использоваться для запроса специфической информации журнала аудита EHR_AUDIT_LOG_EXTRACT (определенной в ISO 13606-4), передаваемого сервису, который предположительно может ее предоставить. Запрашивающий сервис обозначается как EHR_requester. Сервис, который предположительно может предоставить информации журнала аудита EHR_AUDIT_LOG_EXTRACT, обозначается как EHR_provider, а сервис которому должна быть направлена эта информация, — EHR_recipient.

Описание

Этот интерфейс описывает информацию, которую сервис EHR_requester должен представить сервису EHR_provider, чтобы как можно более точно специфицировать информацию журнала аудита, которую сервис EHR_provider должен передать сервису EHR_recipient. Если в этом запросе указано несколько ограничений, то извлекаемая информация журнала аудита EHR_AUDIT_LOG_EXTRACT должна удовлетворять им всем (то есть формируется пересечение информации).

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

Политики безопасности, применяемые к данному запросу, включая авторизацию сервиса EHR_requester и все конкретные информированные согласия, относящиеся к этому запросу, должны быть согласованы заранее или переданы параллельно с данным запросом. Способ передачи политик безопасности не входит в область применения настоящего стандарта, но для его выбора можно использовать ISO/TC 22600-1, ISO/TC 22600-2 и ISO/TC 22600-3. В настоящем стандарте предполагается и требуется, чтобы для передачи всех необходимых политик (или для общего доступа к ним) такие способы были предоставлены.

Список функций

Функция REQUEST_EHR_AUDIT_LOG_EXTRACT

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

• возвратить сервису EHR_requester сообщение REJECT_EXCEPTION, указывающее причину, по которой запрошенные архетипы ARCHETYPE не могут быть предоставлены (если возможность такого возврата имеется). Возврат может быть реализован как специализация метода обработки исключений, используемого в конкретном транспортном протоколе;
• передать сервису EHR_recipient сообщение RETURN_VALUE_ARCHETYPES, содержащее запрошенные архетипы ARCHETYPE. Передача может быть реализована как специализация метода обработки возвращаемого значения, используемого в конкретном транспортном протоколе.

Параметры функции REQUEST_EHR_AUDIT_LOG_EXTRACT

Параметры сообщения RETURN_VALUE_EHR_AUDIT_LOG_EXTRACT

6.4 Список кодируемых значений

Значения перечислимого типа CS_reason

БИБЛИОГРАФИЯ