Quick Connect

Quick Connect allows for an effortless way to access 1upHealth APIs for each supported health system. App developers can use this white-labeled flow to help patients instantly connect to health systems — enabling an automated log-in process.

Currently the Quick Connect white label flow is applicable for Epic EHRs. Epic has now enabled us with the ability to create a private-labelled OAuth2 specifically for you and your application. Epic wants to be transparent with patients authorizing their data to 3rd party applications, while working with 1upHealth as one of their premier FHIR gateway partners.

What are the changes?

  • The patient will input their credentials directly in the Epic patient health system (picture in the blue), customized with your app’s name displayed instead of 1upHealth

  • The automated email the patient receives (picture in white), will also be updated to reflect your app’s name instead of 1upHealth

What does this mean for you?

  • We are offering customization to update your name in the patient authorized workflow:

  • Your company name will be substituted instead of the 1upHealth name for both the

    authorization screen and the patient email, see below.

  • This will now be an even more secure patient authorized workflow between the Epic EHRs and

    your application

  • We are offering this QuickConnect capability for $1,000 per month, per customized application

    name. If you are interested in QuickConnect, please email [email protected], and put

    QuickConnect in your subject line.

This Quick Connect white-label capability is not needed for other EHR’s, since they do not include the application name on their authorization screen or patient email.

Auto Refresh

Auto Refresh provides the ability for a patient to authorize their data to be shared with your application via 1upHealth on a recurring vs a one-time basis. With Auto Refresh activated, 1upHealth will login in nightly to the authorized patient’s health system, retrieve the data, and post any updates to you via FHIR Subscriptions. This is currently available for health records from Epic and claims data from CMS Blue Button. Per the ONC Final Rules for Health Systems and CMS Final Rules for Health Plans, we expect that this capability will be available for an increased number of patient endpoints, and will add once they are in production. If you are interested in QuickConnect, please email [email protected], and put QuickConnect in your subject line. We can answer any technical or commercial questions you might have.


Reach out to our engineering team at: [email protected]

Sign Up As A Developer To Use Quick Connect Now!

Check out our Quick Start Guide on how to access tokens.

You can then use your access token and health system_id in the url screen below to access the 1upHealth's Quick Connect page. After your patient has entered his/her credentials, the individual will be redirected back to your application's callback url.

  • Required parameters

    system_id = the numeric 1upHealth system id for the provider health system To obtain the System ID:


access_token = the user’s live and active 1upHealth access token for your client app

  • Optional parameters

    state = Any string to help you identify the state in your client application upon redirect back to your callback url

    bg = String hex value like ff00ff to indicate the background color you want to use for the quick connect page

Toggle the subscription for patient's health data update

Now 1upHealth users can toggle the health data subscription for a patient. Which means that they can unsubscribe updates on a patients health data. By default patient’s data subscription for a health system gets activated when he/she signs in to a health system which eventually refreshes their health data on a daily basis on our backend.

To deactivate that, users can post a subscription fhir resource to 1upHealth using variables oneup_userId, oneup_systemId , patient_username (username for that health system account ), and patient_name (if required) in criteria property also oneup_access_token in header under channel in the resource, and the value for status property should be off. Subsription resource is as follows:

If there are multiple patients profiles to choose within a patient account, criteria would be as follows:

let criteria = `systemId/{oneup_systemId}/userId/{one_userId}/username/{patient_username}/patientName/${patientName}`


let criteria = `systemId/{oneup_systemId}/userId/{one_userId}/username/{patient_username}`
let body = {
"resourceType": "Subscription",
"id": `${oneup_systemId}${one_userId}${patient_username}`,
"criteria": criteria,
"reason": "Toggle the health system connection",
"status": "off",
"channel": {
"type": "rest-hook",
"endpoint": "https://api.1up.health/fhir/dstu2",
"payload": "application/json",
"header": `Authorization: Bearer ${oneup_access_token}`

curl request to post subscription resource to 1upHealth :

curl -XPOST 'https://api.1up.health/fhir/dstu2/Subscription -H 'Authorization: Bearer {oneup_access_token} -H 'Content-Type: application/json' -d 'body'

Our system would check for this resources before the data refresh flow and if this status is off , then data for that user , patient and system wont be refreshed. This can be undone by posting the same resource by changing the value to active for status property.