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

    • Health Care Provider provides care to a patient and adds clinical information to the Patient's record.
    • Health Care Provider receives additional information for a patient that they wish to share with other HCPs. 

Pre-conditions

    • Clinical data shall uniquely identify the Patient so that it can be uploaded to the Clinical Data Repository and available to other HCPs (e.g., uniquely identified by a Client Registry ID)
    • 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 clinical data recorded/registered in the Clinical Data Repository. 
    • Authorized health care providers have access to view the Patient's clinical data or may 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 (Health Care Provider adding patient clinical data via their local Clinical Solution (e.g., EMR))
  • Data Recipient (Clinical Data Repository receiving/storing the Patient's clinical data)

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.

  • Step 3: Health Care Provider has the option to bypass an additional review of the clinical information, allowing the Clinical Solution to automatically submit/upload the clinical data to the Clinical Data Repository.
  • Step 3: Health Care Provider, upon review of the clinical information, chooses to make changes within the local Patient's health record prior to uploading the clinical data to the Clinical Data Repository.
  • Step 4: Health Care Provider, after submitting the Patient's clinical data, identifies that there is incorrect or missing information. The HCP will have the option to modify and upload the corrected clinical data to the Clinical Data Repository.
  • Step 4: Health Care Provider, after submitting the Patient's clinical data, identifies that incorrect information has been uploaded (e.g., information is for the wrong patient). The HCP will have the option to retract / delete the data from the Clinical Data Repository.

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)
  • No labels