Menu
Today I led the Payer Data Exchange Track at the HL7 Patient Access API event. The event was a combined Education and Implementation-a-Thon event. The Payer Data Exchange (PDex) Track generated numerous questions from Payers and Technology Vendors that related to Patient/Member access and authorization. Presenting information for members through APIs is generally something new for many Payers. The CMS Interoperability and Patient Access Rule that was released on March 9,2020 now requires regulated payers to provide a Patient Access API. HL7 has risen to the challenge and has been developing implementation Guides to help payers meet the requirements of the CMS mandate. The purpose of the Patient Access API Event was to inform payers how these Guides would help them meet the mandate.
Since the PDex track generated so many questions about access and consent I have put together this post to provide some, hopefully, clarifying guidance.
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:
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.
There has been no guidance given on the duration that consent applies for. Many payers are considering options and are settling on the idea of a one year period. This fits both the typical length of time that a health plan is active for and also fits with other reminder services such as the annual privacy notice. It would be an easy modification to add the list of approved apps a member is sharing to a privacy policy review.
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.
