PS-CA v0.3 Draft

The codes in the ICD-10 CA code system (http://hl7.org/fhir/sid/icd-10-ca) are expected to be similar with ICD-10 up to the fourth character level. However, ICD-10 can be coded up to 6 characters for hospital data (with the potential to expand up to 7 characters). We are working to identify what code system would be sent in the system field (http://hl7.org/fhir/sid/icd-10  or http://hl7.org/fhir/sid/icd-10-ca) by hospitals who have implemented ICD-10 CA in scenarios where the code is four characters or less. This will help determine if an additional slice is needed/if value set needs to be expanded to include the non-localized code system.

IPS is currently evaluating the use of this element, as it was originally identified as MS but was not able to be tied back to an original requirement in the ISO 27269 standard. We believe its introduction as MS and the careProvisioningEvent slice in the IPS FHIR profile was influenced by workflow that may be assumed in the CDA creation of patient summary that may not extend to patient summaries that are generated outside of an EMR Provider workflow. We've maintained the slicing to allow for its use but anticipate that IPS will further refine the expectations (and further clarify the use) of this slice. 

Correct. Not every province/territory issues health card numbers that include version code. It is a concept that supplements Ontario Health Card numbers. To reduce diversity in how version code was expressed (and preserve the originally captured identifier even after replacement) the HCN version code extension was introduced in Ontario and proliferated into systems and FHIR Guides.  It's been included in the PS-CA in order to prepare implementers that some identifiers with the type of JHN may include this extension. 

The assumption for the scenario covered by the XDS sequence diagram is that the Patient Portal is hosted on an EMR solution and PS-CA is stored in a local Document Repository within the same EMR solution. In other scenarios, which are not covered in this sequence diagram, a Patient Portal may be hosted on a different system/solution then the Document Repository will be under a separate system. Such an architecture will have a different activity flow diagram. 

Implementation approach and architecture to enable a patient or their designated caregiver to view/access their own patient summary will need to align with existing jurisdictional regulatory requirements. The specification focuses on core capabilities and jurisdictions will likely have guidelines for information sharing with their patients. The expectation is that patients should receive the same documents. 

The specification allows for internal, legacy capabilities to be employed in collecting the information necessary to assemble a Patient Summary. Obsolete standards can be migrated to more modern ones as part of the product roadmap. The main requirement that this specification places on legacy systems is to support the required (R) actor transactions in their specified format. This may require enhancements to existing systems, but it is a relatively low entry bar that would allow participation in future eco-systems. 

In support of the Interoperability specifications, Infoway is developing a privacy toolkit to be released in April, Interoperability Challenge Accepted: A Privacy Toolkit for Canadian Jurisdictions, that will address consent and other privacy considerations at a pan-Canadian level.  

The Interoperability specifications roadmap will be developed to include key areas such as Authorization, Authentication, Role-Based Access Control, etc. to meet the requirements of Canadian implementers. At this time, it is recommended that vendors and jurisdictions ensure appropriate security services, mechanisms and functionality are in place for the PS-CA Specifications, depending on maturity levels of current capabilities. 

The objective of a format rendering service is to provide options for transformation of documents between different formats. If there are jurisdictional requirements to mask data prior to the generation of a PDF then data masking operations may be executed prior to the operation that generates the PDF. 

Infoway gathered input from Clinicians across Canada through various formats, including Clinician engagement sessions, one-on-ones and by participating in jurisdiction-held Clinician sessions (e.g., Alberta Medical Association meetings).   During these sessions, Clinicians indicated that it will be necessary to have the ability to redact/withhold information from the Patient Summary that is not clinically relevant.  

At this time, the PS-CA Specifications includes considerations for consent during the development of the Patient Summary recognizing that local/jurisdictional policies must be considered. In support of the Interoperability specifications, Infoway is developing a privacy toolkit to be released in April, Interoperability Challenge Accepted: A Privacy Toolkit for Canadian Jurisdictions, that will address consent and other privacy considerations at a pan-Canadian level.

The first release of the PS-CA will include supports for sharing Patient Summaries for?scheduled or unscheduled local care with information from a single source. The PS-CA roadmap will include the supports for consolidation of Patient Summary data from multiple sources into a single Patient Summary.