CARIN Consumer Directed Payer Data Exchange
0.1.3 - 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.1.3). 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

Raw OpenAPI-Swagger Definition file | Download

C4BB CapabilityStatement

  • Implementation Guide Version: 1.0.0
  • FHIR Version: 4.0.1
  • Supported formats: xml, json
  • Published: 2020-09-08
  • Published by: HL7 Financial Management Working Group (FM WG)

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.

FHIR 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.

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 response code.

RESTful Capabilities by Resource/Profile:

Summary of Search Criteria

Resource TypeSupported ProfilesSupported SearchesSupported _includesSupported _revincludesSupported Operations
CoverageC4BB-Coverage Coverage:payor
ExplanationOfBenefitC4BB-ExplanationOfBenefit, C4BB-ExplanationOfBenefit-Inpatient-Institutional, C4BB-ExplanationOfBenefit-Outpatient-Institutional, C4BB-ExplanationOfBenefit-Pharmacy, C4BB-ExplanationOfBenefit-Professional-NonClinician _id, patient, _lastUpdated, type, identifier, service-date ExplanationOfBenefit:patient, ExplanationOfBenefit:provider, ExplanationOfBenefit:care-team, ExplanationOfBenefit:coverage, ExplanationOfBenefit:insurer, ExplanationOfBenefit:*
OrganizationC4BB-Organization
PatientC4BB-Patient
PractitionerC4BB-Practitioner

Coverage

Conformance Expectation: SHALL

Supported Profiles: C4BB-Coverage

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support read.

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a Coverage resource using:
    GET [base]/Coverage/[id]

  • SHALL for include for now the capability statement does not create the primitive extensios for this yet. SAK: SHould allow differentiation between SHOULDS and SHALLS with conformance extensions -->
  • A Server SHALL be capable of supporting the following _includes:
    Coverage:payor - GET [base]/Coverage?[parameter=value]&_include=Coverage:payor


ExplanationOfBenefit

Conformance Expectation: SHALL

Supported Profiles: C4BB-ExplanationOfBenefit, C4BB-ExplanationOfBenefit-Inpatient-Institutional, C4BB-ExplanationOfBenefit-Outpatient-Institutional, C4BB-ExplanationOfBenefit-Pharmacy, C4BB-ExplanationOfBenefit-Professional-NonClinician

Resource Specific Documentation:

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, Organization (Facility), PractionerRole, Location.

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.

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.

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support read.
read

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

_include:* SHALL be supported.

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a ExplanationOfBenefit resource using:
    GET [base]/ExplanationOfBenefit/[id]

  • SHALL for include for now the capability statement does not create the primitive extensios for this yet. SAK: SHould allow differentiation between SHOULDS and SHALLS with conformance extensions -->
  • 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:* - GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:*

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL_id token GET [base]/ExplanationOfBenefit?_id=[id]
SHALLpatient reference GET [base]/ExplanationOfBenefit?patient=[patient]
SHALL_lastUpdated date GET [base]/ExplanationOfBenefit?_lastUpdated=[_lastUpdated]
SHALLtype token GET [base]/ExplanationOfBenefit?type=[system]|[code]
SHALLidentifier token GET [base]/ExplanationOfBenefit?identifier=[system]|[code]
SHALLservice-date date GET [base]/ExplanationOfBenefit?service-date=[service-date]

Organization

Conformance Expectation: SHALL

Supported Profiles: C4BB-Organization

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support read.
  • SHOULD support vread.

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a Organization resource using:
    GET [base]/Organization/[id]

  • A Server SHOULD be capable of returning a Organization resource using:
    GET [base]/Organization/[id]/_history/vid

  • SHALL for include for now the capability statement does not create the primitive extensios for this yet. SAK: SHould allow differentiation between SHOULDS and SHALLS with conformance extensions -->

Patient

Conformance Expectation: SHALL

Supported Profiles: C4BB-Patient

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support read.
  • SHOULD support vread.

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

  • SHALL for include for now the capability statement does not create the primitive extensios for this yet. SAK: SHould allow differentiation between SHOULDS and SHALLS with conformance extensions -->

Practitioner

Conformance Expectation: SHALL

Supported Profiles: C4BB-Practitioner

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support read.
  • SHOULD support vread.

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

  • SHALL for include for now the capability statement does not create the primitive extensios for this yet. SAK: SHould allow differentiation between SHOULDS and SHALLS with conformance extensions -->