Skip to content

Instantly share code, notes, and snippets.

@jmandel

jmandel/sketch.md

Last active August 29, 2015 14:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jmandel/4315b5d17fc5ca5d7689 to your computer and use it in GitHub Desktop.
Save jmandel/4315b5d17fc5ca5d7689 to your computer and use it in GitHub Desktop.
Download ZIP
SMART Support for HAPI?
Raw
sketch.md

Here are a few components that could help. This is just a sketch -- looking to refine (or completely replace) these ideas with a more concrete proposal...

Authorization Server

A common set of components that allow end-users to authorize access to clinical data. Handles fundamental aspects of client registration, authorization flows, and token generation. Currently SMART and HSPC (and also Duke) have independently modified versions of MITREid Connect, but they all rely on different, non-compatible customizations. We'd want to build modular support for:

  • User sign-in. Should be able to tie into existing user account services -- e.g. via LDAP or any other back-end protocol. Bottom line: OpenMRS should be able to configure an instance of this server so users can sign in with their existing OpenMRS credentials (and ditto for SMART sandbox users, or HSPC sandbox users, etc).

  • App launch context communication. The SMART launch protocol allows the EHR to establish a "launch context" which flows through the authorization service. The Authorization server needs to be aware of this context to complete the flow. We'd want standard hooks in place for the Authorization sever to get this context from the EHR.

  • App launch context gathering. The SMART launch protocol also allows apps to launch in a "standalone" fashion (where no EHR session was active prior to launch). In this case the app can ask the authorization server to "gather context" (such as a patient ID or encounter ID) as part of the launch flow. Again, we'd want standard hooks to support this context-gathering process.

HAPI modules for FHIR server implementers

We'd want some tools to help HAPI users implement support for SMART's authorization specs. Key aspects would be:

  • a modular server-side interceptor to accept bearer tokens, inspect them, and annotate any given http request with a set of applicable scopes/permissions. That way, any HAPI server could use these scopes/permissions to inform database queries. For example, a search operation might be modified with a restriction where resource_id in (select resource_id from permissions where user_id="123".

  • API hooks to handle launch context communications (see above).

Example HAPI + SMART Server

To tie this together and test out our assumptions, we'd also want an example project providing a single relational-database-backed FHIR server that uses the components above to provide SMART on FHIR support. This server could even directly provide the basis for SMART and HSPC's public sandboxes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment