Mobile Care Services Discovery (mCSD)
4.0.0 - Trial-Implementation
Mobile Care Services Discovery (mCSD)
4.0.0 - Trial-Implementation
Mobile Care Services Discovery (mCSD), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 4.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.mCSD/ and changes regularly. See the Directory of published versions
The Care Services Feed transaction is used to create, update, or delete care services resources. A Data Source initiates a Care Services Feed transaction against a Directory that supports the Feed Option.
| Actor | Role |
|---|---|
| Data Source | Sends the feed request to the Directory. |
| Directory | Receives and processes the feed request. |
Figure 2:3.130.4-1: Interaction Diagram
A Create Care Services Resource Request Message is a FHIR create operation on any supported Care Services resource the Directory supports.
A Data Source triggers a Create Care Services Resource Request to a Directory when it needs to submit a new Care Services resource.
A Data Source SHALL initiate a create request using HTTP POST as defined at http://hl7.org/fhir/R4/http.html#create on the Care Services Resource.
A Data Source SHALL submit the Care Services resource in either XML format or JSON format
thus the media type of the HTTP body SHALL be either application/fhir+json or application/fhir+xml respectively.
A Directory SHALL accept both XML and JSON formats.
All References (Reference.reference element) to Resources defined in this transaction SHALL be populated with an resolvable URL (see http://hl7.org/fhir/R4/references-definitions.html#Reference.reference), unless the referenced resource is not available at a URL known to the server.
See the CapabilityStatements for the Data Source for additional details:
A Data Source may submit Organization Resources. The Organization Resource SHALL be further constrained as described in the Organization Profile for mCSD.
A Data Source may submit Organization Resources when working with Facilities. The FHIR Organization Resource SHALL be further constrained as described in the Organization for Facilities Profile for mCSD.
A Data Source may submit Organization Resources when working with Jurisdictions. The FHIR Organization Resource SHALL be further constrained as described in the Organization for Jurisdictions Profile for mCSD.
A Data Source may submit Location Resources. The Location Resource SHALL be further constrained as described in the Location Profile for mCSD.
When the resource is a Facility, the Location Resource SHALL be paired with an Organization Resource using the managingOrganization element in Location. A Data Source may submit Location Resources when working with Facilities. The FHIR Location Resource SHALL be further constrained as described in the Location for Facilities Profile for mCSD.
When the resource is a Jurisdiction, the Location Resource SHALL be paired with an Organization Resource using the managingOrganization element in Location. A Data Source may submit Location Resources when working with Jurisdictions. The FHIR Location Resource SHALL be further constrained as described in the Location for Jurisdictions Profile for mCSD.
When a geographic boundary is available for the Jurisdiction Location, the location-boundary-geojson extension defined at http://hl7.org/fhir/extension-location-boundary-geojson.html SHALL be used to store this information.
A Data Source may submit Practitioner Resources. The Practitioner Resource SHALL be further constrained as described in the Practitioner Profile for mCSD.
A Data Source may submit PractitionerRole Resources. The PractitionerRole Resource SHALL be further constrained as described in the PractitionerRole Profile for mCSD.
A Data Source may submit HealthcareService Resources. The HealthcareService Resource SHALL be further constrained as described in the HealthcareService Profile for mCSD.
A Data Source may submit 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.
A Data Source may submit 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.
A Directory SHALL process the submission to validate the resources submitted and give a response as per Section 2:3.130.4.2 or an error as per http://hl7.org/fhir/R4/http.html#create. Additional validation and resolution may be required by your business rules, for example with checking for duplicate resources.
The Create Care Services Resource response message uses the response semantics as defined at http://hl7.org/fhir/R4/http.html#create as applicable for the resources.
The Directory sends the Create Care Services Resource response message to the Data Source when submitted resource has been processed.
A Directory SHALL respond with an HTTP 201 Created status code as indicated at http://hl7.org/fhir/R4/http.html#create or an appropriate error status code.
A Directory SHALL also support the requirements in ITI TF-2: Z.6, Populating the Expected Response Format.
See the CapabilityStatements for the Directory for additional details:
The Data Source has received the response and continues with its workflow.
A Update Care Services Resource Request Message is a FHIR update operation on any supported Care Services resource the Directory supports.
A Data Source triggers a Update Care Services Resource Request to a Directory when it needs to update a Care Services resource.
A Data Source SHALL initiate a update request using HTTP PUT as defined at http://hl7.org/fhir/R4/http.html#update on the Care Services Resource.
A Data Source SHALL submit the Care Services resource in either XML format or JSON format
thus the media type of the HTTP body SHALL be either application/fhir+json or application/fhir+xml respectively.
A Directory SHALL accept both XML and JSON formats.
All References (Reference.reference element) to Resources defined in this transaction SHALL be populated with an resolvable URL (see http://hl7.org/fhir/R4/references-definitions.html#Reference.reference), unless the referenced resource is not available at a URL known to the server.
See the CapabilityStatements for the Data Source for additional details:
A Data Source may submit Organization Resources. The Organization Resource SHALL be further constrained as described in the Organization Profile for mCSD.
A Data Source may submit Organization Resources when working with Facilities. The FHIR Organization Resource SHALL be further constrained as described in the Organization for Facilities Profile for mCSD.
A Data Source may submit Organization Resources when working with Jurisdictions. The FHIR Organization Resource SHALL be further constrained as described in the Organization for Jurisdictions Profile for mCSD.
A Data Source may submit Location Resources. The Location Resource SHALL be further constrained as described in the Location Profile for mCSD.
When the resource is a Facility, the Location Resource SHALL be paired with an Organization Resource using the managingOrganization element in Location. A Data Source may submit Location Resources when working with Facilities. The FHIR Location Resource SHALL be further constrained as described in the Location for Facilities Profile for mCSD.
When the resource is a Jurisdiction, the Location Resource SHALL be paired with an Organization Resource using the managingOrganization element in Location. A Data Source may submit Location Resources when working with Jurisdictions. The FHIR Location Resource SHALL be further constrained as described in the Location for Jurisdictions Profile for mCSD.
When a geographic boundary is available for the Jurisdiction Location, the location-boundary-geojson extension defined at http://hl7.org/fhir/extension-location-boundary-geojson.html SHALL be used to store this information.
A Data Source may submit Practitioner Resources. The Practitioner Resource SHALL be further constrained as described in the Practitioner Profile for mCSD.
A Data Source may submit PractitionerRole Resources. The PractitionerRole Resource SHALL be further constrained as described in the PractitionerRole Profile for mCSD.
A Data Source may submit HealthcareService Resources. The HealthcareService Resource SHALL be further constrained as described in the HealthcareService Profile for mCSD.
A Data Source may submit 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.
A Data Source may submit 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.
A Directory SHALL process the submission to validate the resources submitted, and give a response as per Section 2:3.130.4.4 or an error as per http://hl7.org/fhir/R4/http.html#update.
The Update Care Services Resource response message uses the response semantics as defined at http://hl7.org/fhir/R4/http.html#update as applicable for the resources.
The Directory sends the Update Care Services Resource response message to the Data Source when submitted resource has been processed.
A Directory SHALL respond with an HTTP 200 OK status code as indicated at http://hl7.org/fhir/R4/http.html#update or an appropriate error status code as indicated at http://hl7.org/fhir/R4/http.html#update
A Directory SHALL also support the requirements in ITI TF-2: Z.6, Populating the Expected Response Format.
See the CapabilityStatements for the Directory for additional details:
The Data Source has received the response and continues with its workflow.
A Delete Care Services Resource Request Message is a FHIR delete operation on any supported Care Services resource the Directory supports.
A Data Source triggers a Delete Care Services Resource Request to a Directory when it needs to delete a Care Services resource.
A Data Source SHALL initiate a delete request using HTTP DELETE as defined at http://hl7.org/fhir/R4/http.html#delete on the Care Services Resource.
See the CapabilityStatements for the Data Source for additional details:
A Directory SHALL process the submission and give a response as per Section 2:3.130.4.5 or an error as per http://hl7.org/fhir/R4/http.html#delete.
The Delete Care Services Resource response message uses the response semantics as defined at http://hl7.org/fhir/R4/http.html#delete as applicable for the resources.
The Directory sends the Delete Care Services Resource response message to the Data Source when submitted resource has been processed.
A Directory SHALL respond with an HTTP 200 OK status code as indicated at http://hl7.org/fhir/R4/http.html#delete or an appropriate error status code as indicated at http://hl7.org/fhir/R4/http.html#delete
See the CapabilityStatements for the Directory for additional details:
The Data Source has received the response and continues with its workflow.
A Process Care Services Resources Request Message is a FHIR transaction operation including Care Services resources the Directory supports. Each entry in the bundle SHALL conform to the other feed request messages:
A Data Source triggers a Process Care Services Resources Request to a Directory when it needs to process multiple Care Services resource feed messages.
A Data Source SHALL initiate a transaction request using HTTP POST as defined at http://hl7.org/fhir/R4/http.html#transaction on the server with a FHIR Bundle as the body of the request.
The Bundle.type SHALL be transaction and each entry will succeed or fail together.
A Data Source SHALL submit the Care Services resource in either XML format or JSON format
thus the media type of the HTTP body SHALL be either application/fhir+json or application/fhir+xml respectively.
A Directory SHALL accept both XML and JSON formats.
See the CapabilityStatements for the Data Source for additional details:
The Bundle Resource SHALL be further constrained as described in the Process Care Services Profile for mCSD.
A Directory SHALL process the submission and give a response as per Section 2:3.130.4.8 or an error as per http://hl7.org/fhir/R4/http.html#transaction. The Directory SHALL follow the transaction processing rules.
The Process Care Services Resources response message uses the response semantics as defined at http://hl7.org/fhir/R4/http.html#transaction as applicable for the resources. Each entry in the bundle SHALL conform to the other feed response messages:
The Directory sends the Process Care Services Resources response message to the Data Source when submitted resources have been processed.
A Directory SHALL respond with an HTTP 200 OK status code as indicated at http://hl7.org/fhir/R4/http.html#transaction or an appropriate error status code as indicated at http://hl7.org/fhir/R4/http.html#transaction.
A Directory SHALL also support the requirements in ITI TF-2: Z.6, Populating the Expected Response Format.
The response will be a FHIR Bundle with the type set to transaction-response. The entries in the Bundle will correspond to the entries in the request with the result of processing each entry.
See the CapabilityStatements for the Directory for additional details:
The Data Source has received the response and continues with its workflow.
Access controls should be considered to ensure only allowed users and/or systems are able to update data. This may include resource or element level controls as well as Provenance for documenting the data source. These access controls could be addressed by the client or the server as dictated by the implementation. It is recommended to use IUA for authorization.
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.
Note that when grouped with ATNA Secure Node or Secure Application Actor, the same audit message is recorded by both Data Source and Directory. 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 Data Source.
The actors involved shall be able to record audit events according to the transaction being used:
For a transaction Bundle, the actors shall also be able to record audit events for the individual entries in the Bundle.
IG © 2022+ IHE IT Infrastructure Technical Committee. Package ihe.iti.mcsd#4.0.0 based on FHIR 4.0.1. Generated 2025-04-30
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change