201709 FHIR Subscriptions

Sub category of FHIR Connectathon Track Proposals for the current connectathon: Sept 2017 Connectathon 16

FHIR Subscriptions

Submitting WG/Project/Implementer Group

FHIR-I

Justification

The current FHIR Subscriptions spec is based around the idea that a clinical system uses FHIR resources as its native database format and executes subscribed FHIR queries against every resource as it's created or modified. This would work well for custom built middleware and FHIR reference implementations, but generally not for systems that implement clinical workflow.

Many clinical systems are event-based. An implementable subscription criteria would rather be based on an event and then narrowed to specific attributes/criteria.

The subscription pub/sub pattern enables FHIR clients to retrieve data from a server without performing a more expensive periodic polling queries. This model potentially also enables workflow event-based notifications that could keep two applications data in sync, but also synchronize their context. There's some interest within the RIS/PACS community to identify a common, lightweight application synchronization standard.

This track will attempt to prototype this event-based concept on top of the existing FHIR Subscription REST hook and criteria element. Further, as a stretch goal, this connectathon will attempt to prototype this workflow synchronization using FHIR Subscriptions.

Proposed Track Lead

Isaac Vetter

Expected participants

• Brian Postlethwaite
• Alexander Henket
• Christiaan Knaap
• Grahame Grieve
• Will Maethner
• Niklas Svenzén
• Bill Harty

Roles

FHIR Subscriptions server

The FHIR Server supports the Subscription resource and pushing relevant FHIR resources to client.

FHIR Subscribing client

Subscribes to FHIR server and gets updates.

Scenarios

Create FHIR Subscription

Action: Support Subscription resource writes using the topic extension, as illustrated, below.

Precondition: n/a

Success Criteria: Client POSTs new subscription resource to FHIR server. FHIR server persists active subscription resource.

Bonus Point: FHIR server support searching and reading Subscription resources.

REST Hook with payload of "payload": "application/fhir+json"

Action: Support pushing FHIR resources.

Precondition: n/a

Success Criteria: FHIR server pushes FHIR payload of relevant resource using REST Hook when the subscribed event occurs in the FHIR server.

Bonus point: n/a

Subscribe to a REST Hook of "patientchartopen"

Action: Subscribing app creates Subscription with an extended topic that means that a patient chart was opened in the EHR FHIR server in a specific Location. FHIR Server notifies app of the patient chart that was opened.

Precondition: Subscription resource support.

Success Criteria: Subscribing app is notified of the event.

Bonus point: FHIR server has a prototyped EventDefinition resource that defines a patient chart being opened.

Example subscription resource with proposed extension

{
  "resourceType": "Subscription",
  "criteria": "Patient/123",
  "extension": {[
	"url": "http://hl7.org/fhir/subscription/topics",
	"valueReference": {
		"reference": "https://example.com/EventDefinition/123",
		"display": "patient admitted",
	}
     ]
  }
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://biliwatch.com/customers/mount-auburn-miu/on-result",
    "payload": "application/fhir+json"
  }
}