Reference Architecture

Guidance has been developed to help implementers to support the necessary capabilities to enable secure exchange of FHIR resources over the internet. This guidance has been developed following the same approach as the exchange profiles, and highlights any recommended IHE candidate profiles and pan-Canadian Interoperability Specifications that can meet specific needs of the PS-CA project.

The reference architecture guidance is available here

Exchanging Patient Summaries

Within the Reference Architecture, there are two implementation patterns currently defined for exchanging Canadian Patient Summaries, with option 1 having two scenarios.

• Option 1 - Document Repository/Registry Pattern Using MHD Profile
  • Option 1, Scenario #1: MHD implementation, where the Document Repository is Central
  • Option 1, Scenario #2: MHD implementation, where the Document Repository is Local

This option is recommended for jurisdictions who would like to use document repository/registry patterns and promote HL7 FHIR standards for the creation and viewing of a Patient Summary-CA.

• Option 2 - FHIR Health Information Exchange (HIE) Pattern Using CA:FeX

This option is recommended for jurisdictions who would like to use FHIR health information exchange (HIE) patterns that provide support for submitting, searching and retrieving a Patient-Summary-CA to and from a central Document Repository using FHIR resources.

Additional Considerations

• The sequence diagrams included in this section do not showcase all of the possible combinations of IHE profiles and transactions that can be used for a particular implementation pattern. For example, ITI-83 transaction can be used in place of ITI-78 if the preferred implementation pattern is PIXm/PMIR.
• Additionally, a jurisdictional implementation may choose to present a different version of the Patient Summary to patients than providers. For example, the patient version of the Patient Summary may use more patient friendly language, certain information that might lead to patient harm may be redacted (for example, in the case of patients undergoing behavioral health treatment).

The transactions patterns presented above represent initial options to the patient summary use case; and are expected to evolve as we hear from the implementer community, and use cases are refined and added. We encourage the community to provide feedback on these emerging specifications.