Mobile Care Services Discovery (mCSD)
4.0.0-comment - ballot International flag

This page is part of the IHE ITI Mobile Care Services Discovery (v4.0.0-comment: Publication Ballot 8) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

2:3.91 Request Care Services Updates [ITI-91]

2:3.91.1 Scope

The Request Care Services Updates transaction is used to return a list of updated care services resources. A Update Client initiates a Request Care Services Updates transaction against a Directory that supports the Update Option.

2:3.91.2 Actor Roles

Actor Role
Update Client Requests a list of updated resources from the Directory.
Directory Accepts the update request and returns a list of updated resources.

2:3.91.3 Referenced Standards

2:3.91.4 Messages

Update ClientDirectory1. Request Care Services Updates Request [ITI-91]2. Request Care Services Updates Response [ITI-91]


Figure 2:3.91.4-1: Interaction Diagram

2:3.91.4.1 Request Care Services Updates Request Message

A Request Care Services Updates message is a FHIR history operation, optionally using the _since parameter, on the mCSD Resources.

2:3.91.4.1.1 Trigger Events

A Update Client triggers a Request Care Services Updates Request to a Directory according to the business rules for the query. These business rules are outside the scope of this transaction.

2:3.91.4.1.2 Message Semantics

A Update Client initiates a history request using HTTP GET as defined at http://hl7.org/fhir/R4/http.html#history on the mCSD Resources.

A Directory and Update Client shall support the following parameters.

_since

They shall also support the requirements in ITI TF-2: Z.6, Populating the Expected Response Format.

A Directory shall support receiving a request for both the JSON and the XML messaging formats as defined in FHIR. A Update Client shall accept either the JSON or the XML messaging formats as defined in FHIR.

See ITI TF-2: Appendix W for informative implementation material for this transaction.

See the CapabilityStatements for the Update Client for additional details:

2:3.91.4.1.3 Expected Actions

The Directory shall process the query to discover the resources that match the search parameters given, and gives a response as per Section 2:3.91.4.2 or an error as per http://hl7.org/fhir/R4/search.html#errors.

2:3.91.4.2 Request Care Services Updates Response Message

The Request Care Services Updates [ITI-91] transaction uses the response semantics as defined at http://hl7.org/fhir/R4/http.html#history as applicable for the resources.

2:3.91.4.2.1 Trigger Events

The Directory sends the Request Care Services Updates Response to the Update Client when results are ready.

2:3.91.4.2.2 Message Semantics

The Directory shall support the history response message as defined at http://hl7.org.fhir/R4/http.html#history on the Care Services Resources:

All References (reference.reference element) to Resources defined in this transaction shall be populated with an accessible URL (see https://www.hl7.org/fhir/references-definitions.html#Reference.reference), unless the referenced resource is not present on a server accessible to the client.

See the CapabilityStatements for the Directory for additional details:

2:3.91.4.2.2.1 FHIR Organization Resource Constraints

A Update Client and a Directory shall query or return an Organization Resource. The Organization Resource shall be further constrained as described in the Organization Profile for mCSD.

When the Organization represents a Facility and is paired with a Location, the FHIR Organization Resource shall be further constrained as described in the Organization for Facilities Profile for mCSD.

When the Organization represents a Jurisdiction and is paired with a Location, the FHIR Organization Resource shall be further constrained as described in the Organization for Jurisdictions Profile for mCSD.

2:3.91.4.2.2.2 FHIR Location Resource Constraints

A Update Client and a Directory shall query or return a Location Resource. The Location Resource shall be further constrained as described in the Location Profile for mCSD.

When the Location represents a Facility and is paired with an Organization, the FHIR Location Resource shall be further constrained as described in the Location for Facilities Profile for mCSD.

When the Location represents a Jurisdiction and is paired with an Organization, the FHIR Location Resource shall be further constrained as described in the Location for Jurisdictions Profile for mCSD.

2:3.91.4.2.2.3 FHIR Practitioner Resource Constraints

A Update Client and a Directory shall query or return a Practitioner Resource. The Practitioner Resource shall be further constrained as described in the Practitioner Profile for mCSD.

2:3.91.4.2.2.4 FHIR PractitionerRole Resource Constraints

A Update Client and a Directory shall query or return a PractitionerRole Resource. The PractitionerRole Resource shall be further constrained as described in the PractitionerRole Profile for mCSD.

2:3.91.4.2.2.5 FHIR HealthcareService Resource Constraints

A Update Client and a Directory shall query or return a HealthcareService Resource. The HealthcareService Resource shall be further constrained as described in the HealthcareService Profile for mCSD.

2:3.91.4.2.2.6 FHIR OrganizationAffiliation Resource Constraints

A Update Client may query on OrganizationAffiliation Resources. A Directory shall return a Bundle of matching OrganizationAffiliation Resources. The OrganizationAffiliation Resource shall be further constrained as described in the OrganizationAffiliation Profile for mCSD.

When the OrganizationAffiliation contains an Endpoint to an IHE document sharing environment, it shall further be constrained as described in the OrganizationAffiliation for Document Sharing Profile for mCSD.

2:3.91.4.2.2.7 FHIR Endpoint Resource Constraints

A Update Client may query on Endpoint Resources. A Directory shall return a Bundle of matching Endpoint Resources. The Endpoint Resource shall be further constrained as described in the Endpoint Profile for mCSD.

When the Endpoint is to an IHE document sharing environment, it shall further be constrained as described in the Endpoint for Document Sharing Profile for mCSD.

2:3.91.4.2.3 Expected Actions

The Update Client has received the response and continues with its workflow.

2:3.91.5 Security Considerations

See ITI TF-1: 46.5 for security considerations for the mCSD Profile.

See ITI TF-2: Appendix Z.8 for common mobile security considerations.

2:3.91.5.1 Security Audit Considerations

Note that when grouped with ATNA Secure Node or Secure Application Actor, the same audit message is recorded by both Directory and Update Client. The difference being the Audit Source element. Both sides record to show consistency between the message sent by the Directory and the action taken at the Client.

The actors involved shall be able to record audit events according to the Audit Event for Request Care Services Updates by the Directory and Update Client.