Support Implied Profiles in RepositoryValidatingRuleBuilder

[tadgh]

The Core libraries now support the concept of "implied profiles", which indicates that a resource should undergo validation against this "implied profile" whether it is present in the incoming resource's profile section or not. This request is to add the capability to our RepositoryValidatingRuleBuilder to provide the ability to make use of this new feature in the core libraries.

A potential API could look like:

    ruleBuilder
                .forResourcesOfType("Patient")
                                .impliedProfile("http://www.hl7.org/fhir/us/core/StructureDefinition-us-core-patient.html")
                .requireAtLeastProfile("http://www.hl7.org/fhir/us/core/StructureDefinition-us-core-patient.html");

Which would cause any incoming Patients to be validated against US Core, whether or not they indicate that they support the profile in their meta.profile section.

[jamesagnew]

I like that syntax - I'm assuming based on the above:

• impliedProfile means that we assume this profile on this rule only if no explicit declarations are present
• requireAtLeastProfile means that we always validate against this profile regardless of any explicit declarations (which in the actual example above means that the impliedProfile is redundant)

Assuming so, maybe better names would be:

ruleBuilder
   .forResourcesOfType("Patient")
   .impliedProfileIfNoExplicit("http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient")
   .impliedProfileAlways("http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient");

Another thought: FHIR has this neat Profile Mapping Extension which allows a profile to declare under what criteria it just always applies. The idea here is to generalize the concept behind the new rule where an Observation with a vital signs LOINC code is always treated as a vital signs profile and validated as such, even if it doesn't explicitly declare this. I don't think we need to support this extension right away (nobody does) but in the same spirit, I could see us implementing rulebuilder functionality like:

ruleBuilder
   .forResourcesOfType("Patient")
   .matchingExpression("Patient.identifier.where(system='http://foo').present()"
   .impliedProfileAlways("http://foo.org/Patient-profile");

and maybe even

ruleBuilder
   .forResourcesOfType("Patient")
   .notMatchedByAnyOtherRules()
   .impliedProfileAlways("http://foo.org/Patient-profile");

[dmuylwyk]

I'm pretty sure requireAtLeastProfile(...) only enforces the declaration in Meta.profile, and what we want here is an implied profiles equivalent to requireValidationToDeclaredProfiles(). For example, something like: requireValidationToImpliedProfiles()—and possibly requireValidationToDeclaredAndImpliedProfiles() although it'd be my preference to chain the two methods to achieve both. This way we can also decouple specifying implied profiles from enforcement of implied profiles in this API, allowing for multiple profiles both declared and implied.

In any case, it would be nice if the new API aligned with the existing API.

[dmuylwyk]

It seems we could use the rulebuilder to populate the Profile Mapping Extension accordingly, which signals validation expectations to the client.