This page is part of the Da Vinci Unsolicited Notifications (v1.0.0: STU1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions 
Framework
Introduction
FHIR resources can be used to transport patient information relevant to a specific event (e.g. admission, discharge, change in treatment, new diagnosis) to another provider or the health plan to communicate the details of where care was delivered and help to ensure timely follow-up as needed. The intent is to provide the minimally required information in the alert, for the receiver to know, if the alert is of interest and give enough information to be able to request more from the sender, if desired. This information can be used to build an encounter record in the receiving system with appropriate provenance and make it available to CDS and other local services. For the initial phase, alerts are transacted using the Da Vinci $notify operation to push directly to “registered” Alert Recipient or Alert Intermediary.
This project recognizes the impact of the Argonaut Clinical Data Subscriptions project which is working on event based subscriptions and major revisions to the Subscription resource for FHIR R5. In a future version this guide, a subscription based notification is planned which will align with the outcomes of the Argonaut project.
Must Support
All elements in the Da Vinci Alert profiles have a MustSupport flag. Systems claiming to conform to a profile must “support” the element as defined herein:
This guide adopts the following definitions of Must Support for all direct transactions between the Alert Sender and Alert Recipient or Alert Intermediary
Must Support on any data element SHALL be interpreted as follows:
-
As part of the alert notification or a query result as specified by the Da Vinci Alerts CapabilityStatements, the Alert Sender SHALL be capable of including the data elements defined in the Da Vinci Alert profiles that have a MustSupport flag.
-
Alert Recipient/Intermediary SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail. In other words Alert Recipient/Intermediary SHOULD be capable of processing the data elements (display, store, etc).
-
In situations where information on a particular data element is not present and the reason for absence is unknown, Alert Sender SHALL NOT include the data elements in the resource instance returned as part of a $notify alert notification or a query response.
-
When receiving an alert notification or a query response from the Alert Sender, the Alert Recipient/Intermediary SHALL interpret missing data elements within resource instances as data not present in the Alert Sender’s systems.
-
In situations where information on a particular data element is missing and the Alert Sender knows the precise reason for the absence of data, Alert Sender SHALL provide the reason for the missing information using values (such as nullFlavors) from the value set where they exist or using the dataAbsentReason extension.
-
Alert Recipient/Intermediary SHALL be able to process resource instances containing data elements asserting missing information without generating an error or causing the application to fail.
This guide adopts the following definitions of Must Support for all transactions between the Alert Intermediary and Alert Recipient
Must Support on any data element SHALL be interpreted as follows:
-
As part of the alert notification or a query result as specified by the [Da Vinci Intermediary Server CapabilityStatement], the Alert Sender SHALL be capable of including the data elements defined in the Da Vinci Alert profiles that have a MustSupport flag.
-
The Alert Recipient SHALL be capable of processing resource instances containing the data elements the data elements defined in the Da Vinci Alert profiles that have a MustSupport flag without generating an error or causing the application to fail. In other words, the Alert Recipient SHOULD be capable of processing the data elements (displaying, storing, etc).
-
In situations where information on a particular data element is not needed or considered protected information the Alert Intermediary MAY remove the data elements in the resource instance when distributing the alert notification or responding to an Alert Recipient’s query. The Alert Intermediary MAY provide the reason for the missing information using values (such as nullFlavors) from the value set where they exist or using the dataAbsentReason extension.
-
The Alert Recipient SHALL be able to process resource instances containing missing data elements and data elements asserting missing information without generating an error or causing the application to fail.
Preconditions and Assumptions
Preconditions
- There is an event that drives the generation of the Alert.
- An Alert will be generated for each patient separately.
- The event can be for one or more patients.
- The Alert Sender has access to the Alert Recipients/Intermediary FHIR endpoints.
- System level trust exists between the actors.
- Clients have been authorized by the servers.
- It is assumed that consent is managed elsewhere.
- Patient consent allows exchange of data between the relevant systems.
- A secure information transport mechanism exists between the actors.
Assumptions
- Based on FHIR R4 and US Core R4 profiles where applicable.
- Alerts are transacted to an operation endpoint ($notify).
- The Da Vinci Alerts Bundle Profile is the FHIR object that is exchanged for all alert transactions.
- The Da Vinci Alerts Communication Profile is always part of the bundle and provides the necessary context for the alert reason.
Alert Bundle
The FHIR resources used in Da Vinci Alert transactions form a network through their relationships with each other - either through a direct reference to another resource or through a chain of intermediate references. These groups of resources are referred to as resource graphs. The FHIR Alert resource graph for the admit and discharge use case is shown in Figure 7.
Note to Balloters: We are seeking input on the Bundle type to use this context. Both transaction, and collection were considered. Although transaction (and transaction-response) provides some additional confirmation of delivery, the required .request.method element places additional expectations on the server responding to the $notify transaction. In contrast, the collection type imposes no processing obligations or behavioral rules beyond persistence, including any confirmation confirmation of delivery beyond the http status.
For every alert notification, the FHIR object that is exchanged is the Da Vinci Alert Bundle Profile. This bundle is a transaction type bundle that is POSTed to the Alert Recipient’s or Intermediary’s FHIR endpoint via a the $notify operation. The complete set of content to make up an Alert Bundle includes the Da Vinci Alerts Communication Profile which provides the necessary context for the alert reason together with various resources pointed to or indirectly connected to the Communication profile, all gathered together into a Bundle for transport and persistence. Resources associated with the following list of Communication references SHALL be included in the Bundle:
Communication.subject(Patient resource)Communication.encounter(Encounter Resource )- All supporting data (resources) for each kind of alert is referenced in
Communication.payload
The following Table summarizes the Alert Scenarios and the Resources that may be referenced in the [Da Vinci Communication Profile] payload element and included in the alert Bundle:
| Alert Scenarios | Resources in Alert Bundle(1) | Searchable Resources(2) |
|---|---|---|
| Emergency and Inpatient Admissions | US Core R4 Condition | Location, Coverage, Practitioner (sender), Organization (sender), PractitionerRole (sender) |
| Emergency and Inpatient Discharges | US Core R4 Condition | Location, Coverage, Practitioner (sender), Organization (sender), PractitionerRole (sender) |
Example of an Alert Bundle for a patient admission.
Note to Balloters: These scenarios may be added in future iterations of this IG.
| Alert Scenarios | Resources in Alert Bundle(1) | Searchable Resources(2) |
|---|---|---|
| Lab Results | US Core R4 DiagnosticReport, US Core R4 Observation, US Core R4 DocumentReference | TBD… |
| Problem with Treatment – such as drug recall, device recall/issue | US Core R4 Medication, US Core R4 AdverseEvent, US Core R4 Device | TBD… |
| Encounter/Visit Notification | no additional | TBD… |
| Public Health Notification | US Core R4 Condition | TBD… |
| Scheduled Appointment/Pre-Admit | R4 Appointment | TBD… |
| Referral | R4 ServiceRequest, R4 Practitioner | TBD… |
| Ordered Device/Biometric/Patient (i.e. Fit Bit) | R4 DeviceRequest | TBD… |
| Treatment Start/End | US Core R4 MedicationAdministration | TBD… |
| Change in Social Determinants of Health | R4 Observation | TBD… |
| Birth/Death | No additional resource | TBD… |
| Coverage Start/End | DEQM Coverage | TBD… |
| Notification of Prior Authorization (Pended to Approved/Denied) | R4 ClaimResponse | TBD… |
| Pharmacy (Pickup, Restock, Dispense) | US Core R4 Medication, US Core R4 MedicationDispense, R4 SupplyDelivery, R4 SupplyRequest | TBD… |
| Notification of New Condition | US Core R4 Condition | TBD… |
| Work Comp Initial/Visits/Services | US Core R4 Condition, R4 Coverage | TBD… |
| Changes in Care Team | US Core R4 Practitioner, R4 RelatedPerson, R4 CareTeam | TBD… |
footnotes:
(1): In addition to Patient and Encounter which are included in all Alert Bundles.
(2): Minimum set of the patient’s Resources that are Available for Optional Subsequent Queries.
Push Alert Notification
As shown in Figure 4a and 4b, When an event or request triggers an alert, the Alert Sender creates an Alert bundle and notifies the Alert Recipient or Alert Intermediary using the Da Vinci Notify Operation operation. The body of this operation is a Parameter resource consisting of a single parameter with two nested parts containing:
-
The Alert Bundle containing the required Alert Communication profile and required resources for this Alert event use case. The table in the previous section lists for each alert scenario, the relevant resources to be included in the Alert Bundle and referenced in the
Communication.payloadelement. -
The Da Vinci Alerts Endpoint Profile which is intended only for the direct recipient of the operation and provides the recipient with the technical details for getting additional information from the medical record for the alert.
Note that an authentication token may be supplied in
Endpoint.headerby the Alert Sender to allow direct recipients of the Alert (whether an Alert Recipient or Alert Intermediary) to access additional information. This and other supplied headers, if any are given, are appended to the GET request. Sending these tokens has obvious security consequences. The server and client are responsible for ensuring that the content is appropriately secured.
In the context of the $notify operation, the Alert Recipient/Intermediary is treated as a “black box” and simply accepts and processes the submitted data and there are no further expectations. The response to the operation and the transaction Bundle are defined in the FHIR specification.
Note to Balloters: We are actively seeking input on what expectations should be defined for error handling and and whether there is a need to support “reliable delivery”
Since the parameter can repeat a single operation transaction may contain multiple alerts. There is no expectation that the data submitted represents all the data required by the Alert Recipient/Intermediary, only that the data is known to be relevant to the triggering event. The Alert Recipient/Intermediary can optionally fetch additional information from the patient’s medical record using FHIR RESTful searches. The endpoint for this search may be known or supplied via the $notify operation payload.
As shown in figure 4b, after the Alert Intermediary successfully receives the notification, processes the Alert Bundle and optionally searches and process the seach results, it redistributes the data the end users. It may use the $notify operation to do this, however the original Endpoint SHALL NOT be distributed. Note that the Alert Intermediary may customize the content based on the end user (for example, withholding data that a particular care team member does not need).
Note to Balloters: We are actively seeking input on whether this guide should define the expectations of how Alert Intermediaries distribute the alert information to the Alert Recipients. For example using existing data transport protocols such as Direct, SMS or V2 messaging.
APIs
The following Da Vinci Alert FHIR artifacts are used in this transaction:
- Da Vinci Alerts Bundle Profile
- Da Vinci Alerts Communication Profile
- Da Vinci Alerts Endpoint Profile
- Da Vinci Notify Operation
Usage
The $notify operation is invoked by the Alert Sender using the POST syntax with Parameter resource in the request body:
POST [base]Communication/$notify
Examples
Scenario:
Patient Y has been admitted to Provider X ‘s facility. Acting in the role of Alert Sender Provider X alerts Payer Z who is acting in the role Alert Recipient of the admission. The Alert is transacted as the $notify operation. The body of the operation is a Parameter resource containing two parts:
- The Alert Endpoint which provides the recipient with the technical details of an endpoint for getting additional information from the medical record for this event.
- The Alert Bundle containing the required Alert Communication profile and required resources for this Alert event use case.
An HTTP Status success code is returned on successful submission and a Bundle with type transaction-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.
Push Alert Notification using the $notify operation
POST [base]Communication/$notify
Request body
{
"resourceType" : "Parameters",
"id" : "admit-1",
"parameter" : [
{
"name" : "alert",
"part" : [
{
"name" : "alert-endpoint",
"resource" : {
"resourceType" : "Endpoint",
"status" : "active",
"connectionType" : {
"system" : "http://terminology.hl7.org/CodeSystem/endpoint-connection-type",
"code" : "hl7-fhir-rest"
},
"name" : "Acme Hospital EHR FHIR R4 Server",
"payloadType" : [
{
"text" : "n/a"
}
],
"address" : "https://fhir-ehr.acme/r4/1234/",
"header" : [
"Authorization: Bearer eyJraWQiOiIyMDE5LTA3LTE3VDIzOjA1OjQ4LjY3NC5lYyIsInR5cCI6IkpXVCIsImFsZyI6IkVTMjU2In0.eyJzdWIiOiJwb3J0YWwiLCJ1cm46Y29tOmNlcm5lcjphdXRob3JpemF0aW9uOmNsYWltcyI6eyJ2ZXIiOiIxLjAiLCJ0bnQiOiIwYjhhMDExMS1lOGU2LTRjMjYtYTkxYy01MDY5Y2JjNmIxY2EiLCJhenMiOiJ1c2VyXC9DYXBhYmlsaXR5U3RhdGVtZW50LnJlYWQgdXNlclwvQWxsZXJneUludG9sZXJhbmNlLnJlYWQgdXNlclwvQXBwb2ludG1lbnQucmVhZCB1c2VyXC9FbmNvdW50ZXIucmVhZCB1c2VyXC9QYXRpZW50LnJlYWQgdXNlclwvUHJhY3RpdGlvbmVyLnJlYWQgdXNlclwvUmVsYXRlZFBlcnNvbi5yZWFkIn0sImF6cCI6IjgwMjg5YjQ4LTYzMjYtNDcxNi04NDQ1LThmYjIxNTkxNTkwZiIsImlzcyI6Imh0dHBzOlwvXC9hdXRob3JpemF0aW9uLnNhbmRib3hjZXJuZXIuY29tXC8iLCJleHAiOjE1NjM1MDQ2MTksImlhdCI6MTU2MzUwNDAxOSwianRpIjoiNDI1Y2E3NGQtNDFhMy00N2U5LTk2OTEtMGVmYThhYTUzYTdlIiwidXJuOmNlcm5lcjphdXRob3JpemF0aW9uOmNsYWltczp2ZXJzaW9uOjEiOnsidmVyIjoiMS4wIiwicHJvZmlsZXMiOnsic21hcnQtdjEiOnsiYXpzIjoidXNlclwvQ2FwYWJpbGl0eVN0YXRlbWVudC5yZWFkIHVzZXJcL0FsbGVyZ3lJbnRvbGVyYW5jZS5yZWFkIHVzZXJcL0FwcG9pbnRtZW50LnJlYWQgdXNlclwvRW5jb3VudGVyLnJlYWQgdXNlclwvUGF0aWVudC5yZWFkIHVzZXJcL1ByYWN0aXRpb25lci5yZWFkIHVzZXJcL1JlbGF0ZWRQZXJzb24ucmVhZCJ9fSwiY2xpZW50Ijp7Im5hbWUiOiJ0ZXN0LXI0IiwiaWQiOiI4MDI4OWI0OC02MzI2LTQ3MTYtODQ0NS04ZmIyMTU5MTU5MGYifSwidXNlciI6eyJwcmluY2lwYWwiOiJwb3J0YWwiLCJwZXJzb25hIjoicHJvdmlkZXIiLCJpZHNwIjoiMGI4YTAxMTEtZThlNi00YzI2LWE5MWMtNTA2OWNiYzZiMWNhIiwic2Vzc2lvbl9pZCI6Ijk0ZjYyZjhlLTJhMDAtNDAwMi05OWYwLWZkOWYzMjIwM2UwNCIsInByaW5jaXBhbFR5cGUiOiJVTkRFRklORUQiLCJwcmluY2lwYWxVcmkiOiJodHRwczpcL1wvbWlsbGVubmlhLnNhbmRib3hjZXJuZXIuY29tXC9pbnN0YW5jZVwvMGI4YTAxMTEtZThlNi00YzI2LWE5MWMtNTA2OWNiYzZiMWNhXC9wcmluY2lwYWxcLzAwMDAuMDAwMC4wMDQ0LjFEODciLCJpZHNwVXJpIjoiaHR0cHM6XC9cL21pbGxlbm5pYS5zYW5kYm94Y2VybmVyLmNvbVwvYWNjb3VudHNcL2ZoaXJwbGF5LnRlbXBfcmhvLmNlcm5lcmFzcC5jb21cLzBiOGEwMTExLWU4ZTYtNGMyNi1hOTFjLTUwNjljYmM2YjFjYVwvbG9naW4ifSwidGVuYW50IjoiMGI4YTAxMTEtZThlNi00YzI2LWE5MWMtNTA2OWNiYzZiMWNhIn19.weCcKK-zziKrsXlUKHunHTkbUJOZTV0AEzteZeaYdGjhF9581LlBCCp4EnaaUIQbkaWkQ-btukZ_GLw7-cy2Ag"
]
}
},
{
"name" : "alert-bundle",
"resource" : {
"resourceType" : "Bundle",
"id" : "admit-01",
"type" : "transaction",
"entry" : [
{
"fullUrl" : "urn:uuid:3852d906-a361-11e9-86cd-a4d18ccf5172",
"resource" : {
"resourceType" : "Patient",
"meta" : {
"profile" : [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
]
},
"extension" : [
{
"url" : "http://hl7.org/fhir/us/core/StructureDefinition/us-core-race",
"extension" : [
{
"url" : "ombCategory",
"valueCoding" : {
"system" : "urn:oid:2.16.840.1.113883.6.238",
"code" : "2106-3",
"display" : "White"
}
},
{
"url" : "ombCategory",
"valueCoding" : {
"system" : "urn:oid:2.16.840.1.113883.6.238",
"code" : "1002-5",
"display" : "American Indian or Alaska Native"
}
},
{
"url" : "ombCategory",
"valueCoding" : {
"system" : "urn:oid:2.16.840.1.113883.6.238",
"code" : "2028-9",
"display" : "Asian"
}
},
{
"url" : "detailed",
"valueCoding" : {
"system" : "urn:oid:2.16.840.1.113883.6.238",
"code" : "1586-7",
"display" : "Shoshone"
}
},
{
"url" : "detailed",
"valueCoding" : {
"system" : "urn:oid:2.16.840.1.113883.6.238",
"code" : "2036-2",
"display" : "Filipino"
}
},
{
"url" : "text",
"valueString" : "Mixed"
}
]
},
{
"url" : "http://hl7.org/fhir/us/core/StructureDefinition/us-core-ethnicity",
"extension" : [
{
"url" : "ombCategory",
"valueCoding" : {
"system" : "urn:oid:2.16.840.1.113883.6.238",
"code" : "2135-2",
"display" : "Hispanic or Latino"
}
},
{
"url" : "detailed",
"valueCoding" : {
"system" : "urn:oid:2.16.840.1.113883.6.238",
"code" : "2184-0",
"display" : "Dominican"
}
},
{
"url" : "detailed",
"valueCoding" : {
"system" : "urn:oid:2.16.840.1.113883.6.238",
"code" : "2148-5",
"display" : "Mexican"
}
},
{
"url" : "text",
"valueString" : "Hispanic or Latino"
}
]
},
{
"url" : "http://hl7.org/fhir/us/core/StructureDefinition/us-core-birthsex",
"valueCode" : "F"
}
],
"identifier" : [
{
"use" : "usual",
"type" : {
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
"code" : "MR",
"display" : "Medical Record Number"
}
],
"text" : "Medical Record Number"
},
"system" : "http://hospital.smarthealthit.org",
"value" : "1032702"
}
],
"active" : true,
"name" : [
{
"family" : "Shaw",
"given" : [
"Amy",
"V."
]
}
],
"telecom" : [
{
"system" : "phone",
"value" : "555-555-5555",
"use" : "home"
},
{
"system" : "email",
"value" : "amy.shaw@example.com"
}
],
"gender" : "female",
"birthDate" : "2007-02-20",
"address" : [
{
"line" : [
"49 Meadow St"
],
"city" : "Mounds",
"state" : "OK",
"postalCode" : "74047",
"country" : "US"
}
]
},
"request" : {
"method" : "POST",
"url" : "Patient"
}
},
{
"fullUrl" : "urn:uuid:3857dfb4-a361-11e9-86cd-a4d18ccf5172",
"resource" : {
"resourceType" : "Encounter",
"meta" : {
"lastUpdated" : "2017-05-26T11:56:57.250-04:00",
"profile" : [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-encounter"
]
},
"status" : "finished",
"class" : {
"system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code" : "IMP",
"display" : "inpatient encounter"
},
"type" : [
{
"coding" : [
{
"system" : "http://www.ama-assn.org/go/cpt",
"code" : "99234"
}
],
"text" : "inpatient hospital care"
}
],
"subject" : {
"reference" : "urn:uuid:3852d906-a361-11e9-86cd-a4d18ccf5172"
},
"period" : {
"start" : "2015-11-01T17:00:14-05:00",
"end" : "2015-11-01T18:00:14-05:00"
},
"location" : [
{
"location" : {
"reference" : "Location/hl7east"
}
}
]
},
"request" : {
"method" : "POST",
"url" : "Encounter"
}
},
{
"fullUrl" : "urn:uuid:385a65e0-a361-11e9-86cd-a4d18ccf5172",
"resource" : {
"resourceType" : "Condition",
"meta" : {
"profile" : [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition"
]
},
"clinicalStatus" : {
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/condition-clinical",
"code" : "active",
"display" : "Active"
}
],
"text" : "Active"
},
"verificationStatus" : {
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/condition-ver-status",
"code" : "confirmed",
"display" : "Confirmed"
}
],
"text" : "Confirmed"
},
"category" : [
{
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/condition-category",
"code" : "problem-list-item",
"display" : "Problem List Item"
}
],
"text" : "Problem"
}
],
"code" : {
"coding" : [
{
"system" : "http://snomed.info/sct",
"code" : "442311008",
"display" : "Liveborn born in hospital"
}
],
"text" : "Single liveborn, born in hospital"
},
"subject" : {
"reference" : "urn:uuid:3852d906-a361-11e9-86cd-a4d18ccf5172",
"display" : "Amy V. Shaw"
},
"onsetDateTime" : "2016-08-10"
},
"request" : {
"method" : "POST",
"url" : "Condition"
}
},
{
"fullUrl" : "urn:uuid:385bceb2-a361-11e9-86cd-a4d18ccf5172",
"resource" : {
"resourceType" : "Communication",
"meta" : {
"profile" : [
"http://hl7.org/fhir/us/davinci-alerts/StructureDefinition/alerts-communication"
]
},
"identifier" : [
{
"system" : "urn:oid:1.3.4.5.6.7",
"value" : "2345678901"
}
],
"status" : "completed",
"category" : [
{
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/communication-category",
"code" : "alert"
}
],
"text" : "Alert"
}
],
"priority" : "routine",
"subject" : {
"reference" : "urn:uuid:3852d906-a361-11e9-86cd-a4d18ccf5172"
},
"topic" : {
"coding" : [
{
"system" : "http://hl7.org/fhir/us/davinci-alerts/CodeSystem/communication-topic",
"code" : "alert-admit-inpatient"
}
],
"text" : "Alert Admit Inpatient"
},
"about" : [
{
"reference" : "Coverage/example-1",
"type" : "Coverage"
}
],
"encounter" : {
"reference" : "urn:uuid:3857dfb4-a361-11e9-86cd-a4d18ccf5172"
},
"sent" : "2019-07-04T18:01:10-08:00",
"recipient" : [
{
"reference" : "PractitionerRole/example"
}
],
"sender" : {
"reference" : "Organization/example-2"
},
"payload" : [
{
"contentString" : "Admit to xyz"
},
{
"contentReference" : {
"reference" : "urn:uuid:3857dfb4-a361-11e9-86cd-a4d18ccf5172"
}
},
{
"contentReference" : {
"reference" : "urn:uuid:385a65e0-a361-11e9-86cd-a4d18ccf5172"
}
}
]
},
"request" : {
"method" : "POST",
"url" : "Communication"
}
}
]
}
}
]
}
]
}
Response
HTTP/1.1 200 OK
[other headers]
Response body
{
"resourceType": "Bundle",
"id": "42941562-0747-498d-8c02-e37f312f3e99",
"type": "transaction-response",
"link": [
{
"relation": "self",
"url": "http://hapi.fhir.org/baseR4"
}
],
"entry": [
{
"response": {
"status": "201 Created",
"location": "Patient/87904/_history/1",
"etag": "1",
"lastModified": "2019-07-10T22:56:19.306+00:00"
}
},
{
"response": {
"status": "201 Created",
"location": "Encounter/87905/_history/1",
"etag": "1",
"lastModified": "2019-07-10T22:56:19.306+00:00"
}
},
{
"response": {
"status": "201 Created",
"location": "Condition/87906/_history/1",
"etag": "1",
"lastModified": "2019-07-10T22:56:19.306+00:00"
}
},
{
"response": {
"status": "201 Created",
"location": "Communication/87907/_history/1",
"etag": "1",
"lastModified": "2019-07-10T22:56:19.306+00:00"
}
}
]
}
