Clinical Document Architecture ﴾CDA﴿

Clinical Document Architecture ﴾CDA﴿ — один из стандартов HL7, разработанный для стандартизации структуры и обеспечения семантической совместимости мед систем при обмене медицинской информацией и/или мед документами. Первая версия стандарта была одобрена ANSI ещё в 2001 году. Вторая версия, котороя используется и по сей день, была утверждена ANSI в 2005. Третья версия, CDA R3, находится в стадии разработки и согласования.

CDA R2 (Release 2) гарантирует наличие следующих семи характеристик в CDA документе:
• Сохранность представленной информации;
• Управление представленной информацией;
• Поддержка требований к аутентификации всей представленной информации;
• Поддержка контекста представленной информации;
• Поддержка цельности информации;
• Возможность чтения представленной информации человеком;
• Поддержка бинарной информации, таких как мультимедийные компоненты, PDF, изображения и прочее.

Подобные характеристики делают CDA крайне гибким к использованию в различных областях. И даже несмотря на то, что в среде разработчиков мед систем CDA считается крайне сложным стандартом, он стал одним из наиболее успешных разработанных HL7 для интеграции мед данных и согласуется с требованиями Meaningful Use 1 и 2 принятыми в США. Большинство мед систем в настоящее время кодируют информацию в одном из девяти возможных шаблонов документов CDA, например, Continuity of Care Document (CCD) один из таких шаблонов.

В данной статье представлен обзор или упрощённое описание основных компонентов CDA. И так, как и любой документ, CDA содержит заголовок документа (CDA Header) и тело документа (CDA Body).

CDA Header


image

Как показано на следующей картинке, в заголовоке CDA включена некоторая административная информация на основе классов и сущностей RIM модели HL7.

image

Основной класс в заголовке CDA так и называется — Clinical Document, и, в соответствии с его названием, содержит кроме всего прочего информацию для идентификации документа, заголовок, используемый язык, версию, дату публикации и уровень конфиденциальности. Далее рассмотрим назначение некоторых из выше приведённых классов. Чтобы избежать путаницы названия классов будут даны в их английской транскрипции.

Authenticator


Этот класс включен в документ для идентификации лица и/или организации, которые могут использоваться для проверки подлинности всего содержимого документа CDA.

Recipient


Здесь всё просто, в заголовке документа recipient используется для идентификации получателя (лица и/или организации) документа и может включать такие данные как имя, адрес и прочую информацию. Получателей может быть множество.

Author


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

Custodian


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

Source


В данном классе кодируется информация о лице и/или организации поместившим данные в медицинскую систему, на основе которых и был создан документ. Подобным лицом может быть, например, Data Entry clerk.

Parent CDA


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

Patient


Используя данный класс в заголовке CDA документа представлена информация о главном участнике всех событий – пациенте. Имя, адрес, опекуны и всякая прочая информация для полной идентификации пациента. Стоить заметить, что некоторые типы данных запрещены в некоторых странах. Например, информация о расовой и религиозной принадлежности требуется в США, но недопустима в Европе.

CDA Body


Тело документа или CDA Body может быть как неструктурированным для данных, которые не кодируются в XML, так и структурированным для представленных в формате XML данных. С особенностями такого кодирования тесно связано понятие уровней семантической совместимости CDA (в данной статье не рассматриваются).

В описании ниже также будут использоваться английские названия компонентов или классов.

Non-structured Body


Неструктурированное тело документа может содержать только одно вложение со ссылкой на данные вне этого CDA документа, либо Base64 кодированное бинарное вложение (PDF, изображение, аудио, видео и т.п.).

Structured Body


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

Для устранения подобного разногласия были придуманы шаблоны CDA документов. Создание шаблонов и различных руководств разработчика нацелено на упрощение реализации и ограничения разночтений стандарта для одних и тех же клинических областей. К таким шаблоном относятся Clinical Notes, CCD, Discharge Summary и прочее). Все они представлены на официальном сайте HL7. Кроме того, существует около 70-ти шаблонов секций и ещё больше шаблонов записей.

image

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

Подробнее
Реклама
Комментарии 15
  • 0
    Как-то скупо. Не понятно, как, например, разделять получателей, как передавать имя, адрес.

    Может хотя бы ссылку добавите на официальное описание.
    • 0
      Официальное описание в любом HL7 Normative Edition на HL7.org. Доступно бесплатно, но нужно зарегистрироваться. И, как сказано, неплохо бы иметь Implementation Guides, качаются оттуда же.

      Можно отдельно поискать "Quick Start Guide HL7 Implementation Guide: For Simple CDA Release 2 Documents" от Lantana Group.
      • 0
        О! Знакомая тема. Я тоже когда-то с этим разбирался, на гиктаймс перенесли статью — geektimes.ru/post/139904
        Вы в рамках какого-то исследования или по работе с этим столкнулись?
      • 0
        Так это твоя статья была? У тебя там мало-мало неточности. Например, CDA-евский RMIM (POCD_RM000040) ты называешь HL7 RIM и т.п.
        А так, у меня работа такой — HL7v2, HL7v3, CDA/CCD.
        • +1
          Неточности возможны, да, я глубже в эту тему не пошёл. Ну и времени уже прошло 4 года. Тот проект в другую сторону развернулся, от CDA отказались.
          Интересно работать в этой области? Мне что-то скучновато показалось. Хотя это видимо просто мне не нравится в такого рода стандартах копаться :)
          • 0
            Да нормально в этой области работать.
            • 0
              По крайней мере лучше стандарт, чем еще одна велосипедная модель от очередной фирмы на рынке
              • 0
                Безусловно! Причём стандарт проверенный и разработанный весьма детально и тщательно
          • 0
            в неправильности или неполноте понимания самого стандарта различными организациями
            По наблюдениям, эта «неполнота» понимания возникает в 90% внедрений:)
            Причем CDA — один из самых простых.
            Доля учреждений, работающих по стандартам — мала.
            Наверное, дело все-таки не в людях, а в стандартах.
            • 0
              Я бы сказал «и в людях, и в стандартах». Менять устоявшиеся бизнес процесс мало кому хочется, даже если в какой-то организации полный бардак. Тем не менее, этот бардак как-то же работает. Проблемы начинаются, когда они хотят обмениваться неполными данными с другой подобной организацией, у которой свой такой же конкретный бардак. В результате тратится по полгода только чтобы согласовать как должен называться показатель в каком-то отчёте только потому, что каждая из организацией (их ведь может быть больше чем две участвующих в обмене данными) хочет его видеть таким, какой он у них в данный момент.

              Разработчики стандарта тоже особо ни куда не торопятся. У ведущих HL7 Education Working Group я как-то спрашивал, что мешает им написать понятнее какие секции Normative Edition нужны для сертификации, ибо их «Data Types» в стандарте встречается в двух местах – абстрактное описание типов данных и описание реализации (ITS). Неужели двух-страничный листок с описанием этапов подготовки к сертификации трудно написать четко и ясно. Нет, так и не захотели исправить.

              Ну и всякие прочие факторы. В софтверной индустрии для этого придумали рефакторинг, чтобы как в анеке про парикмахера «А, не получается ничего!» и бритвой по черепу крест-накрест. В индустрии стандартизации такое сходу не пройдёт. Вот сейчас со своим FHIR бегают, хотя messaging и documents в нём как-то очень криво получаются. Посмотрим, как потом это всё в реальном случае будет работать.
              • 0
                Происходит примерно следующее:
                — Эй, давайте по стандарту работать! Интероперабельность, дружба, клиент пойдет, от ошибок избавимся все дела…
                — А давайте.
                — Так, почему на то чтобы записать «платифиллин 30мг внутримышечно» уходит полчаса?
                — А про 20мг мы вообще не можем ничего подобрать! Как теперь детей лечить?
                — Стоп, первая запись касалась побочных эффектов, а назначения — это в другом списке.
                — Да ну нафиг эти стандарты!

                Или так: в двух клиниках одного города установлен Медиалог одинаковых версий, поддерживающий HL7. Клиники часто направляют больных друг к другу. И те в общем порядке заполняют от руки анкету в регистратуре. Что, передать данные электронно? Нет, не можем. Можем сделать выписку — 300р, 3 дня, а там вам ее вобьют заново.

                При этом анкеты работают. Жалкие 10 пунктов неподтвержденного анамнеза снижают смертность и осложнения в несколько раз.
                • 0
                  Так может стоит начинать с тех аспектов, которые не требуют ручного ввода: лаб данные, финансовый биллинг, расписания и прочее подобное?
                  • 0
                    А лабораторные данные они сплошным текстом записывают:)
                    Я так понимаю, не хватает единиц измерения для части показателей, особенно из старых лабораторий.
                    • 0
                      Отобрать карандаши и ручки. :))))

                      Если серьёзно, у нас несколько десятков дополнительных локальных словарей для каждой реализации.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Интересные публикации