Description


A Health Care Provider, in any care setting, adds Patient clinical data for use at point of care, which is made available to other authorized HCPs.

Scenario


A middle-aged patient schedules their yearly physical with their regular health care provider, within their Medical Home. As part of their physical, the patient undergoes routine blood tests (e.g., Hemoglobin A1C, Standard Lipid Panel). The A1C test results show above normal levels (6.0%).  During the encounter with the patient, the health care provider adds Prediabetes on the Patient's problem list in the EMR. Upon saving a new problem to the patient's record, a prompted or automatic trigger occurs in the background to update the provincial clinical data repository so that the patient's new condition is available for other health care providers to view who may be providing care for this patient.

Triggers, Pre-conditions, Post-Conditions


This section describes example triggers, pre-conditions & post-conditions related to uploading new clinical information to the Clinical Data Repository. It is not inclusive of all potential workflow scenarios which may be implemented within Canadian jurisdictions.

Triggers

Pre-conditions

Post-conditions

Use Case Participants & Diagram


The participants involved in this use case are:

This use case diagram represents the participants and their role in the use case with a high-level view of the flow of information.


Use Case - Primary Flow


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

  1. Health Care Provider treats Patient and adds clinical information to the Patient's health record in their local Clinical Solution (e.g., EMR, HIS).
  2. Health Care Provider decides to share the new clinical data collected and triggers the process to upload the data to the Clinical Data Repository.
  3. Health Care Provider, optionally, reviews and validates the Patient's clinical data prior to sharing/uploading it to the Clinical Data Repository. 
  4. Health Care Provider sends / uploads the Patient's clinical data to the Clinical Data Repository.
  5. Clinical Data Repository applies business rules (e.g. data standardization, privacy, policy, etc.).
  6. Clinical Data Repository saves the Patient's clinical data.
    1. Clinical Data Repository responds to the submitting system to indicate that the submission was accepted (i.e., recorded/registered) or it was a bad request.
  7. Patient's clinical data is available for access by authorized Health Care Providers. (Refer to UC-04 Query and Retrieve Document)

 Use Case - Alternate Flow


The following list provides possible alternate flows that may occur within this use case but are currently considered out of scope for the defined transactions in this release. Reviewers are encouraged to provide feedback on the prioritization of these alternate flows for future releases.

Use Case - Requirements


The following is a list of key requirements that will be addressed as part of this use case. 

#CategoryRequirement Description
1WriteFHIR API SHALL be capable of accepting write operations to allow creation of new clinical data (e.g., FHIR Resources) in the central Clinical Data Repository
2ResponseFHIR API SHALL be capable of returning a response that a new clinical data has been successfully recorded/registered in the central Clinical Data Repository
3ResponseFHIR API SHALL be capable of returning a response that a Patient clinical data could not be recorded/registered in the central Clinical Data Repository (HTTP 400 - Bad Request)