logical architecture principles - ehealth ontario | it's ... · pdf fileap-ptl-001:...

Ontario Provincial EHR

Logical Architecture Principles

Version: 1.0

Logical Architecture /Architecture Principles /Version #1.0 ii

Copyright Notice

Copyright © 2012, 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.

Logical Architecture /Architecture Principles /Version #1.0 iii

Table of Contents

Introduction 1

EHR SOA Principles 2 AP-SOA-001: The Provincial EHR is supported by a formal governance structure .............................................. 2 AP-SOA-002: eHealth foundation services and consumers are categorized ......................................................... 3 AP-SOA-003: eHealth foundation services are managed ....................................................................................... 4 AP-SOA-004: eHealth foundation services have contracts based on web services ............................................... 5 AP-SOA-005: eHealth foundation services are discoverable .................................................................................. 6 AP-SOA-006: Provincial EHR Services names describe their business function .................................................. 7 AP-SOA-007: eHealth foundation service Policies are enforceable ...................................................................... 8 AP-SOA-008: eHealth foundation services are based on established standards .................................................. 9

External/Public Services Principles 10 AP-EPS-001: Consistent set of interfaces and behaviours .................................................................................... 10 AP-EPS-002: Services to eHealth Ontario internal systems are abstracted from external consumers .............. 11 AP-EPS-003: Limited number of controlled connection points to the eHealth foundation services ................. 12 AP-EPS-004: eHealth foundation services provide different types of service modes ......................................... 13 AP-EPS-005: External/Public services are secured .............................................................................................. 14

Internal Services Principles 15 AP-IS-001: Intra-foundation Communication ...................................................................................................... 15 AP-IS-002: Bus to Bus Patterns and Service Consumption Paths ....................................................................... 16 AP-IS-003: Separation of Concerns ....................................................................................................................... 17 AP-IS-004: Authentication..................................................................................................................................... 18 AP-IS-005: Business Context Propagation ............................................................................................................ 19 AP-IS-006: Enterprise Transaction ID ................................................................................................................. 20

Data Messaging Interaction Principles 21 AP-DMI-001: Use of messaging for transactional data exchanges ...................................................................... 21 AP-DMI-002: Use of industry standards for message structures and application level protocols .................... 22 AP-DMI-003: Use of DICOM for exchanges of binary large objects in diagnostic imaging ...............................23 AP-DMI-004: Unidirectional communication pattern from consumer systems ................................................ 24 AP-DMI-005: Use of request-response messaging pattern for application level interactions ............................ 25 AP-DMI-006: Use of web services and web services protocol ............................................................................. 26 AP-DMI-008: Business Application Level Acknowledgement ............................................................................. 27 AP-DMI-009: Data Messaging Interactions are authenticated and authorised ................................................. 28

EHR Data Principles 29 AP-EHR.Data-001: EHR Data Trusteeship .......................................................................................................... 29 AP-EHR.Data-002: System of Record .................................................................................................................. 30 AP-EHR.Data-003: Authoritative Source .............................................................................................................. 31 AP-EHR.Data-004: History of EHR Data .............................................................................................................32

Logical Architecture /Architecture Principles /Version #1.0 iv

AP-EHR.Data-005: Enterprise Identifiers ............................................................................................................33 AP-EHR.Data-006: Validation of Enterprise Identifiers ..................................................................................... 34 AP-EHR.Data-007: Validation of Client Identifier ............................................................................................... 35 AP-EHR.Data-008: Validation of Provider Identifier.......................................................................................... 36 AP-EHR.Data-009: Referential Integrity .............................................................................................................. 37 AP-EHR.Data-0010: Semantic Alignment ........................................................................................................... 38 AP-EHR.Data-011: EHR Data Conservation ........................................................................................................ 39

EHR Document Principles 40 AP-EHR.Doc-001: EHR Documents are supported ............................................................................................. 40 AP-EHR.Doc-002: EHR Document has trusted authorship ................................................................................ 41 AP-EHR.Doc-003: EHR Document maintains its integrity ................................................................................ 42 AP-EHR.Doc-004: EHR Document conformance ............................................................................................... 43 AP-EHR.Doc-005: EHR Document preserve their wholeness ............................................................................ 44 AP-EHR.Doc-006: EHR Document Secure exchanges ......................................................................................... 45 AP-EHR.Doc-007: EHR Document metadata ...................................................................................................... 46

Portlet Services Principles 47 AP-PTL-001: Portlets via Web Services ................................................................................................................. 47 AP-PTL-002: Portlet Governance ......................................................................................................................... 48 AP-PTL-003: Portlet Consumption of eHealth foundation Services .................................................................. 49 AP-PTL-004: Portlet Look and Feel ..................................................................................................................... 50 AP-PTL-005: Portlets Device Independence ......................................................................................................... 51 AP-PTL-006: Inter-portlet Communication ......................................................................................................... 52 AP-PTL-007: Portlet Hosting Services .................................................................................................................. 53

Privacy Principles 54 AP-PRV-001: Collection ......................................................................................................................................... 54 AP-PRV-002: Individual‟s right of access.............................................................................................................. 55 AP-PRV-003: Disclosure and use .......................................................................................................................... 57 AP-PRV-004: Consent directives .......................................................................................................................... 58 AP-PRV-005: Emergency disclosure (“Breaking the glass”) ................................................................................ 59 AP-PRV-006: Provision of de-identified information without informed consent .............................................. 60 AP-PRV-007: Revocation of disclosure is not retroactive .................................................................................... 61

EHR Service Level Objective Principles 62 AP-SLO-001: Performance .................................................................................................................................... 62 AP-SLO-002: Availability ...................................................................................................................................... 63 AP-SLO-003: Software Quality Assurance (SQA) ................................................................................................ 64 AP-SLO-004: Monitoring ....................................................................................................................................... 65 AP-SLO-005: Business Continuity & Recoverability ........................................................................................... 66 AP-SLO-006: Capacity ........................................................................................................................................... 67 AP-SLO-007: Scalability ........................................................................................................................................ 68 AP-SLO-008: Maintainability ............................................................................................................................... 69

Time Synchronization Principles 70 AP-TS-001: Server Time Synchronization ............................................................................................................ 70 AP-TS-002: Directory Server Synchronization ..................................................................................................... 71

Logical Architecture /Architecture Principles /Version #1.0 v

AP-TS-003: eHealth Services Synchronization ..................................................................................................... 72 AP-TS-004: Support of Universal Coordinated Time (UTC) ................................................................................ 73 AP-TS-005: Storage of Date/Time ......................................................................................................................... 74 AP-TS-006: Support of Pan-Canadian Standards ................................................................................................. 75 AP-TS-007: Display of Date/Time. ........................................................................................................................ 76

Security Principles 77 AP-SEC-001: Apply ISO#27002 ............................................................................................................................ 77 AP-SEC-002: Take guidance from the Canada Health Infoway EHRS Blueprint Privacy and Security Architecture. ............................................................................................................................................................ 78 AP-SEC-003: Personal and Personal Health Information Protection ................................................................. 79 AP-SEC-004: Federated Authentication .............................................................................................................. 80 AP-SEC-005: Federated Authentication Standards .............................................................................................. 81 AP-SEC-006: Multiple Levels of Identity Assurance ........................................................................................... 82 AP-SEC-007: Identity Propagation ....................................................................................................................... 83 AP-SEC-008: Data Protection (Confidentiality) .................................................................................................. 84 AP-SEC-009: Data Protection (Integrity and Non-repudiation) ......................................................................... 85 AP-SEC-010: Transaction and Security Session Propagation ............................................................................. 86 AP-SEC-011: Transaction Independence ............................................................................................................... 87 AP-SEC-012: Assume Hostility ............................................................................................................................. 88

Logical Architecture /Architecture Principles /Version #1.0 1

Introduction

1) This document comprises the Logical Architecture Principles that apply to the implementation of the eHealth

Ontario Blueprint. It is assumed that the reader is knowledgeable in the conceptual framework that is articulated

in the eHealth Ontario Blueprint and a full understanding of these concepts is a pre-requisite to understanding

the Logical Architecture Principles as defined herein.

2) These Logical Architecture Principles are intended to be used in conjunction with the eHealth Ontario Logical

Architecture to provide the logical framework for the procurement and/or development of eHealth applications

and services.

3) The terms used in the Logical Architecture Principles are further defined in the Logical Architecture Glossary

where they deviate from industry standard terminology.

4) It is assumed that the eHealth Ontario Governance Process will provide for future enhancement to the Logical

Architecture Principles as it is understood that development of architectural layers is an iterative

process. However, unless a principle is amended in accordance with the eHealth Ontario Governance Process,

any application or services that do not adhere to the Logical Architecture Principles will be deemed to be non-

compliant with the eHealth Ontario Blueprint.


EHR SOA Principles

Principle

AP-SOA-001: The Provincial EHR is supported by a formal

governance structure

Statement The eHealth foundation services (eHFS)1 will be governed by a formal governance structure responsible for creating, maintaining and enforcing:

1. A catalogue of supported services defining the service contracts of all services. 2. A set of policies/procedures regulating how services in the catalogue can be used

A set of standards and related test / certification procedures that service consumers and producers must meet.

Rationale A formal governance structure is a requisite for managing a large collection of published services that are predictable, free from duplication, and consistent with eHealth Ontario‟s mission and stakeholder needs. The eHealth foundation services governance will ensure that a wide variety of stakeholder perspectives are considered before decisions are made.

Implications Either existing or new Service Review Committee (SRC) or Architecture Review Board service governance processes will be needed to vet additions, changes, and deletions to the service catalogue as well as changes to the policies, procedures, standards, and test/certification regimens.

The SRC‟s membership and processes should be structured to consider the views of a broad array of stakeholders

The SRC should consider the views of a broad array of stakeholders including:

o End-users: representing both internal and external clients; and

o Internal stakeholders representing risk management, security and compliance needs; and

Operational stakeholders representing those who provision, procure, manage, host, support, and maintain services

1 The eHealth foundation is a network of systems at a provincial and regional level that keeps track and makes

accessible a comprehensive picture of an individual‟s Electronic Health Record data. At a high level, it is comprised of components such as registries, repositories and common services.


Principle

AP-SOA-002: eHealth foundation services and consumers

are categorized

Statement All eHealth foundation services (eHFS) are categorized into a mandatory structured

classification for the purposes of Service Governance. This structure must allow for

distinctions between Provincial versus Hub Services as well as External versus Internal

versus Native interfaces.

Rationale These distinctions are fundamental as different levels of features and/or constraints are

offered internally versus externally. Additionally, the categorisation allows for the

distinction between the provincial level of eHealth services and the hub level of eHealth

services which is also fundamental in the approach to the development of eHealth services

in Ontario.

Implications All eHealth foundation services are designated as “internal-provincial”, “internal-hub” or “external” (i.e. public) / “internal” / “native” in the services catalogue.

Such designation must be identified in the formal submission for service approval.

Service policies may be different for internal and external / public services


Principle AP-SOA-003: eHealth foundation services are managed

Statement eHealth foundation services are managed in an on-going manner in respect to their name,

version, classification and to prevent or manage duplication.

Rationale Service consumers must have confidence that they are invoking the appropriate service at

any time. Service discovery and binding are dependent on the proper management of

services names and versions A minimized level of duplication will reduce maintenance

costs and system complexity.

Implications The Service Review Committee will establish and manage:

A taxonomy both for classification, and naming; and

A policy governing the use of version numbers; and

A Service catalogue listing all supported services.


Principle

AP-SOA-004: eHealth foundation services have contracts

based on web services

Statement The eHealth foundation services establish standardized contracts between service

providers and consumers that are based on the web services paradigm.

Rationale Service contracts clearly define expectations of service providers while providing service

consumers a service infrastructure that is predictable, reliable and managed.

The use of standardized service contracts is a requisite to automated quality and policy

enforcement.

Implications Standardized service contracts based on open, technology agnostic, non-proprietary standards

Different contracts may be required for different versions of a service


Principle AP-SOA-005: eHealth foundation services are discoverable

Statement Decisions and descriptions relating to services and their contracts shall be stored in a

single, well-known, accessible location, including contextual information.

Rationale Storing service contracts in a well-known accessible location is a requisite to:

Enabling service producers and consumers to identify and understand the available services

Enabling service producers to have a formal channel to make their services available

Implications eHealth Ontario will need to create, support and maintain a single authoritative metadata repository


Principle

AP-SOA-006: Provincial EHR Services names describe their

business function

Statement The names of Provincial EHR web services relay directly the business function of business

facet that they support.

Rationale Since the Provincial EHR services will be exposed to a large audience of potential users

(health application vendors and developers) and, while controlled, are meant to be

discoverable, the naming of web services should carry a meaning that can easily be

understood.

The level of granularity established in services names should take into account the amount

of regression testing associated with change management and maintenance.

Implications Services names should be established down at a level which represent a unit of business

transaction:

Put a lab result

Get a list of medication history

Get client demographics

Any given service name may correspond to one or multiple HL7 interactions.


Principle

AP-SOA-007: eHealth foundation service Policies are

enforceable

Statement Service policies shall be enforced

Rationale In order to support high quality, predictable services, policies must be enforceable and

enforced.

Implications The Provincial EHR will be managed by a service governance authority with the ability to:

Declare services as compliant / non-compliant based on evidence such as conformance testing results, and operational data

Add / remove services from the eHealth foundation services service catalogue

Add / remove services (i.e. at the ESB or hosting level)

Revoke or stop funding support

Policies applicable to services in general are defined by the service governance authority. Service contracts associated to each service define specific application of policies for each service.


Principle

AP-SOA-008: eHealth foundation services are based on

established standards

Statement Whenever possible, eHealth foundation services use of standards (e.g. messaging, data

types, terminology, communication, etc.) , interoperability specifications and best practices

formally adopted by eHealth Ontario.

Rationale Standardization is associated with increased interoperability, reduced complexity and

reduced operational and support costs, hence their use should be strongly encouraged.

Implications Non-standard integration is only to be considered when, a business case justifies why existing standards cannot be used or extended.

Non-standard integrations should not persist over time, all eHealth services must be supported through Ontario approved standards. Non -standard integration approaches should be taken through the Ontario standards harmonisation process, so as to become formal standards or be adapted to use existing standards.

To enforce standards and interoperability, eHealth Ontario will need to formally adopt specifications and a formal conformance testing process.


External/Public Services Principles

Principle AP-EPS-001: Consistent set of interfaces and behaviours

Statement The collection of external/public eHealth foundation services (eHFS) are offered as a

consistent set of interfaces and behaviours providing data and business service to

organizations and application systems that consume its portlets and data services.

Rationale Healthcare organizations and application system vendors in Ontario expect simplicity and

consistency when accessing eHealth Ontario services. They should not have to conform to

different specifications every time they need to share new domain information or access

new eHealth Ontario services. Use of consistent interfaces and service behaviours will

encourage and accelerate the adoption of the Provincial EHR.

Implications Single service governance for the Provincial EHR

Consistent idempotent services (i.e. each time a service is called, it will have the same behaviour and deliver the same result, regardless of state or context)

Common service use policies and regulations

Common service architecture

Common security requirements

Common communication specifications Common EHR data conformance standards

Single integrated support for developers and users


Principle

AP-EPS-002: Services to eHealth Ontario internal systems

are abstracted from external consumers

Statement The eHealth Ontario internal application systems that make up the Provincial EHR are

abstracted and not directly accessible to consumer organizations and applications.

Rationale Through this abstraction, the Provincial EHR hides the complexity and heterogeneity of all

its components. These application systems can be upgraded or replaced with minimal or no

impact to consumer applications that rely on the capabilities and functions they offer.

Implications This logical abstraction, also known as the HIAL – Health Information Access Layer, is achieved by the use of technologies that implement a public façade that will stand between service consumers and the eHealth Ontario internal systems.

The Health Information Access Layer (HIAL) is conceptualized as the collection of technologies and solutions that are implemented across the various access points to the Provincial EHR, including provincial and regional hubs.

Service Consumers are not aware of the internal systems that are involved in any particular service call.

Enterprise Service Bus (ESB) solutions can be used to expose these service façades to service consumers.

Other existing interface platforms are also used as components of the HIAL.

eHealth Ontario internal application systems expose their services interfaces to the HIAL, which in turns creates and exposes a corresponding set of standard-based external / public services to Service Consumers.


Principle

AP-EPS-003: Limited number of controlled connection

points to the eHealth foundation services

Statement eHealth foundation services are exposed externally through few connection points

established by eHealth Ontario.

Rationale Fewer external gateways (i.e. access points) improves security, facilitates standardization

and management of access to eHealth foundation services.

Implications The eHealth Ontario enterprise architecture will establish the actual ESB instances to be deployed in the province.

The decision on the localization of ESB instances will need to consider governance and/or business considerations and patient referral patterns. For example, initial discussions have indicated 5 possible access points:

o 1 provincial ESB for public data consumers and systems of record o 3 regional hubs o 1 provincial hub for private systems of record


Principle

AP-EPS-004: eHealth foundation services provide different

types of service modes

Statement The eHealth foundation services (eHFS) support the following types of external/public

services:

Synchronous Transactional Data Messaging Services

Asynchronous Transactional Data Messaging Services Synchronous Business Function Services

Portlet Services

Batch Services

Rationale Crucial to the standardization of external/public services is the establishment of service

categories to be supported by the eHealth foundation services. External consumers will

select which category types they will like/need to support their business requirements.

Implications The ESB supports all categories defined for the external/public services.

eHealth Ontario enterprise architecture defines


Principle AP-EPS-005: External/Public services are secured

Statement External/Public eHealth foundation Services enforce security measures that conform to the

security policy requirements established by eHealth Ontario.

Rationale Any service exposed to external access is vulnerable to attacks/penetration by unauthorized

consumers. These services must be protected through a series of security measures that

identify and prevent malicious use.

Implications The Health Information Access Layer access points enforce core required security measures as a common service for all transactions that interact with the EHR

Anonymous and non-authenticated accesses are not allowed

All patient and provider information is considered confidential and is protected during all data transmission

Service Consumers conform to the eHealth Ontario security policies


Internal Services Principles

Principle AP-IS-001: Intra-foundation Communication

Statement Communications within the eHealth Ontario foundation, between foundational

components2 , should use the eHealth Ontario public interfaces published by those

components except where:

An external / public interface does not exist (e.g.: a purely internal component)

It can be demonstrated that the use of the public interface will break non-functional performance requirements and that the use an alternative internal interface will not do the same

In any case, interactions between components should avoid direct system to system calls

and use the Health Information Access Layer through which the target component (the

service producer) exposes services.

Rationale Following this principle assists with the maintenance of a level playing field within the

eHealth ecosystem in Ontario. All service providers and consumers have the same

privileges and rely on the centrally coordinated usage of services via the Health

Information Access Layer.

Communication via the HIAL that publishes services for a component ensures

consistent application of service policies

Allows for the separation of concerns and abstraction to take place, as per principle

AP-IS-003 Separation of Concerns

Consistent use of the HIAL also promotes the use of the Common Services offered by

the HIAL

Implications Following this principle ensures that the relevant steps in the orchestrations at the HIAL / ESBs are consistently applied and that the HIAL/ESBs can assume their responsibilities in managing the flow of traffic between components. Examples are authentication, authorization, consent checking/filtering/masking, validation, sanitation, etc.

Implies that the HIAL/ESBs can apply the proper layering of security and controls in order to account for different levels of trust when services are being invoked internally. E.g. hub-hub service calls, hub-provincial, intra-hub, intra-provincial.

Performance considerations may drive implementation decisions to contravene this principle.

2 E.g.: User Registry Authorization components (PDP) invoking the Provider Registry to resolve Provider information

as input to authorization decisions.


Principle

AP-IS-002: Bus to Bus Patterns and Service Consumption

Paths

Statement While traversing the Health Information Access Layer/Enterprise Service Bus, eHealth

Services should be consumed via the most direct path possible.

Rationale Consider the following patterns of consumption:

1. Consumer -> province -> producer

2. Consumer -> hub -> producer

3. Consumer -> province -> hub -> producer

4. Consumer -> hub1 -> province -> hub2 -> producer

5. Consumer -> hub1 -> hub2 -> producer

6. Consumer -> producer

Patterns (1) and (2) have the shortest path and produce load on the fewest eHealth

components, while still traversing a service bus (see AP-IS-001 Intra-foundation

Communication). These patterns are preferred.

Patterns (3), (4), and (5) are valid, but they represent proxying of services at one level or

another. This introduces latency to the fulfillment of the request. Reduction of

accumulated latency is a key consideration in Service Oriented Architectures. However, in

certain cases this level of proxying may be desirable, for example to increase the adoption

of a particular service.

Pattern (6) is not in keeping with AP-IS-001 Intra-foundation Communication; no service

bus is traversed, so there is no opportunity for orchestration and separation of concerns

(see AP-IS-003 Separation of Concerns).

Implications Connecting the service consumer directly to the province or hub to which the service producer is connected will reduce the number of „hops‟ required to get from a service consumer to a service producer, while still retaining the consistent application of the relevant ESB orchestration steps (see AP-IS-001 Intra-foundation Communication).

eHealth Ontario provincial level resource utilization (network, authentication, authorization, etc.) will be lowered since all communication is not „routed‟ through the Provincial Services Bus.

A hub-to-hub trust model is required.

Services that are deployed to a Hub Services Bus that are destined to become a Provincial Service could be „fronted‟ by a proxy service deployed to the Provincial Services Bus. This would prevent the published location of the service from changing over time.


Principle AP-IS-003: Separation of Concerns

Statement Internal services should assume that the following are being handled by the Health

Information Access Layer/Enterprise Service Bus to which they are deployed:

Authentication (end user and system level)

Authorization

Validation (schema-level)

Message Cleansing (virus scanning etc) Privacy (consent, filtering, masking)

Transaction identification and coordination

Audit Logging (coarse-grained)

Enterprise identifier validation

Rationale HIAL/ESB orchestrations should be applied to internal services as well as external / public

services. This allows common services to be applied uniformly and consistently across

transactions and allows each internal component to concentrate on core competencies.

Implications HIAL/ESB orchestrations can be applied in a consistent way

HIAL/ESB orchestrations may elect to take shortcuts when it is known that a particular interaction is part of a larger, coordinated, transaction

Service provider systems should not provide common services handled by the HIAL/ESB

Service provider systems may apply more refined or detailed policies and rules that complement common services handles by the HIAL/ESB

o For example, the HIAL/ESB will perform coarse grained authorization. A particular internal service may then elect to also perform fine grained authorization checks

o For example, an internal service should not apply different or incompatible mechanisms for authentication. The service should accept the assertion that authentication has been performed by the service bus on its behalf.


Principle AP-IS-004: Authentication

Statement Authentication for internal services should leverage the same mechanism(s) as are used for

external/ public services.

Rationale This reuse allows for reuse of orchestration logic for authentication and authorization, and

simplifies the application of a trust model.

Implications Internal services will require authentication; there is no inherent trust “because the request came from the inside”. The requirement for authentication is applied by the service bus to which the service is deployed.

The choices of mechanisms used may lead to streamlining of the authentication and authorization checks performed during the service bus orchestration.

Fewer security model translations (e.g: from an „inbound‟ SAML2 token to an „outbound‟ certificate for simple mutual authenticated TLS) may correspond to deeper propagation of the context of the original caller, which may correspond to better application of authorization and consent rules. For example, „deep‟ components should see “Dr.X is asking for information Z” rather than “internal component Y is asking for information Z”.


Principle AP-IS-005: Business Context Propagation

Statement The originating business context should be propagated as deeply as possible.

Rationale Components may need to know about the original business context of a call to apply fine

grained authorization and consent policies.

Implications Caller identity should be propagated through all calls that are part of a „transaction‟. Service identities should be avoided; see AP-IS-004 Authentication.

Transaction identification and coordination is required, see AP-IS-003 Separation of Concerns.

“Purpose of Use” is a required part of business context, which must be propagated for privacy and consent checking.


Principle AP-IS-006: Enterprise Transaction ID

Statement All transactions processed via a Health Information Access Layer/Enterprise Service Bus

get a unique permanent identifier that can be exposed for traceability to any system that

interacts with via a HIAL/ESB.

Rationale The traceability and management of transactions touching multiple components of the

ecosystem requires the use of robust and permanent identifier.

Implications The HIAL/ESB needs to provide this enterprise identifier on a transaction by transaction basis

Service consumers and service providers connected to HIAL/ESB s must be able to recognize and carry the Enterprise Transaction ID through request/response interactions


Data Messaging Interaction Principles

Principle

AP-DMI-001: Use of messaging for transactional data

exchanges

Statement System to system interactions between consumers and the Provincial EHR rely on

messaging for transactional data exchanges:

a) required for external (public) services; and

b) optional but preferred for internal (private) services

Rationale Data exchanges associated with the Provincial EHR are wide ranging in nature and will

carry different forms, nature and size of information. The use of messages as a method to

carry information between systems is a recognized and widely adopted industry standard.

The architecture for the Provincial EHR is predicated on the application of Service Oriented

Architecture (SOA) which defines the use of messaging for data exchanges as key concept.

Implications The communication of business or clinical data between the Provincial EHR and its consumers is done through messages


Principle

AP-DMI-002: Use of industry standards for message

structures and application level protocols

Statement Data Messaging Interactions with consumer systems rely on industry recognized standards

for message structures and application level interaction protocols. This includes:

The predominant use of HL7 for the messaging of business and clinical data

The use of widely adopted industry standards for infrastructure related communications (security, web services, transport, networking)

Data Messaging Interactions for internal communication between systems inside the

Provincial electronic health record, may use other interaction protocols if required.

Rationale HL7 is a widely adopted industry specific standard for communication in healthcare.

Application vendors in the healthcare market, those who will need to connect their systems

to the Provincial EHR, know HL7, often already support it in their applications, and

generally follow its evolution.

Implications Message structures defining what data is exchanged, what form the data will take, in which context data is exchanged, what terminologies and vocabularies are used is based on HL7 International Standards

Such standards need to be validated, adopted and established as eHealth Ontario Approved Standards before being used in the context of the Provincial EHR


Principle

AP-DMI-003: Use of DICOM for exchanges of binary large

objects in diagnostic imaging

Statement System to system interactions in the context of diagnostic imaging when transacting

imaging artefacts will use the industry standard DICOM protocol.

Rationale Industry standards for the exchange of large binary objects produced by imaging modalities

in the diagnostic imaging domain have been in existence for many years. The use of DICOM

as a protocol for exchanging these large binary objects is a de facto standard that the

Provincial EHR supports.

Implications The communication of binary large objects for the diagnostic imaging domain (eg. computed tomography scans, magnetic resonance imaging) relies on the use of DICOM

Point of service applications that transmit or receive binary large objects for diagnostic imaging support DICOM


Principle

AP-DMI-004: Unidirectional communication pattern from

consumer systems

Statement Data messaging interactions between consumers and the Provincial EHR are unidirectional

where consumer systems call the Provincial EHR. External EHR interactions are always

triggered by consumer systems (i.e. PoS Applications) Internal systems (that make up the

Provincial EHR) can pull or push data between each other

Rationale The Provincial EHR is used as a resource by consumer systems/point of service

applications. Consistent with REST (Representational State Transfer) architecture style, it

is the clients (consumer systems) that invoke the resources from the Provincial EHR when

they need them.

Putting a general requirement on consumer systems to be available, listen and to fulfil

requests from the EHR is seen as inappropriate and detrimental to the adoption of the

EHR.

On the other hand, internal systems that participate in the Provincial EHR are expected to

have the robustness and availability capabilities to be always on and support push models

(e.g. CDMS listening for lab results from OLIS for a patient)

Implications Communication with the Provincial EHR from consumer systems is always initiated by consumer systems

Implies that in the context of the publish/subscribe pattern, notifications associated with subscriptions are read as a response to a consumer-initiated request


Principle

AP-DMI-005: Use of request-response messaging pattern

for application level interactions

Statement Consumer systems rely on a request-response messaging pattern when communicating

with the Provincial EHR for data messaging interactions.

Rationale The communication of clinical data for the purpose of sharing has high integrity

requirements as well as significant accountability and responsibility implications for

senders and receivers. In that context, it is expected that all interactions will require the use

of a formal response to minimally acknowledge receipt and processing of a request, if not to

provide actual requested data.

Implications Applications that interact with the Provincial EHR with data messaging plan and implement their web services adapters to use the request-response messaging pattern.


Principle AP-DMI-006: Use of web services and web services protocol

Statement Messages are encapsulated into industry standard web services and web services level

features are used to control communication, reliable messaging and security.

Rationale The use of web services provides a consistent means of implementing SOA compliance,

security and reliable messaging in a platform-neutral and standards-based way.

Implications An eHealth Ontario approved standard for transport layer interoperability exists and defines the applicable standards to implement web services, communication control, security and reliable messaging.


Principle AP-DMI-008: Business Application Level Acknowledgement

Statement Data Messaging Interactions offered by the Provincial EHR provide business application

level acknowledgement to consumer applications (senders) when data is being created,

updated (creation of a replacement) or deleted (logical delete) in the Provincial EHR.

Rationale While reliable messaging and communication protocol used by the Provincial EHR

guarantees the delivery of messages, this does not guarantee that a message was accepted

as valid and processed by the Provincial EHR. Given the business/clinical accountability

implications for the management of clinical data shared via the EHR, business application

level acknowledgements are required to confirm the successful processing of transactions

that change the data.

Implications Application level acknowledgements are implemented for every interaction pattern that supports the creation, update or deletion of information in the EHR

Read transactions do not have to be acknowledged at the business application level since the response itself acts as an acknowledgment


Principle

AP-DMI-009: Data Messaging Interactions are

authenticated and authorised

Statement Data Messaging Interactions rely on the use of standards based protocols to authenticate

and authorise requesters.

Rationale To guarantee that only valid recognized and authorized users access and use data

messaging services offered by the Provincial EHR

To enable the traceability and auditing capabilities required of the Provincial EHR

to support the protection of personal health information

Implications See Security principles for details


EHR Data Principles

Principle AP-EHR.Data-001: EHR Data Trusteeship

Statement Every EHR Data Collection contained in the Provincial EHR is assigned to a single EHR

Data Trustee who is solely accountable for its data conformance and fidelity.

Rationale Consumers of the Provincial EHR must have a high level of trust on the quality of EHR

Data. This can be addressed by ensuring that every EHR Data Collection is under the

management responsibility of a single EHR Data Trustee.

Implications EHR Data Trustees will have sole responsibility for maintaining EHR Data Collections under their care

Since the same EHR Data (e.g. height and weight) may be contained in more than one EHR Data Collection (e.g. regional and provincial repositories), it follows that they will have different EHR Data Trustees

EHR Data Trustees will be responsible for enforcing EHR Data conformance and fidelity requirements defined for the Provincial EHR

Clinical data quality and accuracy is the responsibility of the healthcare provider that has entered the information

Management of EHR Data is an on-going activity that requires well-defined roles and responsibilities between EHR Data Trustees and the Provincial EHR

Systems of record acting as sources of EHR Data operate under the responsibility of local health delivery organization data trustees, their responsibilities are different then EHR data trustees


Principle AP-EHR.Data-002: System of Record

Statement The Provincial EHR identifies the “System of Record” (i.e. authoring system for every EHR

Data).

Rationale Consumers of the Provincial EHR must have a high level of trust on the origin of EHR Data.

Implications EHR Data must include appropriate metadata attributes that can uniquely identifies its source (i.e., “system of record”)

Each System of Record will have sole responsibility for creating, validating, preparing and publishing its EHR Data

Systems of Record will be responsible for conforming to EHR Data quality requirements defined for the Provincial EHR

EHR Data is captured only once in the Provincial EHR and is immediately validated by the Authoritative Source System

The Provincial EHR will establish authoritative data policies that will identify potential EHR Data conflicts between equivalent information published by different Systems of Record and define the mechanisms by which these conflicts will be resolved


Principle AP-EHR.Data-003: Authoritative Source

Statement The Provincial EHR is an authoritative source of EHR Data.

Rationale Since consumers cannot have direct access to all of the systems of record for EHR Data

because of their number and heterogeneity, the Provincial EHR acts as an authoritative

provider of such data.

Implications Data Governance policies must be formally established to define the role of the EHR as an authoritative source

The Provincial EHR is capable of preserving all EHR Data as originally published by its System of Record

All EHR Data, inclusive of audit and error logs, can be accessed and retrieved at any time as required

The Provincial EHR ensures the integrity of EHR Data by providing mechanisms that protect against loss, degradation and change

The Provincial EHR provides services that may validate structures or vocabularies transform or normalize data, but these do not replace the responsibilities for Systems of Record and their trustees for the business/clinical quality of the data

The Provincial EHR provides mechanisms that validate EHR Data integrity at that time it is first published and on regular intervals as required. It will report all EHR Data integrity issues and warnings which are the responsibility of the EHR Data Trustee


Principle AP-EHR.Data-004: History of EHR Data

Statement In compliance with a Point in Time architecture pattern, EHR Data in the Provincial EHR

is never deleted and a complete history of all changes is maintained.

Rationale As data from the Provincial EHR is expected to be used as evidence for clinical decision

making and to support requirements for longitudinal and historical analysis, research and

reporting, posted data to the Provincial EHR should never be deleted and changes should

be represented progressively in time while keeping the history of previous postings.

Implications The Provincial EHR conforms to all applicable provincial legal and business/clinical requirements relating to the provision of EHR Data, supporting both current and historical views

EHR Data maintained by the Provincial EHR is never physically deleted or changed

Changes to EHR Data are represented as a logical replacement of the original record

Logical deletions of EHR Data are represented by a change of status in the original record (e.g. „deleted‟ or „deprecated‟)

The Provincial EHR creates a detailed audit trail of all changes to EHR Data

The Provincial EHR includes means by which consumers can retrieve previously changed or logically deleted EHR Data

The Provincial EHR meets or exceeds minimum retention periods established by legislation and/or clinical practices

The Provincial EHR retains the information of a patient past the lifetime of a patient as expected by law


Principle AP-EHR.Data-005: Enterprise Identifiers

Statement The Provincial EHR establishes Enterprise Identifiers used to normalize key concepts in

EHR Data.

Rationale The ability to share EHR Data across multiple systems requires that a small number of key

concepts use a standard, normalized set of Enterprise Identifiers. It is the responsibility of

the Provincial EHR to establish the policies and mechanisms by which these Enterprise

Identifiers are managed and/or referenced.

Implications The Provincial EHR defines Enterprise Identifiers for key reference entities such as users, clients, providers, service delivery locations, service delivery organizations, clinical events, Systems of Records, and Services Consumers.

The Provincial EHR uses the Enterprise Identifiers to index and provide access to EHR Data within its repositories


Principle AP-EHR.Data-006: Validation of Enterprise Identifiers

Statement The Provincial EHR ensures the validity of all Enterprise Identifiers.

Rationale Enterprise Identifiers are key elements for the indexing of EHR Data and it is the

responsibility of the Provincial EHR to ensure that they meet their respective validation

and data quality criteria.

Implications Enterprise Identifiers provided by the Service Consumer will be validated by the Provincial EHR using corresponding validation logic and/or lookups to the appropriate EHR Registry services

The validation criteria will vary by Enterprise Identifier type

The Provincial EHR resolves (i.e. looks up) non-validated (e.g. local) identifiers to the corresponding authoritative registry when such determination has not been or cannot be accomplished by the Service Consumer

Enterprise Identifiers resolved by the Provincial EHR do not replace the corresponding original value in Service Requests; rather they augment the information


Principle AP-EHR.Data-007: Validation of Client Identifier

Statement The Provincial EHR always validates the client identifier.

Rationale Given the level of responsibility tied to the client identifier and the implications of false-

positive association of clinical data to a person, the Provincial EHR must exert a higher

degree of caution by validating the client identifier submitted with any transaction.

Implications The client ID submitted in any transaction must be validated with the client registry before clinical data is transacted

Transactions must carry sufficient client demographic and nominative data to support this validation process with the client registry


Principle AP-EHR.Data-008: Validation of Provider Identifier

Statement The Provincial EHR always validates the provider identifier for the provider directly in

charge of the clinical event to which shared EHR data is associated.

Rationale Given the level of responsibility tied to the provider identifier and the implications of false-

positive association of clinical data to a clinician in charge, the Provincial EHR must exert a

higher degree of caution by validating the provider identifier submitted with any

transaction.

Implications The provider ID submitted in any transaction must be validated with the provider registry before clinical data is transacted

Transactions must carry sufficient provider demographic and nominative data to support this validation process with the provider registry


Principle AP-EHR.Data-009: Referential Integrity

Statement The Provincial EHR preserves the referential integrity of EHR Data.

Rationale The ability to bring together EHR Data from various systems of record and provide a

consistent, holistic patient-centric view of clinical information is one of the most important

capabilities of the Provincial EHR. This can only be accomplished through the creation and

maintenance of referential links between EHR Data. Consequently, the Provincial EHR

provides the mechanisms to ensure that these links are established correctly and maintains

the integrity of these relationships during the EHR Data lifecycle.

Implications The Provincial EHR uses, where applicable, Enterprise Identifiers to define referential links between EHR Data

The Provincial EHR is responsible for managing and/or detecting any changes to Enterprise Identifiers and notifying these changes to all the impacted EHR Data repositories


Principle AP-EHR.Data-0010: Semantic Alignment

Statement The Provincial EHR promotes semantic alignment of EHR Data.

Rationale Effective use of EHR Data requires compliance to common semantic understanding of

structured clinical information. The Provincial EHR promotes semantic interoperability by

establishing a standard information model and standardized terminologies to be used by

Systems of Record and end users when interacting with the EHR.

Implications The Provincial EHR architecture establishes a common information model and terminologies for EHR Data that includes objects such as registry entities, clinical and administrative health information, EHR metadata, workflow metadata, privacy and security, audit trails and system logs

EHR Data that is not fully aligned with the information model can be published to the Provincial EHR provided that normalisation and transformation services are used to achieve compliance with EHR data requirements established by the service contracts

The Provincial EHR includes services such as terminology mapping, transformation and normalisation to support semantic alignment for a limited number of concept domains

The semantic alignment of EHR data will require ongoing maintenance of terminologies including abilities to update and retain semantic alignment for historical EHR data


Principle AP-EHR.Data-011: EHR Data Conservation

Statement Data in the Provincial EHR is persisted cumulatively for every client from the moment a

first piece of information is created up until five (5) years following the formal date of death

or as appropriate by law.

Rationale The Provincial EHR provides a lifelong longitudinal record of key shareable health data for

every health service client in Ontario.

Implications The provincial EHR has the means to become aware through a formal process of the date of death of Ontarians

EHR repositories and systems must have an ability to deactivate and archive data about an individual client based on a recorded date of death

This principle must align with data retention policies defined by eHealth Ontario


EHR Document Principles

Principle AP-EHR.Doc-001: EHR Documents are supported

Statement The Provincial EHR supports the processing, persistence and disclosure of EHR

Documents.

Rationale Clinical documents are used extensively by healthcare providers to record delivery of care

encounters with their patients, to communicate clinical matters with other providers or to

refer patients to other healthcare services and/or providers. Consequently, the Provincial

EHR must be able to support the digital representations of these clinical documents, called

EHR Documents.

Implications EHR Document Services provide the means by which clinical documents will be persisted and shared by the Provincial EHR

EHR Documents are special cases of EHR Data and are subject to all the EHR Data principles and requirements

EHR Documents combine human and system readable data


Principle AP-EHR.Doc-002: EHR Document has trusted authorship

Statement The Provincial EHR provides mechanisms to validate the authorship of EHR Documents.

Rationale Consumers of the Provincial EHR must have a high level of trust on the origin of EHR

Documents. The proper origin of EHR Documents needs to be asserted irrefutably in order

to provide the trust level expected by other healthcare providers that will access this

information.

Implications eHealth Ontario will establish the technical requirements for non-repudiation mechanisms (e.g., digital signatures) to be applied to EHR Documents

Systems of Records that are sources of EHR Documents to the Provincial EHR will include the appropriate non-repudiation mechanism as required


Principle AP-EHR.Doc-003: EHR Document maintains its integrity

Statement The Provincial EHR provides mechanisms to ensure the inviolability of EHR Documents.

Rationale Consumers of the Provincial EHR must have a high level of trust on the inviolability of

EHR Documents, whether during transmission or while persisted in EHR Repositories.

The integrity of EHR Documents needs to be asserted irrefutably in order to provide the

trust level expected by other healthcare providers that will access this information.

Implications eHealth Ontario will establish the technical requirements for integrity mechanisms (e.g., digital signatures can also be used) to be applied to EHR Documents

Systems of Records that are sources of EHR Documents to the Provincial EHR will include the appropriate data integrity mechanism as required. This process must also identify multiple authors in a single document and attribution of authorship


Principle AP-EHR.Doc-004: EHR Document conformance

Statement EHR Documents are based on HL7 v3 Clinical Document Architecture (CDA).

Rationale The ability of the Provincial EHR to effectively share EHR Documents relies on the

existence of data content and document structure standards that can be verified by the

eHealth foundation Services. HL7 v3 CDA is a robust standard that has been endorsed by

eHealth Ontario and Canada Health Infoway.

Implications eHealth Ontario will establish the core CDA specifications and conformance criteria that will be required of all EHR Documents

The Provincial EHR will validate all published EHR Documents against these conformance requirements

Non-compliant EHR Documents will not be accepted


Principle AP-EHR.Doc-005: EHR Document preserve their wholeness

Statement The Provincial EHR ensures that EHR Documents preserve their wholeness and that they

will not be subject to changes.

Rationale Key to the use of Clinical Documents is that they must always be considered in their

entirety, as the content they carry is dependent on understanding the clinical context in

which they were created. The Provincial EHR cannot allow that its services alter these

documents in any way.

Implications The Provincial EHR is capable of preserving all EHR Documents as originally published by its System of Record

EHR Documents maintained by the Provincial EHR are never physically deleted

Logical deletions of EHR Documents are represented by a change of status in the original record (e.g. „deleted‟ or „deprecated‟)

Changes to EHR Documents are represented as new versions (e.g. „replacements‟ or „amendments‟) to its original version

The Provincial EHR creates a detailed audit trail for all EHR Documents

The Provincial EHR includes means by which consumers can retrieve previously logically deleted EHR Documents

Care must be taken when extracting sections of an EHR Document to populate other repositories, as these partial renderings may lose some of the clinical context in which they were created


Principle AP-EHR.Doc-006: EHR Document Secure exchanges

Statement The Provincial EHR provides secure mechanisms for the exchange of EHR Documents.

Rationale The information within an EHR Document only becomes useful once it can be shared

across multiple healthcare providers. The Provincial EHR is responsible for enabling this

exchange of EHR Documents in a secure manner.

Implications Access to EHR Documents is governed by the same Privacy and Security policies applicable to EHR Data in general

The Provincial EHR will not mask parts of an EHR Document as this will violate principle AP-EHR.Document-005. An EHR Document is either accessible or not as a whole

The Provincial EHR provides mechanisms for the discovery (i.e. queries) and retrieval of persisted EHR Documents

The Provincial EHR provides mechanisms for the point-to-point delivery as required by specific workflows (e.g. eReferrals)

The Provincial EHR supports end-to-end encryption of EHR Documents as required by specific workflows (e.g. eReferrals)


Principle AP-EHR.Doc-007: EHR Document metadata

Statement EHR Documents are identified, indexed and classified by metadata.

Rationale Since Clinical Documents will vary considerably from one clinical scenario to another, it is

essential to define a core set of attributes that unique identify and describe the content of

any EHR Document. This set of attributes is called the EHR Document Metadata.

Implications eHealth Ontario will define the core set of metadata attributes to be required of every EHR Document and are part of the conformance criteria for document submission

Metadata attributes are not formally part of the EHR Document, although they often will be derived or determined by information contained within the document

EHR Document Metadata must always be available and visible (i.e. not encrypted) by the eHealth foundation services

EHR Document indexes and queries rely on the metadata provided with each document submission


Portlet Services Principles

Principle AP-PTL-001: Portlets via Web Services

Statement eHealth Ontario foundation portlets are available as web services, following eHealth

Ontario published standards which are themselves based on industry standards.

Rationale Exposing portlets as web services allows reuse of the well-defined web services channel of

the eHealth foundation. Portlet interactions follow the same patterns as any other web

service interaction.

Implications The web services orchestration steps defined for web service invocations may be leveraged

Support for WSRPv2.0 is required; the use of standards based portlet protocols allows for maximum reuse across the province


Principle AP-PTL-002: Portlet Governance

Statement eHealth Ontario foundation (eHOF) portlets are governed in the same fashion as other

eHOF web services.

Rationale As portlets are web services, this principle follows as a corollary of AP-PTL-001 Portlets via

Web Services. The following items require governance:

Portlet (and associated web service) naming.

Context Manager names

Service Level Objectives

Registration in the eHealth Ontario foundation Service Catalog

Implications The governance processes for services should include provisions for governance of portlets

Third Parties will have to be informed that such governance exists

The eHealth Ontario foundation Service Catalog will have to be created, and published


Principle

AP-PTL-003: Portlet Consumption of eHealth foundation

services

Statement eHealth Ontario foundation portlets consume eHealth Ontario foundation services via

eHealth Ontario foundation public service interfaces.

Rationale Follows AP-IS-001 Intra-foundation Communication.

Implications The security context supplied to the portlet producer must be propagated to the internally invoked services

The business context supplied established by the portlet producer must be propagate to the internally invoked services

Some method of correlating portlet interactions with service interactions will be required to support end-to-end audit log reviews


Principle AP-PTL-004: Portlet Look and Feel

Statement eHealth Ontario foundation (eHealth Ontario foundation portlets, follow published

eHealth Ontario UI Design Standards.

Rationale The published eHealth Ontario UI Design Standards cover such topics as:

Standards based mechanisms for controlling their look and feel and branding

Data formatting (dates etc.)

Consistent use of UI controls

If all „provincial‟ portlets follow published design standards, they will be more internally

consistent as a whole. Further, portals that consume eHealth Ontario foundation portlets,

will likely also have varying look and feel; support for branding will allow for tighter

integration into consuming portal.

Implications Support for Cascading Style Sheets will be required

Portlets will have to be coded with externally supplied CSS in mind

The eHealth Ontario UI Design Standards will have to be documented and published


Principle AP-PTL-005: Portlets Device Independence

Statement eHealth Ontario foundation portlets must be as operating system, browser, and device

independent as possible.

Rationale eHealth Ontario foundation portlets will be rendered on a variety of devices (from desktop

through mobile), using a variety of browsers. To reach the largest possible audience, each

portlet should be as standards-based and as open as possible.

Implications The use of browser plug-ins (Flash, Shockwave, Java) is discouraged. Simple, open, web standards are preferred

Vendor support of standards evolves, so a plan to cope with technology deprecation is required


Principle AP-PTL-006: Inter-portlet Communication

Statement Portlet Consumers should use the eHealth Ontario foundation (eHOF) Portlet Shared

Context Manager (aka: the Portlet Framework) mechanism for inter-portlet

communication.

Rationale The context manager is designed to allow a group of portlets to share a common operating

context. Use the context manager simplifies the maintenance of context for each portlet on

a given „page‟.

Implications Third Party Developers of new portlets that participate in the eHOF portlet ecosystem will have to leverage the context manager

Third Party portlets that follow this principle will enrich the eHOF portlet ecosystem. The more portlets that participate in the context manager‟s „Context‟ concept, the better and more useful the „Context‟ becomes

Inter-portlet communication is a common portlet development issue, so widely publishing the details and availability of this mechanism should provide real benefit to Third Party eHealth portlet developers across the province


Principle AP-PTL-007: Portlet Hosting Services

Statement Portlets that are widely consumed across the province should:

Be hosted within the eHealth Ontario foundation (eHOF) Portlet Realization zone, on eHOF Portlet servers

Follow the minimum standard Service Level Objectives for Portlets as published by eHealth Ontario

Rationale eHealth Ontario has an established zone and infrastructure for hosting WSRPv2 portlets.

Third parties may not have same resources that does eHealth Ontario for hosting carrier

grade portlets – DR, backup, change control etc. are all things that can be leveraged by

hosting with eHealth Ontario. This is particularly important for portlets that are intended

for use province-wide.

Implications The eHealth Ontario Portlet servers are implemented on Websphere v6.1. Suppliers of portlets who choose to have their portlets hosted at eHealth Ontario are therefore limited to that platform for development of portlets

Load is concentrated on the eHealth Ontario Portlet servers, whereas it could be distributed across all portlet providers across the province

The Service Level Objectives for Portlets must be documented and published by eHealth Ontario


Privacy Principles

Principle AP-PRV-001: Collection

Statement The provincial EHR allows systems of record to upload EHR data.

Rationale In order to realize the expected benefits to patient, providers and the overall healthcare

system the provincial EHR must collect data for all patients. According to PHIPA

regulations, O. Reg. 331/11:

“Where a health information custodian provides personal health information to eHealth

Ontario for the purpose of eHealth Ontario creating or maintaining one or more electronic

health records, and eHealth Ontario satisfies the requirements listed in subsection (2),

(a) the health information custodian shall not be considered in so providing the personal

health information to be making it available or to be releasing it to eHealth Ontario for the

purposes of those expressions as used in the definition of “disclose” in section 2 of the Act;

(b) eHealth Ontario shall not be considered to be gathering, acquiring, receiving or

obtaining the personal health information for the purposes of those expressions as used in

the definition of “collect” in section 2 of the Act. O. Reg. 331/11, s. 2 (1).”

Implications eHealth Ontario will need to demonstrate compliance to data handling and security policies in order to collect information.


Principle AP-PRV-002: Individual’s right of access

Statement The provincial EHR allows patients to receive copies of their records.

Rationale The individual‟s right of access is a PHIPA requirement; PHIPA states:

“... an individual has a right of access to a record of personal health information about the

individual that is in the custody or under the control of a health information custodian

unless,

(a) the record or the information in the record is subject to a legal privilege that restricts

disclosure of the record or the information, as the case may be, to the individual;

(b) another Act, an Act of Canada or a court order prohibits disclosure to the individual of

the record or the information in the record in the circumstances;

(c) the information in the record was collected or created primarily in anticipation of or for

use in a proceeding, and the proceeding, together with all appeals or processes resulting

from it, have not been concluded;

(d) the following conditions are met:

(i) the information was collected or created in the course of an inspection, investigation

or similar procedure authorized by law, or undertaken for the purpose of the

detection, monitoring or prevention of a person‟s receiving or attempting to receive

a service or benefit, to which the person is not entitled under an Act or a program

operated by the Minister, or a payment for such a service or benefit, and

(ii) the inspection, investigation, or similar procedure, together with all proceedings,

appeals or processes resulting from them, have not been concluded;

(e) granting the access could reasonably be expected to,

(i) result in a risk of serious harm to the treatment or recovery of the individual or a

risk of serious bodily harm to the individual or another person,

(ii) lead to the identification of a person who was required by law to provide

information in the record to the custodian, or

(iii)lead to the identification of a person who provided information in the record to the

custodian explicitly or implicitly in confidence if the custodian considers it

appropriate in the circumstances that the identity of the person be kept confidential;

or

(f) the following conditions are met:

(i) the custodian is an institution within the meaning of the Freedom of Information

and Protection of Privacy Act or the Municipal Freedom of Information and

Protection of Privacy Act or is acting as part of such an institution, and


Principle AP-PRV-002: Individual’s right of access

(ii) the custodian would refuse to grant access to the part of the record

(A) under clause 49 (a), (c) or (e) of the Freedom of Information and Protection of Privacy

Act, if the request were made under that Act and that Act applied to the record, or

(B) under clause 38 (a) or (c) of the Municipal Freedom of Information and Protection of

Privacy Act, if the request were made under that Act and that Act applied to the record.

2004, c. 3, Sched. A, s. 52 (1); 2007, c. 10, Sched. H, s. 19; 2009, c. 33, Sched. 18, s. 25

(5).” -PHIPA s. 51

Implications Process and/or services to enable patient access to EHR records that will also cover

exceptions as per PHIPA, such as for risk of serious harm.


Principle AP-PRV-003: Disclosure and use

Statement The Provincial EHR will enable HICs to access health information on individuals based on

the notion of implied consent unless a patient explicitly withdraws their consent.

Rationale “A health information custodian described in paragraph 1, 2, 3 or 4 of the definition of

“health information custodian” in subsection 3 (1), that receives personal health

information ... is entitled to assume that it has the individual’s implied consent

to collect, use or disclose the information for the purposes of providing health

care or assisting in providing health care to the individual, unless the custodian

that receives the information is aware that the individual has expressly withheld or

withdrawn the consent.” -PHIPA, s. 20 (2) emphasis added.

Implications The EHR supports a mechanism to enable patients to withdraw consent for disclosure.


Principle AP-PRV-004: Consent directives

Statement The eHealth foundation will enable patients to specify coarse-grained consent directives to

regulate the disclosure of EHR Data from the Provincial EHR.

Rationale Consumer confidence in the Provincial EHR and compliance with provincial privacy policies demand that patients be given some level of control on access to their electronic record. Consistent with approach that taken by other Canadian jurisdictions including:

a) Alberta

b) British Columbia

c) Quebec

Implications Systems of Record and / or eHealth Ontario domain system may implement fine-grained consent directive capabilities as required.


Principle AP-PRV-005: Emergency disclosure (“Breaking the glass”)

Statement The Provincial EHR allows providers to override patient consent directives during an

emergency given a justification.

Rationale PHIPA allows for disclosure without a patient‟s explicit consent if:

“... the disclosure is reasonably necessary for the provision of health care and it is not

reasonably possible to obtain the individual‟s consent in a timely manner, but not if the

individual has expressly instructed the custodian not to make the disclosure.” –PHIPA

s. 38 (1)

“ ... the custodian believes on reasonable grounds that the disclosure is necessary for

the purpose of eliminating or reducing a significant risk of serious bodily harm to a

person or group of persons.” -PHIPA s. 40 (1)

“... a summons, order or similar requirement is issued in a proceeding by a person

having jurisdiction to compel the production of information ...” or a “... procedural

rule that relates to the production of information in a proceeding ... ” –PHIPA

s.41(1)(d)

Implications The Provincial EHR must provide functionality to support the recording of a reason for an override

All consent directive overrides will trigger increased scrutiny and/or audits


Principle

AP-PRV-006: Provision of de-identified information without

informed consent

Statement The Provincial EHR supports the disclosure of de-identified information to third parties

without a patient‟s consent to duly qualified and authorized professional legally bound to

protect confidentiality for the following purposes of use:

Approved medical research

Policy and funding decisions related to the healthcare system

Protection of patient safety and public health

Rationale PHIPA allows information to be disclosed to:

Researchers whose research plan has been approved by a Research Ethics Board (REB)

-PHIPA s. 44

Prescribed entities for the purpose of “analysis or compiling statistical information

with respect to the management of, evaluation or monitoring of, the allocation of

resources to or planning for all or part of the health system, including the delivery of

services” -PHIPA s.45

To Provincial Chief Medical Officer of Health to protect patient safety and public

health consistent with the Health Protection and Promotion Act -PHIPA s.39(2)

Implications The Provincial EHR must provide a de-identification service

eHealth Ontario will establish and enforce de-identification policies / procedures


Principle AP-PRV-007: Revocation of disclosure is not retroactive

Statement Consent may not be withdrawn retroactively.

Rationale “If an individual consents to have a health information custodian collect, use or disclose

personal health information about the individual, the individual may withdraw the consent,

whether the consent is express or implied, by providing notice to the health information

custodian, but the withdrawal of the consent shall not have retroactive effect.” –

PHIPA s. 19 (1) [emphasis added].

Implications Definition of purposes of use

Inclusion of purpose of use in service contracts

Once a clinician had access to a piece of health information, such access cannot be taken away

Initial period where patient can opt out prior to go-live of the EHR


EHR Service Level Objective Principles

Principle AP-SLO-001: Performance

Statement Applications, services and transaction orchestrations need to be designed in accordance

with performance goals aligned to their context of use.

“Immediate” class services complete within ½ second or less 90% of the time

“User Waiting” class services complete within 3 seconds or less 90% of the time

“User Transparent” class services complete within 5 seconds or less 90% of the time

“Large Objects” class services complete within 15 seconds or less 90% of the time

All of these response time goals apply to real transaction response time once having

reached the HIAL/ESB destination point, i.e. network latency external to the eHealth

foundation is not factored.

Rationale Customer facing Provincial EHR services are used in different contexts of care and different

contexts of technical integration with point of service applications (including portals and

portlets). Generally the following classes of expectations for performance are

distinguished: “Immediate” class response time for infrastructure, common services registries and

others, generally applicable to services that are invoked as sub-components of a larger transaction (e.g. time synchronisation, authentication, validate client/provider/location ID, validate consent)

“User Waiting” class response time for business application services used in contexts where end-users are typically waiting for a response in real time (e.g. list lab results, get drug profile, get client demographics, put a referral)

“User Transparent” class response time for business application services used in contexts where no end-user is typically waiting and the expectation of responsiveness can generally be qualified as “near real time” (e.g. system-to-system back-end puts for laboratory systems)

“Large Objects” class response time for business application services that deal with large binary or structured data objects (> 1Mb) (e.g. get diagnostic image)

Implications Provincial EHR performance service level objective criteria that must be considered include

but are not limited to: Data throughput

Service throughput

Data volume

Response time for transactions (real, perceived, expected)

Service response time

Average / peak performance

Load balancing

Load distribution based on activities, events, dates, transactions, or users

Performance impacts of multiple applications running simultaneously on shared components of the system (web server, application server, DB server, etc)

Complete system operation (security, servers, databases, and network)

Impact of geographic diversity Network latency (local, national, and international usage)


Principle AP-SLO-002: Availability

Statement Applications, services and transaction orchestrations need to be designed in order to be

available continuously.

All systems participating in the Provincial EHR are available 7 days a week, 24 hours a day, 365 days per year with an availability rate of 99.99% (1.01 minutes per week of downtime);

Availability is inclusive of scheduled maintenance windows.

Rationale Provincial EHR services for data are built to support operational clinical processes in the

context of healthcare service delivery which operates on a continuous basis.

Implications Provincial EHR availability service level objective criteria that must be managed includes

but is not limited to:

Solution uptime

Solution availability (x9s)

Defined maintenance window

Availability service level objectives must also address:

o Data exceptions o System failures o Hardware failures o Fault and failure recording and tracking o Redundancy - Fault |Tolerance o Automatic Failover o Dependencies on other systems o Restore and reactivate procedures o Replicated database(s) o Transaction level integrity o Alternative processes and fail-over plans


Principle AP-SLO-003: Software Quality Assurance (SQA)

Statement Development of Provincial EHR services comply with eHealth Ontario software quality

assurance processes, methods and tools.

Rationale Software quality assurance requires monitoring the software engineering processes and

methods used to ensure quality.

Implications SQA service level objective encompasses the entire software development process, which includes processes such as requirements definition, software design, coding, source code control, code reviews, change management, configuration management, testing, release management, and product integration

o This also covers external tools/software use from other sources to support the provincial EHR.

SQA service level objectives are organized into goals, commitments, abilities, activities, measurements, and verifications


Principle AP-SLO-004: Monitoring

Statement Provincial EHR services comply with enterprise level monitoring criteria set by eHealth

Ontario.

Rationale Provincial EHR services have multiple inter-dependencies and monitoring must be

managed at the enterprise level to comply, achieve and maintain the desired monitoring

service level objectives.

Implications Provincial EHR monitoring service level objective criteria that must be managed includes


Application / infrastructure component monitoring alarms and triggers

(across multiple solution platforms and environments)

Enterprise Monitoring tools that all systems must comply to

Integration of different monitoring tools and technologies

(Could be different tools in each deployment zone / location etc.)

Faults Errors

Capacity Monitoring

Availability monitoring

Performance monitoring

Security threshold monitoring

Intrusion Detection Intrusion Prevention


Principle AP-SLO-005: Business Continuity & Recoverability

Statement Provincial EHR services are implemented in compliance with eHealth Ontario Business

Continuity Plans and system recovery processes.

Rationale Business Continuity and recoverability of Provincial EHR services have multiple inter-

dependencies and must be managed at the enterprise level to comply, achieve and maintain

the desired service level objectives.

Implications Business Continuity service level objectives describe the activities / plans to manage risk

assessments, roles and responsibilities to maintain or recover business operations in a

timely manner following interruption of service. The management and planning of

Business Continuity & Recoverability service level objective activities include but are not

limited to:

Maintaining a unified framework of Business Continuity Plans across different LOBs

Ensuring Disaster Recovery within a number of hours (MMTR)

Performing backup and restore procedures without interruption of service

Archiving data without interruption of service

Ensuring data retention policies comply with legal and operational requirements

Managing data storage location(s) on and off site with transportation as needed

Conducting back-out procedures for a mid-transaction crash, etc


Principle AP-SLO-006: Capacity

Statement Provincial EHR service solutions comply with the capacity service level objectives


Rationale Provincial EHR services have multiple inter-dependencies and capacity must be managed

at the enterprise level to comply, achieve and maintain the desired capacity service level

objectives.

Implications Provincial EHR monitoring service level objective criteria that must be managed includes


Support minimum number of concurrent users per day

Support minimum number of publicly exposed transactions (e.g. web service method) per day

Support a minimum number of patients

Support for data storage capacity such as total patient records based on minimum retention period


Principle AP-SLO-007: Scalability

Statement Provincial EHR service solutions comply with the scalability service level objectives


Rationale Provincial EHR services have multiple inter-dependencies and scalability must be managed

at the enterprise level to comply, achieve and maintain the desired scalability service level

objectives.

Implications Provincial EHR scalability service level objective criteria and activities that must be

managed includes but is not limited to:

Ability of solution(s) to accommodate product upgrades and new functionality (product releases)

Manage change in throughput

Manage change in the number of users

Manage change in the number of transactions processed

Manage change in levels of support

Manage change in memory requirements

Manage change in storage requirements Manage horizontal scalability (adding similar components)

Manage vertical scalability (adding capacity to existing components)

Manage changes in client business direction (including mergers, acquisitions, expansions, and divestitures)

Manage changes in client technical direction


Principle AP-SLO-008: Maintainability

Statement Provincial EHR service solutions comply with the maintainability service level objectives

established by eHealth Ontario to ensure systems are up to date.

Rationale Provincial EHR services have multiple inter-dependencies and maintainability must be

managed at the enterprise level to comply, achieve and maintain the desired

maintainability service level objectives.

Implications Provincial EHR maintainability service level objective activities that must be managed

includes but is not limited to:

Formal change control / change request processes & procedures

Implementation of release management policies

Implementation of patch management policies

Implementation of Emergency Fix procedures

Management of scheduled maintenance procedures without interruption of service

Management of product releases and upgrades Management of logging and tracking defects procedures

Management of routine diagnostic checks


Time Synchronization Principles

Principle AP-TS-001: Server Time Synchronization

Statement Systems employed in delivering eHealth foundation Services (eHFS) will be synchronized

to a common time standard.

Rationale The eHealth foundation service, its applications and its components require a accurate,

synchronized time clocks. Some examples include:

Authentication

Authorization

The in order for these services to complete and function correctly, they must each have

available common time.

Implications Common service for time synchronization within data centres where the eHealth foundation services operates.


Principle AP-TS-002: Directory Server Synchronization

Statement Directory servers employed in delivering eHealth Services (EHS) will be synchronized to a

recognized time service.

Rationale Many systems receive time from directory service servers. These directory servers natively provide time synchronization services to end user systems delivering eHealth Services The eHealth service systems, applications and components require an accurate, synchronized time clock. Some examples include:

Consent

Time in clinical notes

Implications Use recognized and common service for time synchronization. Some examples are: o time.nrc.ca o time.chu.nrc.ca


Principle AP-TS-003: eHealth Services Synchronization

Statement Systems employed in delivering eHealth Services not participating in a directory service

network will be synchronized to a recognized time service.

Rationale The eHealth Services, its applications (eHRs for example) and its components require a synchronized clock time. Some examples include:

Consent Scheduling

Time in clinical notes

Implications Use recognized and common service for time synchronization. Some examples are: o time.nrc.ca o time.chu.nrc.ca


Principle AP-TS-004: Support of Universal Coordinated Time (UTC)

Statement All eHealth foundation Services and the eHealth Services shall utilize Universal

Coordinated time for the transmission of date and time.

Rationale Ontario has two time zones. Data may be received from and transmitted to systems in any

time zone, including those outside of Ontario. Therefore the eHFS services and eHS

systems must allow information containing dates and times to be seamlessly shared across

any time zone.

Implications Systems must support the use of services that conversion of date and time to and from any time zone as well as time zones that have been used in the past and accommodate those defined in the future

When it is important to be able to reconstitute the time in the original time zone, the transmission must include the original time zone offset


Principle AP-TS-005: Storage of Date/Time

Statement Services shall store date/time in native internal formats utilizing UTC time and when

necessary, the time zone offset of the observation or event.

Rationale This allows process and display of date and time using native date/time manipulation

routines. The adoption of native date/time storage will reduce the time required to

translate between incompatible date/time formats while also eliminating mistakes owing to

translations between different time zones.

Implications Ensuring the use of the correct date/time storage and manipulation issues as part of service design and review during systems design and development

The original time zone offset is required in order to calculate local time of the observation or event and includes availability from point of service systems for all devices and applications


Principle AP-TS-001: Support of Pan-Canadian Standards

Statement eHealth Service Applications will utilize Pan-Canadian Standard for processing and messaging date and time values.

Rationale CHI has developed SC-3002-EN - Data Type Specification - R02.04.02 for specifying date and time in HL7 Messages. Support of the Pan-Canadian standard will insure the interoperability of systems across the province and across the country.

Implications Application systems must be able to support the complex time options specified in the standard.


Principle AP-TS-002: Display of Date/Time.

Statement Services shall display date and time using the ISO 8601 date time format providing the greatest level of certainty of the date, time and time zone.

Rationale The adoption of a universal date/time format will reduce the time required to translate between incompatible date/time formats while also eliminating mistakes owing to translations between different time zones.

Implications Dates will generally be displayed in the format YYYY-MM-DD Times will generally be displayed in the format HH:MM[:SS] using the 24 hour clock. Date and Time will be displayed in the format YYYY-MM-DD HH:MM:SS±tttt as a minimum.


Security Principles

Principle AP-SEC-001: Apply ISO#2700234

Statement The guidelines and principles established by ISO#27002 should be followed by all systems that are part of the eHealth Ontario foundation.

Rationale The ISO#27002 document provides organisations with best practices recommendations for information security management. The standard is widely recognized and accepted in the industry. The standard defines a level of rigor to be applied to information security that is appropriate to provincial scale assets.

Implications The standard covers the following topics:

Risk Assessment

Security Policy

Organisation of Information Security Asset Management

Human Resources Security

Physical and Environmental Security

Communications and Operations Management

Access Control

Information Systems Acquisition Development and Maintenance Information Security Incident Management

Business Continuity Management

Compliance Adoption of ISO#27002 for eHealth foundation systems implies that all participating parities must apply the level of rigor defined by the standard.

3 http://en.wikipedia.org/wiki/ISO/IEC_27002, http://www.iso.org/iso/catalogue_detail?csnumber=50297

4 Note that ISO#27002 is an update to ISO#17799.

http://en.wikipedia.org/wiki/ISO/IEC_27002

http://www.iso.org/iso/catalogue_detail?csnumber=50297


Principle

AP-SEC-002: Take guidance from the Canada Health

Infoway EHRS Blueprint Privacy and Security

Architecture5.

Statement The eHealth Ontario Privacy and Security Architecture is informed by the Canada Health Infoway EHRS Blueprint Privacy and Security Architecture.

Rationale The Canada Health Infoway EHRS Blueprint Privacy and Security Architecture builds upon ISO#27002 and supplies specifics that are appropriate for the health domain.

Implications The CHI blueprint introduces the following privacy and security services: User Identity Management Service

User Authentication Service Access Control Service

Consent Directives Management Service

Identity Protection Service

Anonymization Service

Encryption Service

Digital Signature Service

Secure Audit Service General Security Services

eHealth Ontario has not adopted all of the recommendations of the CHI PSA. The eHealth Ontario PSA contains further details.

5 https://knowledge.infoway-inforoute.ca/EHRSRA/doc/EHR-Privacy-Security.pdf

https://knowledge.infoway-inforoute.ca/EHRSRA/doc/EHR-Privacy-Security.pdf


Principle

AP-SEC-003: Personal and Personal Health Information

Protection

Statement The following constraints are applied to any retrieval or update of information containing Personal and/or Personal Health Information:

authentication is required. See later principles on authentication

authorization is required. See later principles on authorization.

consent is required. See later principles on consent and privacy.

audit logging is required. See later principles on audit logging.

These constraints are a subset of the „appropriate safeguards‟ for PI and PHI; in particular, they are the elements that are in direct support of the legislation (see below).

Rationale The eHealth Ontario foundation services (eHOFS) apply security constraints so as to comply with provincial laws, Ministry of Health policies, and eHealth Ontario policies. The constraints are aimed at the protection of personal and personal health information, and they reflect the demands of Ontarians. The policy-bases specifically under consideration are:

Freedom of Information and Protection of Privacy Act (FIPPA)

Municipal Freedom of Information and Protection of Privacy Act (MFIPPA)

Personal Health Information Protection Act (PHIPA)

Implications These constraints should be realized in service orchestrations that are applied at the Provincial and Regional Hub HIAL/ESB instances. Furthermore, services that involve PI or PHI should only be consumed via one or more of these HIAL/ESB instances to ensure that the policies are consistently applied.

Audit logging implies that there are audit log review use cases.

Consent checking implies that there are consent management use cases.

Privacy regulations may also impose the need for anonymization and/or

pseudonimization.

Access control (authentication, authorization etc) also applies to non-PI and non-PHI data. This principle is aimed at those services that supply and/or update PI and PHI.


Principle AP-SEC-004: Federated Authentication

Statement Authentication to eHealth services leverage existing digital identities already established at healthcare organisations across the province.

Rationale The health care organisations that have a well- established and trusted relationship with health care providers are best able to:

Correctly identify providers

Maintain digital identities and credentials

Correctly identify capabilities and qualifications

eHealth Ontario should leverage the relationships that exist between healthcare organisations and the people that work for them.

Implications Authentication follows a federated model. eHealth Ontario will accept identity assertions from healthcare organisations as a form of 'authentication'

The amount of trust placed in any given identity assertion is variable. See Error! Reference source not found.

eHealth Ontario may have additional knowledge about „authenticated‟ users (for example, from the Provider Registry) that is added to the overall identity that propagates through the eHealth Ontario foundation Services

The amount of 'trust' that a given identification is correct is quantifiable in a way that can be leveraged by authorization systems

eHealth Identity Federation business model must be defined

eHealth Ontario ONEID is a federated identity provider


Principle AP-SEC-005: Federated Authentication Standards

Statement The mechanisms used to implement federated authentication, are standards based.

Rationale Support:

Interoperability between platforms

Industry best practices

Integration with federation partners, particularly with Commercial Off-The-Shelf applications

Implications Support for more than one protocol may be required.

Interoperability with Web Services is required.

Web SSO features may be required6

6 For example, for logins to portals.


Principle AP-SEC-006: Multiple Levels of Identity Assurance

Statement The mechanisms used to implement federated authentication,

allow for multiple levels of identity assurance.

Rationale The security policies that apply to eHealth federation services (eHFS) have many components. The required level of identity assurance is one such component. For example, some „sensitive‟ services may require a higher degree of identity assurance than „regular‟ services. As a result, the federated authentication mechanisms supported by eHealth Ontario support multiple levels of identity assurance.

Implications The federated authentication technologies chosen must support multiple identity assurance levels.

The current identity assurance level must be associated with the current transaction.


Principle AP-SEC-007: Identity Propagation

Statement The mechanisms used to implement federated authentication,

allow for propagation of the asserted identity „deep‟ into service invocations.

Rationale The identity of the currently authenticated interactive user may be required by service implementations for the implementation of fine-grained authorization decisioning.

Implications The ability to distinguish interactive users from automated systems is required

This principle is counter to the typical web application pattern of proxied identity via a „service identity‟, which may increase integration costs

This requirement drives the need for a sophisticated „delegation of authority‟ model as the currently authenticated interactive user may be operating „under the authority of‟ or „on behalf of‟ another individual or organisation

The asserted identity and the associated assertion metadata may be required by „deep‟ components to perform fine-grained authorization

The metadata associated with the asserted identity should also be included in the information that is propagated


Principle AP-SEC-008: Data Protection (Confidentiality)

Statement Messages (including service invocations) containing Personal and/or Personal Health Information (PHI) are sent using either transport or message layer encryption mechanisms to protect from inappropriate disclosure of the information. These encryption mechanisms are required whenever a message crosses security zones. Transport layer encryption is preferred to message layer encryption (see rationale). PI and PHI that is stored on mobile devices and/or removable media must be encrypted.

Rationale Personal (Health) Information is sensitive, and is protected by provincial and federal regulations. The information must be protected while in transit, and sometimes even when in persistent storage. Transport layer encryption is preferred over message layer encryption, for the following reasons:

Consistency – transport layer security can be implemented „by the infrastructure‟,

making it harder to expose data inadvertently through programming error

Performance – transport layer security can be implemented „by the infrastructure‟ where appropriate, allowing for optimization when data is in transit on purely „internal‟ networks (for example)

Visibility – The eHealth foundation infrastructure requires visibility into message (and service invocation) payloads to perform some tasks (eg: consent filtering, authorization, pseudonimization etc); message layer encryption makes this inspection difficult or impossible

Implications Support for IPSEC and/or SSL/TLS is required, though it is expected that only one mechanism will be used at a time

Support for WS-Security, XML Encryption, and for standardised encryption techniques is required

Confidentiality implemented via message level security may limit the applicability of common orchestration patterns, increasing the burden placed on the associated service implementations

A Public Key Infrastructure will likely be required

A detailed set of standards and specifications for encryption is required


Principle

AP-SEC-009: Data Protection (Integrity and Non-

repudiation)

Statement The eHealth foundation must support (through validation, verification, and maintenance) mechanisms to ensure data integrity. Mechanisms to ascertain accountability (non-repudiation) for transactions is required.

Rationale In audit (forensic or not) situations, eHealth Ontario must be able to ascertain accountability for the transactions that are received and accepted. It may not be possible to ascertain accountability for messages that are rejected (eg: messages that are rejected because they are incomplete). Certain data integrity mechanisms are required for federated authentication (eg: digital signatures on received security assertions). Some transactions are sensitive enough that the data may be digitally signed to support later data integrity validation and non-repudiation use cases.

Implications Most transactions will require the use of digital signatures

Architectural decisions on where to apply the signatures is required

Support for the WS-Security and XML Signature specifications is required

The eHealth foundation must be capable of validating XML digital signatures to offload such responsibility from service implementations

A Public Key Infrastructure will likely be required


Principle AP-SEC-010: Transaction and Security Session Propagation

Statement The eHealth foundation must support the notion of a „security session‟. Further, a „security session‟ initiated at one element of the eHealth foundation (eg: a regional hub) should be honoured by other elements (eg: the provincial ESB).

Rationale Repeated calls to the eHealth foundation by the same client in close proximity time-wise are common. Each call must be authenticated and authorized. Much of this work is repeated for each call. Therefore, for performance reasons, the eHealth F\foundation must support the notion of a „security session‟ to reduce the repeated work. Hub-to-province calls are going to be common, and must therefore be performant. The provincial HIAL/ESB should be able to „continue‟ a transaction and/or security session established at a hub HIAL/ESB instance.

Implications The User Registry Security Token Service provides a mechanism for establishing a security session. This service should be exposed as a public service

There is a need for common security session and transaction identifiers, and these identifiers will have to be recognized by the various HIAL/ESB instances

There is a need for an established trust model, such that the various HIAL/ESB instances can leverage authentication and authorization performed by instances „earlier in the call stack‟. This will improve performance on hub-to-hub and hub-to-province transactions

Transaction and/or security session IDs could be shared, or simply accumulated in the messages (and/or web service interactions) as they progress through the HIAL/ESB instances


Principle AP-SEC-011: Transaction Independence

Statement Notwithstanding AP-SEC-010 Error! Reference source not found. services are stateless; transactions are independent, and cannot be replayed.

Rationale Scalability and performance requirements drive the need for stateless services. Transaction independence also increases scalability; transactions may be routed to any component (or service instance) that is capable of handling the request. The inability to replay transactions 1) improves the security posture of the eHealth services, as intercepted transactions cannot be replayed later for other purposes; 2) reduces the need for duplicate message detection in application code.

Implications The „security session‟ information required to support AP-SEC-010Error! Reference source not found. must be carried in the service invocations. This implies that session management is the responsibility of the client

This principle does not imply that service calls cannot update state held in the EHR data; rather it implies that the service implementation does not retain state between calls. All information required to service a particular request is included in the request itself

Stateless services are more easily distributed, which improves scalability (and typically, performance)

Duplicate message detection, required to combat transaction replay, is difficult and expensive (performance wise) to implement


Principle AP-SEC-012: Assume Hostility

Statement Service implementations must assume that their environment is hostile, and defend themselves accordingly. Principle AP-IS-003 Separation of Concerns implies that the eHealth foundation is responsible for authentication, authorization, message cleansing etc however services should assume that some callers are hostile and are attacking in ways that are not covered by eHealth foundation.

Rationale Applies the principle of „defence in depth‟; services extend the core protection offered by the eHealth foundation. The service implementations are best able to defend against attacks against line of business rules. In some situations, it may be that *only* the service implementation is able to perform some checks (eg: checks against encrypted payloads etc).

Implications Overall EHR security posture is improved.

Some performance degradation is expected; there is a cost to performing validation and checks.