# Info for third-party developers

## Overview

The [CMS Interoperability and Patient Access Rule (CMS-9115-F)](https://www.cms.gov/about-cms/obrhi/interoperability/policies-and-regulations/cms-interoperability-and-patient-access-final-rule-cms-9115-f) provides patients, and authorized third party apps, with access to their health information.

1upHealth provides a common RESTful API that fully supports FHIR® and provides rich, programmatic access to electronic medical record data for patients, and for the companies and institutions who serve them. The available data includes patient demographics, labs, medications, observations, procedures, allergies, and much more.

## Requirements

Your application must support [FHIR Release 4 (R4 version 4.0.1)](http://hl7.org/fhir/R4/index.html). You must also demonstrate support for FHIR R4 and provide details about your application (logo, description, links, etc.) before it can be made available to members of the supported health plans.

For guidance on the legal requirements for app developers, see [FTC guidelines](https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool).

## Authentication

See the Patient Access section of [Client credentials and OAuth 2.0](/docs/get-started/o-auth) for information about creating an account in the 1up Developer Console for client credentials and requesting a `Bearer` token.

## Test your application in a sandbox

You must use the 1upHealth Demo Health Plan sandbox to test your application before you can connect to production data.

Prerequisite
Ensure that 1upHealth has already synced your application to the sandbox environment.

## Request access to production data

You must email `cms-prod-access@1up.health` with the following information and attachments:

* Completed [Privacy & Security Attestation Questionnaire](/assets/privacy--security-attestation-questionnaire.d75fe8150292bbe882cbe6e04ff7bfb17f75347b408c430ad19349ce0714308e.8f84bdd7.pdf).
* Screen recording of your application connecting to the Demo Health Plan environment and displaying synthetic patient data in your application's UI.
* Your application Terms Of Service (link or attachment).
* Your application Privacy Policy (link or attachment).
* A square logo for your application (link or attachment).
* A user-facing support email address.
* A point of contact for security-related questions (not user-facing).
* A brief description of your application including the purpose, benefits, and personas your application serves (e.g. members, health plan admins).
* Are your customers direct consumers or intermediary, third-party organizations? If they're direct consumers, what is the cost of the application for consumers?
* Do you have a test instance of your application available for demonstration purposes?
* Can we share your answers to our Security and Privacy Attestation questions if a customer asks?
* Can we share your contact information with our clients? If so, which contact information is best to share?
* Do you want to integrate with a specific 1up Payer customer or all 1up Payer customers (60+ Health Plans)? If only a specific customer, which customer?


After 1upHealth's review is complete and your production access request is accepted, your API keys and redirects URIs are synced with our CMS Health Plan customer environments.

## User creation

1upHealth requires that applications create a new `user` for each member that wants to share their data. Applications create a new user with the following request.

## Query FHIR resources

You can query FHIR resources for specific members once you have a `Bearer` token and created a `user` for them. Supported FHIR resources may vary depending on the payer. Some payers support only resources related to claims and coverage while others also support clinical resources.

At a minimum, all payers support the following resources:

* ExplanationOfBenefit
* Coverage
* Organization
* Patient
* Practitioner
* Location


## Supported scopes

1upHealth supports the following scopes for Patient Access:

* `patient/*.read`: Read-only permission to all of the available FHIR resources for the authenticated member.
* `user/*.read`: Read-only permission to resources for the specified user.
* `launch/patient`: Permission to request patient context when launching outside of an EHR.
* `openid`: Permission to request information about the current logged-in user.