This page is part of the Da Vinci Health Record Exchange (v1.0.0: STU1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Task-based queries

Page standards status: Informative

Da Vinci makes use of the Task mechanism to asyncronously solicit information from a target system in few implementation guides. This implementation guide defines a specific profile for use in HRex-based IGs that use this information.

The following are examples of Tasks, showing different phases of the workflow for a Task soliciting execution of a specific query.

• Initial request - What the Task looks like on initial post
• Interim status-check - What a Task might look like if checked on prior to completion
• Completed query Task - What a Task might look like on completion with a query result
• Completed document Task - What a Task might look like on completion with a document result

Checking Task Status

Once a Task has been created on the data source, the data consumer needs to monitor for the results. This can be done on two different mechanisms: Polling and Subscription

Polling

In this mode, the data consumer occasionally queries the system maintaining the relevant Task(s) to see if there is anything ‘new’.
To poll, the client will perform a search for Tasks that are filtered to those owned by the searching organization. The search would also filter to only include those Tasks that had been created or changed since the server last looked. E.g.

[base]/Task?owner=Organization/123&_lastupdated=gt2021-05-03T17:23:18.1732-04:00

The time-stamp specified would be the search result returned from the last search.

The frequency of polling needs to be often enough to allow for timely response to changes, while not imposing too high a requirement on system performance. For Da Vinci, systems that use polling SHALL check for new/updated information at least once per business day and SHOULD check for information at least once per hour during normal hours of operation. Systems SHOULD NOT query more often than every 15 minutes unless there is an urgent change they are monitoring for.

The response would look like this.

Subscription

In the subscription mechanism, instead of the data source system regularly querying the server to see if there are changes to existing Tasks, the client creates a Subscription instance on the server that indicates that it wants to be notified about changes to Tasks and, in the Subscription, provides filters that describe what subset of Tasks it is interested in. The server will then push notifications when there are new Tasks and the data source can then query for the specific Tasks that have changed.

This Gravity functionality is based on the R4 Subscription backport implementation guide. This implementation guide allows pre-adoption of the FHIR R5 topic-based subscription approach in R4 implementations and is the subscription approach that most U.S. EHR vendors have agreed to support. Implementers of this Da Vinci IG who choose to support Subscription must comply with the Subscription Backport IG for the purpose of monitoring Tasks.

For the purposes of this IG, there will be no need for ‘topic discovery’ as there is only one topic of interest - monitoring Task. While this topic is not unique to the Gravity IG, because no standard topics have yet been defined for US Core, this IG will define the needed topic here. In the future, these topics may be subsumed into general-purpose topics defined by US Core and/or the FHIR core specification.

Systems supporting subscription SHALL support the rest-hook channel mechanism, though they may choose to support other channel approaches. Servers SHALL support both JSON and XML and clients SHALL support at least one of these. Client and server SHALL support id-only, though they may also support other content approaches. The id-only approach means that the id of the Task that was updated will be provided. The client will then perform a read or a query to retrieve the specified record(s) specified in the subscription notification. E.g.

[base]/Task?_id=1234,5678

If search is used, the client MAY use _include=Task:output to retrieve the referenced results as well. E.g. [base]/Task?_id=1234m5678&_include=Task:output

Task topic

This topic allows for monitoring for newly created tasks as well as updates to assigned or requested tasks.

Property	Value	Notes
URL	http://hl7.org/fhir/us/davinci-hrex/SubscriptionTopic/Task	This is what will appear in backport-topic-canonical extension
resourceTrigger.resourceType	Task
resourceTrigger.methodCriteria	update
resourceTrigger.queryCriteria	update
resourceTrigger.queryCriteria.previous	status:not=draft&intent=order
resourceTrigger.queryCriteria.current	status:not=draft&intent=order
resourceTrigger.queryCriteria.resultForDelete	test-passes
resourceTrigger.canFilterBy	_lastUpdated code owner requester status	owner will almost always be used. code and status can be used to further filter if desired

The subscription notification response would look like this for a query, or like this for a document request in environments where the data can be directly pushed securely.