CRD Feedback REST API Specification
Overview
As part of the InterSystems® Payer Services CRD (Coverage Requirements Discovery) REST APIs, a provider can use the feedback endpoint to optionally send information about the end user’s response to a card to the feedback endpoint for the relevant service.
Refer to the audience and connection sections of the Using the Public APIs guide for general information on prerequisites, connectivity, and authentication. To use these REST APIs, you will also need to know the base URL of the payer server that you will be connecting to.
The CRD APIs are designed in compliance with the CMS-0057-F regulationsOpens in a new tab and the CDS Hooks SpecificationOpens in a new tab.
Workflow
A typical CRD workflow including use of the feedback API is as follows:
-
A provider’s client application sends a request to the discovery endpoint of the CDS Hooks server of their patient’s payer to receive information about the services that are available at that server. This includes the HL7® FHIR® resources required by each service.
-
The client invokes one of the available services by sending a request to the relevant service endpoint. This request provides access to any FHIR resources that the service requires to perform its evaluation. The server responds to a valid service call with the appropriate cards or system actions, if any.
-
Optionally, the client sends information about the end user’s response to a service’s card to the feedback endpoint (this API) for the service previously called.
Endpoint: cds-services/<id>/feedback
URL
The URL for this API is:
<BaseURL>/csp/healthshare/<namespace_identifier>/cds-hooks/r4/cds-services/<serviceID>/feedback
where <BaseURL> and <namespace_identifier> have been provided to you by the payer organization you are connecting with, and <serviceID> is the identifier of the service you are providing feedback for.
Optional Capabilities
None.
Endpoint Prerequisites
-
You have previously called the service endpoint for which you want to send feedback, and received a card in the response
Required Header Settings
-
Content-Type: application/json
-
Accept: application/json
Request Methods
Shares information about how the client application’s user interacted with the specified service’s output.
Query Parameters
None.
Request Body
The request body contains a list of Feedback objects. Each Feedback object must include:
-
The universally unique identifier (UUID) of the card for which feedback is being submitted
-
The outcome of the card (accepted or overridden)
-
If the outcome is accepted, a list of AcceptedSuggestions and their UUIDs
-
Optionally, if the outcome is overridden, the override reason
-
The time when action was taken on the card
An example of a request body where the suggestion was accepted is as follows:
{
"feedback": [
{
"card": "4e0a3a1e-3283-4575-ab82-028d55fe2719",
"outcome": "accepted",
"acceptedSuggestions": [
{
"id": "e56e1945-20b3-4393-8503-a1a20fd73152"
}
],
"outcomeTimestamp": "2021-12-11T10:05:31Z"
}
]
}
An example of a request body where guidance was overridden, with the overrideReason, is shown below:
{
"feedback":[
{
"card":"9368d37b-283f-44a0-93ea-547cebab93ed",
"outcome":"overridden",
"overrideReason":{
"reason":{
"code":"d7ecf885",
"system":"https://example.com/cds-hooks/override-reason-system"
},
"userComment":"A comment entered by the clinician."
},
"outcomeTimestamp":"2020-12-11T00:00:00Z"
}
]
}
Success Response
The request was invoked successfully.
Error Responses
An error when validating the feedback request.
The request is unauthenticated.
A generic error message, returned when no more specific message is suitable.