CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®)
2.0.0 - STU 2 United States of America flag

CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®), published by HL7 Financial Management Working Group. This is not an authorized publication; it is the continuous build for version 2.0.0). 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: C4BB CapabilityStatement

Official URL: http://hl7.org/fhir/us/carin-bb/CapabilityStatement/c4bb Version: 2.0.0
Active as of 2022-09-11 Computable Name: CarinBbCapabilityStatement

This Section describes the expected capabilities of the C4BB Server actor which is responsible for providing responses to the queries submitted by the C4BB Requestors.

The EOB Resource is the focal Consumer-Directed Payer Data Exchange (CDPDE) Resource. Several Reference Resources are defined directly/indirectly from the EOB: Coverage, Patient, Organization (Payer ID), Practioner, and Organization (Facility).

The Coverage Reference Resource SHALL be returned with data that was effective as of the date of service of the claim; for example, the data will reflect the employer name in effect at that time. However, for other reference resources, payers MAY decide to provide either the data that was in effect as of the date of service or the current data. All reference resources within the EOB will have meta.lastUpdated flagged as must support. Payers SHALL provide the last time the data was updated or the date of creation in the payers system of record, whichever comes last. Apps will use the meta.lastUpdated values to determine if the reference resources are as of the current date or date of service.

Raw OpenAPI-Swagger Definition file | Download

C4BB CapabilityStatement

  • Official URL:http://hl7.org/fhir/us/carin-bb/CapabilityStatement/c4bb
  • Implementation Guide Version: 2.0.0
  • FHIR Version: 4.0.1
  • Intended Use: Requirements
  • Supported Formats: XML, JSON
  • Published: 2022-09-11
  • Published by: HL7 Financial Management Working Group (FM WG)
  • Status: Active

This Section describes the expected capabilities of the C4BB Server actor which is responsible for providing responses to the queries submitted by the C4BB Requestors.

The EOB Resource is the focal Consumer-Directed Payer Data Exchange (CDPDE) Resource. Several Reference Resources are defined directly/indirectly from the EOB: Coverage, Patient, Organization (Payer ID), Practioner, and Organization (Facility).

The Coverage Reference Resource SHALL be returned with data that was effective as of the date of service of the claim; for example, the data will reflect the employer name in effect at that time. However, for other reference resources, payers MAY decide to provide either the data that was in effect as of the date of service or the current data. All reference resources within the EOB will have meta.lastUpdated flagged as must support. Payers SHALL provide the last time the data was updated or the date of creation in the payers system of record, whichever comes last. Apps will use the meta.lastUpdated values to determine if the reference resources are as of the current date or date of service.

Support the Following Implementation Guides:

FHIR Server RESTful Capabilities

The C4BB Server SHALL:

  1. Support all profiles defined in this Implementation Guide..
  2. Implement the RESTful behavior according to the FHIR specification.
  3. 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.
  4. Support json source formats for all CARIN-BB interactions.
  5. Identify the CARIN-BB profiles supported as part of the FHIR meta.profile attribute for each instance.
  6. Support the searchParameters on each profile individually and in combination.

The C4BB Server SHOULD:

  1. Support xml source formats for all C4BB interactions.

Security:

  1. See the General Security Considerations section for requirements and recommendations.
  2. A server SHALL reject any unauthorized requests by returning an HTTP 401 "Unauthorized", HTTP 403 "Forbidden", or HTTP 404 "Not Found" .

RESTful Capabilities by Resource/Profile:

Summary

Resource TypeSupported InteractionsSupported ProfilesSupported SearchesSupported _includesSupported _revincludesSupported Operations
Coverage search-type, read, vread C4BB-Coverage _id, _lastUpdated Coverage:payor
ExplanationOfBenefit search-type, read, vread C4BB-ExplanationOfBenefit, C4BB-ExplanationOfBenefit-Inpatient-Institutional, C4BB-ExplanationOfBenefit-Outpatient-Institutional, C4BB-ExplanationOfBenefit-Oral, C4BB-ExplanationOfBenefit-Pharmacy, C4BB-ExplanationOfBenefit-Professional-NonClinician _id, patient, _lastUpdated, type, identifier, service-date, service-start-date, billable-period-start ExplanationOfBenefit:patient, ExplanationOfBenefit:provider, ExplanationOfBenefit:care-team, ExplanationOfBenefit:coverage, ExplanationOfBenefit:insurer, ExplanationOfBenefit:payee, ExplanationOfBenefit:*
Organization search-type, read, vread C4BB-Organization _id, _lastUpdated
Patient search-type, read, vread C4BB-Patient _id, _lastUpdated
Practitioner search-type, read, vread C4BB-Practitioner _id, _lastUpdated
RelatedPerson search-type, read, vread C4BB-RelatedPerson _id, _lastUpdated

Coverage

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support search-type, read.
  • SHOULD support vread.

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a Coverage resource using: GET [base]/Coverage/[id]
  • A Server SHOULD be capable of returning a Coverage resource using: GET [base]/Coverage/[id]/_history/vid
  • A Server SHALL be capable of returning resources matching a search query using: GET [base]/Coverage/[id]{?[parameters]{&_format=[mime-type]}}
  • A Server SHALL be capable of supporting the following _includes:
    • Coverage:payor - GET [base]/Coverage?[parameter=value]&_include=Coverage:payor

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL _id token GET [base]/Coverage?_id=[id]
SHOULD _lastUpdated date GET [base]/Coverage?_lastUpdated=[dateTime]

Search Parameter Requirements (When Used Alone or in Combination):

  • _id (token):

    http://hl7.org/fhir/R4/search.html#id

  • _lastUpdated (date):

    http://hl7.org/fhir/R4/search.html#lastUpdated

ExplanationOfBenefit

Conformance Expectation: SHALL

Resource Specific Documentation:

When an EOB references another resource (e.g., Patient or Practitioner), the reference may be versioned or versionless. Payers SHALL use versioned references whenever they maintain point-in-time data (data that was effective as of the date of service or date of admission on the claim), but MAY use versionless references when they do not maintain versioned data. Clients MAY request referenced resources as part of an EOB search (by supplying the _include parameter) or directly using read or vread. Payers SHALL support both approaches, and SHALL return the same content for referenced resources in either case. “:iterate" should be used if you request to include Coverage:payor in the EOB response bundle, e.g. GET [base]/ExplanationOfBenefit?_id[parameter=value]&_include=ExplanationOfBenefit:coverage&_include:iterate=Coverage:payor.

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support search-type+, read.
  • SHOULD support vread.

search-type+

Searches using service-date, _lastUpdated, or type require a patient search argument.

_include:* SHALL be supported.

Note: _include=ExplanationOfBenefit:* means, at minimum, the resources that are included as reference type search parameters for the ExplanationOfBenefit resource on the server. Servers claiming compliance to this guide will, at minimum, support the include of patient, provider, care-team, coverage, insurer, and payee, and will support returning all of them in support ExplanationOfBenefit:* (Where not supported only as contained resources). Not all of these are defined as required search parameters, but are defined as part of the _include requirement. For example, the insurer search parameter is not required because in the context of the use case, it is anticipated there will ever be one insurer. It however must be returned in the _include=ExplanationOfBenefit:* results. The means in which this is done (including defining all of the _include as search parameters) is not defined.

Fetch and Search Criteria:

  • A Server SHALL be capable of returning an ExplanationOfBenefit resource using: GET [base]/ExplanationOfBenefit/[id]
  • A Server SHOULD be capable of returning an ExplanationOfBenefit resource using: GET [base]/ExplanationOfBenefit/[id]/_history/vid
  • A Server SHALL be capable of returning resources matching a search query using: GET [base]/ExplanationOfBenefit/[id]{?[parameters]{&_format=[mime-type]}}
  • A Server SHALL be capable of supporting the following _includes:
    • ExplanationOfBenefit:patient - GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:patient
    • ExplanationOfBenefit:provider - GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:provider
    • ExplanationOfBenefit:care-team - GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:care-team
    • ExplanationOfBenefit:coverage - GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:coverage
    • ExplanationOfBenefit:insurer - GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:insurer
    • ExplanationOfBenefit:payee - GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:payee
    • ExplanationOfBenefit:* - GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:*

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL _id token GET [base]/ExplanationOfBenefit?_id=[id]
SHALL patient reference GET [base]/ExplanationOfBenefit?patient=[type]/[id]
SHALL _lastUpdated date GET [base]/ExplanationOfBenefit?_lastUpdated=[dateTime]
SHALL type token GET [base]/ExplanationOfBenefit?type=[system]|[code]
SHALL identifier token GET [base]/ExplanationOfBenefit?identifier=[system]|[code]
SHALL service-date date GET [base]/ExplanationOfBenefit?service-date=[service-date]
SHALL service-start-date date GET [base]/ExplanationOfBenefit?service-start-date=[service-start-date]
SHALL billable-period-start date GET [base]/ExplanationOfBenefit?billable-period-start=[billable-period-start]

Search Parameter Requirements (When Used Alone or in Combination):

  • _id (token):

    http://hl7.org/fhir/R4/search.html#id

  • _lastUpdated (date):

    http://hl7.org/fhir/R4/search.html#lastUpdated

Organization

Conformance Expectation: SHOULD

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support read.
  • SHOULD support vread.
  • MAY support search-type.

Fetch and Search Criteria:

  • A Server SHALL be capable of returning an Organization resource using: GET [base]/Organization/[id]
  • A Server SHOULD be capable of returning an Organization resource using: GET [base]/Organization/[id]/_history/vid
  • A Server MAY be capable of returning resources matching a search query using: GET [base]/Organization/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL _id token GET [base]/Organization?_id=[id]
SHOULD _lastUpdated date GET [base]/Organization?_lastUpdated=[dateTime]

Search Parameter Requirements (When Used Alone or in Combination):

  • _id (token):

    http://hl7.org/fhir/R4/search.html#id

  • _lastUpdated (date):

    http://hl7.org/fhir/R4/search.html#lastUpdated

Patient

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support read.
  • SHOULD support vread.
  • MAY support search-type.

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a Patient resource using: GET [base]/Patient/[id]
  • A Server SHOULD be capable of returning a Patient resource using: GET [base]/Patient/[id]/_history/vid
  • A Server MAY be capable of returning resources matching a search query using: GET [base]/Patient/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL _id token GET [base]/Patient?_id=[id]
SHOULD _lastUpdated date GET [base]/Patient?_lastUpdated=[dateTime]

Search Parameter Requirements (When Used Alone or in Combination):

  • _id (token):

    http://hl7.org/fhir/R4/search.html#id

  • _lastUpdated (date):

    http://hl7.org/fhir/R4/search.html#lastUpdated

Practitioner

Conformance Expectation: SHOULD

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support read.
  • SHOULD support vread.
  • MAY support search-type.

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a Practitioner resource using: GET [base]/Practitioner/[id]
  • A Server SHOULD be capable of returning a Practitioner resource using: GET [base]/Practitioner/[id]/_history/vid
  • A Server MAY be capable of returning resources matching a search query using: GET [base]/Practitioner/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL _id token GET [base]/Practitioner?_id=[id]
SHOULD _lastUpdated date GET [base]/Practitioner?_lastUpdated=[dateTime]

Search Parameter Requirements (When Used Alone or in Combination):

  • _id (token):

    http://hl7.org/fhir/R4/search.html#id

  • _lastUpdated (date):

    http://hl7.org/fhir/R4/search.html#lastUpdated

RelatedPerson

Conformance Expectation: SHOULD

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support read.
  • SHOULD support vread.
  • MAY support search-type.

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a RelatedPerson resource using: GET [base]/RelatedPerson/[id]
  • A Server SHOULD be capable of returning a RelatedPerson resource using: GET [base]/RelatedPerson/[id]/_history/vid
  • A Server MAY be capable of returning resources matching a search query using: GET [base]/RelatedPerson/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL _id token GET [base]/RelatedPerson?_id=[id]
SHOULD _lastUpdated date GET [base]/RelatedPerson?_lastUpdated=[dateTime]

Search Parameter Requirements (When Used Alone or in Combination):

  • _id (token):

    http://hl7.org/fhir/R4/search.html#id

  • _lastUpdated (date):

    http://hl7.org/fhir/R4/search.html#lastUpdated