EHR Connectivity Requirements

EHR Connectivity
Requirements
for Point of Service
(POS) Procurements
Version: 1.0
INTRODUCTION ............................................................................................................................................. 1
PURPOSE ....................................................................................................................................................................1
BACKGROUND ............................................................................................................................................................1
WHY CONNECT TO THE PROVINCIAL EHR? .............................................................................................................1
POS REQUIREMENTS & INTEGRATION OVERVIEW ........................................................................ 2
POS FUTURE & CURRENT STATE ..............................................................................................................................3
EHR CONNECTIVITY REQUIREMENTS ................................................................................................. 5
EHR ASSET INVENTORY ........................................................................................................................... 16
DOCUMENT REFERENCES ....................................................................................................................... 17
EHR Connectivity Requirements for POS Procurements v 1.0
i
COPYRIGHT NOTICE
Copyright © 2015, eHealth Ontario
ALL RIGHTS RESERVED
No part of this document may be reproduced in any form, including photocopying or transmission electronically to
any computer, without prior written consent of eHealth Ontario. The information contained in this document is
proprietary to eHealth Ontario and may not be used or disclosed except as expressly authorized in writing by eHealth
Ontario.
TRADEMARKS
Other product names mentioned in this document may be trademarks or registered trademarks of their respective
companies and are hereby acknowledged.
EHR Connectivity Requirements for POS Procurements v 1.0
ii
DOCUMENT CONTROL
The electronic version of this document is recognized as the only valid version.
APPROVAL HISTORY
APPROVER(S)
APPROVED DATE
EHR Governance Business &
Technical Committee
2015-06-17
REVISION HISTORY
VERSION
DATE
SUMMARY OF CHANGE
CHANGED BY
0.01
2014-10-09
Initial draft
eHealth Ontario
0.04
2014-10-17
Feedback from Solution Architects
eHealth Ontario
0.05
2014-11-14
Feedback from external and internal reviews
eHealth Ontario
0.06
2015-01-19
Document changed to focus on all Point of Service systems
rather than just HIS. Additional feedback provided from
external reviews.
eHealth Ontario
0.7
2015-01-29
General updates. Feedback from Security and Standards.
eHealth Ontario
Updates from Architecture, feedback from external
reviews and Standards.
- Removed mandatory/optional
- Removed ODB service requirement as this is
currently out of scope
eHealth Ontario
0.8
0.9
2015-03-09
Draft for comment by Ontario EHR Architecture &
Standards Governance Committees
eHealth Ontario
0.95
2015-05-11
Updated draft
eHealth Ontario
0.10
2015-05-14
Technical Writer finalization
eHealth Ontario
1.0
2015-07-03
Final for publication
eHealth Ontario
1.1
2015-07-24
Update per MOHLTC request July 16, 2015
eHealth Ontario
DOCUMENT ID
4043
DOCUMENT SENSITIVITY LEVEL
Low
EHR Connectivity Requirements for POS Procurements v 1.0
iii
CONTENTS
INTRODUCTION ................................................................................................................................................ 1
PURPOSE ....................................................................................................................................................................... 1
BACKGROUND ............................................................................................................................................................... 1
WHY CONNECT TO THE PROVINCIAL EHR? ................................................................................................................ 1
POS REQUIREMENTS & INTEGRATION OVERVIEW ........................................................................... 2
POS FUTURE & CURRENT STATE ................................................................................................................................. 3
EHR CONNECTIVITY REQUIREMENTS .................................................................................................... 5
EHR ASSET INVENTORY .............................................................................................................................. 16
DOCUMENT REFERENCES .......................................................................................................................... 17
EHR Connectivity Requirements for POS Procurements v 1.0
iv
INTRODUCTION
PURPOSE
This document describes provincial electronic health record (EHR) connectivity requirements to be used by health
care stakeholders in the procurement of point of service (POS) systems. It is a component of Ontario’s EHR
Connectivity Strategy.
BACKGROUND
A POS is an application used by health care providers for viewing or managing client personal health information
(PHI). This includes hospital information systems (HIS), community and ambulatory health information systems, and
provincial/regional EHR viewers. Electronic Medical Record (EMR) systems are out of scope for this document. EHR
Connectivity Requirements for EMRs are defined by Ontario EMR Specifications managed by OntarioMD.
POS systems meeting the requirements listed below will be strategically positioned to integrate with key provincial
EHR assets and pre-enabled for the province-wide exchange of clinical information. Conformance to specific
requirements (e.g. Security Assertion Markup Language (SAML)) will enable streamlined clinician access to provincewide systems, including:

EHR services from connecting greater Toronto area (cGTA) and connecting northern and eastern Ontario
(cNEO)

ClinicalConnectTM from connecting south west Ontario (cSWO)

Ontario Association of Community Care Access Centre’s Client Health and Related Information System
(CHRIS)

Ontario Telemedicine Network (OTN), Cancer Care Ontario (CCO)
This document will be reviewed by the Ministry of Health and Long Term Care’s Hospital Information System
Renewal Advisory Panel and additional updates to the requirements will be made based on feedback received.
WHY CONNECT TO THE PROVINCIAL EHR?
POS systems are designed to support integrated access to health care information, at any time and from any
location. Providers need a comprehensive, up-to-date view of their patients’ personal health information from all
health care providers and organizations involved in their care, from all disciplines, and including medication history,
test results, allergies, immunizations, hospital reports, office and ambulatory consultations, encounter history,
diagnostic results, and assessments. This information may also need to be shared with other providers supporting
the patient.
In order for POS systems to support integrated access to and sharing of health care information they must be
interoperable with Ontario’s EHR assets. Interoperability allows systems to connect to, exchange with, and process
data from other systems, so that information sent from one system can be understood by another.
EHR Connectivity Requirements for POS Procurements v 1.0
1
POS REQUIREMENTS & INTEGRATION OVERVIEW
To help POS system procurements achieve EHR interoperability, it is recommended that the requirements listed in
this document be included in procurement documentation (e.g. Requests for Information, Requests for Proposals,
Business Cases, Contracts, etc.). The requirements support POS connectivity to provincial assets such as the provider
and client registries and the clinical data repository (CDR); they are considered the core architectural considerations
a new POS system should support.
A significant effort is required to integrate with any EHR service. Suggested priorities for the most gain for effort are:
1.
POS single sign on (SSO) and federation with regional/provincial viewers: Providing increased access to
client information, single sign-on means that once providers have logged on to their POS system, no
subsequent logons are required. Federation is a form of single sign-on, but on a provincial scale, where a
single logon provides access to all solutions participating in the provincial federation. Context sharing is the
ability to specify a client in the POS system and see a provincial view of the client’s information.
2.
Integration requirements that ensure use of client and provider identifiers: Ensuring the use of common
identifiers amongst other EHR services will help validate clients and providers and improve data integrity.
3.
Direct integration to repository services: Access to EHR provincial repository data (e.g. CDR, OLIS, DICS)
from a provider’s POS will simplify the workflow and lookup of patient data.
Each POS initiative must specify the business requirements for the type of interoperability it will require.
Stakeholders should contact eHealth Ontario’s Architecture, Standards, and Planning division for help with the
integration effort: architecture@ehealthontario.on.ca.
EHR Connectivity Requirements for POS Procurements v 1.0
2
POS FUTURE & CURRENT STATE
The following diagram illustrates how POS systems will connect to EHR assets in Ontario in the future. The health
information access layer (HIAL) and the services that it provides play a key role in enabling interoperability. For more
details, refer to the EHR Connectivity Strategy.
Fig. 1: Point of Service Future State
EHR Connectivity Requirements for POS Procurements v 1.0
3
The following diagram illustrates how POS systems such as EMRs currently connect with EHR assets. For more details,
refer to the EHR Connectivity Strategy.
Fig 2: Point of Service Current State
For a high-level, future state view of the EHR landscape in Ontario, refer to Ontario’s eHealth Blueprint.
For questions or comments contact the Architecture, Standards & Planning team at eHealth Ontario:
architecture@ehealthontario.on.ca.
EHR Connectivity Requirements for POS Procurements v 1.0
4
EHR CONNECTIVITY REQUIREMENTS
The following requirements for POS systems interoperability with EHR assets is provided as guidance to organizations
planning POS system procurement. Organizations still require thorough vetting to ensure alignment of clinical
requirements.
This document will be updated regularly to reflect progress and change as Ontario advances towards realizing the
EHR blueprint. A robust standards governance process ensures that new standards and updates to existing standards
are aligned and backwards compatible to the greatest extent possible. To learn more about standards governance
and/or to monitor ehealth standards, visit eHealth Ontario Architecture, Standards and Planning.
The Document Reference Section provides links to references found in the requirements descriptions. The content of
these links (i.e. the actual technical specification detail) should be included in Requests for Proposals (RFPs).
Requirement: EHR Service Transport Interoperability
Description
The POS solution will support common Health Information Access Layer (HIAL) based connectivity and
integration for access to provincial and regional EHR assets (described in other requirements). HIAL standards
include:
 SOAP 1.1

WS-I Basic Profile 1.1

WS-Addressing 1.0

WS-Security 1.1

SAML Token Profile 2.0

WS-Policy 1.5

WS-Trust 1.3

WSDL Specification version 1.1
Expected Response from Vendor
Preference will be given to responses that can demonstrate conformance to these specifications, and provide
descriptions of past implementations with other POS integration efforts. The SOAP and WS technical standards
form a common set of interoperability specifications used by the HIAL.
Rationale
Some technical specifications enable connectivity to many provincial EHR services. All provincial EHR assets are
accessed through the provincial HIAL.
EHR Connectivity Requirements for POS Procurements v 1.0
5
Requirement: Provincial Client Registry (PCR)
Description
The POS solution will feed local health care client identification information to the provincial client registry (data
out), and integrate with the provincial client registry to maintain the accuracy of the POS’s client information
(data in). This integration can occur through conformance to the following specifications:

eHealth Ontario’s provincial client registry standard (access to these services is through the provincial
HIAL)

Ontario Electronic Master Person Index (EMPI) Passive Integration- HL7 Specification Guide

Provincial Client Registry IHE PIX PDQ v2 Implementation Guide

Provincial Client Registry IHE PIX PDQ v3 Implementation Guide
Expected Response from Vendor
Preference will be given to responses that can demonstrate previous experience integrating with external client
registries in other jurisdictions. Experience with the listed specifications, and with leveraging common client
identifiers among participating systems through both a data out and data in integration mechanism, is
preferred.
Rationale
Every person who receives care in Ontario, regardless of their eligibility for government funded health services,
is to be unambiguously identifiable by a unique identifier, used uniformly across the province. The provincial
client registry is the definitive source for a health care client’s identity, facilitating the unique, accurate and
reliable identification of individual clients and others who receive care in Ontario, across the disciplines in the
health care sector.
The provincial client registry is fed by a number of data sources, including the registered persons database
(RPDB) used by OHIP, systems that are used by hospitals to track admissions, discharges, and transfers
(admission, discharge, transfer (ADT) systems), and other systems that participate in health care services. It
includes the functionality of the enterprise master patient index (EMPI), a service that matches records from
different sources referring to a single health care client.
Examples of services provided by the provincial client registry include:

Validating health care client identity information

Searching and resolving information from multiple sources that refer to the same health care client
identity

Obtaining summary and detailed demographic information about a health care client

Adding and updating a health care client record

Merging and unmerging health care client records (because they either do, or do not, refer to the same
individual)

Reconciling duplicates
EHR Connectivity Requirements for POS Procurements v 1.0
6

Managing publish/subscribe notifications of adds, updates, merges and splits to downstream systems
Without a common client registry, and common algorithm and data for linking and un-linking client identifiers,
EHRs cannot be reliably associated with a specific person. A single provincial client registry, one that is
considered the provincial authoritative source of client identifiers by all EHR viewers, is therefore essential to a
provincial EHR. Hospital Information Systems (HIS) currently feed Ontario’s provincial client registry and
contribute local identifiers to help form single linked client records.
POS solutions can actively integrate and use the provincial client registry to ensure the accuracy of client
information that may have been collected through other points of interaction with the health care system.
Requirement: Provincial Provider Registry
Description
The POS solution will feed local health care provider identification information (mnemonics and demographics)
to the provincial provider registry (data out), and actively integrate with the provincial provider registry to
maintain the accuracy of the POS solution’s provincial view of provider information (data in).

Data-in: Ontario PR specification for PR

Data-out: Custom format currently, and HL7v3 format in the future: access to these services is through
the provincial HIAL
Expected Response from Vendor
Preference will be given to responses that can demonstrate previous experience integrating with external
provider registries in other jurisdictions. Experience with the listed specifications, and with leveraging common
provider identifiers amongst other integrated systems, is preferred.
Rationale
The provider registry is the authoritative source of information about providers and health care service delivery
locations for use by EHR solutions. It facilitates the unique and accurate identification of any individual or
organization providing health services in Ontario, or participating in the collection, use, or disclosure of PHI
across the continuum of care.
The registry assigns a unique provincial identifier to each provider, and maintains information about them,
including professional accreditations (e.g. licenses, professions, specialties). It is fed by regulatory colleges,
Ministry of Health and Long-Term Care databases, hospitals, and other organizations. The provider registry:

Positively identifies providers

Provides information on providers, including credentials, status, documented restrictions of activity,
work locations, and relevant health care organization affiliations and local privileges

Provides information on providers to enforce consent directives province-wide
EHR Connectivity Requirements for POS Procurements v 1.0
7
Examples of services provided by the registry include:

Searching and resolving a provider’s identity

Searching and getting provider organization data and locations

Obtaining provider information (e.g. current status of professional accreditations)
A common provider registry is necessary for consistent, province-wide enforcement of patient consent
directives and ehealth service authorization. POS solution access to this information improves the quality of
provider information residing in the POS.
Note: While a provincial provider registry exists today, providing information on over 400,000 providers
throughout Ontario, the ability to accept provider feeds from hospitals is forthcoming. Contact the Architecture,
Standards, and Planning division at architecture@ehealthontario.on.ca to enquire about the status of these
specifications.
Requirement: Lab Results - OLIS
Description
The POS solution will be able to exchange lab orders, lab referrals, and lab results with OLIS. Access to these
services will be through the provincial HIAL. For further details, see eHealth Ontario’s OLIS standard.
Expected Response from Vendor
Preference will be given to responses that can demonstrate previous experience integrating with OLIS in other
deployments. Experience with the Pan-Canadian Laboratory Messaging and Nomenclature (pCLMN)
specification would also be valuable.
Rationale
The Ontario Lab Information System (OLIS) is a single provincial domain repository that allows all Ontario
laboratory test order and result information to be exchanged electronically and securely between authorized
practitioners and laboratory service providers. It also provides the Ministry of Health and Long-Term Care with
de-identified program management information.
The repository is responsible for managing and storing all laboratory test orders and reports, providing access
that can be retrieved by POS systems. Data is currently transmitted to OLIS when lab technicians submit lab test
results. In future, data will also be transmitted to OLIS when providers order lab tests.
EHR Connectivity Requirements for POS Procurements v 1.0
8
Requirement: Diagnostic Imaging Repository Integration (DI Common Services)
Description
The POS solution will be able to retrieve DI reports and image manifests (enabled in Release 2) from the
provincial DI reports repository, and integrate with DI Common Services. Access to these services will be through
the provincial HIAL. For further details, see eHealth Ontario’s DI CS standard.
For additional details on how DI CS is implemented, see:

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles 2.2.10 CrossEnterprise Document Sharing (XDS)
Image retrieval specifications include:

Digital Imaging and Communications in Medicine (DICOM)

Web Access to DICOM Persistent Objects (WADO)
Expected Response from Vendor
Preference will be given to responses that can demonstrate previous experience with integrating DI Reports
repositories in other implementations, and implementing with the above listed specifications.
Rationale
Diagnostic imaging repositories contain health care client diagnostic imaging reports and digital images such as
x-rays, magnetic resonance imaging (MRIs), and ultrasounds. There are four diagnostic imaging repositories in
Ontario (known as DI-Rs), each serving a different geographical area in the province.
DI Common Services will provide a way of searching and exchanging diagnostic images and reports from across
all the repositories and leverage common services, an XDS-I registry and repository, consent, and audit. POS
solutions (i.e. HIS) may have to consider how this would complement their existing Radiology Information
Systems (RIS).
Requirement: Single Sign On (SSO) / Patient Context
Description
The POS solution will support single sign on (SSO) and patient context sharing between federated healthcare
solutions. The SSO solution is based on OASIS SAML Specification version 2.
For further details, see the single sign on and patient context sharing specification.
Expected Response from Vendor
EHR Connectivity Requirements for POS Procurements v 1.0
9
Preference will be given to responses that can demonstrate previous experience participating in SSO with other
systems, leveraging external identity providers, and/or exchanging patient context, as well as the
implementation of the above listed specifications.
Rationale
Single sign on (SSO) is the process where a user logs on once to their POS system, and is able to access a range of
EHR applications through multiple channels without having to logon again during that session (e.g. a user with
account issued by a hospital can access eHealth Ontario, cGTA, cNEO, CCO and OTN portals).
Benefits for health care providers:

Users do not need to have, and remember, multiple user IDs and passwords

Simplified and improved access to patient information and therefore improved patient outcomes

Number of health care providers (HCPs) who can access health care applications can be increased
rapidly
Benefits for health service providers:

Supports sharing of hospital and LHIN-based health care application solutions

Allows organizations to leverage existing assets to improve total cost of ownership (TCO) and maximize
return on investment (ROI)

Simplifies administrative, business, agreements and technical interaction between health care
organizations

Standardizes identity validation and authentication across the province
With SSO initiated from a POS system, providers are able to obtain relatively seamless access to further
comprehensive, up-to-date and relevant patient data.
Requirement: CDR Integration through XDS
Description
The POS solution will support integration with clinical data repositories (CDRs) through the cross enterprise
document sharing (XDS) standard for the purposes of sharing patient records:

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles 2.2.10 CrossEnterprise Document Sharing (XDS)
Expected Response from Vendor
Preference will be given to responses that can demonstrate previous experience implementing integration with
EHR Connectivity Requirements for POS Procurements v 1.0
10
repositories using the XDS standard.
Rationale
EHR initiatives in Canada have initially focused on sharing electronic information in the clinical lines of business,
especially labs, drugs, and diagnostic images. This focus was adopted to fulfil the immediate needs of clinicians
through information sharing. However, clinicians want to share and access other types of information when
providing care. These will be stored in the clinical data repository (CDR).
Examples include adverse reactions, sensitivities, allergies, intolerances, health concerns, health conditions (a
health state that persists over time and requires intervention or management as opposed to a point-in-time
observation), personal health characteristics, health care plans, client teams, episodes of care, encounters, etc.
The CDR will also store information such as hospital discharge summaries, consultation reports, emergency
department reports, medication and drug profiles reports, cardiovascular, neurophysiology or respiratory
reports, community care reports, etc. Services will allow users to search, list, retrieve, enter, and update
information.
Ehealth in Ontario has adopted the XDS standard as a method for health care systems to access provincial and
regional clinical data repositories (CDRs).
Requirement: Clinical Document Architecture (CDA) Release 2 (R2)
Description
The POS solution will support the clinical document architecture (CDA) release 2 (R2) standard for the exchange
of clinical documents between healthcare systems. At a minimum, the POS solutions shall support CDA R2 level
1 documentation. Specifically, the POS solution should support eHealth Ontario’s provincial CDA header
standard.
Expected Response from Vendor
Preference will be given to responses that can demonstrate previous experience implementing CDA R2 level 1
for exchange of documents between the POS and other systems. Experience with implementing level 2 and 3
would also be valuable.
Rationale
eHealth Ontario has adopted the CDA R2 standard to support access to provincial and regional clinical data
repositories (CDRs). Conformance to this specification significantly eases the ability of HIS to exchange clinical
information with provincial EHR services.
EHR Connectivity Requirements for POS Procurements v 1.0
11
Requirement: Clinical Data Repository Integration
Description
The POS solution will integrate and feed data to the cGTA CDR, which will transition to the provincial CDR, and
be accessible through the provincial HIAL. See the clinical data repository specification for more details.
Expected Response from Vendor
Preference will be given to responses that can demonstrate previous experience implementing integration with
other external clinical data repositories.
Rationale
There is great clinical value in POS systems having access to and feeding patient information to a central CDR, as
it gives them access to province-wide clinical documents for their patients, including hospital discharge
summaries, care plans, allergies, and family history information.
Requirement: EHR Security Policies
Description
The POS solution will align with the EHR security policies as developed by eHealth Ontario which focus on the
following roles:

Data contributor

Identity providers (SSO)

Viewing

Program office
These requirements are intended for health information custodians (HICs) who are responsible for requiring
vendors to implement the policies where they play a supporting role.
As of the authoring of this document, some, but not all the security policy documents have been published.
Published documents can be found on the eHealth Ontario website.
Further documents can be requested from architecture@ehealthontario.on.ca.
Expected Response from Vendor
Preference will be given to responses that can demonstrate previous experience implementing and supporting
EHR-related security policies.
EHR Connectivity Requirements for POS Procurements v 1.0
12
Rationale
eHealth Ontario has developed the following EHR security policies through the governance group of the
connecting security committee; these policies, which define requirements for EHR solution participants, may be
updated over time:

Information Security Policy

Acceptable Use of Information and Information Technology

Access Control and Identity Management Policy for System Level Access

Local Registration Authority Practices Policy

Business Continuity Policy

Cryptography Policy

Electronic Service Providers Policy

Information Security Incident Management Policy

Information and Asset Management Policy

Network and Operations Policy

Security Logging and Monitoring Policy

Systems Development Lifecycle Policy

Physical Security Policy

Threat Risk Management Policy
Requirement: Terminology Standards
Description
The POS solution will support multiple terminology standards to meet clinical, administrative, and health
analytics purposes. The system capability for collecting, using, transmitting, and storing terminology standards
will determine how the terminology can be used. Some systems include terminology within an application;
others support terminology knowledge bases with terminology data sets applied when the data is accessed.
Decisions regarding terminology use should consider the purpose, the systems available to support the use, the
terminology/code system rules, and terminology management guidance.
Examples of terminology standards include:

SNOMED-CT (Systematized Nomenclature of Medicine – Clinical Terms)
(to access this page you need to create an account and log in to InfoCentral)

LOINC (Logical Observation Identifiers Names and Codes)

pCLOCD (Pan-Canadian LOINC Observation Code Database)
(to access this page you need to create an account and log in to InfoCentral)
EHR Connectivity Requirements for POS Procurements v 1.0
13

HL7 Value Sets
https://infocentral.infoway-inforoute.ca/2_Standards/1_pan-Canadian_Standards/Terminology/3_panCanadian_Terminology_Artifacts
(to access this page you need to create an account and log in to InfoCentral)

ICD-10-CA (International Statistical Classification of Diseases and Related Health Problems, 10th
Revision – Canadian Enhancement)

CCI (Canadian Classification of Health Interventions)
Terminology standards and terminology sets/subsets will continue to evolve and be released by eHealth Ontario
and other standards development and supporting organizations. Ehealth Standards at eHealth Ontario advises
vendors and others participating in procurements to monitor the above websites for the most current version
and related relevant historical versions to support current and historical analytics and use of the terminology
standards, including information related to licensing and terms of use. The terminology worksheet and
associated implementation guidance included in our published standards addresses terminology specific
guidance, and may be another source of more specific information to use in demonstration, testing or validation
of systems use of terminology. eHealth Standards at eHealth Ontario uses international and national standards,
and monitors the standards development and implementation activities for improved practices and
opportunities to advance balanced standardization, while supporting innovation.
Expected Response from Vendor
Preference will be given to responses that can demonstrate previous experience implementing terminology
standards in the system and within data exchange (e.g. HL7 messages), as well as those that demonstrate
alignment and use of the standards, and to vendors with appropriate membership/adherence to the terms of
use agreements/licensing expectations for the specific terminologies, for example:

Infoway: Standards Collaborative Premium Membership

Canadian Institute for Health Information recognized vendor
Rationale
Making use of commonly used terminology standards greatly increases the opportunity to interoperate with
other EHR systems, ensuring both integration and sematic interoperability amongst participating systems.
Requirement: Hospital Report Manager (HRM)
Description
The POS solution will support HRM interfaces to enable sharing medical record reports with clinician EMRs.
HRM is an eHealth solution that enables clinicians using an OntarioMD-certified EMR offering to securely receive
EHR Connectivity Requirements for POS Procurements v 1.0
14
patient reports electronically from participating sending facilities. HRM electronically delivers text-based
medical record reports, (e.g. discharge summary), and transcribed diagnostic imaging reports (excluding images)
from sending facilities directly into a patients' chart, within the clinician's EMR.
For further details, see the clinical data repository specification, which is also used for HRM.
Expected Response from Vendor
Preference will be given to responses that can demonstrate previous experience integrating POS systems with
HRM interfaces, while aligning with the listed standards.
Rationale
Making use of common HRM interfaces greatly increases the opportunity to interoperate with other EHR
systems, ensuring both integration and sematic interoperability amongst participating systems.
Note that organizations interested in integrating with HRM should contact OntarioMD. See OntarioMD’s HRM
website for additional details.
EHR Connectivity Requirements for POS Procurements v 1.0
15
EHR ASSET INVENTORY
The previous sections have listed the base requirements to connect to the EHR assets hosted by eHealth Ontario.
There are however many more ehealth solution assets in the province that you may want to consider integrating
with, based on the requirements of your POS system.
The EHR Asset Inventory provides a comprehensive list of strategic and tactical ehealth assets integral to
transitioning Ontario’s EHR from the current to the future state.
EHR Connectivity Requirements for POS Procurements v 1.0
16
DOCUMENT REFERENCES
1.
CDA Header iGuide, April, 2014.
2.
cGTA CDR Specification. Contact eHealth Ontario for details: architecture@ehealthontario.on.ca
3.
Cross-Enterprise Document Sharing Specification
4.
Diagnostic Imaging Common Services Project. CDA & XDA Implementation Guide – Rel 1. February, 2014.
5.
eHealth Ontario’s Provincial Client Registry Standard. May, 2013.
6.
eHealth Ontario’s PR Specifications. Contact eHealth Ontario for details: architecture@ehealthontario.on.ca
7.
Health Care Provider Guide – Diagnostic Imaging Common Service Project, Rel 1. 2014.
8.
Hospital Report Manager (HRM) Specification.
9.
IHE Master File Specification for Staff (Chapter 8).
10. OLIS Interface Specifications, May, 2014.
11. Ontario’s eHealth Blueprint, November, 2014.
12. Single Sign On and Patient Context Sharing Specification, 2014.
EHR Connectivity Requirements for POS Procurements v 1.0
17