Da Vinci Health Record Exchange (HRex)
0.2.0 - STU R1 - 2nd ballot

Da Vinci Health Record Exchange (HRex), published by HL7 International - Clinical Interoperability Council. This is not an authorized publication; it is the continuous build for version 0.2.0). This version is based on the current content of https://github.com/HL7/davinci-ehrx/ and changes regularly. See the Directory of published versions

Exchanging with FHIR subscription

Subscriptions allow a data source to notify interested data consumers when a specific event occurs. This might be the creation of a record or the update of a record to match a specific set of criteria. Using Subscription requires that the data source has the infrastructure to support consumer subscribing and can detect events as they occur and send out notifications. However, it is significantly less resource-intensive overall than polling.

Subscription can have two slightly different business flows. In both cases the data consumer POSTs (or updates) a Subscription instance on the data source indicating the type(s) of data it wants to receive. At some point, an event happens within the data source that falls within the criteria set by the subscription. At that point, the subscription will either pass the data directly or it will simply send a notification.

Subscription notifications with data

This approach is the simplest workflow because the data flows to the data consumer immediately, however it requires that the notification process be appropriately secure - and it means that any security rules governing permissions, consent or other access restrictions must be able to apply not only in the context of queries, but also in the context of the subscription mechanism - which may be in a completely different portion of the application.

Data ConsumerData Source1a. POST Subscription1b. HTTP 201 Createdloop2. Relevant event occurs3. Notification containing relevant data sent

Subscription notifications with query

In this mode, the initial notification simply indicates that 'data is available' or possibly the record ids of the relevant records. It does not expose the data itself. Because the shared information does not expose any healthcare or personally identifying information, the security expectations for the notifications are lower. The data source can subsequently query to retrieve the data at its convenience and all the data source's typical mechanism for authorizing the user, performing audit, ensuring permissions and consent, etc. can take place as they would for any query.

Data ConsumerData Source1a. POST Subscription1b. HTTP 201 Createdloop2. Relevant event occurs3. Notification of relevant event (no PHI)4a. Query for recent event data4b search-set Bundle containing relevant data