-
Notifications
You must be signed in to change notification settings - Fork 22
Are you the Hub? Am I the Hub? Common Implementation Patterns of FHIRcast
A FHIRcast Hub takes responsibility for a few complex features:
- a FHIR server
- a SMART/OAuth2 server
- a FHIRcast session Hub
A FHIRcast subscriber must support a handful of HTTP or websocket interactions:
- (recommended) A SMART app launch
- Subscription request
- Receive event notification
- (optionally) request context changes
As part of any context synchronization integration using FHIRcast, there is a single Hub and one to many subscribing apps. Towards the goal of quick, cheap, and fast implementations, integrating applications should know the technical role they're playing before talking to a specific health system.
If the developer of an application doesn't know if they're a subscriber or the Hub before talking to a health system about a specific integration; we've failed.
Generally, yes. Per regulation and current production functionality; the EHR is most capable of serving as the Hub. It likely already has a SMART on FHIR (OAuth2) server and a FHIR resource server. While the EHR may or may not be the "driving application" in an application, you should assume that it will provide the Hub in a FHIRcast integration.
FHIRcast defines a the hub.url as a simple, internet accessible base url which a subscriber contacts to create/delete a subscription and to initiate context changes. In practice the Hub may be accessible publically (over the internet), within the intranet or only on the local machine.
A FHIRcast hub.url available on the public internet may be rare due to the lack of defense in depth security precautions, even with full OAuth2 support. You should be prepared to negotiate with the implementing health system or provide a proxy agent within the intranet or installed on individual machines.
A hub.url, if not limited to the local machine, will most likely only be accessible within a health system's intranet. Your client and, if using rest-hooks, your web server will necessarily need to reside within the health system's network -- either directly or via a VPN.
A local hub is limited to only synchronizing applications running on the same machine; however, this architectural pattern also prioritizes scalability, security and tightly targets replacing current state for proprietary desktop integrations.
If you're developing a FHIRcast client, you should consider supporting client-side http requests and websocket initiation.