Opala’s API Solution

 

 

 

 

Opala is a hosted Software as a Service (SAAS) solution. Opala deploys critical knowledge to support direct, dynamic care coordination. There is no unmediated consumer/patient/client use of Opala’s service; instead, third-party applications who register with Opala can integrate Opala’s APIs into their mobile solution(s) to deliver on-demand data to individual consumers/patients/clients. These individuals view Opala’s data from within the registered third-party application that they have downloaded onto their mobile device.

Opala does not currently have any application offerings.

The Final Rule

In 2020, the Centers for Medicare & Medicaid Services (CMS) published rules primarily designed to make healthcare information accessible, via an application programming interface (API), to individuals covered by a government healthcare program (e.g., Medicare Advantage). The CMS Interoperability and Patient Access final rule governs how these APIs are required to work.

HL7® FHIR®

The HL7® FHIR® (Fast Healthcare Interoperability Resources) specification defines how healthcare information can be exchanged between different computer systems regardless of how it is stored in those systems. It is designed to support providing healthcare in a wide variety of settings by enabling information exchange. FHIR is a standard for exchanging healthcare information electronically. The FHIR specification builds on and adapts widely used RESTful practices to enable integrated healthcare across a wide range of teams and organizations.

The intended scope of FHIR is broad: human and veterinary needs, public health, clinical care, clinical trials, and administration and financial aspects of healthcare. The standard is intended for use in a wide variety of architectures and scenarios.

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 Interoperability Solutions

Welcome to Opala’s Developer Documentation Set. From here, you can access documentation for Opala’s FHIR® APIs. Opala provides four seperate solutions you can use to access data.

• Patient Access API. This API enables access to members' health care data, including claims, explanations of benefit, coverage information, encounter information, and clinical information. This access is via third-party applications and requires member consent before access is granted (third-party apps cannot access member information unless the member gives explicit permission). The Patient Access API follows the SMART App Launch Framework , and utilizes OAuth 2.0 and the OpenID Connect Core 1.0 standard for securing connections.
• Payer-to-Payer Data Exchange. This feature enables a member to initiate the transfer of healthcare information from a previous payer to their current payer. The member enters their information on Opala’s white-labeled Health Data Transfer page, then logs into their account with the previous payer. Opala then initiates the transfer. For a payer's data to be available for members to transfer, the payer must be registered with Opala. If a payer is not registered, the member can request registration from this page.
• Member Attribution (ATR).This API enables access to Member Attribution Lists, which can be used by, among others, providers and payers to implement use cases for Value Based Contracts (VBC), Quality Reporting, Da Vinci Payer Data Exchange (PDex), and Da Vinci Clinical Data Exchange (CDex). Opala uses the Da Vinci FHIR ATR standard to exchange Member Attribution information.
• Provider Directory API. This API enables a search of provider directories. Opala’s Provider Directory API is publicly accessible and does not require any authorization to access. The API conforms to the HL7 FHIR Da Vinci PDex Plan Net IG .

Opala’s APIs are based on the HL7 Fast Healthcare Interoperability Resources (FHIR) standards and use the OAuth 2.0 / Open ID connect standard for member authentication and authorization.

SLA Summary for Opala’s APIs

The uptime Service Level Agreement for Opala’s production and test APIs is 99.9%, excluding scheduled downtime, measured monthly.

The average API call response time is no greater than five (5) seconds (i.e., no less than 50% of users should get a response time under five (5) seconds) measured daily, calculated and reported monthly to the customer, and also measured by the provider daily for its own information.

The average API end-to-end response time is no greater than five (5) seconds (i.e., no less than 90% of users should get an end-to-end response time under five (5) seconds) measured daily, calculated and reported monthly to the customer, and measured by the provider daily for its own information. API end-to-end response times measures shall exclude times from third-party systems other than those third-party services provided by the provider's subcontractors.

Terms and Conditions

Documentation Feedback

Opala welcomes your input about its documentation. If you have any thoughts, comments, or suggestions about any topic, you can email the Documentation Department at feedback@opala.com by clicking the link in the upper right of any page.