On this page:

10.2LiveBundle Rule Definition


A LiveBundle rule is configured using JavaScript. Below is an example of a LiveBundle configuration. LiveBundle searches the JavaScript for a function named buildLiveBundleRuleSet(). This function is expected to return a LiveBundleRuleSet object. A LiveBundleRuleSet contains a list of Watchlists and Rules.

10.2.1Loading Rules


When a LiveBundle enabled FHIR Storage module is started, the module will compile the LiveBundle JavaScript and execute the buildLiveBundleRuleSet() function. This will load Watchlists and Rules into Smile CDR so that Subscribers can be added to Watchlists and data collected for those Subscribers.

Changing the definition of a rule after it has been loaded will not change any bundles that had been previously stored for that rule. If you need to rebuild LiveBundles after changing a rule, you will need to unsubscribe and resubscribe all members of that rule's watchlist. This will rebuild all bundles for all rules that use that Watchlist.

10.2.2Example LiveBundle Javascript


Let's start with a fully functional buildLiveBundleRuleSet() method that defines an aggregation rule that keeps the the most recent visit details for patients of a Diabetes Ward.

const EXAMPLE_SYSTEM = 'http://myorg.org/diabetes_management';

function buildLiveBundleRuleSet() {

	let ruleSet = LiveBundleRuleSet.create();

	// Add Watchlists

	ruleSet.addWatchlist(LiveBundleWatchlist.create(EXAMPLE_SYSTEM, 'PATIENT_WATCHLIST', 'Patient'));

	// Add Rules


	return ruleSet;

function lastVisitRule() {
	return LiveBundleRule.create()

function lastVisitFilter() {
	return LiveBundleFilter.create()

function lastVisitKeeper() {
	// This is the path we use to determine which resource is the most recent one
	let pathToOrderDate = 'period.start';

	return LiveBundleKeeperFactory.newLatestByPath(pathToOrderDate);

10.2.3LiveBundle Watchlist


A LiveBundle watchlist holds subscribers of a certain type. It is created as follows:

LiveBundleWatchlist.create(system, name, subscriberType)
systemStringSystem identifier for the Watchlist. Used to manage subscribers and assigned to Filters.
nameStringName identifier for the Watchlist. Used to manage subscribers and assigned to Filters.
subscriberTypeStringthe type of resource references that are stored on this watchlist

10.2.4LiveBundle Rule


A LiveBundle rule defines aggregation rules. It is created as follows:

		.setRuleToken(system, name);
filterLiveBundleFilterThe LiveBundle Filter
keeperLiveBundleKeeperThe LiveBundle Keeper
seedCountIntegerWhen a subscriber is added, how many root resources to seed the bundle with
systemStringSystem identifier used to request LiveBundles for this rule
nameStringName identifier used to request LiveBundles for this rule

10.2.5LiveBundle Filter


A LiveBundle filter chooses which incoming Root References are sent to the Keeper for aggregation.

		.setWatchlistToken(system, name); 
rootResourceTypeStringThe type of resource this filter watches for
criteriaStringThe criteria used to match incoming resources. These must be search criteria that can be evaluated in-memory
pathToSubscriberStringThe path used to find the subscriber reference in the root resource
systemStringSystem identifier of the Watchlist used by this rule
nameStringName identifier of the Watchlist used by this rule

10.2.6Keeper Filters


Some Keepers require a Filter as one of their parameters. Keeper Filters are allowed to have any legal fhir search criteria (not just those that can be evaluated in-memory). However, to allow a Filter to call the database for it's criteria evaluation you must call keeperFilter.setDatabaseSearchAllowed(true) on that keeper filter. LiveBundle will throw an error if DatabaseSearchAllowed is set to true on a Rule Filter. This is only allowed on Keeper Filter for performance reasons.

10.2.7LiveBundle Keeper


The Keeper assigned to a LiveBundle rule decides which references to keep. See LiveBundle Keepers for details.