Visit the HL7 website
Visit the FHIR website

Pan-Canadian FHIR Exchange (CA:FeX) IGuide 2.2.0 DFT-Ballot

2.2.0-DFT-Ballot   Canada flag
  • Home
  • Business Context
    • Project Background
    • Scope
    • Relationship to Other Specifications
    • Use Cases
  • Technical Context
    • Overview
    • FHIR Exchange Paradigms
    • Sequence Diagrams
    • Actor Mapping to Interoperability Specification
    • Security
  • Actor and Conformance Options
    • Technical Actors
    • Actor Options
    • Conformance Requirements
  • FHIR Artifacts
    • Profiles and Extensions
    • Search Parameters
    • Operations
    • Capability Statements
  • Change Log
    • Change Log
    1. Home
    2. Business Context
    3. Use Cases
    4. UC-03 Create and Submit Data

DFT Ballot - This specification is currently in ballot review and subject to change. It is not ready for limited roll-out or production level use. For a full list of available versions, see the Directory of published versions

UC-03 Create and Submit Data

Description

A Health Care Provider records structured clinical data during a care encounter and submits it to the Clinical Data Repository, making it available to other authorized providers.

Scenario

A middle-aged patient attends their annual physical with their regular health care provider in their Medical Home. As part of the visit, the patient undergoes routine blood work, including a Hemoglobin A1C and a lipid panel. The A1C result is 6.0%, indicating prediabetes. During the encounter, the provider adds "Prediabetes" to the patient’s problem list in the EMR. Saving the new condition triggers an automated background process that updates the provincial Clinical Data Repository, making the information available to other authorized providers involved in the patient’s care.

Triggers, Pre-conditions, Post-Conditions

This section outlines example triggers, preconditions, and postconditions related to submitting new clinical information to the Clinical Data Repository. These examples are illustrative and do not capture all possible workflow scenarios across Canadian jurisdictions.

Triggers

  • A Health Care Provider documents new clinical information in the patient’s record during a care encounter.
  • A Health Care Provider receives new clinical information for a patient and initiates its submission to the Clinical Data Repository for availability to other authorized providers.

Pre-conditions

  • The clinical data includes a unique patient identifier (e.g., Client Registry ID) to enable submission to the Clinical Data Repository and retrieval by other authorized providers.
  • In jurisdictions where explicit consent is required to share Patient clinical data:
    • Patient provides, or has previously provided, consent to share their data to the Clinical Data Repository.

Post-conditions

  • New Patient data is recorded/registered in the Clinical Data Repository.
  • Authorized health care providers have access to view the Patient's clinical data or receive a notification that new clinical data about the patient is available.

Use Case Participants & Diagram

The participants involved in this use case are:

  • Data Source: A Health Care Provider’s clinical system (e.g., EMR) that contributes patient clinical documentation to the Clinical Data Repository.
  • Data Recipient: The Clinical Data Repository that receives and stores clinical documentation submitted by Health Care Providers.

This diagram illustrates the participants, their roles, and the flow of information within the use case.

CAFEX_UC-03

Use Case – Primary Flow

The following provides a textual description corresponding to the use case diagram:

  1. The Health Care Provider delivers care and documents new clinical data in the patient's health record using a local clinical system (e.g., EMR, HIS).
  2. The Health Care Provider initiates the process to submit the newly recorded clinical data to the Clinical Data Repository.
  3. Optionally, the Health Care Provider reviews and confirms the clinical data before submission.
  4. The clinical system submits the clinical data to the Clinical Data Repository.
  5. The Clinical Data Repository enforces applicable business rules (e.g., data standardization, privacy, and policy compliance).
  6. The Clinical Data Repository stores the clinical data, making it available for authorized retrieval.
  7. The Clinical Data Repository returns a response to the submitting system indicating success (e.g., data recorded and registered) or failure (e.g., invalid submission).
  8. The submitted clinical data becomes available for retrieval by authorized Health Care Providers. See UC-04 Query and Retrieve Data.

Use Case – Alternate Flow

The following alternate flows are out of scope for this release but may be prioritized in future iterations based on stakeholder feedback.

  • Step 3: Health Care Provider bypasses manual review, enabling the Clinical Solution to automatically submit the clinical data to the Clinical Data Repository.
  • Step 3: After reviewing the clinical data, the Health Care Provider updates the patient’s record before initiating submission to the Clinical Data Repository.
  • Step 4: After submitting the clinical data, the Health Care Provider identifies errors or omissions and resubmits a corrected version to the Clinical Data Repository.
  • Step 4: After submission, the Health Care Provider identifies that incorrect data was submitted (e.g., for the wrong patient) and initiates a retraction or deletion request, if supported by the Clinical Data Repository.

Table of Contents | IG © based on FHIR R4 | Package package:ca.infoway.io.cafex@2.2.0-DFT-Ballot | Version History
HL7® and FHIR® are the registered trademarks of Health Level Seven International