CDA на FHIR определяет, как реализовать CDA R2 с помощью ресурса FHIR Composition .
Первоначальная архитектура клинических документов (CDA) HL7 определяла структуру и семантику «клинических документов». с целью обмена.
Клинический документ - это документация клинических наблюдений и услуг со следующими характеристиками:
Стойкость - клинический документ продолжает существовать в неизменном состоянии в течение периода времени, определенного местными и нормативными требованиями (ПРИМЕЧАНИЕ. Для клинического документа существует определенная область постоянства, независимо от стойкости любого XML-кодированного документа. Экземпляр документа АКД).
Управление - клинический документ поддерживается организацией, которой доверена его забота.
Возможность аутентификации - клинический документ - это совокупность информации, которая предназначена для юридической аутентификации.
Контекст - клинический документ устанавливает контекст для его содержания.
Полнота - аутентификация клинического документа применяется ко всему и не применяется к частям документа без полного контекста документа.
Документ CDA на FHIR - это определенный и полный информационный объект, который может включать текст, изображения, звуки и другой мультимедийный контент.
7.17.4.2 Объем CDA на FHIR
Сфера CDA на FHIR - стандартизация клинических документов для обмена.
Формат данных клинических документов вне контекста обмена (например, формат данных, используемый для хранения клинических документов) в этой спецификации не рассматривается.
CDA на FHIR не определяет создание или управление документами, а только разметку их обмена. Хотя схему АКД можно напрямую использовать в среде разработки документов, такое использование не является основной целью спецификации АКД.
Управление документами критически взаимосвязано со спецификациями АКД, но спецификация сообщений управления документами выходит за рамки АКД.
7.17.4.3 Цели и принципы дизайна
Цели CDA на FHIR:
Отдавайте приоритет оказанию помощи пациентам.
Обеспечьте рентабельное внедрение в максимально широком спектре систем.
Поддержка обмена удобочитаемыми документами между пользователями, в том числе с разным уровнем технической подготовки.
Обеспечение долговечности всей информации, закодированной в соответствии с этой архитектурой.
Включите широкий спектр приложений для обработки после обмена.
Будьте совместимы с широким спектром приложений для создания документов.
Продвигайте обмен, который не зависит от основного механизма передачи или хранения.
Достаточно быстро подготовьте дизайн.
Разрешить политикам контролировать свои собственные требования к информации без расширения этой спецификации.
Из рассмотрения вышеуказанных целей вытекают несколько принципов проектирования:
Эта архитектура должна быть совместима с XML и JSON.
Эта архитектура должна быть совместима с представлениями клинической информации, полученной от других комитетов HL7.
Технические барьеры для использования архитектуры должны быть сведены к минимуму.
Архитектура определяет представление экземпляров, необходимых для обмена.
Архитектура должна налагать минимальные ограничения или требования на структуру и контент документа, необходимые для обмена.
Архитектура должна быть масштабируемой для размещения мелкозернистой разметки, такой как структурированный текст и закодированные данные.
Спецификации документов, основанные на этой архитектуре, должны учитывать такие ограничения и требования, которые предоставляются соответствующими профессиональными, коммерческими и регулирующими органами.
Спецификации документов для создания и обработки документов, если они предназначены для обмена, должны соответствовать этой архитектуре обмена.
Документы CDA должны быть удобочитаемыми с использованием широко доступных и широко используемых браузеров с поддержкой XML и драйверов печати, а также общей таблицы стилей CDA, написанной на стандартном языке таблиц стилей.
Используйте открытые стандарты.
7.17.4 Общий CDA по концепциям FHIR
7.17.4.1 Основные компоненты CDA в документе FHIR
Этот раздел служит введением высокого уровня в основные компоненты документа АКД, все из которых будут описаны снова и более подробно позже. Цель здесь - познакомить читателя с концепциями высокого уровня, чтобы облегчить понимание следующих разделов.
[РЕДАКТОРЫ: в CDA r2 есть множество подробностей о том, как упакован CDA - и пример. Подумайте, уместно ли здесь обсуждение: «Документ CDA заключен в элемент < ClinicalDocument > и содержит заголовок ...»]
7.17.4.2 Удобочитаемость и отрисовка документов CDA
Требование CDA к удобочитаемости человека гарантирует, что получатель документа CDA может алгоритмически отображать клиническое содержание заметки в стандартном веб-браузере.
Для получателя произвольного документа АКД должен существовать детерминированный способ визуализации заверенного содержимого.
Для удобочитаемости отправитель не должен передавать специальную таблицу стилей вместе с документом АКД. Должна быть предусмотрена возможность визуализации всех документов АКД с помощью единой таблицы стилей и инструментов отображения общего рынка.
Удобочитаемость применяется к аутентифицированному контенту. В документе может содержаться дополнительная информация, предназначенная в первую очередь для машинной обработки, которая не аутентифицирована и не требует отображения.
Когда структурированный контент выводится из повествования, должен быть механизм для описания процесса (например, автором, человеком-программистом, алгоритмом обработки естественного языка, конкретным программным обеспечением), с помощью которого обрабатываемые машиной части были получены из блока. повествования.
Когда повествование создается из структурированного контента, должен быть механизм, позволяющий идентифицировать процесс, с помощью которого повествование было создано из структурированных данных.
Эти принципы и требования привели к нынешнему подходу, при котором отображаемый материал помещается в Section.content.
[РЕДАКТОРЫ: В нынешнем дизайне неясно, где постоянно искать повествование.]
Implementation Support
Work Group
|
Propose a change 
