PS-CA v0.2 Draft

PS-CA was developed in close collaboration with participating Canadian jurisdictions. There are multiple integration patterns offered, XDS, MHD and CA:FeX. Two of these patterns support FHIR transactions and one is a legacy, but very popular, exchange paradigm in the US and Europe. The market is expected to choose the appropriate one depending on local business needs.

PS-CA v0.2 (FHIR Implementation Guide v0.0.3 & v0.0.4) maintained the minimum cardinality on the three required sections: Medication Summary, Problem List, Allergies and Intolerances and supplied an alternative pattern for systems to communicate the reason for not having content for that section (i.e. asked but none present, not known, not supported due to technical or policy limitation). This pattern is only applied to the three required sections. This preserves the original intent of IPS to guarantee that patient summary reviewers could anticipate at least those three sections in any patient summary. 

Infoway provides FHIR API access through the Terminology Gateway to the ValueSets. All Terminology Gateway ValueSets are fully expanded. There is no Terminology Server available that supports the full set of ValueSets that are part of the PS-CA Specifications. Any known limitations with terminology validation are noted in the Known Issues & Future Development Page of the Pan-Canadian Patient Summary Implementation Guide.

Within the FHIR MedicationRequest resource the dosageInstruction element uses the dosage data type(https://www.hl7.org/fhir/dosage.html) to model timing, dose, rate, etc. The MedicationRequest profile, in v0.0.4, has maintained the MustSupport flag on dosageInstruction.text and dosageInstruction.route, but relaxed the MustSupport flag on dosageInstruction.timing (originally in IPS) as the data dictionary analysis identified separation of these timing details was not consistently supported across jurisdictions. Note, this does not mean it is constrained out. Implementers who can send titratable information as sub elements under dosageInstruction are encouraged to do so.

The use of CodeableConcept.text in MedicationRequest or MedicationStatement is recommended over trying to form a Medication resource when only text is known.

The PS-CA v0.2 (FHIR Implementation Guide v0.0.4) profile currently allows for the use of text descriptions of medications if that is what is in use in the jurisdiction. While not necessitated by the profiling, implementers are encouraged to begin using the preferred valuesets (e.g., CCDD). Existing guidance on compound products in CCDD can be found here: Combination Products.

CCDD is preferred. DIN codes for Manufactured Products are part of the CCDD (i.e., codes starting with 0s). The DPD, where DINs are housed, are updated regularly and may occasionally be out of cycle with the CCDD updates. This is known to the CCDD team, not something that is unique to implementation in FHIR. Since neither is hosted by a terminology service with $validate operations, the scenario of sources updating on different cycles is not expected to cause issues in creating compliant instances in the first release.

Within the implementation guide, these can be found in the following two places:

• on the profiles themselves (i.e., items listed in the differential with comments indicating MustSupport in IPS), and
• on each of the respective profile pages there is a list of items that are in IPS as MustSupport that required relaxation in PS-CA due to principles reflected in the guide.  

A cardinality of 1..1 at the composition.section level ensures that the section is always populated with a consistent section title (Allergies and Intolerances Section), LOINC code that makes the section mechanically recognizable (48765-2– Allergies and Adverse Reactions), etc. This is a requirement shared across all iterations of the patient summary because even if you do not have clinical information for that particular patient’s section, you still need to be able to structure the summary in a consistent way and indicate the reason why the allergy information is not provided (e.g., no allergy, not known, not supported).

All jurisdictions have indicated they would be able to support Medication, Allergy, and Problem sections, which means even if they do not have data for the patient for that section the systems will know how to produce a resource for that section. We do not think it will be needed, but we did create a profile showing what a system would send if they truly do not support the provision of any medication, allergy, problems for any of their patients. These are the Content Not Supported profiles.

We have updated the language in the next version of the Implementation Guide, section Differences between the IPS-UV and PS-CA to provide the following clarification:

In order to maintain compliance with the IPS-UV, the PS-CA Composition has maintained the required cardinality on Medication Summary, Allergies & Intolerances, and Problem List sections. However, it provides clear guidance to implementers for what should be included within the section.entry element if:

• • for a given patient, no information exists for that section, or
  • the implementing system cannot produce the section (due to lack of capability, jurisdictional restrictions, etc.).

One of the guiding principles considered foundational for specification development by the Governance Tables was to try to adopt as much as possible from international standards. There are two internationally recognized implementation guides for IPS, one at IHE International recommending the MHD profile, the second at HL7 International as IPS IG. Both of these have been considered. The complexity of document sharing in a diverse eco-system requires a variety of solutions. Some of the typical challenges have already been solved through IHE profiles and where these are appropriate, in line with our principles, we are listing them as valid choices. Implementers will chose the right pattern based on the appropriate business drivers.

We are currently in the process of consulting with our partner vendors, agencies and provincial territories to refine the future of the Interoperability program.  We will provide specific details and updates on program components once they have been defined completely.

Infoway is currently in the process of consulting with our partner vendors, agencies and provincial territories to refine the future of the Interoperability program.  We will provide specific details (e.g., Details on CA:FMT and related transactions) and updates on program components once they have been defined within the Interoperability program roadmap.

The MHD ITI transactions (ITI-65, 66, 67 & 68) use the FHIR-R4 standard for health data exchange that supports all CRUD operations. An Open API page to test the PS-CA with the CA:FeX option is coming soon! Stay tuned to the Patient Summary working group on InfoCentral for more information.

The MHD Profile is not limited to mobile devices. Using the term “mobile” is used as a grouping for mobile applications, mobile devices or any other systems that are resource and platform-constrained. 

MHD is an API between four actors (i.e., Document Recipient, Document Responder, Document Consumer, and Document Source). These ITI transactions specify semantics of the data exchanged between actors. The MHD test plan focuses on these semantics and on the expected actions on the server-side actors (Document Recipient and Document Responder). Infoway recommends that participants are able to test all required transactions for MHD profile for the role the application is expected to play in the transaction.

The PS-CA Specification refers to the IHE IUA profile that manages access tokens used for authorization of access to HTTP RESTful services based on the flows and transactions defined in the OAuth 2.1 Authorization Framework [OAuth 2.1]. It recommends the use of asymmetric (public-key based) methods for client authentication [OAuth 2.1, Section 9.1], but allows other suitable HTTP-based authentication schemes matching the security policy of the Authorization Server [OAuth 2.1, Section 2.3.2].

Implementation of IUA is recommended, but not mandatory. However, when MHD actors are grouped with IUA actors there are additional security and privacy functionality enabled by this grouping and is therefore encouraged.

Authenticating a user by grouping the IUA profile with MHD is recommended for vendors that use OAuth 2.1 Authorization Framework. If there is an existing implementation for authorizing a user (SAML 2.0, WS-Trust or any other means) then that existing solution and process flow can be leveraged.

Patient summaries are intended to convey a summary of the patient's relevant medical history. This is separate from what event, such as an encounter, led to the creation of the summary.

Both IPS and PS-CA are flexible in the approaches they support for the generation of patient summaries. Some may be generated during a visit between patient & author or with an author reviewing & compiling the summary document without the patient (both may/may not be captured as a standalone encounter). Some summaries may also be automatically generated outside an official event/encounter with a physician.

Composition.encounter is used to communicate if there is an encounter where the document was generated. (This is not necessarily the encounter(s) where the documented care was originally provided. For example, immunization.encounter may be different that composition.encounter where immunization is referenced). It is not good practice to constrain the ability for systems to claim the encounter/event that the PS was generated during, however it is considered optional in the profile and the MustSupport flag is relaxed (originally applied in IPS-UV). 

Yes, the focus of release 1 is to collect/create a Patient Summary from a single source (e.g., EMR). The location to which the PS is submitted (e.g., EHR) is dependent on the jurisdictional architecture. Future releases of the PS-CA may include aggregation of data from multiple sources.

The official language of all International Standards is English and they are not usually translated to country locales. The terminology value sets that are used within the standard are however translated. Under certain circumstances implementation guides and specifications may also be translated but this is usually the exception not the norm. We have checked with International SDOs and with colleagues from countries in Europe and South America to make sure that what we represent here is accurate.

In terms of practical next steps, content translation for terminology is already implemented as a methodology into our National Release Centre. InfoRMS is the central ticketing system accepting requests for terminology code management and translations. We recommend using this channel for requesting French translations of the applicable terminology ValueSets. We believe that these are the most impactful components of the Standard since they are the terms that are directly available to end users.

Once the Specification completes it's iterative reviews and reaches Trial Implementation in April 2022, French translation can be requested.