Challenges using SMART on FHIR for Multi-Vendor Authorization

Challenge by Nick Youngson CC BY-SA 3.0

One of the challenges for application developers in implementing SMART on FHIR is that of metadata endpoint discovery.  In order to initiate the SMART on FHIR authorization flow, the application developer needs to know the metadata or Conformance endpoint for the FHIR Server it is going to communicate with.  However, this endpoint is going to vary based on the vendor supplying the FHIR Server, the version of FHIR that is supported, and possibly even the healthcare organization deploying it.

The problem here is in the use of metadata as a way to discover the authorization endpoint, when in fact, the challenge for application vendors is configuring to support multiple endpoints with the same application.  If you use MyChart or other apps to access your health records (as I do), you can see how this plays out when you go to login as a patient.  The first step of your login process has you identify your state and healthcare practice (this shows up in other applications as well).  I'm certain that somewhere in that application and others like it, that selection process is doing something to resolve the practice specific endpoint details.

In a single vendor environment, it's pretty easy to address this, but when developing an application to support multiple environments, this can be quite challenging for the application developer.

NO, this isn't a claim that we need a global SMART on FHIR endpoint directory (although that is one way to resolve this issue).  It's more a statement that we've combined the process of conformance inspection with the problem of endpoint discovery.

Think about it: If your authorization endpoints are different, it is also likely that FHIR conformance associated with those endpoints could be different.  Why should they both use the same mechanism.

This creates a challenge for patients, because it means that App developers are likely unable to support as broad a variety of endpoints as they'd like simply due to the configuration challenges presented to them.

Smart SMART developers will obviously work around this.  One possibility is to modify the Launch sequence so that the application first asks the patient where their practice is located through some sort of internally managed directory, so that the application first selects the practice, and then the directory resolves the authorization endpoints AND the actual FHIR conformance endpoint the application can use to customize its operations based one what capabilities are available.

This would allow patient facing SMART applications to support multiple versions of FHIR from multiple provider organizations.

There are a lot of other challenges.  Like anyone else, you have to get your product into the vendor's App store, and there's a lot more vendors than one has to typically deal with for smart phone applications (two covers a lot of territory here, whereas you need 5 or 6 for EHRs to get the same coverage).  And of course, you also have to get your app into the smart phone stores too.  Those aren't problems I'm going to try to solve here.

   Keith