For a full list of available versions, see the Directory of published versions

4.1.1. Interaction: Submit MI Bundle

4.1.1.1. Submit MI Bundle

The MI bundle submission operation is based on FHIR transaction paradigm using HTTP asynchronous interaction to support batch process from the sending system. Each Bundle in a transaction must include one or more ServiceRequest, DiagnosticReport, and 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]/Bundle{?_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. In most casess, this should be a PUT command with business identifiers of the associated resource to support conditional update. The FHIR server will use the business identifier to determine if the resource will be created or updated if it already exists. If multiple matches are found, no action shall be performed and the bundle will be rejected.

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.

4.1.1.1.1. 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 submitting a bundle in a transaction, a resource SHALL not include the "id" for the logical ID. The logical ID will be assigned by the FHIR server. To maintain referential integrity, a reference must be specified as follows:

• Each resource SHALL contain a fullUrl field whose value is a GUID in the format of "urn:uuid:[guid]"

• A resource SHALL reference another resource using the same GUID value matching the fullUrl of the resource being referenced.

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

4.1.1.2. Interaction Diagram

Actor: miCDR FHIR Contributor

Role: Submits MI data in a FHIR transaction bundle the miCDR FHIR server.

Actor: miCDR FHIR server

Role: Returns HTTP 202 (Acknowledgement) to contributor. FHIR server will perform validation and return applicable responses at a later time.

4.1.1.3. Specification

This operation is based on FHIR R4 transaction.

Submit FHIR Bundle Interaction

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

4.1.1.4. MI Transaction Bundle Resources

TBD

4.1.1.5. MI Transaction Bundle Submission Example

Transaction Bundle Example

4.1.1.6. 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	error	timeout