lmsurpre
commented
3 years ago I confirmed by setting allowUnknown at just the "Resource" endpoint, then by setting it on the "Patient" endpoint. it worked as described in the user's guide.
test results for ingestion:
| allowUnknown | Resource.meta.profile | result | |
|---|---|---|---|
| false | ["profile1"] | 400 Bad Request with "Profile 'profile1' is not supported" | |
| false | ["profile1|a"] | 400 Bad Request with "Profile 'profile1 | a' is not supported" |
| false | ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"] | 200 OK | |
| false | ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient\|3.1.1"] | 200 OK | |
| false | ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient\|bogus"] | 200 OK | |
| false | ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient\|3.1.1"] | 400 Bad Request with "Profile 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient | bogus' is not supported" |
notably, the setting does NOT cause the $validate endpoint to return an error when a resource claims conformance to an unknown profiile. that was never really discussed and so I think this behavior is fine, but i wanted to make sure it was clear that the server will still try to validate against the "notAllowed" profiles at this alternate endpoint
Is your feature request related to a problem? Please describe. In https://github.com/IBM/FHIR/issues/1547 we introduced a config property:
fhirServer/resources/<resourceType>/profiles/atLeastOneAs documented at https://ibm.github.io/FHIR/guides/FHIRServerUsersGuide#453-profile-validation, setting this property causes us to:
However, I think points 2 and 3 there are confusing/unexpected behavior for a property named
atLeastOne.For example, consider this scenario:
with no
atLeastOneprop, we accept the resource, validate against profile1, and emit a warning about profile2.with
atLeastOne: [profile1], we would now reject this resource, despite it having the required profileDescribe the solution you'd like Introduce a new config property that controls whether or not the server allows for resources that claim conformance to unknown profiles (aka profiles it can't check conformance to because they are not in the registry).
Something like:
fhirServer/resources/<resourceType>/profiles/allowUnknown(with a default value of true).I doubt we need it at a per-resource-type basis, but if we supported it at this level, users could just use the "Resource" section to set it for all resource types.
Describe alternatives you've considered Introduce
fhirServer/resources/<resourceType>/profiles/allowed(to go along with thenotAllowedlist from #2871 ).Acceptance Criteria
GIVEN server knows about profile1 but not profile2 AND a create resource request comes in with a resource that claims conformance to profile1 and profile2 WHEN allowUnknown is true (default) THEN the resource is successfully validated against profile 1 and a warning is issued to state it couldn't be validated against profile2
GIVEN server knows about profile1 but not profile2 AND a create resource request comes in with a resource that claims conformance to profile1 and profile2 WHEN allowUnknown is false THEN the request is rejected with a reasonable error message that explains that profile2 isn't supported
Additional context A separate idea/question I had is whether we want to let users configure a set of implicit profiles that we could check against whether the resource instance claims conformance to these or not... maybe a separate enhancement request?