Семантические уровни совместимости CDA

«Необходимость в семантической совестимости медицинских документов очевидна. Но что означает эта совместимость по отношению к тому разнообразию данных, которые любая медицинская система предоставляем. Исторически сложилось, что CDA документ определяет три уровня совестемости, на каждом из которых возрастает разнообразие кодируемых данные, а следовательно, и полезность с точки зрения совместимости.»

Выше корявый перевод с одного из сайтов HL7 касательно семантических уровней CDA. Столкнулся с тем, что в силу отсутствия примеров каждый трактует уровни несколько по-своему, поэтому приведём примеры каждого из уровней.

CDA Level 1
На первом уровне, CDA содержит неструктурированные данные представленные в виде, в первую очередь, удобном для человека. В теле CDA документа может использоваться как StructuredBody, так и NonXMLBody для передачи разных, в том числе и бинарных, данных. Максимум удобств для человека означает минимум удобств для кодирования такого взаимодействия.

<title>Medications</title>
<text>Albuterol inhalant - 2 puffs QID PRN wheezing<br/>
Clopidogrel (Plavix) - 75mg PO daily<br/>
Metoprolol - 25mg PO BID<br/>
</text>




CDA Level 2
На втором уровне CDA, данные минимально структурируются, но всё ещё предназначены для человека. Появляется понятие шаблонов секций в теле документа. Структурирование данных позволяет парсить документ, но любое изменение в кодировке ведёт к переделке как минимум парсера документов. В теле документа используется только StructuredBody. Данные кодируются в виде близком к HTML.

<title>Medications</title>
<text>
   <table border="1" width="100%">
      <thead>
         <tr>
            <th>Medication</th>
            <th>Instructions</th>
            <th>Start Date</th>
            <th>Status</th>
         </tr>
      </thead>
      <tbody>
         <tr>
            <td>Albuterol inhalant</td>
            <td>2 puffs QID PRN wheezing</td>
            <td>&#160;</td>
            <td>Active</td>
         </tr>
         <tr>
            <td>Clopidogrel (Plavix)</td>
            <td>75mg PO daily</td>
            <td>&#160;</td>
            <td>Active</td>
         </tr>
         <tr>
            <td>Metoprolol</td>
            <td>25mg PO BID</td>
            <td>&#160;</td>
            <td>Active</td>
         </tr>
      </tbody>
   </table>
</text>




CDA Level 3
На третьем уровне CDA используются шаблоны как для секций, так и для записей внутри секции. Секции могут включать представление данных для человека (в виде HTML как на втором уровне), и обязательно должны включать представление данных для машинного взаимодействия. В примере ниже показана одна из записей. Человеко-читаемая часть не приведена, она как раз над entry и повторяет пример с CDA Level 2.

<entry typeCode="DRIV">
   <substanceAdministration classCode="SBADM" moodCode="EVN">
      <templateId root="2.16.840.1.113883.10.20.1.24"/>
      <!-- Medication activity template -->
      <id root="cdbd33f0-6cde-11db-9fe1-0800200c9a66"/>
      <statusCode code="active"/>
      <effectiveTime xsi:type="PIVL_TS">
         <period value="6" unit="h"/>
      </effectiveTime>
      <routeCode code="IPINHL" codeSystem="2.16.840.1.113883.5.112" codeSystemName="RouteOfAdministration" displayName="Inhalation, oral"/>
      <doseQuantity value="2"/>
      <administrationUnit code="415215001" codeSystem="2.16.840.1.113883.6.96" displayName="Puff"/>
      <consumable>
         <manufacturedProduct>
            <templateId root="2.16.840.1.113883.10.20.1.53"/>
            <!-- Product template -->
            <manufacturedMaterial>
               <code code="307782" codeSystem="2.16.840.1.113883.6.88" displayName="Albuterol 0.09 MG/ACTUAT inhalant solution">
                  <originalText>Albuterol inhalant</originalText>
               </code>
            </manufacturedMaterial>
         </manufacturedProduct>
      </consumable>
      <precondition typeCode="PRCN">
         <criterion>
            <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
            <value xsi:type="CE" code="56018004" codeSystem="2.16.840.1.113883.6.96" displayName="Wheezing"/>
         </criterion>
      </precondition>
   </substanceAdministration>
</entry>

Как делать деньги ни чего не делая

Как это обычно говорится – «внезапно!» - обнаружилось, что регистрация OID теперь платная. Всегда была бесплатная и все кто хотел мог пользоваться, учитывая, что не так уж и много желающих то было, а теперь вдруг платная. Причём за каждый выделенный OID.

На сайте OID Registry (http://www.hl7.org/oid/index.cfm) висит такое объявление:
Starting in June 2014, non-members, student members, and healthcare professionals may purchase OID registrations for $100 each. OID Registry will continue to be free to all other HL7 members (or to individual and organizational members). To be clear, HL7 members are NOT authorized to register OIDs for non-member organizations.

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

=======
OID (Unique Object Identifiers) выполняет роль уникального идентификатора, тоже, что и UUID/GUID. В HL7 используется в качестве глобального идентификатора в документах и сообщениях. Например, системы кодирования SNOMED-CT зарегистрирована под OID 2.16.840.1.113883.6.96, т.е. если указано
<v3:code code="[some code]" codeSystem="2.16.840.1.113883.6.96"/> 

то понятно, что код взят из системы кодирования SNOMED-CT,

А если
<v3:code code="[some code]" codeSystem="2.16.840.1.113883.6.1">

то система кодирования LOINC.

Иногда полезно расшифровывать все коды в явном виде, особенно на этапе разработки и тестирования. И тогда тот же элемент code может быть представлен как:
<v3:code code="48765-2" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Allergies, adverse reactions, alerts"/> 

The 2014 HL7 Interface Technology Survey Results

Опубликована новая версия The 2014 HL7 Interface Technology Survey Results от Core Health Technologies.

Очень интересные данные по FHIR - в то время как у топ-менеджемента есть хоть какое-то понимание о новом стандарте в категории strong, у ИТ манагеров оно отсутствует напрочь.

По количеству используемых HL7 interface технологий, Mirth Connect уверенно разделяет третье место с Point-to-Point не сильно отставая от монстров индустрии.

Автор этого блога оказывает консалтинговые услуги в разработке HL7 интерефейсов на основе Mirth Connect 3.x версий.

FHIR Developer Days

Rene Spronk был so kind выложив видео с предыдущих AID.

AID (Application Implementation and Design) группа разработчиков HL7 специализирующихся на реализации HL7/IHE/DICOM/OpenEHR/SNOMED и прочих сопутствующих стандартов.

Видео доступно по линку - http://vimeo.com/channels/hl7aid

Семантическая совместимость

В одной из интеракций попался такой способ кодирования данных:

<hl7:value unit="{yy/mm/dd}" nullFlavor="NI">
   <hl7:originalText representation="TXT" mediaType="text/plain">14/10/11</hl7:originalText>
</hl7:value>


Первое, что бросается в глаза, вставка с форматом данных - unit="{yy/mm/dd}" - тем не менее, данная вставка соответствует стандарту, ошибки тут нет.

Что, однако, настораживает, что машино-читаемая часть сообщает об отсутствии информации:
<value nullFlavor="NI">



В то время как человеко-читаемая часть указывает на конкретный день:
<originalText>14/10/11</originalText>


Ну и чему верить? Заказчик утверждает, что верить надо машиночитаемой части. Откуда же тогда взялась дата в originalText, что именно у них хранится в базе данных?

Consolidated CDA для Meaningful Use

В общем случае, спецификация CDA содержит описание секций (темплейтов) для самых разных ситуаций. Очевидно, что для конкретных ситуаций не все из них необходимы. Чтобы было понятно, какие секции необходимы для конкретного случая были придуманы дополнительные типы CDA документов, например: CCD (Continuity of Care Documents), C83 (HITSP CDA Content Modules), C32 (HITSP Summary Document), C37 (Lab Report), C48 (XDS-MS Discharge Summary) и другие.

Разные документы могут использовать одни и те же секции, вкладывая в них разный смысл или используя разные уровни кодирования (Level 1 – Level 3).
Чтобы разобраться во всей этой путанице, куча типов документов была изучена на выявления соответствий и разночтений, в результате появился единый тип документа, названный Consolidated CDA.

Презентация на английском.  Видео презенташки по линкам ниже. На момент написания этого поста, кто-то перевёл первые две части на русский.


Part 1 – Introduction to C-CDA and corresponding 2014 Edition EHR Certification Criteria - https://www.youtube.com/watch?v=rZAmLBgcUTQ (eng)
http://rutube.ru/video/d80941ae061509fc53f6e616843c9d19 (рус)

Part 2 – How to use C-CDA to meet 2014 Edition EHR Certification Criteria - https://www.youtube.com/watch?v=L6R1Xideuac (eng)
http://rutube.ru/video/1cc9608a561f0bf1e1498a34fa13aef7/ (рус)

Part 3 – Certification process for C-CDA capabilities required by the 2014 Edition EHR Certification Criteria - https://www.youtube.com/watch?v=2eoAGNXzzDI (eng)
 

SNOMED CT

Иногда приходится слышать, что мол, зачем изобретать велосипед, когда достаточно взять SNOMED CT и вся терминология у нас в кармане. Действительно, что было бы проще... в теории. А на практике сейчас проверим как всё выглядит, благо и пример нужный подвернулся.

Предположим злостному курильщику предложили пройти программу отказа от курения (smoking cessation) и нужно закодировать следующие положения:

  • Курильщик сразу отказался пройти программу;

  • Курильщик согласился пройти программу, но не смог её завершить по причине того, что саму программу ликвидировали.


SNOMED

Простой поиск по термину - smoking cessation – возвращает вышеприведённые результаты, причём некоторые из них относятся к локальным словарям (в данном случае Англии) и некоторые из них deprecated. Сразу стоит заметить, что термины относятся к разных веткам, т.е. нельзя сказать, что если код находится в диапазоне от ... и до ..., то наверное он про smoking cessation. Это к тому, что семантического соответствия не получится если клиники заранее не договорятся какой же именно код используется для приведенных выше двух случаев.

И ведь это только малая часть. Т.е., SNOMED CT предоставляет слишком большую свободу в трактовании терминологии, что ни чуть не лучше, чем если бы клиники сами придумывали свои термины. Для практического использования SNOMED CT, куча специалистов тратит много-месяцев на то, чтобы существенно сократить первоначальный список терминов, оставив из пары сотен тысяч, скажем, только 5-10 тыс терминов.

Clinical Document eXchange

Не так уж и часто спецификации на реальные разработки оказываются доступны для посторонних глаз. Тем интереснее, что Northern Health и Interior Health Authorities (провинция Британская Колумбия, Канада), выложили в открытый доступ, специально для будущих вендоров, спецификации по CDA и механизамам доставки.

Нужно сразу заметить, что это локальные реализации.

Ссылка для скачивания документов - https://bccdx.ca/Pages/docs.aspx