Understanding the Blue Button 2.0 API Mission
We’re pleased that you’re considering applying for production access to the CMS Blue Button 2.0 API. There is a broad and growing community of third-party companies, organizations, and developers building exciting applications that empower Medicare beneficiaries with their personal health information. Our mission is to provide a developer-friendly, standards-based API that enables developers to create these amazing resources for our beneficiaries.
Another core element of our mission is making sure that Medicare beneficiaries (and their data) are protected. Our production access process and terms of service are designed to ensure that the beneficiary feels secure and that they are given the information to make informed decisions when using the Blue Button 2.0 API to share their healthcare data with third-party applications. Before you apply for production access, it is vital that you have read and understand the Blue Button 2.0 API terms of service.
This guide will help make sure you understand the requirements outlined in our terms of service, but you should always treat the terms of service as our official policy.
Our Requirements for Production Access
Before you apply for production access, it might be helpful for you to better understand our requirements and why they are important. Every part of this process comes from our mission to make sure Medicare beneficiaries are informed and protected. So - let’s dive in!
We’ll need to know some basic information about your organization and your application. To continue delivering the best service possible to developers, it helps us to have information including (but not limited to):
- Details on your plan for timeline/release of your application
- The number of Medicare beneficiaries you plan to provide services to
- How you will market you application to Medicare beneficiaries
- Contact information for your team
Some of this information is useful to ensure an efficient roll-out of your application, but we also like to make sure that organizations are carefully marketing to Medicare beneficiaries.
We require that organizations applying for production access have the following documents publicly available for users to see and read:
- Terms of Service
- Give the users the full picture: if they revoke access to their data, do you continue to store their data or do you delete it?
- What happens if your company is sold and the use of user’s data could change in a material way? Are beneficiaries and CMS notified?
- If your application works with third-party vendors, do your third-party vendors commit to data protection requirements that are consistent with the law and your expectations based on the sensitivity of the personal information they will receive from you or collect on your behalf?
What We Expect From Your Terms of Service
Keeping the Beneficiary Informed About Privacy
For example, If a beneficiary’s data is about to be shared, you could use a message, modal, or the general UI to clearly and concisely convey what is about to happen, why it is about to happen, and give the beneficiary the ability to choose to move forward or not. Short contextual messages like this are also far easier for users to digest and understand. Additionally, giving the user the ability to take action on the information ensures they have complete and thoughtful control over their healthcare data.
User Interface and Security Practices
It is important that we understand how a Medicare beneficiary will actually interact with your application. Since Medicare beneficiaries are sharing incredibly sensitive information, we want to make sure that they are given opportunities to opt-in to service or revoke service, request that their data be deleted, etc. Please be sure to refer to the Production Access Checklist for a full list of requirements.
Here are some examples of the kinds of questions we’d like to see you answer:
And similarly from the security perspective:
- Are you using industry best-practices to store and retain healthcare information?
- How will you protect this identifiable health information?
What does this process look like?
1. Review the Production Access Checklist
After you’ve read the Blue Button 2.0 API Terms of Service, take a moment to look over our Production Access Checklist. Going over this document will help ensure that your application is ready for approval.
2. Email Our Team
Once you feel like you are ready for approval, you can send an email to BlueButtonAPI@cms.hhs.gov. Once we receive your email, we’ll schedule a brief demonstration of your application to the BB2.0 API team to introduce ourselves and better understand a beneficiary’s user journey using your application.
3. Application Demo
The demo meeting is an opportunity for you to showcase your application to the Blue Button 2.0 Team. We need to see a predominately completed view of the journey beneficiaries take using your application. What does account creation look like? How do they initiate the OAuth flow? How do you display their data after they’ve shared it? How is their data used? If there is a feature within the app that allows the user to share their data with others (i.e., a provider), show how that is executed.
4. Final Steps
After the in-person demo, if necessary, we will follow up with your team to address any final concerns before issuing production credentials.Back to top