visit the hl7 website
Ontario Medical Imaging HL7® FHIR® Implementation Guide v1.0.0-Ballot
fhir-logo
  • Index
  • Home
    • Home
    • Introduction
    • Relationship to Other Specifications
    • Scope
    • Glossary
  • Business Context
    • Business Context
    • Business Model
    • Business Data
    • Use Cases
    • Business Rules
  • Technical Context
    • Technical Context
    • Implementer Responsibility
    • Conformance Rules
    • Connectivity Summary
  • FHIR Artifacts
    • FHIR Artifacts
    • Interactions
    • Profiles
    • Extensions
    • Terminology
    • System URIs
    • Examples
    • Capability Statement
    • Response Handling
    • Downloads
  • Change Log
    • Change Log
    • Known Issues & Future Developments
    • Revision History
    1. Index
    2. FHIR Artifacts
    3. Interactions
    4. Interaction: Submit MI Report

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

4.1.3. Interaction: Submit MI Report

The Submit MI Report interaction is based on RESTful HTTP interaction using FHIR transaction bundle. Each transaction bundle 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.

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

4.1.3.0.2. Transaction Response

In an HTTP synchronous interaction, API client submits a contribution payload, miCDR validates the payload and returns an appropriate response to the data contributor depending on the validation outcome.

4.1.3.1. Interaction Diagram

Actor: miCDR DiagnosticReport Contributor

Role: Submits a DiagnosticReport resource and other referenced resources to the miCDR FHIR server.

Actor: miCDR FHIR server

Role: Performs validation of the submission payload and returns HTTP acknowledgement and applicable FHIR OperationOutcome depending on the validation outcome.

4.1.3.2. Specification

This interaction is based on FHIR R4 transaction bundle.

Submit MI Report Interaction

POST [base]/Bundle

4.1.3.3. MI Report Submission Resources

submit-DiagnosticReport-bundle

4.1.3.4. MI Report Submission Example

Transaction Bundle Example

4.1.3.5. 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
200 OK The submission payload has passed conformance rules, and records are stored in miCDR
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
422 Unprocessable Entity The submitted transaction Bundle cannot be validated as it does not conform to the specification error varies (e.g. invalid) varies varies
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
Version: v1.0.0-ballot FHIR Version: R4.0.1

Powered by SIMPLIFIER.NET

HL7® and FHIR® are the registered trademarks of Health Level Seven International