База ГОСТовallgosts.ru » 35. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ » 35.240. Применение информационных технологий

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

Обозначение: ГОСТ ISO 13606-5-2013
Наименование: Информатизация здоровья. Передача электронных медицинских карт. Часть 5. Спецификация интерфейсов
Статус: Действует
Дата введения: 07/01/2015
Дата отмены: -
Заменен на: -
Код ОКС: 35.240.80
Скачать PDF: ГОСТ ISO 13606-5-2013 Информатизация здоровья. Передача электронных медицинских карт. Часть 5. Спецификация интерфейсов.pdf
Скачать Word:ГОСТ ISO 13606-5-2013 Информатизация здоровья. Передача электронных медицинских карт. Часть 5. Спецификация интерфейсов.doc

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



МЕЖГОСУДАРСТВЕННЫЙ СОВЕТ ПО СТАНДАРТИЗАЦИИ, МЕТРОЛОГИИ И СЕРТИФИКАЦИИ

(МГС)

INTERSTATE COUNCIL FOR STANDARDIZATION, METROLOGY AND CERTIFICATION

(ISC)

ГОСТ ISO 13606-5— 2013


МЕЖГОСУДАРСТВЕННЫЙ

СТАНДАРТ

Информатизация здоровья

ПЕРЕДАЧА ЭЛЕКТРОННЫХ МЕДИЦИНСКИХ КАРТ

Часть 5

Спецификация интерфейсов

(ISO 13606-5:2010, IDT)

Издание официальное

Москва

Стакдартикформ

2014


Предисловие

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

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

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

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

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

За принятие проголосовали:

Кратное наименование страны по МКГИСО 3166)004—97

Коп страны по МК (ИСО 3166) 004—97

Сокращенное наименование национального оогана по стандаогиэаиии

Армения

AM

Минэкономики Республики Армения

Беларусь

BY

Госстандарт Республики Беларусь

Киргизия

KG

Кыргызстандарт

Молдова

MD

Мопдова-Стандарт

Россия

RU

Росстандарт

Узбекистан

UZ

Узстандарт

4    Приказом Федерального агентства по техническому регулированию и метрологии от 03 июня 2014 г. No 494-ст межгосударственный стандарт ГОСТ ISO 13606-5—2013 введен в действие в качестве национального стандарта Российской Федерации с 01 июля 2015 г.

5    Настоящий стандарт идентичен международному стандарту ISO 13606-5:2010 Health informatics - Electronic health record communication - Part 5: Interface specification (Информатизация здоровья. Передача электронных медицинских карт. Часть 5. Спецификация интерфейсов).

Международный стандарт разработан Техническим комитетом Межгосударственной электротехнической комиссии ISO/TC 215 «Health informatics» (Информатизация здоровья).

Перевод с английского языка (еп).

Официальные экземпляры международного стандарта, на основе которого подготовлен настоящий межгосударственный стандарт, имеются в ФГУП «СТАНДАРТИНФОРМ».

Степень соответствия — идентичная (IDT)

6 ВВЕДЕН 8ПЕРВЫЕ

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

€> Стандартинформ. 2014

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

Введение

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

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

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

•    описать интерфейсы способами, совместимыми со стандартом HISA (ISO 12967). В частности. представить эти интерфейсы как специализации тех интерфейсов, что описаны в ISO 12967-3;

-    описать интерфейсы на уровне вычислительной точки зрения в терминах эталонной модели открытой распределенной обработки (ЭМ-ОРО). обеспечивая поддержку широкого диапазона инженерных точек зрения, которые могут быть приняты индивидуальными поставщиками или программами «электронного здоровья» (eHealth) (следует учесть, что ISO13606-1. ISO 13606-2 и ISO 13606-4 определяют соответствующую информационную точку зрения, a ISO/TC 18303 - соответствующую корпоративную точку зрения);

сконструировать интерфейсы таким образом, чтобы их было легко реализовать как специализацию стандартных интерфейсов, реализуемых с помощью широко распространенных языков программирования и спецификации, например. Java. Visual Basic. .NET. SOAP. ebXML;

•    совместно с Группой объединенных инициатив разработчиков стандартов (Joint SOO Initiative) и ее Совета (Council) разработать руководства по применению инженерной точки зрения, определяющие детали реализации этих интерфейсов (например, в стандарте HL7 версии 3); эти руководства будут опубликованы отдельно от настоящего стандарта, чтобы обеспечить более динамичное сопровождение и изменение (отражающие практический опыт реализации), чем это предусмотрено процедурой разработки стандартов ISO:

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

учесть, что для управления сервисами безопасности может быть применена архитектура ролевого контроля доступа, описанная в ISO/TC 2600 или ее эквиваленты, и не дублировать или переопределять описания этих сервисов в настоящем стандарте;

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

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

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

a)    в ISO 13606-1 описана эталонная модель объекта EKRJ-XTRACT. представляющего собой часть ЭМК субъекта медицинской помощи;

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

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

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

определенных е 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 и rcjd. содержащиеся в композиции COMPOSITION), рекомендованный третьей стороне. В этом случае третья сторона должна получить прямой доступ к этим данным, если обладает необходимыми разрешениями, и делегирование привилегий не требуется.

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

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Информатизация здоровья ПЕРЕДАЧА ЭЛЕКТРОННЫХ МЕДИЦИНСКИХ КАРТ Часть 5

Спецификация интерфейсов

Health informatics. Electronic health record communication. Part 5. Interface specification

Дата введения — 2015—07—01

1    ОБЛАСТЬ ПРИМЕНЕНИЯ

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

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

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

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

•    выписка EHR EXTRACT данного субъекта медицинской помощи в соответствии с ISO 13606-1:

•    один или несколько архетипов ARCHETYPE в соответствии с ISO 13606-2:

•    информация журнала аудита EHR_AllDITJ_OG_EXTRACT. относящаяся к данному субъекту медицинской помощи, в соответствии с ISO 13606-4.

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

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

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

2    СООТВЕТСТВИЕ

2.1 Сообщение или вызов интеофейса сервиса, предназначенные для запроса всей или части ЭМК субъекта медицинской помощи, должны включать в себя всю информацию, которая в 6.1 приведена как обязательная, и могут содержать любую информацию, изложенную в 6.1 в качестве рекомендуемой. Сервис EHRjxovider должен быть способен обработать всю обязательную и необязательную информацию, переданную в запросе. Предоставление выписки 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:1996. определение 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): Информация, отправленная в систему ведения электронных медицинских карт на постоянное хранение и составляющая часть электронной медицинской карты субъекта медицинской помощи.

(IS013606-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 18306:2004. определение 3.39]

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

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)

OPO - открытая распределенная обработка (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) или определенных архетипов (используя параметр archetypejds);

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

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

•    физиотерапевту необходимо извлечь композицию COMPOSITION (которой нет в местной системе), являющейся целью связи LINK с композицией, хранящейся в местной системе ведения ЭМК. например, чтобы получить информацию о результате консультации по поводу травмы, которая послужила основой для направления пациента на физиотерапию. Соответствующий запрос будет включать в себя конкретный идентификатор rcjd элемента RECORD_COMPONENT в качестве значения параметра rc.ids;

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

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

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

EHR_requester

EHR_provider

I

I

I----

I

Request_EHR_EXTRACT

ИЛИ

1

---

1

I

Г

I

Request_ARCHETYPE

ИЛИ

1

---*1

1

I Request EHR AUDIT LOG EXTRACT I Г *1

EHR_recipient

1

1

1

1

1

Reject_exception

1

1

1

ИЛИ

1

1

1

r«-

1

Return_value_EHR_EXTRACT | ИЛИ

1

r«----

1

Return_value_ARCHETYPE

ИЛИ

1

1

i

| Return value EHR AUDIT LOG EXTRACT i

r*--------------“-------J

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

описанных э настоящем стандарте

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

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

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

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

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

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

Хотя подписки на уведомления, триггеры или условия, при которых сервис 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_prov>der. По этому запросу сервис EHR_provider может выполнить следующие действия:

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

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

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

Наименование

параметра

Описание

Обязатель

ный/

необяза

тельный

Тип данных

Значение по умолчанию (если применимо!

requestjd

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

Необяза

тельный

String

Наименование

параметра

Описание

Обязатель

ный/

необяза

тельный

Тип данных

Значение no умолчанию (если применимо)

subject.of.

care_id

Уникальный идентификатор, с помощью которого сервисы EHR.requester и EHR_provider могут идентифицировать субъект медицинской помощи, чья выписка EHR EXTRACT запрошена

Обяза

тельный

II

purpose

Указание цели запроса должно быть задано. с использованием ка-кой-либо стандартной терминологии

Необяза

тельный

CV

rcjds

Явно заданная совокупность идентификаторов rcjds элементов RECORD.COMPONENT. которые должны быть включены в выписку EHR.EXTRACT. (Согласно требованиям соответствия ISO 13606-1 сформированная выписка EHR.EXTRACT может содержать дополнительные элементы RECORD.COMPONENT. например, композиции COMPOSITION, которые содержат заданные элементы RECORD COMPONENT)

Необяза

тельный

SET<II>

time .period

Интервал дат или времени, за которые запоошены данные ЭМК

Необяза

тельный

IVL<TS>

max.sensitivity

Максимальное значение атрибута чувствительности sensitivity всех элементов RECORD.COMPONENT. включаемых в запрошенную выписку EHR.EXTRACT (любая часть данных ЭМК. имеющих более высокую чувствительность, должна быть исключена из выписки)

Необяза

тельный

Integer

al.versions

Если этот параметр имеет значе-кие True, то должны быть переданы все версии каждой композиции COMPOSITION, включаемой в выписку EHR.EXTRACT сервисом EHR_provider. Если он имеет значе-ние False, то в выписку включаются только самые последние ееосии

Необяза

тельный

Boolean

False

multimedia.

included

Если этот параметр имеет значение True, то в выписке EHR.EXTRACT должны быть сохранены все мультимедийные (инкапсулированные) значения данных. Если он имеет значение False, то все такие значения исключаются из выписки EHR EXTRACT до ее пеоедачи

Необяза

тельный

Boolean

True

archetype.ids

Явно заданная совокупность идентификаторов архетипов. Если значение параметра arcbetype.id релевантного элемента RECORD.COMPONENT входит в эту совокупность, то он включается в выписку EHR.EXTRACT. (Согласно требованиям соответствия ISO 13606-1 сформированная выписка EHR.EXTRACT может содержать дополнительные элементы RECORD.COMPONENT. например, композиции COMPOSITION, которые содержат заданные элементы RECORD COMPONENT)

Необяза

тельный

SET<II>

Наименование

параметра

Описание

Обязатель

ный^

необяза

тельный

Тип данных

Значение по умолчанию (если применимо)

meanings

Явно заданная совокупность кодов понятий. Если значение параметра meaning релевантного элемента RECORD_COMPONENT входит в эту совокупность. то он включается в выписку EHR_EXTRACT. (Согласно требованиям соответствия ISO 13606-1 сформированная выписка EHR_EXTRACT может содержать дополнительные элементы RECORD_COMPONENT. например, композиции COMPOSITION, которые содержат заданные элементы RECORD COMPONENT)

Необяза

тельный

SET<CV>

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

Наименование

паоаметоа

Описание

Обязательный необязательный

Тип даншх

requestjd

Этот параметр должен быть возвращен, если он был пеоедан в запоосе

Необязательный

String

reason

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

Необязательный

CS_reason

Параметры сообщения R£TURN_VALUE_EHR_EXTRACT

Наименование

параметра

Описание

Обязательный/

необязательный

Тип данных

requestjd

Этот параметр должен быть возвращен, если он был передан в запросе.

Необязательный

String

ehr_extract

Выписка EHR_EXTRACT, структура которой определена в ISO 13606-1. содержащая данные, соответствующие параметрам поиска, переданным в запросе. Из нее дополнительно могут быть изъяты данные. к которым сервис EHR_recipient не должен иметь доступа.

Примечание - Обычно не разрешается передавать информацию о том. что такое изъятие данных из выписки имело место

Обязательный

EHR_EXTRACT

6.2 Интерфейс REQUEST.ARCHETYPES

Назначение

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

Описание

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

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

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

Функция REQUEST.ARCHETYPES

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

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

передать сервису EHR.recipient сообщение RETURN.VALUE.ARCHETYPES, содержащее запрошенные архетипы ARCHETYPE. Передача может быть реализована как специализация метода обработки возвращаемого значения, используемого в конкретном транспортном протоколе.

Параметры <

Пункции REQUEST.ARCHETYPES

Наименование

паоаметоа

Описание

Обязательный/

необязательный

Тип данных

request, id

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

бУЮТ

Необязательный

String

archetype.ids

Совокупность идентификаторов архети* пое. которые должны быть предоставлены по данному запросу

Необязательный

SET<II>

concept

Кодированное представление, которому должно соответствовать значение корневого атрибута concept запрошенных архетипов

Необязательный

CV

specializations

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

Необязательный

II

parent.of

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

Необязательный

II

terminology.

available

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

Необязательный

String

language.

available

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

Необязательный

String

Наименование

паоаметоа

Описание

Обязательный/

необязательный

Тип данных

requestjd

Этот параметр должен быть возвращен, если он был передан в запросе.

Необязательный

String

reason

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

Необязательный

CS.reasoo

Параметры сообщения RETURN VALUE ARCHETYPES

Наименование

паоаметоа

Описание

Обязательный:

необязательный

Тип данных

requestjd

Этот параметр должен быть возвращен. если он был передан в запросе

Необязатель

ный

String

archetypes

Совокупность экземпляров архетипов ARCHETYPE, удовлетворяющих параметрам запроса

Обязательный

SET<ARCHETYPE>

6.3 Интерфейс REQUEST_EHR_AUDIT_LOG_EXTRACT

Назначение

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

Описание

Этот интерфейс описывает информацию, которую сервис EHRjequester должен представить сервису 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 может выполнить следующие действия:

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

—    передать сервису EHR.recipient сообщение RETURN_VALUE_ARCHETYPES. содержащее запрошенные архетипы ARCHETYPE. Передача может быть реализована как специализация метода обработки возвращаемого значения, используемого в конкретном транспортном протоколе.

Наименование

параметра

Описание

Обязательны й/нво&я-затвльный

Тип данных

Значение no умоп-чанию (если применимо!

request_id

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

Необяза

тельный

String

subject_of_

carejd

Уникальный идентификатор, с помощью которого сервисы EHR_requester и EHR_provider могут идентифицировать субъект медицинской помощи, для которого запрошена информация журнала аудита EHR AUDIT LOG EXTRACT

Обязатель

ный

II

time ^period

Интервал дат или времени, за которые запрошена информация журнала аудита (период доступа к данным ЭМК)

Необяза

тельный

IVL<TS>

rcjds

Явно заданная совокупность идентификаторов rcjds элементов RECORD_COMPONENT. действия над которыми должны быть переданы в информации журнала аудита

Необяза

тельный

SET<ll>

max_sensitivity

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

Необяза

тельный

Integer

archetypejds

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

Необяза

тельный

SET<ll>

meanings

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

Необяза

тельный

SET<CV

>

using_polictes

Совокупность политик безопасности, равным образом идентифицируемых сервисами EHR_requester. EHR_provider и EHR_recipient. В запрошенной информации журнала аудита будут оставлены сведения только о том доступе, к которому применялись эти политики

Необяза

тельный

SET<CV

>

Наименование

параметра

Описание

Обязательный/

необязательный

Тип данных

requestjd

Этот параметр должен быть возвращен, если он был пеоедан в запоосе

Необязательный

String

reason

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

(Список возможных значений определен в 6.4.)

Необязательный

CS_reason

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

Наменование

паоэмвтоэ

Описание

Обязательный/ необязательна

Тип данных

requestjd

Этот параметр должен быть возвращен. если он был передан в запросе

Необязательный

String

ehr_audit_log_

extract

Информация журнала аудита EHR_AUDlT_LOG_EXTRACT. структура которой определена в ISO 13606-4. содержащая данные, соответствующие параметрам поиска, переданным в запросе. Из нее дополнительно могут быть изъяты данные, к которым сервис EHR_recipient не должен иметь доступа.

Обязательный

EHR AUDIT LOG_EXTRACT

Примечание - Обычно не разрешается передавать информацию о том. что такое изъятие данных имело место

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

Значения перечислимого типа CS.reason

Код

Значение

Описание

REAS01

Нет доступных данных, соответствующих запросу

По запросу могли быть извлечены данные, не авторизованные сервису EHR requester

REAS02

Запрошенное хранилище временно недоступно

Доступ отсутствует вследствие технических проблем

REAS03

Авторизация сервиса EHR_requester не распознана

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

Библиография

(1)    ISO 7498-2:1969. Information processing systems — Open Systems Interconnection — Basic Reference

Model — Part 2: Security Architecture (Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 2. Архитектура защиты информации)

(2)    ISO 17090-1 ;2008. Health informatics — Public key infrastructure — Part 1: Overview of digital certificate

services (Информатизация здоровья. Инфраструктура с открытым ключом. Часть 1. Структура и общие сведения)

(3)    ISO/TS 18308:2004, Health informatics — Requirements for an electronic health record architecture

(Информатизация здоровья. Требования к архитектуре электронного учета здоровья)

(4)    ISO/TS 22600-1, Health informatics — Privilege management and access control — Part 1: Overview

and policy management (Информатизация здоровья. Управление полномочиями и контроль доступа. Часть 1. Общие сведения и управление политикой)

(5)    ISO/TS 22600-2, Health informatics — Privilege management and access control — Part 2: Formal mod

els (Информатизация здоровья. Управление полномочиями и контроль доступа. Часть 2. Формальные модели)

(6)    ISO/TS 22600-3. Health informatics — Privilege management and access control — Part 3: Implementa

tions (Информатизация здоровья. Управление полномочиями и контроль доступа. Часть 3. Реализации)

(7)    ISO/IEC Guide 2:2004, Standardization and related activities — General vocabulary (Руководство no

стандартизации и сопутствующей деятельности. Общий словарь.)

(8)    ISO/IEC 2382-8:1998. Information technology — Vocabulary — Part 8: Security (Информационная тех

нология. Словарь. Часть 8. Безопасность)

(9) ISO 12967-1. Health informatics — Service architecture — Part 1: Enterprise viewpoint

(Информатизация здоровья. Сервисная архитектура. Часть 1. Корпоративная точка зрения)

(10) ISO 12967-2, Health informatics — Service architecture — Part 2: Information viewpoint

(Информатизация здоровья. Сервисная архитектура. Часть 2. Информационная точка зрения)

(11)    ISO 12967-3, Health informatics — Service architecture — Part 3: Computational viewpoint

(Информатизация здоровья. Сервисная архитектура. Часть 3. Вычислительная точка зрения)

(12)    EN 13940-1:2007. Health informatics — System of concepts to support continuity of care — Part 1: Ba

sic concepts (Информатизация здоровья. Система концепций обеспечения непрерывности медицинской помощи. Часть 1. Базовые концепции)

(13)    ISO/IEC 10746-4. Information technology — Open Distributed Processing — Reference Model: Archi

tectural semantics — Part 4 (Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 4. Архитектурная семантика)

УДК 004:61:006.354    МКС 35.240.80    ITD

Ключевые слова: здравоохранение, информатизация здоровья, передача электронной медицинской карты

Подписано в печать 01.11.2014. Формат 60x84%.

Уел. леч. л. 2,33. Тираж 31 экэ. Зак. 4459

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

ФГУП «СТАНДАРТИНФОРМ»

123995 Москва. Гранатный пер., 4.