Description


A Health Care Provider, in any care setting, adds Patient clinical documentation 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) in the form of a clinical document (e.g., patient summary) 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 documents 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 information collected in the form of a document and triggers the process to upload the document to the Clinical Data Repository.
  3. Health Care Provider, optionally, reviews and validates the Patient's clinical documentation prior to sharing/uploading it to the Clinical Data Repository. 
  4. Health Care Provider sends / uploads the Patient's clinical documentation 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 documentation, Patient identified, etc.)
    2. Checks for existing clinical documentation for same patient/same provider - apply replacement / archiving rules
  6. Clinical Data Repository saves the Patient's clinical documentation.
    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 documentation 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 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 document in the central Clinical Data Repository
2ResponseFHIR API SHALL be capable of returning a response that a new clinical documentation has been successfully recorded/registered in the central Clinical Data Repository
3ResponseFHIR API SHALL be capable of returning a response that a Patient clinical documentation could not be recorded/registered in the central Clinical Data Repository (HTTP 400 - Bad Request)