Lee Surprenant

It turns out we already support setting the default FHIR version from fhir-client. I'm not sure how commonly we'd need to set the fhirVersion on a per-request basis, and so...

the schema upgrade is split into multiple transactions, so we need to move the check to the beginning to avoid complicated rollback logic

some related conversation: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.24docref.20operation.20Q see especially the [suggested] JIRA on a potential change from CodeableConcept to Codings, and the comment about not enforcing the required binding to http://hl7.org/fhir/ValueSet/c80-doc-typecodes

with the changes from #3779, the expected response status for this case is now a 403 (not a 500) and the error message should be like this: > Error retrieving...

During QA, we found that we still emitted a generic 500 error in the case that the user was missing read access to their patient resource (e.g. missing scope `patient/Patient.read`).

After the fix, we confirmed some additional cases to ensure we're not leaking information, and everything looks OK to us.

@punktilious do we still need this one?

I missed it when we talked before, but the *system* is whats wrong in your example. The "http://hl7.org/fhir/ValueSet/c80-practice-codes" valueset consists of codes from SNOMED CT. Therefor, the error is right...

QA: 1. Add a ValueSet to the registry which enumerates concept from a made up CodeSystem * this can be provided via either a test RegistryResourceProvider or by setting `serverRegistryResourceProviderEnabled`...

stretch goal for sprint 22