The section below provides guidance on how to read the sequence diagrams:

• The sequence diagrams illustrates how the different standardized actors of systems should interact with each other to carry out specific standardized transactions, and the order in which the transactions and interactions occur when a PS-CA use case is executed.
• The legend on the bottom right corner describes the different system components, actors and transactions that are necessary to carry out this particular use case.
• The green swim lane is a simplified view of the actors and transactions required by the Foundational Profiles, defined here, in addition to the other ones that are not explicitly illustrated on the diagram (e.g. ATNA, CT) but included as a white note. These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied.
• The blue swim lanes groups sequence of processes (along with their required actors and transactions) that are needed to occur to satisfy this particular use case. These are to be read from left to right and top to bottom.
• The red note boxes describe important call outs, information and notes that provide more context for the sequence diagram.
• For more information on core IHE Profiles and specific Canadian implementation guidance, refer to Reference Architecture.

UC-01: HCP Creates a PS-CA

A Health Care Provider in any care setting creates/produces a PS-CA for use at point of care, including for unscheduled/scheduled local care, which is made available to PS-Consumers.

Implementation Option 1: MHD

Scenario / Assumption(s): Patient Summary-CA is stored in Central or Local (Decentralized) Document Repository

Release 1: Clinical data (e.g. medication, lab results, immunization) is retrieved from local sources only

Implementation Option 1: This sequence diagram provides the option of using the MHD IHE profile, including a Document Repository actor and supporting HL7 FHIR standards.

Implementation Option 2: CA:FeX

Scenario: Clinical Solution A Retrieves Patient Summary-CA from Central Document Repository

Assumption: Patient Summary-CA is stored in Central Document Repository

Implementation Option 2: This sequence diagram provides the option of using the CA:FeX Interoperability Specifications that provide support for saving and retrieving a Patient Summary-CA to and from a central Document Repository. This profile includes a Data Source and a Data Recipient actor. Additionally, this sequence diagram uses the 'Submit Data' FHIR operation.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.

Sequence Diagram

UC-02: HCP Views/Consumes a PS-CA

A Health Care Provider in any care setting requests and uses a PS-CA at the point of care, including for unscheduled/scheduled local care.

Implementation Option 1: MHD

Scenario: Clinical Solution A Retrieves Patient Summary-CA from MHD Document Registry – (MHD* IHE Profile).

Assumption: Patient Summary-CA is stored in Central or Local (Decentralized) Document Repository.

Implementation Option 1: This sequence diagram provides the option of using the MHD IHE profile, including a Document Repository actor and supporting HL7 FHIR standards.

Note: Additionally, this sequence diagram include the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc). Additional details will be included in the PS-CA Interoperability Specifications.

Sequence Diagram:

Implementation Option 2: CA:FeX

Scenario: Clinical Solution A Retrieves Patient Summary-CA from Central Document Repository

Assumption: Patient Summary-CA is stored in Central Document Repository

Implementation Option 2: This sequence diagram provides the option of using the CA:FeX Interoperability Specifications that provide support for saving and retrieving a Patient Summary-CA to and from a Document Repository (Local to PS-Producer or Central). This profile includes a Data Consumer and a Data Responder actor. Additionally, this sequence diagram uses the 'Search Data' and 'Retrieve Data' FHIR operations.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.

Sequence Diagram

UC-03: Patient Views/Obtains Personal PS-CA

A Patient or Subject of Care accesses/views and can retrieve a copy of their own PS-CA to support unscheduled/scheduled local care, or for any other purpose.

Implementation Option 1: MHD

Scenario: Patient Portal Retrieves PS from MHD Document Registry – (MHD* IHE Profile).

Assumption: Patient Summary-CA is stored in Central or Local (Decentralized) Document Repository.

Implementation Option 1: This sequence diagram provides the option of using the MHD IHE profile, including a Document Repository actor and supporting HL7 FHIR standards.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). The Document Repository in this scenario can be either (1) central or (2) at PS-CA Producer (the source where the document was produced). The Document Consumer actor would query the appropriate repository.

Sequence Diagram

Implementation Option 2: CA:FeX

Scenario: Clinical Solution A Retrieves Patient Summary-CA from Central Document Repository

Assumption: Patient Summary-CA is stored in Central Document Repository

Implementation Option 2: This sequence diagram provides the option of using the CA:FeX Interoperability Specifications that provide support for saving and retrieving a Patient Summary-CA to and from a Document Repository (Local to PS-Producer or Central). This profile includes a Data Consumer and a Data Responder actor. Additionally, this sequence diagram uses the 'Search Data' and 'Retrieve Data' FHIR operations.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.

Sequence Diagram

UC-04: HCP Requests PS-CA On-Demand

A Health Care Provider in any care setting requests and uses a PS-CA on-demand at the point of care, including for unscheduled/scheduled local care.

Implementation Option 1: CA:FeX $summary operation

This option is recommended for systems where the clinical data needed to generate the Patient Summary is internal to the Clinical Data Repository.

Note that generally with $summary operation, servers may choose not to produce “fresh” patient summaries on every request. Due to performance impacts, servers may choose to generate Patient Summaries on a nightly or cached basis, and return those.

Implementation Option 2: CA:FeX $docref operation

This option is recommended for systems where the clinical data needed to generate the Patient Summary is either external to the Clinical Data Repository generating the summary, or distributed across various internal and external data sources.

Implementation Option 1: CA:FeX $summary

Scenario: Clinical Solution A Requests Patient Summary-CA On Demand from Clinical Data Repository

Assumption: Clinical data used to generate the Patient Summary is retrieved from sources internal to the Clinical Data Repository

Implementation Option : This sequence diagram provides the option of using the CA:FeX Interoperability Specifications that provide support for requesting a Patient Summary-CA on demand from a Clinical Data Repository (Local to PS-Producer or Central). This profile includes a Data Consumer and a Data Responder actor. Additionally, this sequence diagram uses the 'Retrieve Patient Summary' CA:FeX-3D transaction which is based on IPS Summary ($summary).

This implementation option is suitable for systems where the discrete FHIR resources needed to generate the Patient Summary are internal to the Clinical Data Repository where the Patient Summary is generated.

Note that generally with $summary operation, servers may choose not to produce “fresh” patient summaries on every request. Due to performance impacts, servers may choose to generate Patient Summaries on a nightly or cached basis, and return those.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.).

Sequence Diagram

Implementation Option 2: CA:FeX $docref

Scenario: Clinical Solution A Requests Patient Summary-CA On Demand from Clinical Data Repository

Assumption: Clinical data used to generate the Patient Summary is retrieved from sources that are internal and/or external to the Clinical Data Repository

Implementation Option 2 : This sequence diagram provides the option of using the CA:FeX Interoperability Specifications that provide support for requesting a Patient Summary-CA on demand from a Clinical Data Repository (Local to PS-Producer or Central). This profile includes a Data Consumer and a Data Responder actor. Additionally, this sequence diagram uses the 'Fetch DocumentReference' CA:FeX-2B transaction which is based on $docRef

This implementation option is suitable for systems where the discrete FHIR resources needed to generate the Patient Summary are either external to the Clinical Data Repository generating the summary, or distributed across various internal and external data sources.

The on-demand Patient Summary generation occurs in two steps and involves asynchronous processing when data retrieval has longer response times, which is typically the case for external data sources. In the first step, a DocumentReference resource is created, that contains the location where the Patient Summary document is or will be available. The retrieval of the discrete FHIR resources needed to assemble the Patient Summary document is an asynchronous operation. In the second step, the on-demand Patient Summary document is retrieved once the assembly of the discrete FHIR resources is complete.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.

Sequence Diagram

UC-05: Patient Mediated Access and Exchange of their Patient Summary

This use case describes the process of accessing and sharing a Patient Summary using a Shareable Health Link (SHL) and QR code. It is split into two distinct parts (Part A: Patient Requests Access to Their Shareable Patient Summary and Part B: Patient presents their QR code or SHL to HCP for access to their Patient Summary), offering a complete overview of the workflow from the creation of the shareable Patient Summary to its use by Health Care Providers (HCP).

UC-05A: Generate SHLink for Patient Summary

Scenario: Patient-facing application (Mobile App, Patient Portal, or proprietary Patient Viewer Application) requests access to a shareable copy of their Patient Summary in SHLink format.

Assumption: The Patient Summary either exists or is generated on demand. This step occurs prior and is transparent to the SHLink generation.

Implementation Option : This sequence diagram demonstrates one approach using the CA:SHL Interoperability Specifications which define support for requesting the generation of a Shareable Health Link (SHLink) for a PS-CA from a Clinical Data Repository. In this example, the actors SHLink Requester and SHLink Creator participate in the CA:SHL-1 Generate SHLink transaction. The retrieval of the PS-CA supports multiple interoperability standards. This diagram illustrates the use of CA:FeX(Canadian FHIR Exchange), which includes three options for retrieving the Patient Summary:

Option A: Retrieve a document Bundle Option B: Retrieve a DocumentReference and then fetch the document Option D: Retrieve a Summary resource directly

Other standards, such as MHD (Mobile access to Health Documents), may also be used to retrieve the PS-CA in other implementations. The diagram is agnostic to the specific retrieval mechanism and is intended to illustrate the sequence when CA:FeX is used.

Once the PS-CA is retrieved, it is encrypted, stored securely, and an SHLink is generated. This SHLink may include a viewer URL and is often transformed into a QR code that the patient can download and save to their phone or other media.

Sequence Diagram

UC-05B: Consume SHLink and Access Patient Summary

Scenario: Clinical Solution A decodes SHLink and Retrieves Patient Summary from Document Repository.

Assumption: The Patient Summary is encrypted and either pre-prepared and stored in a secure location, or made available when the SHLink is accessed and the data is requested. As a prerequisite, the patient shares the passcode with the HCP to allow accessing the Patient Summary associated with the SHLink. Typically the HCP is authenticated in their clinical system such as an EMR or HIS.

Implementation Option : This sequence diagram provides the option of using the CA:SHL Interoperability Specifications that provide support for consuming a Shareable Health Link associated with a Patient Summary. This profile includes an SHLink Consumer and an SHLink Responder actor. Additionally, this sequence diagram uses the 'CA:SHL Retrieve SHLink Manifest' CA:SHL-2 transaction to retrieve the manifest file and 'CA:SHL Retrieve SHLink Clinical Data' CA:SHL-3 transaction to retrieve the Patient Summary document. The client-side consumer application has the capability of scanning QR codes, interpreting SHLinks and access encrypted data. The SHLink optionally contains a viewer URL that is recognizable by a browser and can display relevant information. A viewer might have the capability to consume the SHLink and display the Patient Summary, if the client application does not have the necessary capabilities. The location where the Patient Summary is available for access must be short-lived and and potentially limited to one-time use.

Sequence Diagram