0.9.0 - ci-build

RuCoreIG, published by HL7 FHIR Россия. This guide is not an authorized publication; it is the continuous build for version 0.9.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/fhir-ru/RuCoreIG/ and changes regularly. See the Directory of published versions

Gost 05 Profiling

5. Требования к расширению и профилированию ресурсов

Архитектура стандарта HL7 FHIR R5 устанавливает принципы формализованного моделирования комплексных информационных структур в сфере здравоохранения. Глобальная иерархия объектов FHIR наследуется от абстрактного суперкласса Base. На следующем уровне абстракции происходит строгое разделение на сущности, не имеющие независимой идентичности (Типы данных), и объекты первого класса (Ресурсы).

Типы данных (Data Types) не являются самостоятельными информационными объектами и применяются исключительно в составе родительского ресурса родительского ресурса. Спецификация HL7 FHIR R5 выделяет несколько категорий:

  1. Примитивные типы (Primitive Types): Наследуют базовый тип и могут содержать внутренний строковый идентификатор id и массив расширений extension. Спецификация накладывает строгие ограничения на сериализацию: например, тип integer64 сериализуется в JSON как строка для предотвращения потери точности вычислений.

  2. Комплексные типы (General-Purpose Complex Types): Включают логически связанные кластеры элементов (например, Identifier, CodeableConcept).

  3. Метаданные (Metadata Types) и Специальные типы (Special Purpose Datatypes): Структуры UsageContext, Reference, Extension.

Ресурсы (Resources) наделены собственным логическим идентификатором (id), метаданными версионирования (meta) и способностью участия в REST-транзакциях. Иерархия ресурсов включает следующие абстрактные уровни:

  1. Resource: Корневой уровень для инфраструктурных объектов (Bundle, Binary).

  2. DomainResource: Наследует Resource и выступает базой для клинических сущностей. Внедряет текстовое представление text (XHTML) для обеспечения клинической безопасности, а также массивы extension и modifierExtension.

  3. CanonicalResource: Интерфейс, расширяющий DomainResource для дефинициальных артефактов (definitional resources). Внедряет глобально уникальный абсолютный URI (url), версию и статус публикации.

  4. MetadataResource: Интерфейс, расширяющий CanonicalResource, применяемый к ресурсам, требующим доказательного управления жизненным циклом. Добавляет метаданные процесса разработки (approvalDate, author, reviewer).

Базовая спецификация непригодна для прямого применения в производственных системах без контекстной адаптации. Процесс наложения ограничений на базовые структуры именуется профилированием. Роль декларативного механизма ограничений выполняет мета-ресурс StructureDefinition, концептуально согласованный со стандартом метаданных ISO 11179.

Ресурс StructureDefinition содержит массив объектов ElementDefinition. Технологически описание разделяется на snapshot (исчерпывающий свод всех элементов для валидаторов) и differential (массив, содержащий исключительно изменения относительно родительского профиля). В данной спецификации используется snapshot-режим предоставления

При разработке профилей должен соблюдаться принцип преемственности и безусловной непротиворечивости по отношению к родительской структуре, в качестве которой может выступать как базовая спецификация HL7 FHIR, так и вышестоящий профиль (например, профиль национального уровня RuCore). При формировании нового профиля не допускается ослабление или отмена ограничений, установленных в родительской структуре. Любое расширение или ограничение, вводимое профилем, должно сохранять логическую целостность и обеспечивать совместимость с исходной спецификацией

Профилирование должно осуществляться исключительно путем уточнения требований родительской структуры. Уточнение модели данных реализуется посредством следующих механизмов:

  1. Ограничение кардинальности (Cardinality Constraints): Кардинальность элементов min и max может быть изменена исключительно в сторону ужесточения. Трансформация поля 0..* в 1..1 является легитимной и делает опциональный элемент строго обязательным для заполнения на уровне JSON-схемы.

  2. Разделение на срезы (Slicing): В случаях, когда элемент базовой структуры допускает множественные значения (представляет собой массив, например, с кардинальностью 0..*), применяется механизм разделения на подмножества – так называемые срезы. Данный механизм позволяет классифицировать элементы массива на основе заданного критерия (дискриминатора) и установить для каждого выделенного среза независимые правила профилирования (индивидуальные ограничения кардинальности, фиксацию типов или привязку к специфическим наборам значений). Например, для ресурса Patient с помощью подобного подхода можно задать требования к разным объектам в массиве Patient.identifier[] для кодирования в них идентификаторов пациента: СНИЛС, ИНН, полиса ОМС и документов, удостоверяющих личность – в данном случае дискриминатором каждого отдельного среза, активирующем специфический для него набор требований, будет значение элемента Patient.identifier[].system

  3. Семантические обязательства (Must Support): В ситуациях, когда жесткое изменение структурной кардинальности min: 1 недопустимо из-за риска потери данных (например, информация объективно отсутствует в момент оказания помощи), применяется булевый флаг mustSupport. Наличие данного флага накладывает на реализатора нормативное обязательство (Obligation) поддерживать обработку элемента (сохранение в БД, отображение, экспорт) при наличии фактических данных в экземпляре ресурса.

  4. Привязка терминологий (ValueSet Binding): Элементы могут быть строго связаны с наборами значений (ValueSet) из одного или нескольких справочников. Сила привязки (Binding Strength) варьируется по нескольким разным уровням:

    1) Required (Обязательная) Для прохождения валидации (conformance) значение элемента строго обязано принадлежать к указанному ValueSet. Использование любых других кодов или текста недопустимо. При наследовании профиля дочерние структуры не имеют права добавлять новые коды или расширять этот справочник.

    2) Extensible (Расширяемая) Интеллектуальная привязка. Экземпляр ресурса обязан использовать код из укаузанного ValueSet, если в нем присутствует концепт, подходящий по клиническому смыслу. Однако, если справочник физически не покрывает нужный сценарий, системе разрешается передать альтернативный код из другой терминологии или просто текст. Дочерние профили могут добавлять новые правила для кодов, но только в том случае, если в родительском справочнике не было кода с подходящим значением.

    3) Preferred (Предпочтительная) Системам настоятельно рекомендуется использовать коды из указанного справочника для обеспечения максимальной интероперабельности, но это не является обязательным требованием для успешной валидации. Этот режим применяется, когда на уровне стандарта или профиля достигнут консенсус о «лучших» кодах, но признается, что в некоторых юзкейсах разработчики по объективным причинам не могут их применить.

    4) Example (Иллюстративная) Спецификация не требует и даже не рекомендует обязательно брать коды из этого справочника. Привязанный ValueSet служит исключительно для демонстрации того, какие примерно типы концептов ожидаются в данном элементе.

  5. Спецификация расширений (Extension и ModifierExtension):

    1) Extension Обогащает ресурс дополнительными атрибутами. Согласно правилам клинической безопасности, неизвестные принимающей стороне расширения могут быть безопасно проигнорированы.

    2) ModifierExtension Модифицирующие расширения фундаментально меняют семантику родительского элемента (например, директива «Не реанимировать»). В случае выявления неизвестного modifierExtension принимающая информационная система обязана отклонить транзакцию обработки ресурса для исключения угрозы безопасности пациента.

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

В рамках процесса наследования действуют следующие правила:

  1. Наследование кардинальности: допускается только дополнительное ограничение диапазона допустимых значений. Дочерний профиль вправе сузить кардинальность (например, изменить 0..* на 1..5), но не может ее расширить или восстановить до исходного состояния базовой спецификации, если родительский профиль уже ввел ограничение.

  2. Сохранение структуры срезов (Slicing): все срезы, выделенные в родительском профиле, являются обязательными для наследования. Не допускается удаление унаследованных срезов, изменение их критериев разделения (дискриминаторов) или ослабление наложенных на них ограничений. При этом дочерний профиль вправе накладывать дополнительные ограничения на унаследованные срезы, а также вводить новые, дополнительные срезы в массив, если это не противоречит общей кардинальности родительского элемента.

  3. Сохранение статуса семантических обязательств (Must Support): если в родительском профиле элементу присвоен флаг mustSupport, данное обязательство является безусловным для всех дочерних структур. Снятие флага mustSupport или понижение уровня ответственности реализатора за обработку такого элемента в дочерних профилях не допускается.

  4. Усиление силы привязки (Binding Strength): при наследовании допускается только повышение уровня обязательности использования наборов значений (ValueSet). Переход возможен только от более слабых типов привязки к более сильным (например, от Preferred к Extensible или от Extensible к Required). Ослабление привязки или замена строгого справочника (Required) на иллюстративный (Example) в дочерних структурах запрещены.

  5. Наследование расширений: все расширения (Extension и ModifierExtension), объявленные в родительском профиле как обязательные или имеющие статус mustSupport, сохраняют свой статус и правила интерпретации в дочерних структурах.

UML-диаграмма классов (Рисунок 1. ниже) представляет базовую объектную модель стандарта FHIR и демонстрирует иерархию наследования от корневых абстрактных классов до конкретных прикладных профилей национального уровня RuCore и профилей предметного уровня на примере организации процесса оказания высокотехнологичной медицинской помощи, описанных в приложении Б.

Диаграмма ориентирована слева направо: в левой части расположены фундаментальные классы Base, Element, Resource, которые по мере продвижения вправо детализируются через наследование до конкретных типов данных, базовых ресурсов и адаптированных профилей. Для удобства восприятия и разделения логических слоев на диаграмме применено следующее цветовое кодирование:

  • светло-зеленый фон обозначает фундаментальные классы и интерфейсы стандарта FHIR, формирующие ядро спецификации. В него входят корневые классы (Base, Resource, Element), структурные типы (DataType, BackboneElement, DomainResource), а также интерфейсы метаданных и канонических ресурсов (CanonicalResource, MetadataResource);

  • голубой фон выделяет примеры реализации примитивных и сложных типов данных (string, dateTime, CodeableConcept, Address), а также внутренних элементов ресурсов (например, Patient.contact, Condition.stage);

  • желтый фон (используется для обозначения стандартных доменных и канонических ресурсов FHIR на уровне спецификации базового стандарта без какой-либорегиональной адаптации (например, Patient, Observation, Composition, StructureDefinition);

  • розовый фон указывает на ресурсы и типы данных, профилированные в рамках национального руководства по реализации (RuCore). Они наследуют свойства базовых ресурсов FHIR и добавляют российскую специфику (например, Core_Patient, Core_Organization, Core_Address);

  • белый фон с пунктирной границей обозначает предметно-ориентированные профили специализированного руководства на примере профилей ВМП (наименования классов начинаются с VMP_). Данное графическое выделение подчеркивает возможность осуществлять наследование как от базовых профилей RuCore, так и от стандартных классов базового стандарта FHIR (например, VMP_condition, VMP_DocumentReference).

​UML-диаграмма классов стандарта FHIR и его профилей

Рисунок 1. UML-диаграмма классов стандарта FHIR и его профилей, описанных в данном документе