ГОСТ ISO 13606-5—2013
определенных в 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.
V