From detailed guides to online courses – resources are available to provide you with the knowledge necessary to build and integrate EHR applications.
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 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.
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:
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.
The integration pattern for diagnostic imaging has some unique characteristics:
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
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.
Entitled community health care providers with a clinical system can access the EHR through one of following three paths:
Multiple views describe the many ways the blueprint supports EHR delivery.
From advisory consultations on blueprint alignment to standard selection, we can help you align, adopt and implement solutions.Contact Us