Resources

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

Other Systems Connecting to the EHR

There are a number of other non-clinical systems that can benefit from connectivity with the EHR. These include systems belonging to the Ministry of Health and Long Term Care, the Ministry of Community and Social Services, the Agency for Health Protection and Promotion, and health research groups. These participants do not have direct access to the personal health records of health care clients but they typically get de-identified or summary data for system management purposes.

Integrating Web Applications and Portals

Web applications and portals play a significant role in the dissemination of functionality and information associated with the EHR, as well as providing an important channel for rapid deployment and early adoption.

In settings such as hospitals, with multiple hard-to-integrate legacy systems, local portals play a critical role in presenting EHR functionality to providers. 

Web delivery channels will play a key role in disseminating information to health care clients and their supporters. Web access is the most common way for individuals to get information from the institutions that they deal with, and will become a standard tool for individuals involved in their own care or the care of others. 

Three EHR integration models for portlets in remote partner portals are supported. In two cases the partner portal owner is responsible for deploying the eHealth Ontario portlets, and in the third the portal owner is responsible for designing all aspects of the EHR integration. 

Remote Portlet Model

Remote portlets (specifically WSRP v2.0) will be leveraged to deploy provincial content in a consistent manner across multiple portals (e.g. provincial, regional, and institutional portals). This approach enables the central management of versioning and implementation, while supporting distributed deployment of functionality through the reuse of provincial portlets. Refer to the figure below.

Figure 20: Remote Portlet Model

In this scenario, a partner portal is managed and maintained locally. User accounts, security, audit logs and other administrative details are the responsibility of the portal owner. Using OLIS as an example, the portal is configured to display content from eHealth Ontario using WSRP to access the eHealth Ontario OLIS portlet. This portlet is responsible for ensuring that laboratory reports are displayed in alignment with appropriate standards and best practices. It ensures that all aspects of the lab report are displayed in the correct order on the screen, with the right details as well as correct links to other documents. The portal owner does not need to understand the lab line of business or its display requirements to use this portlet; they only need to allocate a portion of the portal screen to display the pre-formatted HTML from the eHealth Ontario portlet producer server.

When a user connects to the portal and is authenticated, a secure connection is made (using SSL), via the eHealth Ontario HIAL segment, to the portlet producer, which manages and maintains all of the logic for the OLIS portlet component. The portlet producer then sends back the appropriate markup for the portal to show the user an interface that can display OLIS lab results. At this point, no query to OLIS has been performed, and the portlet does not display any PHI.

Should the user choose to search, he/she fills out the appropriate input fields in the portlet and submits a request containing the form data, which is then sent via the HIAL to the portlet producer. The portlet producer then connects to the OLIS web services interface (again via the HIAL) and makes a properly formatted OLIS request on behalf of the user. It receives and formats the OLIS response appropriately, including both HTML display information and the data returned by OLIS, and sends it back to the portal. The portal displays this content to the user as part of the aggregated portal page.

At no point does the portal designer need to understand the details of the OLIS transaction; that information is within the OLIS portlet. All that is needed is an understanding of how to configure the portal to use the OLIS portlet.

Local Portlet Model

The second scenario is very similar to the first, except that all of the business logic built into the portlet runs locally in the portal. This could be local code, or code provided by eHealth Ontario; in either case, for this scenario, there is no need to access the portlet producer every time. The application then consumes eHealth Ontario web services via the HIAL, using the appropriate protocol (e.g. CeRx) and security. Refer to the figure below. 

Figure 21: Local Portlet Model

Continuing with the OLIS example, in this case, the user connects to a local portal, which runs the portlet code to display content. The user then fills out the appropriate fields in the portlet and submits the request. The portlet code connects to eHealth Ontario via the eHealth Ontario HIAL segment, and submits a properly formatted OLIS request containing the details provided by the user. OLIS returns the information to the portlet which formats the data for presentation to the user. 

As in the remote services example, the portal owner does not need to understand the workings of OLIS in order to use the portlet, only how to deploy and configure it.

Local Implementation Model

In the last scenario, all of the development and design work is done by the portal owner. This is the most technically challenging and complex scenario. The portal developer simply consumes the underlying EHR web services directly. 

This approach requires the portal developer to properly understand the business details of the EHR and the application (in this example, OLIS). It requires the developer to understand what should be displayed, where it should be displayed and how it should be displayed. This is a matter of medical functionality that requires specialized knowledge. It also means that ongoing maintenance of the functionality and presentation is the responsibility of the portal owner.

Figure 22: Local Implementation Model

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

×