Contact Us

Patient Access API

Patient Access API

The Patient Access Documentation Set provides detailed guidance for Opala’s FHIR Patient Access API. The documentation assumes familiarity with the HL7 FHIR Release 4 specification, but if you’re not already familiar, each endpoint topic includes links to the relevant sections of the FHIR specification for reference.

The Patient Access documentation is organized into two main parts: an introduction to the API, which covers FHIR Resources and Interactions as well as API Queries; and a deeper dive into Patient Access, which explores topics such as CARIN for Blue Button®, Da Vinci PDex, and mapping adjudicated claims.

Introduction to the Opala Patient Access API

The CMS Interoperability and Patient Access final rule requires CMS-regulated payers to effectuate and maintain a secure, standards-based Patient Access API using HL7® FHIR®. Opala’s Patient Access API enables patients to access their claims and encounter information — including cost — as well as a defined sub-set of their clinical information through the third-party application of their choice.

The Opala API follows the SMART App Launch Framework for the HL7 FHIR Release 4 specification and CARIN for Blue Button®.

The SMART App Launch Framework specification enables applications to launch and securely connect to a FHIR API. The SMART on FHIR OAuth requirements are met by providing the FHIR Capability Statement and a Well-Known Uniform Resource Identifier JSON file. The Capability Statement is a key part of the overall conformance framework in FHIR. The Capability Statement documents a set of behaviors of a FHIR Server that may be used to identify actual server functionality or implementation. It also provides a set of launch capabilities for SMART on FHIR apps. The Well-Known Uniform Resource Identifier displays the SMART authorization endpoints that an application would use to authorize and access Opala’s FHIR resources.

CARIN for Blue Button® and Da Vinci Payer Data Exchange (PDex)

The CMS Interoperability Final Rule requires a covered plan to make a member’s information available to any other plan as directed by the member. The approaches to delivering the required health plan data to various stakeholders by CARIN for Blue Button® and Da Vinci Payer Data Exchange (PDex) are very different. The CARIN Alliance approaches providing health plan data primarily from a financial (claims) perspective, with limited associated clinical data. The Da Vinci Project approaches the issue primarily from a clinical perspective and leaves most financial data out of scope.

For more information, see this documentation set’s CARIN for Blue Button® and Da Vinci Payer Data Exchange (PDex) topics.

Health Insurance Portability and Accountability Act (HIPAA) Compliance

According to CMS’s Interoperability Rule, third-party applications are not required to be HIPAA compliant. Similarly, members may choose to ignore payer recommendations about whether or not to use a third-party application. However, be aware that payers prefer their members use an application that is both secure and follows HIPAA guidelines; these payers may discourage their members from using non-compliant applications.

Once health information has been transmitted to a third-party app, it is, generally, no longer protected by HIPAA. To better understand an application’s relationship to HIPAA, see the Office for Civil Rights’ (OC’s) Resources for Mobile Health Apps Developers.

Registering with Opala

Access to Opala’s Patient Access API requires app registration to be submitted and approved by Opala. When a 3rd party application is registered, it is made available in Opala’s App Gallery for members to use.

For more information, see the registering your application topic in the Getting Started section of this documentation.

Additional Resources