dft-preBallot - This is the first draft of the P-Care IG. For a full list of available versions, see the Directory of published versions

Future Enhancements

This specification is an initial release and will evolve as new versions are published. The following sections identify areas where future changes are likely. They are neither commitments to specific changes nor an exhaustive roadmap.

Expanded Scope

The initial release covers a defined set of Ontario, Alberta, and pan-Canadian specifications. It does not include every national or jurisdictional FHIR specification, and additional specifications and versions will continue to be published. To fully meet its mandate, this specification will need to expand to cover the resources, obligations, extensions, and RESTful capabilities required across that broader landscape.

The scope and sequencing of future additions will be determined through ongoing feedback from EMR vendors, providers, and jurisdictions.

Additional Patient Summary resources

The Canadian Patient Summary (and jurisdictional variations) imposes obligations on supporting sections and entries for resources for which no profiles are defined:

• CarePlan
• ClinicalImpression
• Consent
• Device
• DeviceUseStatement
• ImmunizationRecommendation
• Specimen

Because of the lack of profiles, this IG does not impose any expectations with respect to those resources, as there are no conformance-testable criteria that could be evaluated. This may be addressed for some or all resources in a future release

Adjusted Search Parameters

This specification includes all search parameters for in-scope resources that are present in US Core or CA:FeX. However, the profiles do not include the requirements from those guides. In some cases, this means that there are search parameters that are marked as 'SHALL', when there are no obligations on the element the search parameter is checking. A future release will need to evaluate whether to remove or loosen the search parameter expectations, or to add obligations to the corresponding element.

Expanded Search Expectations

Future releases may define clearer conformance expectations for search capabilities, including:

• Required modifiers for each search parameter
• Whether repeated parameters expressing logical "and," and repeated values expressing logical "or" are permitted
• Permitted forms of chaining
• Resources that may be included or reverse-included in search results
• Permitted comparators for numeric parameters

Conformance requirements may also apply to general search functions that are not strictly parameters, such as _count and _sort.

The current guidance is limited because most source Canadian implementation guides did not define these characteristics, and the guidance that did exist was not always comprehensive. Future versions of this specification are therefore likely to establish additional conformance expectations in these areas.

Advanced _content Search

The _content search parameter is flexible, and its syntax and capabilities are not fully defined in the core specification. This release therefore places limited expectations on EMRs. Future releases may introduce a formal query language or other advanced search capabilities, informed by discussions with EMR vendors about what is practical to implement.

Search Corrections

Some of the search parameters referenced by source implementation guides used to define this guide were not correctly defined in their source IGs. These issues have been reported back to the guide authors. When these issues are corrected in the source IGs, those same changes will be need to be made here.

Additional 'update' guidance

Most resources in this guide treat 'update' as a SHOULD, not a SHALL. This is because update logic is often complex:

• There may be constraints on which instances can be updated (e.g. only data created by the current user, created by the current users's organization, etc.)
• There may be constraints on which data elements can be changed (e.g. status, but not other elements
• Limits imposed on changing 'historical' data that may have been relied on

As pan-Canadian expectations are agreed, additional guidance and tighter expectations for support of updates is likely.

Artifact Migration to CA Core+

In this IG, all extensions, code systems, and value sets that were specific to a provincial source implementation guides that did not have an existing international or Canadian equivalent have been migrated to use a PCare-based url. Some, and potentially all, of these extensions are candidates for migration to CA Core+. They will need to be manually evaluated. Implementations should prepare for the possibility of that migration by ensuring software will be able to accomodate both old and new URLs. (In some cases, it might also be necessary to support the original jurisdictional URLs as well.)

Complex Interactions

This release excludes non-resource-specific interactions, such as batch, transaction, and cross-resource search, as well as version-aware interactions, such as vread, history, and patch. Future use cases may identify requirements for some of these features, at least for selected resources

Provenance Support

US Core, CA:FeX, and several non-Canadian national initiatives expect systems to retrieve and create Provenance instances. These records support traceability by identifying the origin of information and the changes made over time. Although the in-scope jurisdictional systems do not currently support or require provenance information, future versions of this specification are likely to introduce expectations for this resource.

External and Legacy Data

Many implementation guides describe what systems should do now without accounting for years or decades of legacy data. EMRs may also receive data from external systems whose content they cannot control. In those cases, they must choose between discarding data that does not meet current best practices and retaining imperfect data because it is still clinically useful.

The original FHIR conformance binding strengths reflect the same focus on current behaviour. They are less effective for legacy or externally sourced data:

• Required: If legacy or externally sourced data is not in the bound value set, the sender must map it - even manually. If it cannot be mapped, the element cannot be sent. If the element is mandatory, the containing element or the entire resource may also be unsendable.
• Extensible: The same rule applies, except that after a mapping attempt, data with no valid match may be sent as free text or an alternate code. Sending unmapped data without first attempting to map it is not conformant.

In practice, asking software or clinical staff to map every legacy record - and to repeat that work continuously for all inbound data - is not feasible.

FHIR addresses this issue through new binding types in the additional-binding extension. These bindings apply only to data captured locally after conformance with the specification has been declared. The relevant purposes are current and current-extensible.

Before this specification can adopt these purposes, the underlying CA Core+ implementation guide must support them. Once that occurs, future versions will likely revise their binding strengths accordingly, because current and current-extensible are better suited to the EMR RESTful interface use case.

Tighter Terminology Bindings

Many of the key clinical data elements remain with only 'preferred' or 'candidate' bindings. Such bindings mean that apps cannot make decisions on or usefully search based on those elements. As apps are developed, the need to force the use of standard terminologies is likely to increase.

Data-Type Constraints

Most source implementation guides did not specify which properties of a data type must be supported or populated. This includes elements and nested extensions within extension definitions. As a result, a Reference might support only display, or a ContactPoint might support only use. Future versions may tighten these expectations through inline constraints or dedicated data-type profiles.

Polymorphic and Multi-Reference Target Support Expectations

Some of the PCare elements that impose obligations allow a choice of data types (e.g. value[x]). Others have a type of 'Reference' or 'canonical' and allow referencing a choice of target resources. In most cases, the source IGs did not make clear whether the expectation was to support all of the permitted types or target, or only some of them. In a futue release, once analysis has been performed, obligations will likely be added on a per-type and per-target basis to make clear which ones must be supported and which (if any) are optional.

Tighter obligations

Many of the obligations are inherited from guides with slightly loose expectations. Any data elements with obligations that are less than 'SHALL' cannot be counted on by apps. As well, a number of jurisdictional and national specifications have expectations around data capture, display, inclusion in narrative, and other requirements that are not reflected in the declared obligations. To allow more comprehensive conformance testing, more needs that can be computably expressed via obligations may migrate into this specification.

Guidance for Absent Data

FHIR permits a data type's value to be omitted and a required element to be satisfied instead with an extension such as data-absent-reason. This is not possible when the element has a required binding. The flexibility accommodates legacy data, externally sourced data, and other situations in which the desired value does not exist. However, it can surprise systems that interpret a cardinality of 1..x as a guarantee that a value will always be present.

Future versions may define more precisely when extensions such as data-absent-reason are acceptable and when an actual value must be provided.

Model Revisions

In some situations, the algorithmic process has produced profiles that are modeled in ways that could make implementation difficult. As well, not all source specifications used consistent modeling approaches. It is likely that human review of the profiles will identify changes that will make them more fit-for-purpose, while retaining the ability to meet the requirements of the various jurisdictions and use-cases.

Subsciption Topics

This specification establishes baseline support expectations for subscription-related resources. However, true interoperability also requires an agreed set of subscription topics. Jurisdictional and client requirements for subscription topics have not yet been determined. Future versions of this guide will likely define standardized topics, including the events, search parameters, and payload structures associated with each subscription type.

URL Migration

In this guide, code systems, value sets, and extensions that were jurisdiction-specific have been migrated to generic 'Canadian' equivalents, changing their canonical URL. (Exceptions were made when there was an existing international or Canadian artifact that served the same purpose and could be cleanly mapped.) Many of these artifacts are candidates for migration into the CA Core+ or other use-case-specific guides. If that migration occurs, the canonicals might change again. Implementers should include a translation layer that allows for concepts to be expressed using both old and new URLs and that can consume data using either representation.

Business Guidance

The source specifications used to create this guide include more than profiles and dynamic exchange requirements. They also address security, consent, enrolment, identity, and other technical and business considerations needed for interoperability. This release does not attempt to incorporate or align that broader guidance. Future versions may add selected requirements from these areas.

Security Guidance

Security is a particularly important aspect of the broader business guidance. Although this specification sets baseline expectations for TLS and SMART on FHIR, additional guidance is needed in the following areas:

• Required SMART scopes, potentially including fine-grained scopes
• Authorization-process rules, including token exchange, expiry limits, and refresh periods
• Additional TLS protocol expectations
• Processes for application registration and trust establishment

Future releases should therefore be expected to introduce additional conformance requirements in this area.

Feedback-Driven Refinements

As a first release, this guide also serves as a proof of concept. EMR vendors and jurisdictions will almost certainly identify both new requirements and practical implementation constraints. The guide will evolve in response to that feedback. Instructions for submitting feedback are available here.