CDS Client capability endpoint proposal

[isaacvetter]

During the Jan HL7 WGM as part of CDS Hooks 1.1 issue resolution, we talked through this jira, from @bvdh: https://jira.hl7.org/browse/FHIR-28684

Proposal:

CDS Client hosts a well-known json file of key/value pairs describing a CDS Client's support of CDS Hooks towards the goal of enabling sufficiently advanced CDS Services to dynamically re-configuring itself.

GET {some base url, see below}/.well-known/cds-hooks-configuration

{
   "CDS_Client_capabilities":{
      "supported_cards":[
         "info",
         "link",
         "smart-link",
         "suggestion"
      ],
      "support_override_reasons":true,
      "support_feedback_service":false,
      "suggestions_supported":[
         "Condition.create",
         "Condition.update",
         "MedicationRequest.create/update/delete",
         "ServiceRequest.create/update/delete",
         "NutritionOrder.create/update/delete"
      ]
   }
}

---

• Question: Where does this capability statement reside, and how does the CDS Service know about it?
• Options:
  • {fhirServer}/.well-known/cds-hooks-configuration
    • Note that CDS Clients aren't required to have a fhirServer and that the fhirServer is not communicated when the CDS Client queries the CDS Service's discovery endpoint
  • {JWT's iss}/.well-known/cds-hooks-configuration
    • Note that CDS Client do authenticate (provide a JWT) both when calling discovery and the service, but that the most reasonable iss value would be the CDS Client's authorization server, possibly totally unrelated to its FHIR server and CDS Client.
  • {some url provided in the discovery request}/.well-known/cds-hooks-configuration
  • {some url provided in the cds hooks request}/.well-known/cds-hooks-configuration