ГОСТ Р ИСО/HL7 27932-2015 Информатизация здоровья. Стандарты обмена данными. Архитектура клинических документов HL7. Выпуск 2

     5.8 Указания по реализации

5.8.1 Создание АКД-документов

Введение

Для создания АКД-документов используется все более возрастающее разнообразие средств и методов:

- операторский ввод: большинство клинических документов создаются с помощью речевого интерфейса. В настоящее время и крупные, и малые производители средств операторского ввода обеспечивают возможность передачи введенных документов в формате АКД. Некоторые из них обеспечивают встроенные возможности анализа текста на естественном языке, позволяющие создавать кодированные структуры внутри АКД-документов, являющихся результатом обработки диктовки;

- системы ведения электронных медицинских карт: многие производители систем ведения электронных медицинских карт обеспечивают экспорт документов в формате АКД. Обычно это не является стандартной функцией и делается по запросу. Для этих систем формат АКД представляется относительно простым форматом вывода;

- XML-формы: новое поколение средств конструирования XML-форм позволяет создавать формы ввода, при заполнении которых создаются АКД-документы;

- база знаний: по крайней мере один из основных поставщиков медицинской помощи США разработал редактор АКД-документов поверх базы знаний, предназначенный для структурированного ввода с доступом к базе;

- динамический запрос: в некоторых распределенных приложениях используется динамическое создание АКД-документов для предварительного заполнения из существующих хранилищ данных, например из баз данных результатов лабораторных анализов. Этот метод может использоваться в сочетании с другими методами.

В данном приложении конкретные средства и методы не рассматриваются, оно служит общим руководством по использованию АКД при создании документов.

Прежде чем начать: соответствие модели RIM:

- структуры, словарь, типы данных.

Создание экземпляра документа, соответствующего спецификации АКД, означает, что структура содержащейся в нем информации определена моделью RIM. Независимо от исходной точки разработки или метода генерации документов, вычислительная семантика полученного документа должна быть производной от отношений между классами, определенными в модели RIM, контролируемого словаря и типов данных модели V3 RIM. Любая реализация генератора АКД-документов должна начинаться с проверки того, как требования к документам соотносятся с моделью RIM, типами данных и словарем.

Модель RIM, однако, является очень абстрактной и позволяет использовать много обширных словарных доменов. Хотя возможность отображения на модель RIM является необходимым условием генерации АКД-документов, для создания документов недостаточно выбрать метод генерации или вид пользовательского интерфейса.

АКД является спецификацией обмена документами, а не конструирования документов:

- спецификация АКД не является определяющей для создания документов.

АКД является спецификацией формы обмена клиническими документами. В XML-схему АКД-документов заложены многие из требований соответствия спецификации АКД, но для большинства конструкторов документов эта схема оказывается слишком общей. Вообще говоря, стандарты интероперабельности и сетевого обмена не могут оказывать непосредственное влияние на графический интерфейс пользователя, предназначенный для конструирования документов. В конкретной области применения АКД - документирование медицинской помощи - общие требования к обмену данными пересекаются, но не совпадают с требованиями к такому интерфейсу пользователя.

Например, для удовлетворения требования АКД к человекочитаемости необходимо создать единую таблицу стилей, с помощью которой можно отобразить заверяемое клиническое содержание любого АКД-документа. Если бы элементы общей схемы АКД-документов были определены соответствующими разделами документа, к примеру, <historyOfPresentIllness> (история текущего заболевания) или <Subjective> (жалобы), то в таблицу стилей мог бы быть включен код, распознающий их как теги уровня раздела и обеспечивающий их адекватный вывод. Но подход АКД, при котором разделам соответствуют элементы section, а типы разделов задаются с помощью кодированного слова, означает, что расширяемость АКД обеспечивается не только за счет применения внешних словарных доменов, управляемых другими организациями, но и разработчики документов получают гибкие возможности создания иерархий разделов и присвоения им имен и тегов в соответствии с местными требованиями, которые позволяют сохранить совместимость в контексте обмена. Таким образом, использование специфичных имен тегов облегчает местную разработку графических интерфейсов пользователя, но там, где практика накладывает более жесткие требования, для АКД требовалось использовать более общий подход.

Необходимо учитывать оба комплекса требований - для конструирования документов и для их передачи. При определенной общности интересов, например в единой корпорации, в профессиональных ассоциациях и в некоторых случаях в местных и региональных органах управления здравоохранением, может быть достигнуто твердое соглашение о форме документа, и определения структуры документов для их конструирования и передачи совпадут. Учитывая разнообразие местных требований, можно утверждать, что универсального обмена документами не будет до тех пор, пока не будет выработано универсальное соглашение. Скучно повторять, что АКД останется общим стандартом обмена документами, и должны быть предложены другие подходы к разработке требований по проверке ввода данных и создания документов.

Общие подходы: ограничение или преобразование:

- ограничение: получение правильного АКД-документа непосредственно из системы конструирования документов с использованием схемы, отличающейся от схемы АКД-документов;

- преобразование: использование местной XML-схемы, преобразование в АКД-документ.

Первый способ состоит в наложении ограничений на схему АКД-документов, в результате которого будет получена спецификация конкретного типа документа (см. приведенное ниже обсуждение создания АКД-документов с использованием местной схемы). Существует несколько способов наложения ограничений. Один из них состоит в модификации самой схемы АКД-документов, превращающей ее в местный вариант (см. local.cda.xsd на рисунке 3). Модификации могут включать в себя ограничение уровней вложения, ограничение словарей данных и последовательности компонентов; например, можно потребовать, чтобы раздел section с кодом LOINC, соответствующим "жалобам", был первым в теле документа, а за ним следовал раздел section с кодом LOINC, соответствующим "результатам осмотра". Такие модификации могут быть отражены в самой XML-схеме или с помощью выражений XPath в местной схеме. Экземпляры документов, которые будут соответствовать этой ограниченной, местной версии схемы АКД-документов, будут, по определению, также и правильными АКД-документами.

Рисунок 3 - Использование ограниченной местной схемы

Одним из типов ограничений схемы являются шаблоны. В настоящее время комитет HL7 работает над созданием формального способа описания шаблонов (см. 5.1.2.2).

Второй подход состоит в создании местной схемы и преобразовании местного экземпляра XML-документа в АКД-документ (см. рисунок 4).