Skip to main content

CRD Service FHIR API Specification

Overview

As part of the InterSystems® Payer Services CRD (Coverage Requirements Discovery) APIs, a provider can submit a CRD query to a CRD service’s Service endpoint to find out the payer’s coverage requirements for a given service or device.

The CRD APIs are designed in compliance with the CMS-0057-F regulationsOpens in a new tab. Refer to the Getting Started section for information on connectivity, authentication and how to get help. You can also retrieve the capability statement for the CRD APIs.

To use the CRD Service API, you will need to know the base URL of the payer server you will be connecting to. In addition, you will need information about the desired CRD service or services which can be retrieved from the Discovery Response. Most notably, you will need to know the unique identifier for the service and the appropriate point in the provider workflow (the hookOpens in a new tab) when the service should be invoked.

Workflow

A typical CRD Service API workflow is as follows:

  • The provider system acquires the information necessary to submit queries to a payer system CRD service by using the CRD Discovery API.

  • The provider system uses the aforementioned information to construct and submit an authorized POST request to the CRD service’s Service endpoint at the appropriate point in the provider workflow (the hookOpens in a new tab). This request must provide the payer system access to any HL7® FHIR® resource data that the service requires.

  • The payer’s system returns a CDS Service ResponseOpens in a new tab, which provides information about coverage requirements, a link to a questionnaire where the provider can provide further details, or both.

  • If applicable, the provider completes the questionnaire so that the payer system can determine coverage requirements and return them to the provider system.

Endpoint

URL

The URL for this API is:

<BaseURL>/cds-services/<serviceID>

Optional Capabilities

None.

Endpoint Prerequisites

None.

Required Header Settings

  • Content-Type: application/json+fhir

  • Accept: application/json+fhir

Request Methods

POST <BaseURL>/cds-services/<serviceID>

Requests a CDS Service ResponseOpens in a new tab from the payer system.

Query Parameters

None.

Request Body

The body of the request is a CDS Service RequestOpens in a new tab. If the service requires FHIR resource data about the patient or the clinical context, you may provide access to this data in any of the following ways:

  • Fetch the data prior to sending the request, and then passes the data along within the request body according to the service’s prefetch” templatesOpens in a new tab.

  • Acquire an OAuth 2.0 access token from the FHIR repository’s authorization server which will allow the payer system to query the FHIR repository directly for the data it requires. The client includes the access token along with other FHIR resource access parametersOpens in a new tab in the request body

  • Combine both the preceding methods: provide some prefetch data in the request body along with FHIR resource access parameters enabling the payer system to acquire the rest of the required data.

Success Response

Status code 200

The request succeeded. The body of the response is a CDS Service ResponseOpens in a new tab, containing all cards or system actions which apply. If no cards or system actions apply, the body of the service response is an empty JSON object.

Error Responses

Status code 400 Error

Error when validating the service request. The request may be invalid structurally (improper JSON, for example), or semantically (an improper service ID is given, for example.)

Status code 401 Unauthorized

The bearer token used for authentication failed validation (if it expired, for example).

Status code 404 Not Found

The named service does not exist, or is not associated with the hook identified in the request body.

Status code 412 Precondition Failed

Error when trying to fetch necessary FHIR data.

Status code 500 Internal Server Error

A generic error message, returned when no more specific message is suitable.

FeedbackOpens in a new tab