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:

      • Patient visits Health Care Provider for care.

Scenario 3: 

      • Patient, or their designated caregiver, chooses to view personal health information to stay informed of their medical information. 
      • Patient wants to obtain a copy of their personal health information to have on their person while travelling.
      • Patient wants to obtain a copy of their personal health information to share with another care provider.

Pre-conditions

Scenario 1 & 2:

      • Health Care Provider is logged in to their Clinical Solution (e.g., EMR).
      • Health Care Provider's Clinical Solution is connected / part of the Clinical Data Repository network
      • Health Care Provider's Clinical Solution knows the Resource ID of the patient from the Clinical Data Repository or Repository network or is requesting from a system that supports the optional use of a patient's identifier (system and value) to perform the FHIR Operation
      • In jurisdictions where a patient may have applied consent directives to their clinical information, HCP complies with local/jurisdictional privacy policies.

Scenario 2:

      • An EMR on the network has configured their system to support creation of the document on-demand 

Scenario 3:

      • A jurisdictional clinical system with patient access is available. 
      • If applicable, patient has designated and authorized a designated caregiver to access their personal health record on their behalf.

Post-conditions

Scenario 1 & 2:

      • Health Care Provider views the references to the clinical document(s) and decides which ones to retrieve in support of patient care.
      • Health Care Provider performs the Retrieve a Document transaction to retrieve the desired clinical document(s).
      • Health Care Provider views the desired documents in support of patient care.

Scenario 3:

      • Patient, or their designated caregiver, views the references to clinical document(s).
      • Patient performs the Retrieve a Document transaction to retrieve the desired clinical document(s).
      • Patient views the desired document(s), and optionally prints a copy of their personal health information.
      • Patient, or their designated caregiver, presents their personal health information to another health care provider to support continuity of care.

Use Case Participants & Diagram


The participants involved in this use case are:

    • Data Consumer (Clinical Solution, e.g., EMR used by the Health Care Provider to request & retrieve access to clinical document(s) from the Clinical Data Repository; Patient Portal used by the Patient / Subject of Care to request & retrieve access to their clinical document(s) from the Clinical Data Repository)
    • Data Responder (Health Records System acting as the Clinical Data Repository enabling access and responding with the requested clinical document(s))

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. Participant (i.e., Health Care Provider or Patient / Subject of Care) determines need to view clinical information.
  2. Participant fetches references for clinical information via the clinical solution, providing criteria (if needed) to narrow the clinical document references that are returned.
  3. Clinical Data Repository applies applicable business/policy rules (e.g. validates requestors credentials).
  4. Clinical Data Repository prepares and returns the references to the available clinical document(s) that correspond to the request criteria.
  5. Participant uses the information in the document references to identify the clinical document(s) they would like to retrieve.
  6. Participant retrieves the desired document(s) in support of care for the Patient or themselves.

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 2: Participant identifies that they would like to additionally receive references to documents that are generated on-demand in response to the fetch request
  • Step 3: Patient Consent Services are not currently supported in the CA:FeX specifications. However, Patient consent is considered as a roadmap item and would be represented in a separate use case at that time where a Patient has identified consent directives requiring the Health Care Provider to address prior to accessing the Patient's clinical information. It is recognized that some jurisdictions may have existing Patient Consent Services implemented and should be considered when implementing in that jurisdiction. 
  • Step 4: Clinical Data Repository generates document references that meet request criteria.


Use Case - Requirements


The following is a list of key requirements that will be addressed as part of this use case. 

#CategoryRequirement Description
1FetchFHIR API SHALL be capable of executing the FHIR Operation based on a Patient Resource ID
2FetchFHIR API SHOULD be capable of executing the FHIR Operation based on a Patient's identifier (e.g., jurisdictional health number)
3FetchFHIR API SHOULD be capable of executing the FHIR Operation based on a specified date range
5FetchFHIR API SHOULD be capable of executing the FHIR Operation based on specific a Document Type that the health care provider is interested in retrieving
6FetchFHIR 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
7ResponseFHIR API SHALL be capable of returning a "searchset" Bundle that includes document references that match the provided parameters
8ResponseFHIR 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
9ResponseFHIR API MAY be capable of returning an OperationOutcome that provides additional details in the response 
  • No labels