On this page:

6.1LiveBundle API

 

Once LiveBundle rules have been configured and enabled on a FHIR Storage module, all FHIR Endpoints attached to that module will accept LiveBundle Operations.

6.1.1Add a Subscriber to a Watchlist

 
This method requires the FHIR_LIVEBUNDLE permission.

Each Watchlist has a set of resource ids for which Smile CDR stores LiveBundles. The type of these resource ids is the subscriberType of that Watchlist. A subscriber id is added to a watchlist using the $livebundle-watchlist-add operation on the Composition resource.

For example, to add Patient/123 to http://myorg.org/diabetes_management|PATIENT_WATCHLIST, call:

POST [base]/Composition/$livebundle-watchlist-add
Content-Type: application/fhir+json

{
  "resourceType": "Parameters",
  "parameter": [
		{
      "name": "watchlist",
      "valueCoding": {
          "system": "http://myorg.org/diabetes_management",
          "code": "PATIENT_WATCHLIST"
      }
		}, {
      "name": "subscriber",
      "valueString": "Patient/123"
      }
  ]
}

Optionally, when adding a subscriber to a watchlist, you can provide a subscriberGroup. If you do this, in addition to being added to the watchlist, the subscriber will also be added to that subscriberGroup. A subscriberGroup can be used in place of a list of trackingIds when requesting a liveBundle. Subscribing to a watchlist is independent from adding a subscriber to a subscriberGroup; they are performed in the same operation for convenience. To add a patient to more than one subscriberGroup, call the same $livebundle-watchlist-add operation again with the same watchlist and a different subscriberGroup.

Here is what a request looks like that includes a subscriberGroup:

POST [base]/Composition/$livebundle-watchlist-add
Content-Type: application/fhir+json

{
  "resourceType": "Parameters",
  "parameter": [
		{
      "name": "watchlist",
      "valueCoding": {
          "system": "http://myorg.org/diabetes_management",
          "code": "PATIENT_WATCHLIST"
      }
		}, {
      "name": "subscriber",
      "valueString": "Patient/123"
      }
		}, {
      "name": "subscriberGroup",
      "valueString": "New mothers"
      }
  ]
}

A common example for a subscriberGroup is to set the subscriberGroup to an organization id so that bundle data can be pulled for all subscribers from that organization at once.

6.1.2Remove Subscriber from a Watchlist

 
This method requires the FHIR_LIVEBUNDLE permission.

A Subscriber is removed from the watchlist using the $livebundle-watchlist-delete operation on the Composition resource:

POST [base]/Composition/$livebundle-watchlist-delete
Content-Type: application/fhir+json

{
  "resourceType": "Parameters",
  "parameter": [
	{
      "name": "watchlist",
      "valueCoding": {
          "system": "http://myorg.org/diabetes_management",
          "code": "PATIENT_WATCHLIST"
      }
	}, {
      "name": "subscriber",
      "valueString": "Patient/123"
    }
  ]
}

If the subscriber was a part of any subscriberGroups, then when the subscriber is removed from the last watchist it was a part of, it will be removed from all of its subscriberGroups.

6.1.3View list of Subscibers to a Watchlist

 
This method requires the FHIR_LIVEBUNDLE permission.

To obtain a list of Subscribers to a Watchlist, use the $livebundle-watchlist command:

GET [base]/Composition/$livebundle-watchlist?watchlist=http://myorg.org/diabetes_management|PATIENT_WATCHLIST

This will return a List resource with references to the Subscribers to that Watchlist.

Alternatively, you can request by subscriberGroup as follows:

GET [base]/Composition/$livebundle-watchlist?subscriberGroup=New+mothers

This will return a List resource with references to the Subscribers in that subscriberGroup.

6.1.4Request a bundle of Subscribers to a watchlist

 

The $livebundle-watchlist-subscribers operation takes the same parameters as $livebundle-watchlist but instead of returning a List object, it returns a bundle that includes the List object followed by each subscriber resource. E.g. If a watchlist had two Patient subscribers, this bundle would return three resources: a List referencing these two patients followed by two Patient resources.

6.1.5Reseed all bundles for a rule

 

The $livebundle-reseed operation removes all bundles for the named rule and reseeds the bundles for that rule for all subscribers on that rule's watchlist. This is often required after a rule definition has changed.

GET [base]/Composition/$livebundle-reseed?rule=http://myorg.org/diabetes_management

6.1.6Request a LiveBundle

 
This method requires the FHIR_LIVEBUNDLE permission.

Once subscribers have been added to a Watchlist, the server will begin aggregating data for all rules that use that Watchlist. Request the aggregated data for a TrackingId (usually the SubscriberId) and a Rule by calling the $livebundle operation on the Composition resource.

GET [base]/Composition/$livebundle?rule=http://myorg.org/diabetes_management|LAST_VISIT&trackingId=Patient/123

Multiple trackingIds can be requested. In this case, a separate composition will be returned for each tracking id followed by the resources referred to in those compositions.

GET [base]/Composition/$livebundle?rule=http://myorg.org/diabetes_management|LAST_VISIT&trackingId=Patient/123,Patient/456

You request a LiveBundle for all subscribers in a subscriberGroup as follows:

GET [base]/Composition/$livebundle?rule=http://myorg.org/diabetes_management|LAST_VISIT&subscriberGroup=New+mothers

The $livebundle operation returns a Bundle of that rule’s aggregated resources for all trackingId requested. The first entries in the bundle are Compositions for each trackingId that references resources for that trackingId. These Composition resources are then followed by the union of all the references in the Compositions.

The _include and _include:recurse parameters are supported on this operation. E.g. if the LAST_VISIT rule stored Encounter resources, you could also include the associated Condition resources by calling:

GET [base]/Composition/$livebundle?rule=http://myorg.org/diabetes_management|LAST_VISIT&trackingId=Patient/123&_include=Encounter:condition

Two sort parameters are supported for livebundle: _sort=date which sorts results by date from earliest to latest and _sort=-date sorts results from latest to earliest by date. Root resources are sorted based on the keeper pathToOrderDate. Other resources stored in the LiveBundle or added with _include follow the root resources they are associated with.