Примечание - Точный метод упаковки и передачи экземпляра АКД-документа в сообщении не входит в область применения настоящего стандарта. Описанный в этом подразделе метод кодирования по стандарту MIME не является нормативным, он приведен в качестве иллюстрации одного из способов передачи документов, удовлетворяющих описанным ниже требованиям.
Любая стратегия передачи АКД-документов должна включать в себя следующие требования:
- должна обеспечиваться возможность включения всех компонентов АКД-документа, являющихся неотъемлемыми частями его состояния целостности (например, заверенные мультимедийные данные), в один пакет передачи;
- если ссылки перестают быть доступными после передачи сообщения через межсетевой экран, то должна обеспечиваться возможность включения отображаемого содержания в один пакет передачи;
- должна обеспечиваться возможность включения всех вспомогательных файлов, ассоциированных с АКД-документом и обеспечивающих получателю возможность отображения содержания в соответствии с пожеланиями отправителя (например, одной или нескольких таблиц стилей), в один пакет передачи;
- при создании пакета передачи, включающего базовый АКД-документ, не должна возникать необходимость изменения любых ссылок, содержащихся в этом документе (например, ссылок на заверенное мультимедийное содержание, передаваемое в отдельном файле);
- при извлечении содержания из полученного пакета, включающего базовый АКД-документ, не должна возникать необходимость изменения любых содержащихся в нем ссылок;
- при создании пакета передачи не должна возникать необходимость изменения каких-либо значений XML-атрибутов ID;
- не должно быть никаких ограничений на структуру папок файлов, используемую получателем. Получатели АКД-документа должны иметь возможность размещения его компонентов в папках по своему усмотрению;
- в пакет передачи должны быть включены ключевые метаданные АКД-документа, необходимые для управления документами (например, состояние документа, статус архивирования документа). (Полную информацию о метаданных клинического документа, управлении документами, а также о состояниях документа и переходах состояний см. в спецификации HL7 V3 Medical Records).
В контексте сообщений, определенных в стандартах HL7 2.x и V3, АКД-документ можно рассматривать как мультимедийный объект, который может передаваться в поле с типом данных ED (инкапсулированные данные) закодированным в соответствии со спецификацией многоцелевых расширений интернет-почты MIME (Multipurpose Internet Mail Extensions, RFC 2046).
В текущей спецификации MIME рекомендуется следовать подходу, изложенному в Интернет-стандарте RFC 2557 "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)" (инкапсулирование агрегированных документов, например, HTML (MHTML), в пакет MIME) и предусматривающему инкапсуляцию в пакетах MIME агрегированных документов, передаваемых в соответствии с протоколами ebXML и DICOM.
В любых сообщениях стандарта HL7 V2.x, позволяющих передавать документы (например, в сообщении MDM), АКД-документы должны передаваться в сегментах OBX. При этом пакет MIME передается в поле OBX-5 (00573 "Результат исследования") как значение типа данных ED. Полю OBX-2 (00570 "Тип значения") должно быть присвоено значение "ED". Значения поля OBX.3 должно быть тем же самым, что и значение компонента ClinicalDocument.code.
Значения многих полей сообщения перекрываются со значениями компонентов АКД-документа. В таблице 3 показано соответствие между полями сегмента TXA, передаваемого в сообщении HL7 V2 MDM, на компоненты АКД-документа.
Таблица 3 - Отображение полей сегмента HL7 V2 TXA на компоненты АКД-документа
Поле сегмента TXA | Компонент АКД-документа |
2 Тип документа | ClinicalDocument.code |
4 Дата и время действия | ServiceEvent.effectiveTime |
5 Код/ФИО основного лица, ответственного за выполнение действия | ServiceEvent performer |
6 Дата и время создания документа | ClinicalDocument.effectiveTime |
7 Дата и время ввода документа | dataEnterer.time |
9 Код/ФИО автора документа | author |
11 Код/ФИО лица, которое ввело документ | dataEnterer |
12 Уникальный номер документа | ClinicalDocument.id |
13 Номер документа-родителя | ParentDocument.id |
14 Номер заказа у заказчика | Order.id |
18 Статус конфиденциальности документа | ClinicalDocument.confidentialityCode |
19 Статус доступности документа | authenticator, legalAuthenticator |
22 Штамп исполнителя, отвечающего за аутентичность документа | informationRecipient |
23 Разосланные копии (коды и ФИО получателей) | ServiceEvent.effectiveTime |
В следующем примере показано не нормативное, но допустимое использование спецификации RFC 2557 в сообщении стандарта HL7 V2. Возможны и другие допустимые представления.
Пример 3
MSH |...
EVN |...
PID |...
PV1 |...
TXA |...
OBX |1|ED|11492-6^History and Physical^LN||
^multipart^related^A^
MIME-Version: 1.0