CARIN Consumer Directed Payer Data Exchange
0.3.1 - STU1

CARIN Consumer Directed Payer Data Exchange, published by HL7 Financial Management Working Group. This is not an authorized publication; it is the continuous build for version 0.3.1). This version is based on the current content of https://github.com/HL7/carin-bb/ and changes regularly. See the Directory of published versions

CapabilityStatement: Consumer-Directed Payer Data Exchange HealthPlan API CapabilityStatement

Raw OpenAPI-Swagger Definition file | Download

Consumer-Directed Payer Data Exchange Server CapabilityStatement

  • Implementation Guide
  • FHIR Version: 4.0.1
  • Supported formats: xml, json
  • Published: 2019-12-04
  • Published by HL7 International and CARIN Alliance

This Section describes the expected capabilities of the Consumer-Directed Payer Data Exchange Server actor which is responsible for providing responses to the queries submitted by the Consumer-Directed Payer Data Exchange Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Consumer-Directed Payer Data Exchange Servers are defined.

FHIR RESTful Capabilities

The Consumer-Directed Payer Data Exchange Server SHALL:

  1. Support the CARIN Blue Button Patient and ExplanationOfBenefit resource profiles.
  2. Support additional resource profiles from the list of CARIN Blue Button Profiles.
  3. Implement the RESTful behavior according to the FHIR specification.
  4. Return the following response classes:
    • (Status 400): invalid parameter
    • (Status 401/4xx): unauthorized request
    • (Status 403): insufficient scope
    • (Status 404): unknown resource
    • (Status 410): deleted resource.
  5. Support json source formats for all Consumer-Directed Payer Data Exchange interactions.

The Consumer-Directed Payer Data Exchange Server SHOULD:

  1. Support xml source formats for all Consumer-Directed Payer Data Exchange interactions.
  2. Identify the CARIN Blue Button profiles supported as part of the FHIR meta.profile attribute for each instance.

Security:

  1. See the Authorization, Authentication, and Registration section for requirements and recommendations.
  2. A server SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code.