jmandel
commented
4 years ago Thanks!
The SMART App Launch discovery process shouldn't/doesn't actually depend on Capability.rest.security.service; it only depends on Capability.rest.security.extension, with the Extension.url of http://fhir-registry.smarthealthit.org/StructureDefinition/oauth-uris.
That said, we do have some examples that populate Capability.rest.security.service; we should either remove those examples or try to make them self-consistent. None of the code system URLs should be version-specific.
The example Capability Statements use the STU3 code system in CapabilityStatement.rest.security.service http://hl7.org/fhir/STU3/valueset-restful-security-service.html - STU3 binding https://www.hl7.org/fhir/valueset-restful-security-service.html - R4 binding
the old code system is used in at least: http://hl7.org/fhir/smart-app-launch/conformance/index.html#example http://hl7.org/fhir/smart-app-launch/CapabilityStatement-smart-app-launch-example.html http://www.hl7.org/fhir/smart-app-launch/capability-statement/
These should be updated to the R4 code system (http://terminology.hl7.org/CodeSystem/restful-security-service) because the binding is extensible so using the same code with a different code system is not allowed; these examples as-is are invalid as R4 capability statements.
some minor edits for clarification