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

Communication Services

The HIAL is the integration point between all point of service applications and service providers. Both EHR service consumers and service providers communicate through this layer, removing the need for them to create and maintain their own point-to-point connections with each other. The communication services provide all the necessary services to connect and send and receive messages in the appropriate formats. 

These services are the gateway layer that creates the separation between the point of service applications and the registries, domain repositories, applications, and other resources. They allow point of service applications to connect and access, put, or use information in the shared resources layer. 












Figure 6: Communication Services


Encrypt/decrypt: responsible for encrypting the communication channel between the service consumer and the HIAL, usually via an encrypted Transport Layer Security (TLS) connection with an asynchronous key exchange. Messages passing through the HIAL need to be parsed for processing, so the incoming messages should not be encrypted by the service invoker; the encrypted channel provides sufficient security.

Parser: breaks a data structure into smaller elements according to a set of rules that describe its structure. For example, a phone number consists of an area code, prefix and suffix. In the eHealth Ontario context, examples of standards the parser must support include HL7v2 (pipe delimited and XML), HL7v3 and XML.

Encode/decode: encodes and decodes messages from and to different coding formats such as UTF-8, EBCDIC, and Base64

Serialization: packages the message in the destination format, e.g. XML, flat file positional, flat file fixed field length


Caching: manages the cache and provides functions related to cached responses based on configured settings. The purpose of caching is always to drive performance improvements.

Session management: performs security session management so all services and transactions are ‘idempotent’ (i.e. giving the same result no matter how many times they are applied) and thus ‘stateless’ in nature. This means that exposed services do not store ‘stateful’ data that could be reused across multiple consumer service calls. Security sessions are an outcome of the use of the authentication service – applications insert a security token as part of every service invocation and the session management service validates the security token to control the session’s lifecycle.


Application protocol: supports the use of application level communication protocols to enable communication channels with point of service applications. Application layer functions typically include identifying communication partners, determining resource availability, and synchronizing communication. This service will support MLLP, HL7v2.x, HL7v3, XML, SOAP 1.1, WS-ADDRESSING, WS-NOTIFICATION, WS-SECURITY, WS-SECURITYPOLICY, WS-POLICY, WSDL, HTTP(S), (S)FTP, Connect Direct (mainframe), SMTP, SNMP, and TLS 2.1 (OSI Layer 6) and others that will be required in the future. 

Network protocol: provides communication capabilities over physical networks. The primary network protocols that will be supported are TCP/IP and IP/SEC.


Interoperability: provides the capability required to support interoperability at various levels within the EHR

Service catalogue: a central repository or service registry that allows for the cataloguing of eHealth Ontario services. It allows service consumers to search for details about service providers, the functional areas (taxonomies) these services address, and binding details (location, service contract, transport, etc.) for services. 

Broker: provides support for brokered HIAL patterns, where several HIAL segments can participate and fulfill services. It allows for service requests to be evaluated and brokered to other HIAL segments or separate transaction processing environments. 

Routing: routes messages to internal integration channels. Routing service functionality includes static/deterministic routing, content-based routing, rules-based routing, and policy-based routing. 

Mapping: creates a map file that translates a source document format to the destination format, including mapping of fields and mapping using business rules or algorithmic conversions

Queuing: provides store and forward capabilities. Message queues provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time. Messages placed into the queue are stored until the recipient retrieves them. The message queuing service provides enhanced resilience functionality to ensure that messages do not get lost in the event of a system failure.

Alert/notification: provides support for handling system alerts. For example, when an alert condition is triggered, the service notifies the corresponding users and/or systems. This service ties into, and works closely with, the publish/subscribe service. An alert notification is triggered by an event that may occur at the HIAL level, at the point of service level, or at the line of business application level. When an applicable event occurs, an alert is pushed out to appropriate recipients via email, fax, phone, SMS or pager.

Publish/subscribe: used to decouple providers and consumers of EHR data. It allows the producers of data to publish information to a topic with no knowledge of the recipients of that data. This service s used for system-to-system communication only. 


Management: provides tools to monitor service execution and enforce policies in order to manage the availability and performance of eHealth Ontario services. These tools include dashboards for monitoring, and service level arrangement reporting for application services. They also cover exception and error reporting and management for the HIAL, and transaction processing.

Configuration: provides centrally-established capabilities to manage the parameters of EHR services

Exception/error handling: provides an interface to raise and manage errors and other business level exceptions. Exceptions can range from system / application level exceptions to exceptions found as a result of corrupt or invalid data and other such conditions.

Logging: allows for the construction of immutable auditable logs for the purposes of traceability, dispute resolution, security, privacy, and compliance with policy (external and internal) and laws. It does not refer to ‘system’ logging’ that is normally produced for system and application debugging.

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