The first step in the process is for the third-party app to register with the payer and be approved to receive application credentials. The app uses these credentials to interact with the payer’s Patient Access API. However, it gives the app NO access to any member data. When a member uses the approved third-party app they can choose to connect to the payer.
When the app connects to the payer’s API the first step is to understand which member is making the access request. The API will typically forward the request from an approved app to the Member Identity Provider service. This is typically the service that enables a member to login to a member portal. If the member successfully authenticates with the Identity Provider the app is handed back to the API with information about the member. Unless the member has already pre-authorized the sharing of their data with the app, the API then presents an Authorization request to the user.
If the member authorizes (Consents) to share data with the app an access token is handed back to the app. This process is based on the OAuth2.0 protocol and the resulting access token is provided without revealing the user credentials to the app. Throughout the process the payer, as data holder, is in control of the authorization process. The process happens in the API and is completely opaque to the app. All the app will know is whether they received an access token, or not.
After the app is authorized and has an access token the app can make calls to the API using the app credentials and the member access token. This has two important benefits for the payer data holder:
- If the payer detects that an app is a bad actor they can revoke the app credentials. This prevents the app from making any further calls to retrieve data for any member form the API
- If a member decides they want to revoke the access for an app, they can go to an “application dashboard” provided by the payer, identify the app in question and issue a revocation request to the API. This revocation request removes the member access token for the individual app. The app can still retrieve data for other members that have given permission but retrieving data for the member who revoked their permission will fail.
Members of the Onyx team were responsible for designing this authorization/consent flow for the CMS Blue Button 2.0 API. This process was reviewed by the CMS Office of General Counsel and the US Department of Health and Human Services Office of Civil Rights.
By following this same flow to obtain member consent a payer is matching the process adopted by CMS.
The CMS Rule lands on the side of granting access. There are provisions that allow a payer to reject or revoke access for an application. These are primarily on system security grounds.
Since HIPAA provides consumers with a right to access their data a payer generally has to provide the access. If a payer applies acceptance requirements to enable access these must be applied consistently for all requests for access. If the acceptance requirements are too strict the payer can find themselves open to fines as a result of being judged to be an “information blocker.”
There are emerging Trust Frameworks. The CARIN Alliance has a code of conduct for consumer applications. Payers can recommend that third party apps attest to the code of conduct. However, they can’t demand adoption but many consumer health applications are open to attesting compliance. Violation of the attestation is serious because it opens up an app to investigation and penalties from the Federal Trade Commission (FTC).
While a payer is still expected to provide access to an app without it meeting their acceptance requirements the payer can ask the member to confirm that they want to use the app.
This scenario is the “friction-full” scenario. If an app doesn’t provide basic safeguards but insists on being accepted into the API, the payer can provide a warning to the member as part of the authorization process. This could be a warning graphic but it could also be a series of additional questions posed to the member to confirm that they are aware of the risks and are certain they want to proceed.
Why is this a good approach? Developers hate friction. Any extra step that a potential user has to go through reduces the likelihood of completing a sign -up. Developers, therefore like to take steps to reduce friction. If attesting to qualifiers, such as attesting to a code of conduct, help to reduce the steps a member goes through to share data then serious developers are likely to take steps to open up the easy path. At the same time this approach still leaves the door open to innovators to experiment and determined users can still connect the apps that they want to their data.
Hopefully this post has helped to clear up some of the confusion surrounding granting consent to apps to gain access to member data. There are many other aspects to be considered, including industry developments that aim to increase the confidence around authorizing apps with less effort.
If you would like to see this authorization and consent process in action you can reach out to us at OnyxHealth.io and we can demonstrate what is possible with SAFHIR.