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.
Opala's Patient Access Documentation Set enables you to access API documentation for Opala's FHIR Patient Access API. The documentation for this API assumes that you are familiar with the HL7 FHIR Release 4 specification. If you are not, each endpoint topic in the documentation contains links to the referenced sections of the FHIR specification.
Opala's Patient Access documentation set is divided into four sections.
- An introduction to Opala's Patient Access API, including FHIR Resources and Interactions and FHIR Searches.
- A discussion of SMART on FHIR, beginning with the SMART App Launch Framework.
- A deeper dive into Patient Access, which includes discussions on CARIN for Blue Button®, Da Vinci PDex, and mapping adjudicated claims.
- Details on Opala's The Patient Access API.
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 a user account and app registration. Once a user account has been created, the developer can then register his, her, or their app with Opala. When an application is registered, it is made available in Opala's App Gallery for members to use.
For more information, see the Creating an Opala Account and Registering an Application topics earlier in this documentation.
Getting Started with the Patient Access API
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.
Additional Resources
