Получить список зависимостей для данного ресурса проверки, например StructureDefinition, ValueSet и т. д.?

Question

Получить список зависимостей для данного ресурса проверки, например StructureDefinition, ValueSet и т. д.?

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

Есть ли способ получить список зависимостей для какого-либо конкретного ресурса проверки, например, StructureDefinition, извлеченного из файла пакета?

В любом случае валидаторам приходится делать это внутри компании в ходе своей обычной работы, но я не вижу способа получить эту информацию. Можно ли это сделать с помощью библиотек HAPI или Firely? Если нет, есть ли другой способ получить эту информацию?

0

hl7-fhir hapi-fhir fhir-net-api

Источник

user4156577 23 май '23 в 12:03

3 ответа

Другие вопросы по тегам hl7-fhir hapi-fhir fhir-net-api

user2382420 23 май '23 в 14:08 2023-05-23 14:08 · Answer 1 · 2023-05-23 14:08

Появился новый IG (http://build.fhir.org/ig/HL7/crmi-ig/), предлагающий операцию по сбору всех зависимостей. Однако он еще не полностью готов и, насколько мне известно, еще нигде не реализован.

2

Источник

user2382420 23 май '23 в 14:08

user1229969 23 май '23 в 21:39 2023-05-23 21:39 · Answer 2 · 2023-05-23 21:39

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

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

1

Источник

user1229969 23 май '23 в 21:39

user2370163 23 май '23 в 15:53 2023-05-23 15:53 · Answer 3 · 2023-05-23 15:53

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

Да, действительно «в ходе обычной работы», поэтому валидатор .NET делает это во время выполнения («получите профиль X и проверьте его»), но здесь не проводится статический анализ. Кстати, оно всегда будет неполным, поскольку расширения могут содержать ссылки на профили, неизвестные до тех пор, пока вы не встретите экземпляр с этим расширением.

Возможно, генератор кода Gino (https://github.com/microsoft/fhir-codegen) имеет информацию и выполняет полную загрузку профилей, прежде чем начнет запускать генераторы кода.