Consolidation Methodology

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

As noted on the Home page, this guide consolidates content and expectations from several existing specifications. This section explains how the effective requirements were derived from those sources.

This material is provided for context. It may help explain why certain requirements are expressed as they are, but EMR vendors do not need to understand this methodology to implement the guide successfully.

The consolidation process had two main components:

Dynamic/behavioural consolidation: established the CapabilityStatement requirements for EMR FHIR servers.
Static/data-structure consolidation: established resource profiles and the obligations and constraints within them.

General

Both the static and dynamic consolidation processes follow one foundational rule:

To work across all in-scope implementation guides (IGs), an EMR must support every function required by any one of them.

Accordingly, the consolidated requirements include every extension, obligation, terminology expectation, interaction, and search parameter required by any in-scope IG.

Where conformance expectations differ - for example, one specification says MAY or SHOULD and another says SHALL - the consolidated requirement adopts the most stringent expectation. In this example, SHALL applies.

Cardinality is the exception. The tightest cardinality is not necessarily the most demanding requirement. If one IG requires 1..1 for an element such as name and another requires 0.., the consolidated profile uses the wider 0.. range. A system that can handle both missing elements and multiple repetitions is more capable than one that requires exactly one occurrence.

Dynamic/Behavioral Consolidation

The guide's dynamic requirements are represented in the Capability Statement. It defines the interactions, operations, and search parameters that compliant EMRs must support through their FHIR server interfaces. Its contents were derived from three sources:

Requirements in the source IGs
Search parameters needed to address cardinality differences
Additional requirements identified by Ontario Health

Source IG Processing

A major challenge in deriving RESTful expectations was that most source IGs did not define RESTful interfaces. Where CapabilityStatements existed, they generally focused on receiving messages or processing operations.

The intended P-Care model assumes that an intermediary SMART app performs the functions required by a jurisdictional or national IG, then interacts with the EMR to retrieve or manipulate the necessary data. This model required the team to infer both the interactions the EMR must support and the search parameters those interactions require.

This analysis was performed manually by reviewing use cases, identifying the data required for messages, operations, and documents, and, where necessary, making informed assumptions. These conclusions may evolve following further review by source-IG authors and implementers.

The analysis also incorporated the server CapabilityStatements from US Core and CA:FeX.

Cardinality-Driven Search Requirements

A second source of requirements was the set of search parameters needed to resolve differences in profile cardinality.

An element required or prohibited by one IG may be optional in another. Because the consolidated profile adopts the loosest cardinality, systems that could previously count on an element always being present or absent would no longer be able to do so. That means they may now need a way to retrieve only resources in which that element is present - or absent - so that the results still meet a particular IG's requirements.

Where possible, search parameters were added to support filtering on those elements. This was only feasible when the element used a searchable data type; backbone elements and complex types such as Dosage could not be handled this way. Search parameters were also omitted when no realistic app use case would search on the element.

Ontario Health Requirements

Ontario Health introduced several requirements to support known P-Care use cases associated with specifications and specification versions that have not yet been developed or published.

support for Subscription and SubscriptionTopic
support for the _content search parameter (and the guidance around its use) to support keyword searching
support for _lastUpdated to enable polling
support for requester search parameter on Task
PractitionerRole _include support for organization and location
SHALL read on Binary
SHALL search on Encounter, and SHOULD search on all other resources except Patient and PractitionerRole
SHOULD create on Binary and Encounter
MAY delete on MedicationStatement
SHALL update on DiagnoisticReport
SHOULD update on Condition, Binary, Encounter, FamilyMemberHistory, HealthcareService, ImagingStudy, MedicationStatement, Observation, Patient, and Procedure
expectation for patient-centric search parameter combinations on all resources except Task

CapabilityStatement Consolidation

The requirements from all three sources were combined into a single union, applying the strictest conformance level to each interaction.

The consolidation also applied the following considerations:

Resource scope: Search criteria were limited to resources initially identified as in scope. This covered most resources used by the source IGs, except some resources in CA:FeX and US Core.
Advanced search features: Requirements for chaining, includes, modifiers, and permitted search-parameter combinations were retained when explicitly defined by a source IG. The initial release generally does not infer fine-grained requirements where none existed.
Patient-centric searches: Search-parameter combinations are the exception. Because this specification initially targets SMART apps operating in a patient context, cross-patient searches - for example, retrieving every patient with diabetes - are not currently supported. Every search must first identify the patient, and this was enforced by adding search parameter combinations requiring patient.
Versioning and provenance: Interactions that depend on version history, patch operations, or Provenance were excluded.

**Implementation Note: The CapabilityStatement uses a non-standard syntax for chaining requirements. Chaining should normally be expressed as characteristics of a derived SearchParameter rather than as separate supported search parameters. The current approach is retained because it makes the requirements more visible to readers. Until tooling can surface constrained SearchParameter details more effectively within CapabilityStatement renderings, this guide will continue to use this representation. As a result, comparisons with correctly formed system CapabilityStatements may be limited.

Static / Data Structure Concolidation

This guide defines profiles that support the combined capabilities of all in-scope resources. Most resource types have a single consolidated profile. Observation is the exception: separate profiles are retained for different Observation types, consistent with common IG practice.

Only the source IGs were considered when defining profiles; CA:FeX and US Core profiles were excluded from this analysis.

The consolidation process applied the following rules:

CA Core+ derivation: All profiles were derived from CA Core+ where a corresponding profile existed, unless CA Core+ was more constrained than one or more of the source IGs.
Jurisdiction-specific artifacts: Extensions, value sets, and code systems were generalized as P-Care artifacts unless they could apply only within one jurisdiction. Canonical URLs were changed to P-Care URLs, and names were made more generic where appropriate.
Cardinality: As described in the dynamic section, each element uses the loosest cardinality found across the source profiles.
Slicing: Where elements were sliced, slicing was retained, combining the discriminators used across the source profiles (if there were differences) and slices were merged when discriminators were the same or added as additional slices when they were distinct.
Choice types: Choice types had their list of allowed data types expanded to the union of all target types
Referecing types: Data types of type Reference or canonical had their set of targets expanded to the union of possible target resources and, where P-Care profiles existed, the references were changed to refer to those profiles.
Data type profiles: Where data types had profiles, these profiles were combined in the same manner as resource profiles.
Constraints: Where there were constraints (invariants, patterns, fixed values, etc.) that did not hold across all profiles, they were all translated into 'warning' invariants noting the additional rules imposed for some use-cases.
Documentation: Where there was custom documentation (definitions, comments, requirements, examples, etc.) it was generified to content that applied across the full P-Care use-case
Terminology: The following rules were applied:
1. If there were conformance-enforcing bindings in play (required or extensible), then only those bindings were used. example or preferred bindings would be dropped.
2. If there were multiple bindings to value sets drawing from the same code system, they were combined into a binding to a single union value set.
3. If there were conformance bindings to multiple distinct value sets, they were all retained with the largest value set established as the 'primary' binding and all others set as 'additional' bindings. The effect of this is that the data element must have codings that meet all the bindings.

CodeableConcept Datatype Profile Derivation

P-Care uses multiple levels of CodeableConcept profiling to distinguish between base FHIR requirements, Canadian requirements inherited from CA Core+, and additional requirements identified through consolidation of the source implementation guides.

FHIR CodeableConcept: The base FHIR R4 datatype is used where no additional Canadian or P-Care datatype constraints apply.
CodeableConceptCACore: Builds on the base FHIR CodeableConcept datatype and incorporates CA Core+ requirements. Its coding entries conform to CodingCACore, including the Canadian representation of coded information and translations of Coding.display.
PCareCodeableConcept: Derives from CodeableConceptCACore and incorporates additional P-Care requirements identified through consolidation. Its coding entries conform to PCareCoding, and it carries applicable obligations on elements such as coding.system, coding.code, coding.display, and text.

The profile derivation hierarchy is:

CodeableConcept → CodeableConceptCACore → PCareCodeableConcept

The derived profiles inherit the applicable requirements of their base profiles. Consequently, an instance conforming to PCareCodeableConcept is also subject to its inherited CA Core+ and base FHIR requirements. The reverse is not true: P-Care-specific constraints do not automatically apply to elements constrained only to CodeableConceptCACore or the base FHIR datatype.

The applicable datatype profile is declared by the resource profile. Implementers SHALL conform to the datatype profile specified on the relevant resource element and SHALL NOT independently substitute another CodeableConcept variant.

The remaining area - Must Support and obligations - requires a more detailed treatment.

Must Support and Obligations

P-Care uses obligations to define expected server behaviour during supported interactions. Profile elements describe what may or must appear in a FHIR instance; obligations describe how the system must handle that content - for example, whether it must send, store, or accept an element without error.

Obligations are independent of cardinality. For example, a SHALL:populate obligation may apply to a 0..1 element, while a MAY:populate obligation may, in rare cases, apply to a 1..1 element.

Obligations provide greater precision than Must Support because a single element can carry multiple behavioural expectations, each potentially associated with a specific actor. This also allows IGs derived from P-Care to decide whether to inherit those obligations. All obligations in this guide apply to the P-Care Server actor.

Obligation Consolidation Process

The consolidation process for obligations consists of the following steps:

Identify effective Must Support requirements and explicit obligations in every in-scope source IG, then translate Must Support statements into equivalent obligations.
Combine the obligations and apply the stricter expectation when multiple obligations affect the same element. For example, SHALL takes precedence over MAY, and populate takes precedence over populate-if-known.
Carry forward CA Core+ obligations unless another source IG defines a stricter expectation.

Translation of Must Support Rules

Source IG	P-Care translation
CA:eReC	`SHALL:populate`; `SHOULD:persist`; `SHALL:no-error`
PS-CA	`SHALL:populate`; `SHOULD:persist`; `SHALL:no-error`
Alberta eReferral/eConsult	`SHALL:populate`; `SHALL:persist`; `SHALL:no-error`
PS-AB	`SHALL:populate`; `SHOULD:persist`; `SHALL:no-error`
Ontario eReferral	`SHALL:populate`; `SHALL:persist`; `SHALL:no-error`
Ontario Immunization Repository	`SHALL:populate`; `SHOULD:persist`; `SHALL:no-error`
Ontario CMS	`SHALL:populate-if-known`; `SHALL:persist`; `SHALL:no-error`
Ontario eForms	`SHALL:populate`
Base FHIR profiles	`SHALL:populate`; `SHOULD:persist`; `SHALL:no-error`

Note: : In many source IGs, Must Support effectively meant "handle" because those guides focused on consuming data through messages or operations. In P-Care, the relevant consuming interactions are create and update. In that context, "handle" is not sufficiently precise, so persist is the appropriate obligation code.

Ontario Health Requirements

Ontario Health introduced several requirements to support known P-Care use cases associated with specifications and specification versions that have not yet been developed or published.

Immunization: Added candidate binding for DIN, dropped reportOrigin, added obligations for location.display, protocolApplied, and protocolApplied.doesNumber, added warning rules on basedOn cardinality
Medicaiton: Added obligations on ingredient and ingredient.itemCodeableConcept; added preferred binding on ingredient to PrescriptionMedicinalProduct and Candidate binding to LicensedNaturalHealthProduct
Encounter: Added obligations to status, class, type, participant, period, reasonCode, location, and serviceProvider
Task: Added input and output slices to support SDC Questionnaire solicitation Tasks and added obligations to them. Added obligations to 'for'
DiagnosticReport: Added obligations to presentedForm