Production API Access

In order to gain production access, an organization should start by reviewing the production access user guide and checklist. Once an organization believes it is fulfilling all the requirements detailed in the checklist and has successfully tested API Connectivity in Sandbox, they should review and complete the ‘App Developer Patient Access API Attestation’ form and email interoperabilitysupp@blueshieldca.com.

Steps to get started:

• Create an account on Blue Shield Developer Portal
• Register/Test APIs in Sandbox Environment
• Review Production checklist
• Review Production access user guide
• Download the "App Developer Patient Access API Attestation" form
• Blue Shield of California may require a demo of your application

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.

General Information/Questions

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 your 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.

Required Resources

We ask that organizations applying for production access have the following documents publicly available for users to see and read:

• Privacy Policy
• Terms of Service

We’ll walk through each of these specific documents, but in general, it is vital that these documents are easy to read and understand. We understand that these are legal documents, and language can get complicated, but we ask that you keep your ultimate audience in mind when reviewing your privacy policy and terms of service. Medicare beneficiaries, like all people, need to know that they will be protected and want to know definitively how their data will be used. When you apply for production access, please verify the reading level of these documents to ensure that you made them as clear and readable as possible.

In cases where it may be difficult to write or update your privacy policy to be more readable, you could create a separate publicly hosted document we refer to as a Privacy Notice. A privacy notice is simply an accurate summary of the terms in your privacy policy that could be hosted and displayed prominently together.

What We Expect from Your Privacy Policy

In general, we are looking for your privacy policy to clearly demonstrate to Medicare beneficiaries how you use, store, and potentially share their healthcare data. When you are applying for production access, you will need to attest if your privacy policy covers all of the requirements listed in the terms, so be sure you have read it and checked your privacy policy against those requirements.

Here are other topics/items we’ll need to see indicated in your privacy policy:

This gives you an idea of what we are looking for in a privacy policy: that Medicare beneficiaries are prioritized, protected, and informed. Be sure to refer to our terms of service for all requirements.

• Does your privacy policy detail if and how data is shared? What data is shared? Is data “anonymized” or “de-identified” before it is shared? Are you communicating that clearly to users in terms they will understand?
• 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?
  • Note: We understand that when your company is being purchased, you may have very little power over these decisions. The responsibility of informing users about material changes to the way their data is used belongs to the acquiring company. We would, however, like to see some indication of this in your privacy policy to ensure that the burden is not on the beneficiary find that out on their own.
• 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 happens if you suffer a security or data breach? How will you notify your users? Will you inform them of steps they can take to protect their data, if possible? Is this information clearly stated in your privacy policy?

What We Expect from Your Terms of Service

While the privacy policy should be designed to protect and inform your users, your terms of service is likely designed to protect your organization from a legal perspective. The main thing that we want to see with your terms of service is that it in no way contradicts, negates, or detracts from the protections detailed in your privacy policy.

Keeping the Beneficiary Informed About Privacy

We put a lot of emphasis on your privacy policy and terms of use because they help ensure that beneficiaries (and their data) stay protected. But we also know that privacy policies are not enough on their own. The simple fact is that many users will click through and authorize access to their medical information without reading the complete privacy policy and terms of service. For this reason, it is essential that you try to deliver information and context to Medicare beneficiaries in the application itself.

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.

We like to think of it like this: “A Medicare beneficiary should never be surprised to learn how their data is being used.” Create your application with that in mind. Are you taking the content of the privacy policy and presenting it to users in the application itself? Are you letting them know when their data is being shared? Are you giving them information and choice?

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 a service or revoke a 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:

• Does your user interface present the terms of service and privacy policy in a way that is clearly accessible for the user? How?
• Does the UI of your app allow the beneficiary to actively opt-in to the terms of service and privacy policy, instead of defaulting to agreement?

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?