Profiles & Operations Index > Operation: Submit MI Image Study

Operation: Submit Imaging Study

Submit MI Imaging Study

The MI imaging study submission operation is based on FHIR transaction paradigm using HTTP asynchronous interaction. Each Bundle in a transaction must include an ImagingStudy resource and its referenced resources.

The transaction interactions submit a set of actions to perform on a server in a single HTTP request/response. The actions are performed as a single atomic "transaction" where the entire set of changes succeeds or fails as a single entity.

A transaction interaction is performed by an HTTP POST command as shown:

  POST [base] {?_format=[mime-type]}

The content of the post submission is a Bundle with Bundle.type = transaction. Each entry SHALL carry request details (Bundle.entry.request) that provides the HTTP details of the action in order to inform the system processing the batch or transaction what to do for the entry. For the POST HTTP command, the entry SHALL contain a resource for the body of the action. The resources in the bundle are each processed separately as if they were an individual interaction. The actions are subject to the normal processing for each, including transactional integrity. In a transaction, all interactions or operations either succeed or fail together.

Transaction Processing Rules

For a transaction, servers will either accept all actions or reject all resources. The outcome of processing the transaction will not depend on the order of the resources in the transaction. A resource can only appear in a transaction once (by identity).

When processing a transaction, the server will assign new ids to all submitted resources, irrespective of any claimed logical id in the resource, or fullUrl on entries in the transaction.

Transaction Response

In an HTTP asynchronous interaction, API client submits a contribution payload and miCDR returns an “Accepted” (HTTP 202) response, before the contribution payload has been validated against conformance rules and business rules. After accepting the payload, the contribution is queued and processed. Errors generated during async processing are stored in miCDR for review and analysis, but are not returned to the API client in the response to the original request.

Interaction Diagram

Actor: miCDR ImagingStudy Contributor

Role: Submits a ImagingStudy resource and its reference resources to the miCDR FHIR server.

Actor: miCDR FHIR server

Role: Returns HTTP acknowledgement and later a Bundle containing ImagingStudy instances (as well as referenced resources if requested by use of _include and _revinclude parameters) that match the search criteria specified by the miCDR ImagingStudy Contributor.

Specification

This operation is based on FHIR R4 transaction.

Submit Imaging Study Operation

`POST [base]{?_format=[mime-type]}

MI Image Study Submission Resources

MI Image Study Submission Example

Transaction Bundle Example

Submission Response

If the submission payload is conformant, MiCDR server will return HTTP 202 Accepted with no HTTP body. If the payload fails conformance rules, an HTTP error code (e.g. 400, 404) will be returned and the payload will be rejected.

Later MiCDR will try to process the payload. If it is successful, a FHIR transaction response bundle will be returned indicating how each resouce has been processed. If any part of processing fails, the transaction fails and a transaction response bundle will be returned indicating the error.

Expected Behavior

See Response Handling page for additional response handling behavior.

Legend
code = OperationOutcome.issue.code
severity = OperationOutcome.issue.severity
details.coding.code=OperationOutcome.issue.details.coding.code
details.coding.display=OperationOutcome.issue.details.coding.display
details.text = OperationOutcome.issue.details.coding.text

HTTP Status	Scenario Description	severity	code	details.coding.code	details.coding.display	details.text
202 Accepted	The submission payload has passed conformance rules, and put into message queue for further processing. No Operationoutcome is returned.
400 Bad Request	Missing security token	error	required			Missing required security token: PIN
401 Unauthorized	Failed authentication	error	security			Authorization is required for the interaction that was attempted
500 Internal Server Error	API validates the request but cannot return a valid response due to internal issues.	fatal	exception			Internal Error
503 Service Unavailable	Indicates that the services has been temporarily taken down (on purpose)
504 Gateway Timeout	Downstream system(s) did not return timely response	error	timeout