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
- 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 documentation:
- Patient provides, or has previously provided, consent to share their data to the Clinical Data Repository.
Post-conditions
- New Patient clinical documentation recorded/registered in the Clinical Data Repository.
- Authorized health care providers have access to view the Patient's clinical documentation or may receive a notification that new clinical documentation 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 documentation via their local Clinical Solution (e.g., EMR))
- Data Recipient (Clinical Data Repository receiving/storing the Patient's clinical documentation)
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.
- Health Care Provider treats Patient and adds clinical information to the Patient's health record in their local Clinical Solution (e.g., EMR, HIS).
- 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.
- Health Care Provider, optionally, reviews and validates the Patient's clinical documentation prior to sharing/uploading it to the Clinical Data Repository.
- Health Care Provider sends / uploads the Patient's clinical documentation to the Clinical Data Repository.
- Clinical Data Repository applies business rules (e.g. data standardization, privacy, policy, etc.).
For example:- Validation of Patient Summary data (e.g. Provider identified and eligible to submit clinical documentation, Patient identified, etc.)
- Checks for existing clinical documentation for same patient/same provider - apply replacement / archiving rules
- Clinical Data Repository saves the Patient's clinical documentation.
- 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.
- 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.
- Step 3: Health Care Provider has the option to bypass an additional review of the clinical documentation, allowing the Clinical Solution to automatically share/upload the clinical documentation to the Clinical Data Repository.
- Step 3: Health Care Provider, upon review of the clinical documentation, 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 documentation, identifies that there is incorrect or missing information. The HCP will have the option to modify and upload the corrected clinical documentation to the Clinical Data Repository.
- Step 4: Health Care Provider, after submitting the Patient's clinical documentation, 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 documentation 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.
# | Category | Requirement Description |
---|---|---|
1 | Write | FHIR API SHALL be capable of accepting write operations to allow creation of new clinical document in the central Clinical Data Repository |
2 | Response | FHIR API SHALL be capable of returning a response that a new clinical documentation has been successfully recorded/registered in the central Clinical Data Repository |
3 | Response | FHIR 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) |