Description


Query and retrieval of clinical data 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 (PHI).

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, in any care setting, queries and retrieves a clinical information for use at the point of care

A patient has a visit with an urgent care provider, outside of their Medical Home, with intense redness and mild discharge in her left eye. After collecting information about the patient in their Clinical Solution (e.g., EMR), the health care provider suspects the patient has bacterial conjunctivitis. Before prescribing an optic antibiotic the health care provider wants to ensure they know the full list of potential allergies the patient may have. Using their Clinical Solution, the health care provider searches for clinical data (e.g., searches the network to locate clinical data created and shared by another Health Care Provider) for information on the Patient's active allergies and conditions. Upon finding a clinical data for their patient, the health care provider views and uses the clinical data in support of providing care for this patient.

2) A Patient or Subject of Care accesses/views and can obtain a copy of their own personal health information

A patient, or their designated caregiver, would like to access their clinical data 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 data from the Clinical Data Repository. It is not inclusive of all potential workflow scenarios which may be implemented within Canadian jurisdictions.

Triggers

Scenario 1:

      • Patient visits Health Care Provider for care.

Scenario 2:

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

Pre-conditions

Scenario 1:

      • 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.
      • In jurisdictions where a patient may have applied consent directives to their clinical data, HCP complies with local/jurisdictional privacy policies.

Scenario 2:

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

Post-conditions

Scenario 1:

      • Health Care Provider views and uses the clinical data in support of Patient care.

Scenario 2:

      • Patient, or their designated caregiver,  accessed/viewed, and optionally printed a copy of, their clinical data
      • Patient, or their designated caregiver, presents their clinical data 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 data from the Clinical Data Repository; Patient Portal used by the Patient / Subject of Care to request & retrieve access to their clinical data from the Clinical Data Repository)
    • Data Responder (Health Records System acting as the Clinical Data Repository enabling access and responding with the requested clinical data)

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 data.
  2. Participant requests access (i.e., queries) for clinical data via the clinical solution.
  3. Clinical Data Repository applies applicable business/policy rules (e.g. validates requestors credentials).
  4. Clinical Data Repository prepares and returns the FHIR searchset bundle with corresponding clinical data.
  5. Participant views/uses the clinical data 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 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 data. It is recognized that some jurisdictions may have existing Patient Consent Services implemented and should be considered when implementing in that jurisdiction. 

Use Case - Requirements


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

#CategoryRequirement Description
1QueryFHIR API SHALL be capable of executing searches based on a Patient Resource ID
2QueryFHIR API SHOULD be capable of executing chained searches based on a Patient Identifier (e.g., jurisdictional health number)
3QueryFHIR API SHALL be capable of executing searches as they are defined in the CA:FeX Server Capability Statement
4QueryFHIR API SHALL be capable of accepting requests originating from a patient portal or any other system that allows a patient to initiate a request to access their personal health information (PHI)
5ResponseFHIR API SHALL be capable of responding to requests for retrieval of clinical data for requests initiated by patient to access their PHI
  • No labels