From detailed guides to online courses – resources are available to provide you with the knowledge necessary to build and integrate EHR applications.

Integrating Point of Service Systems via System to System Communications

Integration of point of service systems happens at various levels such as network, messaging, applications, security, etc. and is dependent on the systems implemented in different environments. 

The hospital environment is a blend of acute and ambulatory care. In larger institutions there may be internal IT diversity as well, such as EMR systems in clinics, broader HIS systems for admissions, resource management and inpatient care, and additional systems for specific uses such as emergency rooms, radiology and laboratory work. Hospitals need to verify professional licenses and other legislative obligations. The PHI Protection Act requires health care providers to have privacy officers to address health care client inquiries and ensure that privacy is not violated. eHealth Ontario will leverage these privacy features to help manage and integrate the EHR into these environments.

Hospital Information Systems (HIS)

Hospital information systems refer to application suites deployed institutionally. These suites are functionally rich and provide internal consistency, and the hospitals that run them are technically mature. They do not generally comply with all Ontario and pan-Canadian standards required to consume EHR services directly. 

eHealth Ontario’s integration strategy for hospitals centres around identity federation and integration with the HIAL. The federated approach relies on trusting assertions from hospitals about the identities of their users of EHR services. Essentially, a hospital is entitled to request information from the EHR under its own recognizance as a health information custodian (HIC, as defined under PHIPA), but it must assert the identity and strength of authentication of the user requesting the information, for further authorization, audit and consent purposes. Hospitals sign agreements with eHealth Ontario referencing its policy and standards and establishing their responsibilities. Once this is done, eHealth Ontario will ensure that its policies and standards are followed.

Figure 16: HIS Integration Pattern 

Hospital systems have user management mechanisms which are often based on older, proprietary or internal naming standards and other integration mechanisms which may not meet the EHR’s user identity management requirements. These solutions may integrate using HL7v2 over MLLP or other standards. It is expected that a local interface engine or a regional HIAL segment will provide any necessary ‘last mile’ integration services before sending the systems request to the eHealth Ontario HIAL segment. For example, issuing required Security Assertion Markup Language (SAML) assertions, mapping local users to provincial identities for proper authentication and authorization, or transforming/translating messages to and from provincial standards.

In practice many hospitals may choose to use a hybrid solution, incorporating both the HIS and a hospital portal, with the HIS acting as a data source and potentially feeding information to the EHR. Users can be presented with a composite view of information (from the HIS, other local solutions, and the EHR) via context-sensitive portlets on the portal. Users can access their portals through their HIS with single sign-on enabled, or through a separate browser session using suitable context management mechanisms. 

Other hospital systems supporting core functionality in the EHR such as lab or radiology information systems are expected to follow either the general HIS integration pattern or the patterns specific to the solution space in which they act.

Electronic Medical Record (EMR) Systems 

EMR solutions are used in many health care settings. When used in a hospital ambulatory care setting, an EMR may be integrated with the broader hospital information environment, which provides common provisioning, identity, security and other services. These EMR systems may connect directly with the EHR components at eHealth Ontario via the eHealth Ontario HIAL segment, or through a regional HIAL segment; they will likely also integrate with local systems at the hospital. EMR systems in community care settings are typically used by primary care physicians and specialists in the community.

eHealth Ontario, with OntarioMD, publishes specifications for EMR systems to work with EHR components. Users who purchase EMR systems that comply with these specifications qualify for funding from us. Clinical EMR systems at hospitals may or may not necessarily be specification-compliant. Those that are not compliant will need to rely on a local integration facility or the regional HIAL segment to leverage EHR services. Those that are compliant will have more flexibility and ease in using this integration pattern.

There are two models for the provincially funded EMRs:

  • A local model – deployed, managed and operated at the clinic 
  • An application service provider (ASP) model – deployed in a central location; services are accessed by providers in remote locations 

The major distinction between these two models, from an integration perspective, is the scale of operations. The following diagram depicts the two models. 

Figure 17: EMR Integration Pattern

Since the local EMR pattern is able to continue providing many services with the network down, it is often deployed to small practices or those without adequately reliable network availability. However, this pattern requires local technical skills and resources (for maintenance, operation, upgrades, patches, support, disaster recovery, backup, etc.). 

The application service provider (ASP) pattern provides a centrally managed and highly-available service for providers. It has a light local footprint and can be rapidly deployed to new environments. It is highly dependent on high-quality network services being available to the provider, and therefore network instability is a critical operational issue. Local EMRs will connect directly to a HIAL segment, while shared EMRs in an ASP model will have the ASP‘s system connect to the HIAL segment.

Radiology Systems

The integration pattern for diagnostic imaging has some unique characteristics:

  • There are different kinds of data of interest – actual images (e.g. x-rays) and documents – specifically, reports and manifests (documents that indicate the images that are part of a study and their location). Images are far bigger in terms of file size than documents.
  • Currently there are four diagnostic imaging repositories (DI-Rs) in place across the province, each of which stores images, reports, and manifests for a different part of the province. These repositories are built with different technologies which support interoperability between systems within their respective regions. Users are currently limited to accessing diagnostic imaging data from within their regional diagnostic imaging repository. With the proper credentials a user in one repository could access data in another via a supported access channel. However, to provide consolidated view of data across all four repositories, a common service approach is required (see below). 
  • Data comes into these repositories from radiology systems (picture archiving and communication systems (PACS), or radiology information systems), but needs to be accessible not only by radiologists but also by other types of providers who do not use these systems.
  • The vision for diagnostic imaging integration is to provide diagnostic imaging common services (DI-CS), through the eHealth Ontario HIAL segment, to allow for searching and retrieval of diagnostic imaging data for a health care client across the province at once. Reports and images will be accessible via various channels.

The following diagram shows the anticipated integration pattern to put images and documents into the EHR. 

Figure 18: Diagnostic Imaging PUT Integration Pattern 

The following diagram shows the anticipated integration pattern for conducting a search across the entire province for diagnostic imaging information on a health care client.

Figure 19: Diagnostic Imaging GET Integration Pattern

Laboratory Information Systems

Currently, hospitals, community labs, and public health labs are populating OLIS with lab orders and reports. They are doing so using the OLIS interface specification; OLIS SOAP messages carry a HL7 V2 compliant payload, travel over an SSL mutually authenticated channel, and are digitally signed. At present, most OLIS clients (users or systems) connect directly to OLIS. When the eHealth Ontario HIAL segment is ready, OLIS services will be accessed through it and the integration pattern will be similar to that used for integration of other point of service systems.

Systems in Community Care Settings

Entitled community health care providers with a clinical system can access the EHR through one of following three paths: 

  • Connecting through local integration tools provided by the regional HIAL segment or an interface engine 
  • Connecting to a segment of the Ontario HIAL Solution directly using web services 
  • Connecting to a portal service provider and consuming EHR services through another affiliated organization 
  • The integration pattern is similar to the ones described in this section for direct connections via web services or as described in the section below describing integration using portals.
Back to Top

Explore the Blueprint

Multiple views describe the many ways the blueprint supports EHR delivery.

Get Us Involved

From advisory consultations on blueprint alignment to standard selection, we can help you align, adopt and implement solutions.

Contact Us

Stay Up To Date

Published four times a year, the Blueprint Bulletin provides readers with regular insight into the elements, services and new developments associated with the Ontario eHealth blueprint.

Looks like you’re using an old browser.

To view this site, you’ll need to upgrade your browser.

Upgrade Now