Description


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

Scenario


A patient schedules a visit with their regular health care provider, within their Medical Home, with symptoms including dizziness and an earache. The patient mentions that since they last visited, another clinic noted that they have high blood pressure (hypertension) which is being monitored at home for now. The patient also mentions a suspected penicillin allergy. The health care provider determines that the patient has an external ear infection (otitis externa) and prescribes antibiotics. The health care provider creates a clinical note in their EMR, which may trigger automatic updates, such as updates to the prescription information. The health care provider decides to submit this new information to the network (i.e., Clinical Data Repository) so that it is available for other health care providers 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. For example, HCP receives test results for a Patient and adds the clinical information to the Patient's problem list. 

Pre-conditions

    • Clinical documentation 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 information: 
      • Patient provides, or has previously provided, consent to share their data to the Clinical Data Repository. 

Post-conditions

    • New Patient clinical information recorded/registered in the Clinical Data Repository. 
    • Authorized health care providers have access to view the Patient's clinical information or may receive a notification that new clinical information 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 information via their local Clinical Solution (e.g., EMR))
  • Data Recipient (Clinical Data Repository receiving/storing the Patient's clinical information)

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 information collected and triggers the process to upload the information to the Clinical Data Repository.
  3. Health Care Provider, optionally, reviews and validates the Patient's clinical information prior to sharing/uploading it to the Clinical Data Repository. 
  4. Health Care Provider sends / uploads the Patient's clinical information to the Clinical Data Repository.
  5. Clinical Data Repository applies business rules (e.g. data standardization, privacy, policy, etc.).
    For example:
    1. Validation of Patient Summary data (e.g. Provider identified and eligible to submit clinical information, Patient identified, etc.)
    2. Checks for existing clinical information for same patient/same provider - apply replacement / archiving rules
  6. Clinical Data Repository saves the Patient's clinical information.
    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 information is available for access by authorized Health Care Providers. (Refer to UC-02 Query and Retrieve Document)

 Use Case - Alternate Flow


The following list provides possible alternate flows that may occur within this use case.

  • Step 3: Health Care Provider has the option to bypass an additional review of the clinical information, allowing the Clinical Solution to automatically share/upload the Clinical Information 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 it to the Clinical Data Repository.
  • Step 4: Health Care Provider, after submitting the Patient's clinical information, identifies that there is incorrect or missing information. The HCP will have the option to modify and upload the corrected clinical information to the Clinical Data Repository.
  • Step 4: Health Care Provider, after submitting the Patient's clinical information, 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 information 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 document in the central Clinical Data Repository
2ResponseFHIR API SHALL be capable of returning a response that a new clinical information has been successfully recorded/registered in the central Clinical Data Repository
3ResponseFHIR API SHALL be capable of returning a response that a Patient clinical information could not be recorded/registered in the central Clinical Data Repository (HTTP 400 - Bad Request)
  • No labels