Description


Query and retrieval of 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.

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 document for use at the point of care

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 for clinical information (e.g., searches the network to locate clinical documentation created and shared by another Health Care Provider). Upon finding a clinical document(s) for their patient, the health care provider views and uses the information 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 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:

      • Patient visits Health Care Provider for care.
      • Where applicable, HCP received a notification that new clinical information is available for the Patient to which they have subscribed to receive notifications.

Scenario 2:

      • 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:

      • 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.

Scenario 2:

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

      • Health Care Provider views and uses the clinical document(s) in support of Patient care.

Scenario 2:

      • Patient, or their designated caregiver,  accessed/viewed, and optionally printed 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 requests access (i.e., queries) for clinical information 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 bundle with corresponding clinical document(s).
  5. Participant views/uses the clinical 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 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. 

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 SHALL be capable of executing chained searches based on a Patient Identifier
3QueryFHIR API SHALL be capable of executing searches as they are defined in the CA:FeX Server Capability Statement
5QueryFHIR 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)
6ResponseFHIR API SHALL be capable of responding to requests for retrieval of clinical information for requests initiated by patient to access their PHI
  • No labels