Appendix A describes baseline information on the recommended IHE profiles and pan Canadian Interoperability Specifications, with links to the IHE source documentation where stakeholders can get additional details on each PS-CA actor and transaction.

Published Versions 

The following describes the published versions in scope for the required and optional IHE Profiles that have been referenced in this PS-CA Specification:

  • MHD:  v4.0.2: Trial Implementation v4.0.2 based on FHIR R4
  • IUA:  Revision 2.1 - Trial Implementation
  • PDQm:  v2.3.0: Trial Implementation) based on FHIR R4
  • PMIR:  Revision 1.3 – Trial Implementation 
  • SVCM: Revision 1.2: Trial Implementation based on FHIR R4
  • XDM: Revision 18.0, July 30, 2021 – Final Text

*Note: There will be a process in place to monitor changes in the current versions of the IHE profiles which will be incorporated in future versions of the PS-CA specification based on our interoperability roadmap.

MHD Profile Overview 


Introduction

The Mobile Access to Health Documents (MHD) Profile defines one standardized interface to health document sharing. This profile is applicable to systems where needs are simple, such as pulling the latest summary for display.

Benefits of MHD

  • The Mobile access to Health Documents (MHD) Profile defines one standardized interface to health document sharing (a.k.a. an Application Programming Interface (API)) for use by mobile devices so that deployment of mobile applications is more consistent and reusable.
  • The MHD Profile is not limited to mobile devices. The term “mobile” is used only as a grouping for mobile applications, mobile devices or any other systems that are resource and platform-constrained, which were early use cases for FHIR-based solutions.
  • The critical aspects of the “mobile device” are that it is resource-constrained, has a simple programming environment (e.g., JSON, JavaScript), simple protocol stack (e.g., HTTP), and simple display functionality (e.g., HTML browser) with a goal to avoid burdening the client with additional libraries such as those that are necessary to process SOAP, WSSE, MIME-Multipart, MTOM/XOP, ebRIM, and multi-depth XML.
  • The MHD Profile can be used as an API to a Document Sharing exchange using XDS (Cross-enterprise Document Sharing) or XCA (Cross-Community Access). The MHD Profile is used by the MHDS (Mobile Health Document Sharing) solution. The MHD Profile can be used in push solutions alone or as an API to solutions like XDR (Cross-enterprise Document Reliable Interchange) or XDM (Cross-enterprise Document Media Interchange). 

Scenarios for MHD Implementation 

The following are examples of environments which may choose the MHD Profile:

  • Medical devices such as those targeted by the IHE Patient Care Devices (PCD) domain or Continua organization, submitting data in the form of documents.
  • Kiosks used by patients in hospital registration departments, where it is anticipated that a hospital staff member will review, edit, and approve the document before it is allowed into the hospital system.
  • PHR publishing into a staging area for subsequent import into an EHR or HIE.
  • Patient or provider application that is configured to securely connect to a PHR in order to submit a medical history document. (For example BlueButton+)
  • Electronic measurement device participating in an XDW (IHE Cross-enterprise Document Workflow) workflow and pulling medical history documents from an HIE.
  • A General Practitioner physician’s office with minimal IT capabilities using a mobile application to connect to an HIE or EHR.

Actor & Transaction Diagram of MHD

CA:FeX Interoperabilty Specifications


Introduction 

The CA:FeX Interoperability Specififcations for FHIR Exchange provide support for submitting, searching and retrieving a document, such as a PS-CA to and from a central Document Repository using FHIR resources.

 

Benefits of CA:FeX

The following are some examples of the benefits of CA:FeX:

  • Supports scenarios of health care provider creating, viewing and updating a Patient Summary-CA using standardized HL7 FHIR operations such as submission, search and retrieval
  • Supports safe provision of care in a scheduled or unscheduled medical situation
  • Supports transitions of care or transfers of patients across the continuum of care
  • Supports coordination and collaboration of a patient’s care

 

Actors and Transactions Diagram

The diagram below provides an overview of the Actors, Transactions and their interactions that are part of CA:FeX.



IUA Profile Overview 


Introduction

The Internet User Authorization (IUA) is an interoperability profile that provides an authorization profile for the HTTP RESTful transactions. Being authorized means that the user, patient, or provider has legitimate access to this HTTP RESTful service. The authorization includes identifying the user and the application that is making the request to the HTTP RESTful server, so that server can make further access control decisions.

Benefits of IUA

IUA conveys User Identity, Attributes, and Authorizations to a RESTful service to enable security and confidentiality policy enforcement. The primary use cases are for obtaining authorization for access to a resource using HTTP RESTful HTTP transactions. There are other use cases for delegation, provisioning, etc. which are out of scope for this profile.

The authorization service is separated from the HTTP RESTful access so that it can be provided by a different organization or part of the organization than the resource service. This is driven by the requirements of patients, providers, and other users to simplify and maintain autonomy and control over authorization services. A user may interact with dozens of providers. It is difficult for the user to coordinate different authorization mechanisms with each of these dozens of providers.

This pattern is a common Internet usage and there are already vendors of authorization services that are being used to solve this problem. These include Facebook, Google, and a variety of other service providers in different commercial and governmental sectors. Some countries may use their citizen identity card to access their governmental services. These overlap with providers of authentication services. These services allow a patient to establish an authentication and authorization relationship with minimal provisioning by the healthcare provider. The user can specify “use vendor X” to their healthcare provider.

Actor & Transaction Diagram of IUA

PDQm Profile Overview 


Introduction

The Patient Demographics Query for Mobile (PDQm) Profile provides a transaction for mobile and lightweight browser-based applications to query a patient demographics supplier for a list of patients based on user-defined search criteria and retrieve a patient’s demographic information.

Benefits

  • This profile leverages HTTP transport, and the JavaScript Object Notation (JSON), Simple-XML, and Representational State Transfer (REST). The payload format is defined by the HL7 FHIR standard.

Scenarios of PDQm Implementation 

Using these patterns, the PDQm Profile exposes the functionality of a patient demographics supplier to mobile applications and lightweight browser applications. The following list provides a few examples of how PDQm might be leveraged by implementers:

  • A health portal securely exposing demographics data to browser-based plugins
  • Medical devices which need to access patient demographic information
  • Mobile devices used by physicians (example bedside eCharts) which need to establish patient context by scanning a bracelet
  • Web based EHR/EMR applications that wish to provide dynamic updates of patient demographic information such as a non-postback search, additional demographic detail, etc.
  • Any low resource application which exposes patient demographic search functionality
  • Any application using the MHD Profile to access documents may use PDQm to find an appropriate patient identifier 

Actor & Transaction Diagram of PDQm

PMIR Profile Overview 


Introduction

The Patient Master Identity Registry (PMIR) Profile supports creating, updating, and deprecating patient identity information about a subject of care, as well as subscribing to changes, using HL7 FHIR resources and RESTful transactions. This profile includes the Patient Identifier Cross-reference for Mobile (PIXm) and Patient Demographics Query for Mobile (PDQm) profiles. The “patient master identity” is the dominant patient identity managed centrally among many participating organizations (a.k.a., “Golden Patient Identity”).

Benefits of PMIR

Beyond the basic create, retrieve, update, and delete transaction set, this profile addresses important patient safety issues related to cases where there are two or more patient master identities that have been established for the same person, thus it is not clear which identity is the “true” one. There is also a risk that health data (possibly conflicting) may be associated with each identity – and these disparate data, together, may need to be reconciled before a fully and accurate “health picture” can be developed for this person. These situations represent patient safety risks. This profile addresses how these multiple patient master identities can be merged into a single patient master identity, and how this merge flows down to data custodians so that they take appropriate actions. It is outside the scope of this profile to define how references to the deprecated patient master identity from other data should be handled.

Actor & Transaction Diagram of PMIR

*Note: The IHE Technical Framework of PMIR mentions the ongoing issue of the changing the name convention of the actor role Patient Identity Manager to Patient Identity Registry in their Open Issues and Questions section. For more information, please see this link


Introduction

The Cross-Enterprise Document Media Interchange (XDM) profile provides document interchange using a common file and directory structure over several standard media types. This permits the patient to use physical media to carry medical documents. This also permits the use of person-to-person email to convey medical documents. XDM supports the transfer of data about multiple patients within one data exchange.

Benefits of XDM

XDM Facilitates person-to-person exchange of the healthcare information by supporting transport via physical media - USB and CD-R and supporting transport as an attachment to an email.

Actor & Transaction Diagram of XDM

SVCM Profile Overview 


Introduction

The Sharing ValueSets, Codes and Maps (SVCM) Profile defines a lightweight interface through which healthcare systems may retrieve centrally managed uniform nomenclature and mappings between code systems based on the HL7 Fast Healthcare Interoperability Resources (FHIR) specification.

 Benefits of SVCM

Terminologies managed in value sets are most useful when they are widely shared and standardized across geography and disciplines to add clarity and specificity.

 Actor & Transaction Diagram of SVCM

  • No labels