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

Below provides guidance on how to read the sequence diagram:  

• This sequence diagram 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 Use Case 5 of the Patient Summary-CA 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, if present, describe important call outs, information and notes that provide more context for the sequence diagram. 
• This sequence diagram includes the CA:SHL Interoperability Specifications. Additional details will be included in the PS-CA Interoperability Specifications.
• For more information on core IHE Profiles and specific Canadian implementation guidance, refer to the Reference Architecture.