Дифференциальные профили FHIR

При объявлении дифференциального элемента в StructureDefinition заменяет ли дифференциальный элемент ВСЕ свойства базового элемента или только указанные свойства?

Пример:

<StructureDefinition>
...
  <differential>
     ...
    <element>
      <path value="Patient.gender" />
      <min value="1" />
    </element>
    ... 
  </differential>
</snapshot>

Каково правильное значение свойства метки в сгенерированном снимке после применения этого дифференциала? Если из базы, как при желании убрать собственность?


person Chris Grenz    schedule 21.09.2015    source источник


Ответы (2)


Похоже, что стандартный здесь говорит, что метка будет исходить из базы. Однако нет способа удалить базовое свойство?

Кроме того, в стандарте ничего не говорится (я думаю) о том, как обращаться со списками свойств (например, ограничений, типов и т. Д.) - следует ли их заменять массово?

Наконец, «первичный ключ» списка элементов немного нечеткий ... мы предполагаем, что COALESCE (имя, путь) - если он доступен, он переопределяет базу того же ключа, а не редактирует эти поля. Однако это предотвращает переименование срезов, ЕСЛИ система не должна использовать фиксированные дискриминаторы + привязки (+ ограничения ??) для сопоставления.

person Chris Grenz    schedule 21.09.2015
comment
Нет способа удалить свойство из базы, нет. Я думаю, что мы ясно понимаем ограничения: их нельзя удалить. Типы сложнее, потому что это определяется семантикой набора текста. Список дифференциальных типов заменяет список типов в базовом. И да, путь + имя - это первичный ключ. И да, срезы нельзя переименовать. Но поскольку имя используется только при нарезке, это разумно. - person Grahame Grieve; 21.09.2015

Неуказанные свойства считаются такими же, как у основания. Удаление свойств невозможно. Если указан набор псевдонимов, вы не можете удалить их все, но можете заменить список. Контент, объявленный в дифференциале, всегда заменяет контент в базе. Исключением является текстовое содержимое, где, если дифференциальное содержимое начинается с «...», новое содержимое добавляется к родительскому содержимому.

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

person Lloyd McKenzie    schedule 21.09.2015
comment
Итак, у name есть пара обязательных элементов форматирования: базовая / дифференциальная навигация с использованием косой черты и навигация parent.child с точкой, правильно? - person Chris Grenz; 21.09.2015
comment
Кроме того, из связанной страницы видно, что для проверки ресурса либо требуется: а) создание снимка, в который необходимо добавить ограничения (базовые ограничения нельзя удалить / изменить), ИЛИ б) проверка на соответствие разности и всей базовой профилирует родословную. Это намерение? - person Chris Grenz; 21.09.2015
comment
вот для чего нужен снимок. Все валидаторы используют снимок. В ближайшее время я создам сервис для создания снимков - person Grahame Grieve; 21.09.2015
comment
Привет, Грэхем, значит, на снимке ограничения всегда будут суперсистемой (добавление, а не замена) базовых ограничений? А как насчет привязок? - person Chris Grenz; 21.09.2015
comment
Привязки в дочернем профиле заменят привязки в родительском профиле. В зависимости от силы привязки могут быть ограничения на то, что может делать дочерняя привязка. Например, если требуется базовый набор значений, тогда набор дочерних значений не может включать в себя какие-либо концепции, кроме родительского набора значений. - person Lloyd McKenzie; 22.09.2015