Authored by: Charlie Provenzano
There has been much discussion in various FHIR-related online forums and presentations about the need for various member portal features. Some participants have gone as far as saying, “do not develop a member portal”. Others have expanded their use of existing member portals, all to meet the same set of requirements. What is needed to enable a Patient Access API, and what is recommended both now and in the longer term?
The CMS mandate is that payers must provide a Patient API and it must be available “without special effort”, meaning it must be reasonably easy to use. Logically that requires that a user be able to access the data described in that API. If you build an API but don’t build a means for your members to access that API, you have not met the requirements of the rule. I hope that is an obvious statement. The sentence, “don’t build a member portal” is most often intended to say, “don’t create your own system for member authentication” and that is a very reasonable (but not obvious) statement.
In order to make your API reasonably usable, there is a small list of basic functions you will need to provide for your members:
The ability to create an account/credentials to use with third-party apps
A self-service registration process with a set of common validation fields
Self-service ability to retrieve the username and reset password
Ability to attest as parent/guardian and utilize on behalf of a minor
Ability to allow access for specific third parties to the member’s data
In the above list, the account and credentialing requirements can be accomplished using a third party. This has the potential to save both development time and administrative time as the assigning and resetting of passwords is delegated out. If you choose to go the third-party route, your users will have the option of logging in with one of your chosen ID providers for operations on your portal or your API, much like some shopping sites now let users “sign in with Facebook” or “sign in with Google.” (There are several solutions on the market, but Change Healthcare and ID.me are two that leap to mind.)
If you’ve delegated the credentialing process, you still need to have a way to deal with associating member IDs (parent/guardian or other) and allowing third-party access to a member’s data. You might choose to handle these two aspects via a phone-based helpline. If that’s the case, you may not need any other member portal functionality. If not, you will want your members to be able to at least request these changes through your portal. Whether you allow automatic verification or some other means of verification is up to you. What’s important is that any set of user credentials that accesses your API has the correct user scopes associated so that the data is returned for the appropriate member records and no others. Reference: SMART App Launch Scopes.
If you already have a full-featured member portal, then you already have a means of member identification and authentication. It’s perfectly reasonable (and probably most efficient) to just re-use those systems for your API access. The same goes for associating member ID with user IDs. The one wrinkle that is new for the Patient Access API is the need to allow users to grant access to their data to third-party applications. There are many publicly available guidelines around this and many ways to accomplish it. For example, https://myhealthapplication.com/. You might choose to allow your members to select specific apps that have already registered with your API via a simple pick list or other portal UI. You may also choose to handle this consent via a phone-based helpline, but clearly an online form will be more efficient over time.
In an ideal roll-out of this feature for consumers, there would be a fully functional ecosystem that allows for federated identification of individuals and linkage to their data regardless of where they have their insurance. Groups like the CARIN Alliance are working towards the goal to create a seamless consumer experience. Until then, companies will need to consider what they currently have and how they can support their members in accessing this data.