Profiles & Operations Index > Operation: Submit MI Report

Operation: Submit MI Report

Submit MI Report

The MI order submission operation is based on FHIR transaction paradigm using HTTP asynchronous interaction. Each Bundle in a transaction must include an DiagnosticReport 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 DiagnosticReport Contributor

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

Actor: miCDR FHIR server

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

Specification

This operation is based on FHIR R4 transaction.

Submit MI Report Operation

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

MI Report Submission Resources

MI Report Submission Example

Transaction Bundle Example

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