Description
Fetch of references to clinical documentation performed by a Health Care Provider for use at the point of care or by the Patient themselves to obtain a copy of their own personal health information.
This use case allows the requester to review the information describing the document(s) that are available for the Health Care Provider or Patient to consume. This use case is intended to provide the requester with more control over what they fetch (e.g., if they don't want to receive every document in full that meets their criteria).
Fetch is also distinct from UC-02 Query and Retrieve Document because it is predicated on the Data Responder supporting a predefined FHIR Operation that allows a requester to provide more sophisticated input criteria that will impact how the Data Responder executes the request.
Scenario
The following are example scenarios. It is not inclusive of all potential scenarios which may be implemented within Canadian jurisdictions.
1) A Health Care Provider, fetches the references to a patient's existing clinical documents from a particular date range
A patient schedules a visit with a health care provider, outside of their Medical Home, with symptoms including dizziness and an earache. The patient mentions that they have a regular health care provider, within their Medical Home, and experiences high blood pressure (hypertension) which is being monitored at home for now. The health care provider collects information from the patient and, using their Clinical Solution (e.g., EMR), searches the network to locate references to clinical documentation created and shared by another Health Care Provider in the last three years.
The health care provider finds references to two documents for the patient, one from her primary care provider from six months ago, one from a past primary care provider that is three years old. Upon finding these references to clinical document(s) for their patient, the health care provider reviews the information describing the document(s) and decides to retrieve only the latest document from the primary care provider. The health care provider uses the information in support of providing care for this patient.
2) A Health Care Provider, fetches the references to a patient's clinical documents and indicates they would like documents that are generated on-demand
A patient schedules a visit with an urgent care health care provider, outside of their Medical Home, with symptoms including chest congestion and a crackling cough. The patient mentions that they have a regular health care provider, within their Medical Home. The health care provider collects information from the patient and, using their Clinical Solution (e.g., EMR), searches the network to locate references to clinical documentation created and shared by another Health Care Provider in the last three years.
The health care provider indicates that they would also like to receive any references to documents that were created on-demand in response to the health care provider's request.
The health care provider finds references to two documents for the patient, one that was generated on demand from her primary care provider's EMR that contains the most up-to-date information on the patient, and one that was shared following a visit from a specialist that the patient saw for a GI concern 18 months ago. Upon finding two references to clinical document(s) for their patient, the health care provider reviews the information describing the document(s) and decides to retrieve only the latest on-demand document from the primary care provider. The health care provider uses the information in support of providing care for this patient.
3) A Patient or Subject of Care fetches the references to a patient's existing clinical documents
A patient, or their designated caregiver, would like to access their personal health information (PHI) to stay up to date with their medical health information, empowering them to play an active role in their own care.
Triggers, Pre-conditions, Post-conditions
This section describes example triggers, pre-conditions & post-conditions related to the query and retrieval of clinical document(s) from the Clinical Data Repository. It is not inclusive of all potential workflow scenarios which may be implemented within Canadian jurisdictions.
Triggers
Scenario 1 & 2:
Scenario 3:
Pre-conditions
Scenario 1 & 2:
Scenario 2:
Scenario 3:
Post-conditions
Scenario 1 & 2:
Scenario 3:
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.
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.
# | Category | Requirement Description |
---|---|---|
1 | Fetch | FHIR API SHALL be capable of executing the FHIR Operation based on a Patient Resource ID |
2 | Fetch | FHIR API SHOULD be capable of executing the FHIR Operation based on a Patient's identifier (e.g., jurisdictional health number) |
3 | Fetch | FHIR API SHOULD be capable of executing the FHIR Operation based on a specified date range |
5 | Fetch | FHIR API SHOULD be capable of executing the FHIR Operation based on specific a Document Type that the health care provider is interested in retrieving |
6 | Fetch | FHIR API MAY be capable of executing the FHIR Operation based on a specific Document Category (e.g., type of service) that the health care provider is interested in retrieving |
7 | Response | FHIR API SHALL be capable of returning a "searchset" Bundle that includes document references that match the provided parameters |
8 | Response | FHIR API SHALL be capable of returning a "searchset" Bundle that is empty in the case where no document references can be returned based on provided parameters |
9 | Response | FHIR API MAY be capable of returning an OperationOutcome that provides additional details in the response |