The Opala Solution
The Opala Patient Access API Resources and Interactions

SMART App Launch Framework Authorization Flows Access Tokens Scopes Endpoints Working with the FHIR Server

CARIN for Blue Button®
Da Vinci Payer Data Exchange (PDex) Mapping Adjudicated Claims and Encounter Information

The Patient Access API

© 2021-2023 Opala. All Rights Reserved.

Version 1.0.1.0


Contact Opala's
Documentation Team

CARIN for Blue Button®

The CMS Interoperability and Patient Access Final Rule expanded the scope of a Blue Button 2.0 equivalent to include not just Medicare Advantage (MA) plans, but also Medicaid HMO (managed care plans), Children’s Health Insurance Program (CHIP) HMO and qualified health plans (QHP) in the federally facilitated exchanges (FFEs). These entities must meet certain requirements regarding patient access to their health care information, including requirements related to application programming interfaces (APIs).

The Consumer-Directed Payer Data Exchange Implementation Guide (CARIN IG for Blue Button®) was defined by the CARIN Alliance to meet CMS requirements.

CARIN is an acronym of Creating Access to Real-time Information Now through Consumer-Directed Exchange. A consumer-directed exchange occurs when a consumer, or an individual authorized by a payer to access another person’s information, invokes their HIPAA Individual Right of Access and requests their digital health information from a HIPAA covered entity (CE) via an application or other third-party data steward.

The implementation guide defines how to provide claims and encounter data. The IG describes the CARIN for Blue Button® Framework and Common Payer Consumer Data Set (CPCDS). The framework and data set provide a collection of resources that payers can display to consumers using a FHIR API.

Note: Blue Button, the slogan, 'Download My Data,' the Blue Button Logo, and the Blue Button combined logo are registered service marks owned by the U.S. Department of Health and Human Services.

Background

The CARIN Alliance Health Plan Workgroup was organized to develop a FHIR-based API that could be implemented by a consumer-facing application. The goal of the CARIN Alliance Health Plan Workgroup was to develop an agreed upon set of data fields to exchange with consumers and a FHIR-based implementation guide for health plans and consumer facing applications to use to implement the API.

The CARIN for Blue Button® Framework was designed to answer the challenge for health plans to meet or exceed CMS Blue Button® 2.0 capabilities. The CMS Blue Button® 2.0 project provides over 53 million Medicare fee-for-service beneficiaries access to their electronic claims information.

CMS provides implementation guidance for the following data types that make-up the Patient Access API:

The ExplanationOfBenefit resource

The CARIN IG for Blue Button® is focused on providing claims information, including adjudication information, in the form of a FHIR ExplanationOfBenefit (EOB). CARIN for Blue Button® uses the EOB resource as its primary resource. EOB has the following reference resources:

Because the ExplanationOfBenefit and Coverage profiles are not included in the US Core, there is no alignment requirement for these profiles. Patient, Practitioner, and Organization, however, are US Core Profiles. Since these are supporting/reference profiles rather than focus profiles in CARIN IG for Blue Button®, the alignment with the US Core is on the content of these profiles, not on the search parameters.

SMART Application Launch Framework

The SMART App Launch Framework connects third-party applications to Electronic Health Record data. The framework supports apps for use by clinicians, patients, and others via a PHR or Patient Portal or any FHIR system where a user can give permissions to launch an app.

The CARIN IG for Blue Button® requires the use of the SMART App Launch Framework’s standalone launch sequence since it will clarify that applications maintain a patient context for the duration of the connection. The SMART App IG also provides guidance on how to configure OAuth 2.0 servers to mediate access based on a set of rules configured to enforce institutional policy, which may include requesting end-user authorization. The SMART App IG also provides guidance on how to handle authentication.

Additional Resources

Top