Current Build

Переводит компания Health Samurai . Приглашаем поучаствовать в русификации стандарта FHIR: GitHub , Email.

FHIR Infrastructure Work GroupMaturity Level: 4Ballot Status: Trial Use

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

По этой причине спецификация FHIR является "платформенной спецификацией" - она создает общую платформу или фундамент, на котором реализуется множество различных решений. Вследствие этого, данной спецификации, как правило, требуется дальнейшая адаптация к конкретному контексту использования. Обычно такие адаптации означают:

  • Правила о том, какие элементы ресурса использовать, какие не использовать, а также какие дополнительные элементы, которые не вошли в основную спецификацию, добавлять
  • Правила о том, какие свойства интерфейса использовать и каким образом
  • Правила о том, какие справочники используются в конкретных элементах
  • Описание, каким образом элементы ресурса и свойства интерфейса сопоставляются с локальными требованиями и/или реализациями

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

Для этих целей FHIR вводит несколько определений:

Артефакт Описание DAF -пример
Руководство по реализации (IG) Согласованный и связанный набор адаптаций, которые опубликованы единым целым. Валидация происходит в контексте руководства по реализации DAF IG
Package (пакет) Группа связанных адаптаций, которые опубликованы в виде группы внутри руководства по реализации DAF Medication Usage
Conformance Resource Отдельный ресурс в пакете, который вводит правила о том, как работает реализация. Они описаны ниже DAF Prescription

Термин "профиль" - это общий термин, который используется либо по отношению к "пакету" (package), либо к "пункту" (item). "Профилирование" - это общий термин, который описывает процесс создания руководства по реализации или любых ресурсов соответствия, находящихся в нём.

Руководства по реализации, как правило, и ограничивают, и расширяют API, ресурсы и справочники. FHIR предоставляет набор ресурсов, которые могут использоваться для отображения и совместного использования решений, которые были созданы, и позволяет реализаторам на их базе создавать полезные сервисы. Эти ресурсы известны как ресурсы соответствия. Эти ресурсы соответствия позволяют реализаторам:

  • Указывать, что некоторые вызовы интерфейса не используются в определенных случаях, и предоставлять дополнительное описание по использованию интерфейса (ресурс Capability Statement)
  • Вводить дополнительные операции и параметры поиска, отсутствующие в базовой спецификации (с помощью ресурсов OperationDefinition и SearchParameter)
  • Задавать способ использования конкретной структуры (ресурса, расширения или типа данных) (ресурс StructureDefinition):
    • Описывать, каким образом используются существующие элементы ресурсов
    • Указывать, какие именно элементы в ресурсах не используются
    • Определять расширения для использования в ресурсах или типах данных
  • Смешивать пользовательские и стандартные справочники и выбирать, какие коды из них использовать в конкретном кодированном элементе (ресурсы Value Set и StructureDefinition)
  • Устанавливать соответствие между локальными и стандартными справочниками или моделями содержания (ресурс Concept Map)
  • Регистрировать пространства имен систем для идентификаторов и справочников (ресурс NamingSystem)

Эти ресурсы необходимо использовать, придерживаясь правил, рассмотренных ниже, а также следуя основным концепциям расширения, которые описаны в разделе "Расширяемость". Для удобства реализаторов основные определения самой спецификации публикуются с помощью этих же самых ресурсов.

Ресурс Capability Statement описывает два различных способа применения профилей ресурсов: профили ресурсов (Resource Profiles) и системные профили (System Profiles). Профили ресурсов задаются с помощью элемента Conformance.rest.resource.profile, а системные профили задаются с помощью элемента Conformance.profile.

Такие профили описывают общие свойства, поддерживаемые системой для каждого вида ресурса. Как правило, это супермножество всех возможных сценариев использования, реализованных системой. Это взгляд на функциональность системы с уровня ресурсов.

Такие профили описывают информацию, обрабатываемую/создаваемую системой на посценарной основе. Вот некоторые примеры профилей этого типа:

  • Лабораторный сервис, создающий ряд различных отчетов - общая химия, анализ крови и т. п. Типичные лаборатории будут поддерживать несколько сотен различных отчетов
  • Управляющий медицинским обслуживанием (care manager), оперирующий множеством планов медицинского обслуживания (care plans) различного типа и связанных клинических ресурсов
  • Формуляр медикаментов, оперирующий несколькими различными уровнями сложности представления медикаментов

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

  • Экспертная система, проводящая анализ нескольких различных множеств данных, соответствующих определенному паттерну - проверяет x,y и z с конкретными кодами и единицами

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

В качестве примера рассмотрим лабораторную систему, производящую тысячи отчетов в день. 1% этих отчетов будет некоторый эндокринный отчет, который система поддержки принятия решений знает как обрабатывать. Обе системы декларируют, что они поддерживают определенный профиль эндокринного отчета, однако как экспертная система на деле находит те эндокринные отчеты, которые она умеет обрабатывать?

Одним из возможных решений для экспертной системы будет получать каждый отчет, приходящий из лабораторной системы, проверять его на соответствие профилю и затем принимать решение, обрабатывать ли его. Проверка, соответствует ли ресурс определенному профилю - это прямая операция (как вариант можно использовать предложенные для этого инструменты), однако это очень неэффективный способ - экспертной системе придется получить и обработать в 100 раз больше ресурсов, чем нужно. Чтобы помочь потребителю находить подходящий набор отчетов для конкретного варианта использования, производитель ресурсов ДОЛЖЕН для всех профилей, объявленных в Conformance.profile:

  1. Указать для ресурсов профили, которым они соответствуют (что позволит делать индексирование по профилям)
  2. (для сервера) поддерживать поиск по параметру _profile для заявленных профилей

Помимо этих требований, производитель ресурсов ДОЛЖЕН гарантировать, что любые экземпляры ресурсов, от которых резонно будет ожидать соответствия заявленным профилям, ДОЛЖНЫ быть опубликованы в этой форме.

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

Feedback is welcome here .

Ресурс CapabilityStatement перечисляет REST-взаимодействия (read, update, search и т.п.), которые предлагает сервер или которые использует клиент, наряду с некоторой вспомогательной информацией для каждого. Может также использоваться для задания набора желаемого поведения (например в рамках спецификации или Request for Proposal). Единственное взаимодействие, которые серверы обязаны поддерживать, это само взаимодействие capabilities - для получения заявления о возможнотях сервера. Помимо этого, серверы и клиенты поддерживают и используют те API-вызовы, которые подходят в их случае.

В дополнение к операциям, которые предлагает FHIR, серверы могут предоставлять дополнительные операции, которые не входят в FHIR-спецификацию. Реализаторы могут безопасно делать это добавлением имени пользовательской операции с префиксом '$' к существующему URL-адресу FHIR, как это делает Operations framework. Ресурс Conformance поддерживает определение того, что OperationDefinitions использует конкретные имена в точке взаимодействия. Если определены сервисы, которые не объявлены с помощью OperationDefinition, может быть допустимо использовать более длинные имена, сокращая шанс коллизии (и путаницы) с сервисами, объявленными в других интерфейсах. Базовая спецификация никогда не будет давать операциям имена, содержащие "." , поэтому реализаторам рекомендуется использовать некоторый подходящий префикс в их именах (например "ihe.someService") для уменьшения вероятности конфликта имен.

В реализациях поощряется, но не требуется определять операции с помощью стандартного фреймворка операций FHIR - то есть объявлять операции, используя ресурс OperationDefinition, однако некоторые операции могут включать форматы, которые не могут быть описаны этим способом.

В реализациях также можно расширять FHIR API, используя дополнительные типы содержимого. К примеру, может быть полезно read или update ресурсы appointment с помощью формата на основе vCard. vCard определяет собственный MIME-тип, и эти дополнительные MIME-типы можно безопасно использовать в дополнение к тем, что определены в данной спецификации.

Расширение и ограничение ресурсов (общеизвестное как "профилирование ресурса") выполняется с помощью ресурса "StructureDefinition", который представляет собой правила о том, каким образом используются элементы в ресурсе и где в ресурсе используются расширения.

Одна из ключевых функций профилей - это изменение кардинального множества элемента. Профиль может ограничить кардинальное множество элемента в пределах базовой структуры, которую он ограничивает. Таблица ниже показывает, какие типы ограничений разрешены:

derived (across)
base (down)
0..0
(Не используется)
0..1
(необязательный)
0..n
(необязательный, несколько)
1..1
(обязательный)
1..n
(минимум 1)
0..1 да да нет да нет
0..* да да да да да
1..1 нет нет нет да нет
1..* нет нет нет да да

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

Возможности Structure Definitions по ограничению существующих ресурсов и типов данных несколько ограничены:

  • Профили не могут нарушать правила, установленные в базовой спецификации (например кардинальное число, как описано выше)
  • Профили не могут задавать элементам значения или смысл по умолчанию
  • Профили не могут давать элементам более конкретные имена
  • Обрабатывать ресурс без знания его профиля должно быть безопасно

Следствием этого является то, что если профиль разрешает расширенное поведение, которое нельзя игнорировать, он должен также разрешать использование расширения-модификатора. Другими словами, это знание должно быть явным в экзепляре, а не подразумеваться в профиле.

В качестве примера, если профиль желает описать, что ресурс Procedure отрицается (например утверждение, что это никогда не случалось), он не может просто сказать в самом профиле, что это то, что значеит ресурс; вместо этого профиль должен сказать, что этот ресурс должен иметь расширение, которое представляет это знание.

Существует средство для обозначения ресурсов, что они могут быть безопасно поняты только при таком способе обработки, когда известен и понятен набор опубликованных правил. Для получения дополнительной информации см. Restricted Understanding of Resources.

Ограничивающее Structure Definition устанавливает ряд ограничений для содержимого FHIR-ресурса или типа данных, либо ряд дополнительных ограничивающих условий для существующего профиля. Заданное structure definition идентифицируются по своему каноническому URL-адресу, который ДОЛЖЕН быть тем URL, по которому он был опубликован. О том, каким образом используется элемент, можно делать следующие утверждения, используя серию определений элементов:

  • Уменьшение кардинального числа элемента, например базовая спецификация может разрешать 0..*, а конкретное приложение может поддерживать 1..2
  • Исключение элемента из использования установкой его максимального значения кардинального числа в 0
  • Ограничение содержимого элемента одним фиксированным значением
  • Создание дополнительных ограничивающих условий для содержимого вложенных элементов внутри ресурса (выраженных в виде XPath-утверждений)
  • Ограничение доступных типов данных для элемента, в котором допустимы несколько типов
  • Требование к типизированному элементу или целевому объекту ссылки ресурса соответствовать другому структурному профилю (объявленному в этом же профиле либо в другом месте)
  • Указание привязки к другому терминологическому набору значений (см. ниже)
  • Предоставление уточнённых определений, комментариев/примечаний к использованию и примеров для элементов, заданных в ресурсе, для отражения их использования в контексте этого профиля
  • Предоставление более конкретных или дополнительных таблиц соответствия (например с HL7 v2 или HL7 v3 ) для ресурса при использовании в определенном контексте
  • Объявление, что один или несколько элементов в структуре должны быть 'поддержаны' (см. ниже)

Все изменённые определения ДОЛЖНЫ быть ограничениями, которые не противоречат правилам, установленным в ресурсе спецификации FHIR, на основе которого создаётся профиль. Обратите внимание, что некоторые из этих ограничений могут быть обеспечены принудительно с помощью инструментов (и обеспечиваются средствами FHIR), однако другие (например регулирование изменений описательного текста) не могут быть автоматически применены.

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

Структурное определение содержит линейный список определений элементов. Присущая вложенная структура элементов происходит из значения path каждого элемента. К примеру, такая последовательность путей элементов

  • Root
  • Root.childA
  • Root.childA.grandchild1
  • Root.childB

определяет следующую структуру:

 <Root>
   <childA>
     <grandChild1/>
   </childA>
   <childB/>
 </Root>

или ее JSON-эквивалент. Структура является логически последовательной - потомки никогда не подразумеваются, а пути всегда идут по порядку. Перечень элементов - это линейный список, а не явно вложенные элементы, так как определения элементов часто используются повторно в нескольких местах внутри одного definition, и это повторное использование проще осуществлять с плоской структурой.

Структурные определения могут содержать differential statement или snapshot statement, либо и то, и другое.

Differential statements описывают только те изменения, которые они задают по отношению к другому structure definition (которым чаще всего является базовый FHIR-ресурс или тип данных). Например профиль может делать один из элементов обязательным (кардинальное число 1..1). В этом случае дифференциальная структура будет содержать один элемент и его путь, сделанный обязательным, и кардинальное число. Больше ничего не заявляется - вся остальная структура подразумевается (примечание: это означает, что дифференциальный профиль может быть разреженным и указывать только те элементы, которые были изменены, без необходимости перечисления всей структуры. Это правило включает корневой элемент - в нём нет необходимости в разреженном дифференциале).

Отметьте, что в дифференциальном профиле можно и не ограничивать элементы. Это означает, что такой профиль будет более гибким в плане совместимости с другими профилями, однако для его поддержки потребуется больше усилий со стороны использующих его систем. С другой стороны, профиль может ограничить все опциональные элементы так, чтобы они отсутствовали (указав максимальное кардинальное число равным 0). Это уменьшает количество содержимого, что делает реализацию проще, но снижает её полезность.

Чтобы правильно интерпретировать дифференциальную структуру, ее необходимо применить к структурному определению, на котором она основывается. Чтобы не возникала необходимость в инструментах для поддержки этой операции (которая требует большого объема вычислений - и не возможна, если базовая структура недоступна), StructureDefinition может также хранить "снимок" - полностью вычисляемую форму структуры, которая не зависит ни от какой другой структуры. Проект FHIR предлагает инструменты для распространенных платформ, которые могут восстановить снимок из дифференциала (обратите внимание, что эти инструменты создают полные, подробные снапшоты; они не поддерживают возможность убирать мэппинги и ограничения).

StructureDefinitions, содержащие и дифференциальный вид, и снимок. По сути, это самая распространенная форма - дифференциальная форма используется в процессе авторской разработки (authoring process), в то время как снимок используется в инструментах реализации. Ресурсам StructureDefinition, применяемым в операционных системах, следует всегда иметь восстановленный снимок.

Одна из распространенных функций constraining Structure Definitions - это взять элемент, который может появиться больше одного раза (например список) и разбить этот список на последовательность подсписков, каждый со своими ограничениями на элементы в подсписке с ассоциированным дополнительным значением. В FHIR эта операция называется "нарезка" ("Slicing") списка. Общепринято "нарезать" список на подсписки, где каждый из них содержит по одному элементу, эффективно накладывая ограничения на каждый элемент в списке.

Вот пример для иллюстрации этого процесса:

Slicing diagram

В этом примере базовое структурное определение ресурса Observation задаёт элемент "component", который содержит вложенные "code" и "value" для наблюдений с несколькими значениями. Классическим примером такого вида наблюдений является измерение кровяного давления - оно содержит 2 значения: систолическое и диастолическое (пример).

На диаграмме показан воображаемый процесс "нарезки" списка компонентов на систолический и диастолический срезы (примечание: чтобы избежать загромождения схемы, атрибут "name" ресурса Observation показан просто как код, а не полный CodeableConcept).

Структурное определение для измерения кровяного давления разбивает список компонентов на два подсписка из одного элемента каждый: элемент systolic и элемент diastolic. Каждый из этих элементов имеет фиксированное значение элемента "code" (фиксированный код LOINC для "name"), и оба имеют значение типа Quantity. Это процесс называется "нарезка" (slicing), а элементы Systolic и Diastolic - "срезы" (slices).

Обратите внимание, что при обмене ресурсом, формат сериализации обмена не изменяется constraining definition. Это означает, что имена элементов, определенные в structure definition (в этом примере "systolic") никогда не меняются. Экземпляр ресурса выглядит следующим образом:

 <Observation>
   ...
   <component>
     <code {LOINC="8480-6"}/>
     <value ...> 
   </component>
   <component>
     <code {LOINC="8462-4"}/>
     <value ...>
   </component>
 </Observation>

Для того чтобы определить, что первый связанный элемент соответствует "Systolic" в structure definition, так чтобы он мог установить, каким дополнительным ограничениям для подсписка соответствует этот элемент, система проверяет значения этих элементов. В этом случае можно использовать элемент "code" в целевом ресурсе, к которому относится эта ссылка, для определения, какому срезу (slice) он относится. Этот элемент называется "дискриминатор" (классифицирующая функция, "discriminator").

В общем случае, системы обработки ресурсов, использующие structure definition, который разбивает список, могут установить срез, соответствующий элементу в списке с помощью проверки, соответствует ли содержимое этого элемента правилам, указанным для этого среза. Это потребовало бы от обработчика возможности проверить все правила, применимые к этому срезу, и сделать это гипотетически в глубину. Оба этих требования неуместно сложны для операционной систем и особенно для генерируемого кода (например ПО, автоматически созданное на основе StructureDefinition). Таким образом, для обеспечения способа различения срезов, для нарезаемого элемента можно указать поле или набор полей, которые будут действовать как "дискриминатор", т. е. будут использоваться для разделения срезов друг от друга.

Когда есть дискриминатор, композиция значений элементов, обозначенных в этом дискриминаторе, является уникальной и различается для каждого возможного среза, и приложения могут легко определить, какому разрезу соответствует пункт в списке. Предполагается, что это можно будет делать в генерируемом коде. например с помощью оператора switch/case.

When a constraining structure designates one or more discriminators, it SHALL ensure that the possible values for each slice are different and non-overlapping, so that the slices can easily be distinguished.

Each discriminator is a pair of values: a type that indicates how the field is processed when evaluating the discriminator, and a FHIRPath expression that identifies the element in which the discriminator is found. There are five different processing types for discriminators:

valueThe slices have different values in the nominated element
existsThe slices are differentiated by the presence or absence of the nominated element
patternThe slices have different values in the nominated element, as determined by testing them against the applicable ElementDefinition.pattern[x]
typeThe slices are differentiated by type of the nominated element to a specifed profile
profileThe slices are differentiated by conformance of the nominated element to a specifed profile

The FHIRPath statement that allows for the selection of the element on which the discriminator is based is a restricted FHIRPath statement that is allowed to include:

  • Element selections (e.g. FHIRPath statements without "()" such as component.value)
  • The function extension(url) to allow selection of a particular extension
  • The function resolve() to allow slicing across resource boundaries

Each slice must use the element definition for the element in the discriminator(s) to ensure that the slices are clearly differentiated (by assigning a fixed value, a specific type, or a profile, depending on the discriminator type. If the type is 'value', then the element definition must use either ElementDefinition.fixed[x] or, if the element has a terminology binding, a required binding with a Value Set that enumerates the list of possible codes in the value set ("extensional definition").

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

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

Внутри structure definition срез определяется с помощью нескольких записей element, которые имеют общий path, но различные name. Эти записи вместе формируют "группу срезов", которая:

  1. Инициируется с помощью "slicing entry" То есть первый element в группе срезов обязан содержать свойство slicing, которое устанавливает discriminator для всех членов этой группы. Также он содержит естественное определение элемента, который был разбит, потенциально включая потомков элемента без ограничивающего условия, если таковые имеются
  2. Взаимно исключающий. Это значит, что каждый element в группе срезов ДОЛЖЕН описывать различный набор значений для discriminators группы. Из-за этого условия элемент в экземпляре ресурса instance никогда не будет соответствовать более чем одному element в данной группе срезов. Если дискриминаторы не названы, СЛЕДУЕТ оставить возможность дифференцировать эти срезы по их свойствам, хотя может это и существенно сложнее будет сделать.
  3. Сериализованный как группа. Записи в группе срезов должны быть adjacent в сериализованном structure definition, либо, если есть какие-либо промежуточные элементы, эти элементы должны быть "совместимы с" этой группой. Конкретно это означает, что любые промежуточные элементы должны иметь path, который начинается с path группы срезов. Например element с path Observation.name.extension будет совместим с (и, таким образом, не будет "break up") группой срезов, чей путь был Observation.name

Some examples of descriminators:

Context Discriminator Type Discriminator Path Interpretation
List.entry value item.reference.resolve().name Entries are differentiated by the name element on the target resource - probably an observation, which could be determined by other information in the profile
List.entry type item.reference.resolve() Entries are differentiated by the type of the target element that the reference points to
List.entry profile item.reference.resolve() Entries are differentiated by a profile tag on the target of the reference, as specified by a structure definition (todo: how to do that?)
List.entry value item.extension("http://acme.org/extensions/test").code Entries are differentiated by the value of the code element in the extension with the designated URL
List.entry.extension value url Extensions are differentiated by the value of their url property (usually how extensions are sliced)
List.entry type, value item.reference.resolve(), item.reference.resolve().code Extensions are differentiated by the combination of the type of the referenced resource, and, if it has one, the code element of that resource. This would be appropriate for where a List might be composed of a Condition, and set of observations, each differentiated by its name - the condition has no name, so that is evaluated as a null in the discriminator set
Observation.value[x] type $this Different constraints (e.g. "must support", usage notes, vocabulary bindings, etc.) are asserted for different supported types for the multi-typed element Observation.value[x]

Note that discriminator types of type and profile can also be used where a repeating element contains a resource directly (e.g. DomainResource.contained, Bundle.entry, Parameters.parameter.resource).

The examples of slicing and discriminators show exactly how this and other typical uses of slicing are represented in profiles.

Note that extensions are always sliced by the url element, though they may be resliced on additional elements where required.

There is a special slice, called the default slice. This allows a profile to describe a set of specific slices, and then make a set of rules that apply to all the remaining content that is not in one of the defined slices. Some rules about the default slice:

  • It is identified because the name of the slice is @default. The sliceName '@default' is reserved and cannot be used in any other context
  • Default slices are only allowed when the slicing rule = closed
  • Default slices must not fix the value of the discriminator elements
  • Default slices can be re-sliced in dependent profiles

One use of a default slice would be the case where the profile slices an identifier element to require a set of known identifiers, where the type element is prohibited (since they are known identifiers) but requires type on all other identifiers if any are present. In this case, the default slice makes no rules about the identifer.system (which is the slicing discriminator), but fixes the cardinality of type to 1..1 in the @default slice.

Profiles can be based on other profiles, and apply further constraints to those already specified. This is a useful technique, but implementers should be wary of over-use - humans have trouble understanding the implications of deep stacks of constraining profiles.

When a profile constrains another profile, it can make additional constrainta, including extending the discriminator, adding new slices (if the slices are not already closed), and slicing inside the existing slices.

The rules for changing the slicing are as follows:

  • Rule = open can be changed to rule = closed, and unordered can be changed to ordered)
  • If a discriminator for an element is declared in a parent profile, child profiles referencing that element must either declare the same discriminator or must declare a new discriminator that includes the parent discriminator content. I.e. additional discriminator paths may be added, but none of the existing paths can be removed.

It's sometimes necessary to slice data that has already been sliced in the base profile - that is, create new slices within the existing slices. This is called "Re-slicing". The rules for re-slicing are as follows:

При нарезке вы задаёте имя каждого нового среза. Это имя должно быть уникальным в пределах набора срезов этого профиля. Таким образом, если профиль А задаёт элемент Х с кардинальным множеством 0..*, а профиль Б основывается на профиле А, тогда профиль Б может:

  1. добавить ограничивающее условие на X без имени - в этом случае профиль добавляет огринчения на все срезы Х; либо
  2. добавить ограничивающее условие на X с именем - в этом случае этот профиль будет описывать особый срез для X, и ограничивающие условия будут применяться только к этому срезу; либо
  3. сделать и то, и другое

Затем, профиль В основан на профиле Б. Профиль В может делать следующее:

  1. добавить ограничивающее условие на X без имени - в этом случае этот профиль ограничивает все появления Х; либо
  2. добавить ограничивающее условие на X с другим именем, отличающимся от использованного в профиле Б - в этом случае этот профиль будет описывать особый новый срез для Х, и ограничивающие условия будут применяться только к этому срезу; либо
  3. добавить ограничивающее условие на X с таким же именем, как в профиле Б - в этом случае этот профиль вводит новые ограничивающие условия для среза, определённого в профиле Б; либо
  4. некоторая комбинация перечисленных выше вариантов

Примечание: профиль В может вводить правила, несовместимые с профилем Б, в этом случае не будет экземпляров, которые соответствовали бы профилю В.

В дополнение к перечисленному выше, бывают случаи, когда профилю В потребуется ещё раз нарезать срез, определённый в профиле Б. В этом случае будет необходимо ссылаться на оба имени оригинального среза из профиля Б, а также задать имя для среза, определённого в профиле В. Это делается с помощью разделителя имён "/". Например если профиль Б задаёт срез "example", а профиль В задаёт срез "example/example1", тогда он считается срезом "example1" среза "example". Этот процесс может продолжаться неограниченно, отделяя каждый слой имён срезов с помощью символа "/". This pattern applies to @default too: @default/@default.

Определение расширения указывает URL, который идентифицирует это расширение и который используется для ссылки на определение этого расширения, когда оно используется в ресурсе.

Определение расширения также устанавливает контекст, в котором это расширение может использоваться (обычно конкретный путь или тип данных) и затем определяет элемент extension с помощью те же данные, используемые для профилирования структурных элементов, входящих в ресурс. Это означает, что одно расширение может быть определено только один раз и использоваться в различных ресурсах и/или типах данных, например потребуется определить расширение для "цвет волос" один раз и потом указать, что его можно использовать и в Patient, и в Practitioner.

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

Однажды определенное, расширение может использоваться в экземпляре ресурса без того, чтобы какой-то профиль объявлял, что это возможно, следует или должно быть, однако профили могут использоваться для описания, каким образом используется расширение.

Чтобы на самом деле предписать использование расширения в частном случае, список расширений ресурса необходимо нарезать. Это показывается в примерах расширяемости

Обратите внимание, что минимальное кардинальное число расширения ДОЛЖНО быть допустимым ограничением на минимальное кардинальное число в определении этого расширения. Если минимальное кардинальное число расширения 1, когда оно было определено, оно может быть обязательным только если добавлено в профиль. Это не рекомендуется - минимальное кардинальное число, как правило, должно быть 0.

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

Набор возможных кодов - это либо формальная ссылка на ресурс ValueSet , которая может быть версионной, либо ссылка общего вида на какое-то веб-содержимое, которое определяет набор кодов. Второе более уместно, когда набор значений определяется некоторым внешним стандартом (например MIME-типы). В качестве альтернативы, если привязка неполная (например находится в разработке), можно предоставить просто текстовое описание возможных кодов.

У привязок есть свойство, которое определяет, насколько строго реализации должны использовать данный набор кодов. См. Binding Strength.

В ресурсах CodeSystem можно определять локальные коды (пример), а ValueSets могут использовать смешанные комбинации локальных и стандартных кодов (примеры: LOINC, SNOMED), или просто выбирать определенный набор стандартных кодов (например LOINC, SNOMED, RxNorm). Профили могут привязываться к этим наборам значений вместо тех, которые определены в базовой спецификации, следуя этим правилам:

Степень привязки в базовой спецификации Правила кастомизации в профилях
required Этот набор значений может содержать только коды, содержащиеся в наборе значений, определенном спецификацией FHIR
extensible Этот набор значений может содержать коды, не найденные в базовом наборе значений. Этим дополнительным кодам НЕ СЛЕДУЕТ иметь такой же смысл, как у существующих кодов в базовом наборе значений
preferred Этот набор значений может содержать все, что допустимо для локального использования
example Этот набор значений может содержать все, что допустимо для локального использования

Note that local codes are not as interoperable as standard published code systems (e.g. LOINC, SNOMED CT, so it is preferable to use standard code systems.

A profile can change the terminology binding of an element - both strength and value set - within the limits of the base structure it is constraining. This table summarizes the changes that can be made to the binding strength:

derived (across)
base (down)
required extensible preferred example
required yes no no no
extensible yes yes no no
preferred yes yes yes no
example yes yes yes yes

Note that a constraining profile may leave the binding strength the same and change the value set instead. Whatever the constraining profile does, it cannot make codes valid that are invalid in the base structure/profile.

Одно свойство, которое может быть объявлено в профилях, которое не объявляется в определениях ресурса или типа данных, это"Must Support" (должен быть поддержан) . Это логическое свойство. Если истинно, значит системы, заявляющие о соответствии данному профилю, должны "поддерживать" этот элемент. Это отличается от кардинального числа. Возможно иметь элемент с минимальным кардинальным числом "0" и при этом ожидать от систем поддержки этого элемента.

Смысл слова "поддержан" не определён в базовой спецификации FHIR, но может быть установлен в значение "true" в профиле. В этом случае в профиле НЕОБХОДИМО также чётко обозначить, какой вид "поддержки" там требуется. Возможные примеры:

  • Система должна быть способна хранить и извлекать элемент
  • Система должна показывать элемент пользователю и/или позволять пользователю вводить элемент с помощью пользовательского интерфейса
  • Элемент должен появиться в выходном отчете
  • Элемент должен быть принят во внимание при совершении поддержки принятия решений, вычислений или другой обработки
  • другое

Смысл слов "Must Support" для конкретного профиля ДОЛЖЕН быть описан в element.definition, общем StructureDefinition.description или в другой документации инструкции по реализации, в которую входит этот профиль.

При создании профиля, основанного на другом профиле, значение Must Support может быть изменено с ложного на истинное, но не может быть изменено с истинного на ложное. Отметьте, что элемент со свойством IsModifier не обязательно является "ключевым" элементом (т. е. одним из важных элементов, необходимых для применения этого ресурса), и не является автоматически mustSupport - однако обе эти вещи более вероятны для IsModifier, чем для остальных элементов.

Последнее, что реализации могут сделать, это определить критерии поиска в дополнение к тем, что определены в самой спецификации. Критерии поиска попадают в одну из четырех категорий:

  1. Включение поиска по основным элементам, у которых не определены стандартные критерии поиска (например, поиск Observation по диапазону нормальных значений)
  2. Включение поиска по элементам, у которых уже определены стандартные критерии поиска, но с пользовательскими правилами соответствия. Например sounds-like поиск по имени Practitioner
  3. Включение поиска по определенному расширению
  4. Включение поиска, который соответствует не одному элементу, а, скорее, сочетанию элементов или вычислению на элементе. Например поиск пациентов по возрасту

Дополнительные параметры поиска могут быть определены с помощью ресурса SearchParameter.

When this specification describes a profile, the profile is presented in 5 different forms:

  1. Text Summary
  2. Differential Table
  3. Snapshot Table
  4. XML Template
  5. JSON Template

This presents a short summary of the profile - a combination of the author's summary, and some automatically generated summary content

This is a view of the differential statement (see above). For context, additional information not in the differential is also show partially transparent

This is a view of the snapshot produced by the profile (see above). The information is a comprehensive view of what the profile means

Not one yet

Not one yet

Может возникнуть ситуация, когда приложению необходимо поддерживать больше одного профиля одновременно. Типичный пример такой ситуации - приложение системы ЭМК, которое должно поддерживать профиль совместного использования данных общего назначения (например DAF ), а также поддерживать специфические профили для системы поддержки принятия решений, использующей тот же самый интерфейс.

Эффект от поддержки двух наборов профилей зависит от того, создаются ли ресурсы или используются. Когда приложение создаёт некоторый контент, оно должно создать такой контект, который соответствует обоим наборам профилей - т. е. "пересечению" этих профилей (intersection). Когда приложение получает информацию в качестве потребителя, оно должно иметь возможность принимать контент, который соответствует каждому набору профилей - т. е. "объединению" этих профилей (union).

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

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

  1. непересекающиеся множества: нет экземпляров, которые соответствуют профилям А и Б (технически, пересечение профилей А и Б соответствует пустому множеству)
  2. частично пересекающиеся множества: некоторые экземпляры соответствуют и А, и Б, остальные - только А или Б
  3. одно множество входит в другое: все ресурсы, которые соответствуют А, соответствуют и Б, но только некоторые из тех, что соответствуют Б, соответствуют А (или наоборот)
  4. равные множества: все ресурсы, которые соответствуют профилю А, также соответствуют и профилю Б, а все ресурсы, которые не соответствуют профилю Б, не соответствуют и профилю А

Профили можно сравнивать для определения их совместимости. Одно такое сравнение можно найти (no - todo: bring this into the build) между DAF и QICore . Обратите внимание, что это сравнение сгенерировано инструментарием, находящимся в разработке, и является полностью черновым содержимым для демонстрации концепции сравнения профилей.