Skip to content
Isaac Vetter edited this page Mar 25, 2018 · 2 revisions

FHIRcast extends the SMART on FHIR launch protocol by synchronizing two healthcare applications following the initial launch.

FHIRcast defines an FHIR server, an authorization server, a session management server and one or more subscribing applications. Integration between the FHIR, authorization and session management server is outside the scope of the specification (because they will often be the same system).

Goals for FHIRcast:

Support multiple devices over http.

  • Applications on different devices are first-class citizens -- communication should happen over http naturally.

No CCOW-like context server.

  • Synchronized applications should communicate directly, without the need for a third-party context server.

One of the synchronized applications owns the user's session.

  • For simplicity's sake, one of the applications being synchronized must provide or integrate tightly with the authorization server, FHIR server and own the user's session by exposing it via a session management server. This application notifies subscribed applications of context changes. Subscribed applications request context changes of the session server.

Use what's already in production!

  • Application context synchronization is widespread is production health system environments. These production integrations are also rarely based on an interoperable standard. FHIRcast must build on top of real-world functionality; not divurge from it.

Re-use existing standards.

  • Re-use existing standards where possible. SMART's launch protocol and Oauth2 access_token are widely adopted. CDS Hooks and WebSub likely also have parts worth borrowing.