[Validator] Support Global profiles from IGs

[ewoutkramer]

If you validate instances in the context of an IG, that IG (formally by means of ImplementationGuide.global) may specify a set of IG specific profiles that a kind of resource must conform to. I.e. although Observation.subject and many other core resources refers to Patient, in the context of a Dutch IG, all these references must be interpreted (or replaced by) references to a dutch constrained version of Patient.

Add a feature to the validator to support "profile substitution", where any reference to a core profile X, would be translated to a reference to a more specific profile from such an IG.

[wmrutten]

An IG resource can define dependencies to other IG resources:
https://www.hl7.org/fhir/implementationguide-definitions.html#ImplementationGuide.dependency

Should this logic also try to resolve the parent IG's and verify any inherited global profiles?

[ewoutkramer]

I've almost assumed these references are "informal", but I am not sure....

[wmrutten]

I think this is intended for validation purposes...

[LouisBernath]

Any plans to support IGs in the near future? :)

[wmrutten]

Just thinking out loud, we could implement a new ResourceResolver that indexes all dependencies referenced by an IG. The resolver could also build a closure of all external dependencies to other IGs. This ResourceResolver could then be consumed by the SnapshotGenerator & Validator classes.

[ewoutkramer]

Yes, if we combine that with package support (which @mharthoorn has already built) we basically have all the tools in place we need, based on the existing framework.

[wmrutten]

Sounds like a plan! Shouldn't be too complicated.

[marcovisserFurore]

Duplicate of FirelyTeam/firely-net-sdk#1863

[ewoutkramer]

Why is this marked as a duplicate of FirelyTeam/firely-net-sdk#1863? This issue is about the "global" feature in the IG resource, and has nothing to do with NPM packages...

[mmsmits]

Add a substitute resource resolver based on the IG to solve this to the SDK.
This should live in Base, however, ImplementationGuide is not in base, we should think about the design here (maybe a partial class?).