Architectural Considerations

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

This guide defines a set of general EMR capabilities that can support a range of clinical and administrative healthcare functions. It does not address a single interoperability scenario, such as eReferrals, adverse event reporting, or laboratory data exchange.

The goal is to provide a reusable interface that jurisdictions can use to meet new data-exchange needs without designing a separate integration for every use case. Accordingly, this section focuses on how interoperability will occur rather than on the workflow of a particular area of healthcare.

P-Care also complements the HALO specification by defining the common EMR-facing FHIR capabilities that HALO-conformant applications and other clients can use. In this model, P-Care provides the reusable interoperability foundation, while HALO supports the application ecosystem that uses those capabilities.

The sections below summarize the principal business and architectural implications of conforming to this specification.

Types of interactions

EMRs interact with jurisdictional and third-party systems in two primary roles:

Client role: The EMR initiates an action on an external system, such as querying for information or submitting data.
Server role: An external system acts on the EMR, such as by searching for or updating data.

Traditionally, EMRs have operated mainly as clients, while external systems have rarely acted directly on them. This guide focuses on the server role. In the near term, callers are likely to be EMR companion systems such as SMART on FHIR applications. Over time, the same API may support additional interaction patterns, including direct EMR-to-EMR interoperability.

RESTful exchange

Historically, Canadian EMRs have exchanged information through messaging interfaces. Each message packages the data required for a defined business function, and the response returns a separate package. When data requirements change, the specification and participating systems must be updated. Messaging can also expose information that some recipients do not need because the message must accommodate every potential consumer.

RESTful interfaces are defined independently of individual use cases. The EMR exposes general capabilities for searching, creating, updating, and, where appropriate, deleting resources. Client systems combine these operations to meet their business needs. When a use case evolves, the server often requires no change; it only needs to govern which data and functions each client may access.

This model requires more up-front effort because interfaces must be defined for all data structures that may be accessed or changed. Once established, however, the same interfaces can serve multiple clients, use cases, and versions. Enhancements may still be required - for example, to expose new resources or extensions or to add search parameters - but the overall maintenance burden should be substantially lower.

While this guide focuses exclusively on RESTful interactions, implementers should be aware that there is not currently any commitment amongst national and jurisdictional specifications to convert all messaging interactions to the use of REST. Such conversions, if they occur, will proceed on a case-by-case basis.

SMART on FHIR

SMART App Launch, commonly called SMART on FHIR, is an HL7 standard that enables EMRs to use standardized third-party applications. An app can launch within the EMR, receive the current user context, and provide specialized user-interface functionality without requiring the EMR vendor to redesign its interface for each jurisdictional requirement.

SMART apps can support a wide range of workflows, including:

Rendering and completing complex forms
Retrieving and displaying jurisdictional data alongside local EMR data
Guiding users through externally defined decision trees

Key benefits include:

Functionality can be developed and maintained once, then deployed across multiple EMRs.
After an EMR implements a RESTful FHIR interface and SMART App Launch, most new apps require no EMR software changes unless they need additional API capabilities.
Apps can be tested centrally, reducing the testing burden on EMR vendors.
New functionality can reach clinicians sooner because it does not need to wait for each vendor's development cycle.
Vendors with smaller development teams can offer the same capabilities as larger vendors.
Apps can be maintained and enhanced centrally, with new versions made available transparently to EMRs and users.

Access control

Because RESTful clients can perform many business functions, access control shifts from deciding which systems may send particular messages to deciding which systems or users may access or modify specific resources. An authorization server evaluates access requests and determines the scope of access to grant.

This guide uses SMART Scopes as the mechanism through which SMART apps and other clients request data access. EMR vendors must establish access policies - or enable their customers to do so - that specify which data each app or external system may view or modify.

Subscriptions

A FHIR server allows clients to retrieve information from an EMR and to submit information through create and update interactions. Some use cases, however, require the EMR to push data to an external system. Traditional messaging can support this pattern, but it often creates one-off, fragile interfaces that are difficult to upgrade.

FHIR Subscriptions provide a more flexible, dynamically configurable alternative. An EMR publishes supported topics representing events such as a new admission, patient discharge, or medication order. Clients subscribe to selected topics and may apply filters, such as patient, encounter type, or medication. When an event occurs, the EMR can send a resource, a collection of resources, or references to them; the client can then query for further details if needed.

Conformance testing

A central objective of this guide is robust conformance testing so that EMR vendors, customers, and client systems can rely on the interfaces to meet interoperability requirements. Its expectations are therefore more prescriptive than those in base specifications such as CA Core+:

Terminology requirements are generally mandatory rather than optional.
Conformance and behavioural obligations for profile elements generally use SHALL rather than SHOULD or MAY.

If a source implementation guide requires support for a resource, data element, terminology, or other capability, this guide also requires it. The resulting expectations may exceed those of an EMR's current interface partners. Vendors must therefore weigh the benefit of conforming to one comprehensive guide against the effort of complying separately with the jurisdictional guides relevant to their deployed systems.

Note: As described under Types of Interactions, this guide addresses server functionality only. EMRs may still require separate certification for client-side capabilities, such as transmitting required messages or interacting correctly with a jurisdictional system.

Terminology

Different jurisdictions or use cases may bind the same data element to different code systems. For example, one guide may require one allergy terminology while another requires a different one. To support both clients, a FHIR API must be able to expose both coded representations.

FHIR allows multiple coded representations of the same concept. Because users are unlikely to code the same item more than once, the EMR will usually need to translate between code systems. Translation may already be necessary when the EMR's internal codes differ from those required by interoperability specifications. Multiple terminology bindings on a single element therefore indicate that the EMR may need to translate the concept into each required code system, where a valid mapping exists.