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
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 |