logical architecture principles - ehealth ontario | it's ... · pdf fileap-ptl-001:...
TRANSCRIPT
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.
Logical Architecture /Architecture Principles /Version #1.0 2
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.
Logical Architecture /Architecture Principles /Version #1.0 3
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
Logical Architecture /Architecture Principles /Version #1.0 4
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.
Logical Architecture /Architecture Principles /Version #1.0 5
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
Logical Architecture /Architecture Principles /Version #1.0 6
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
Logical Architecture /Architecture Principles /Version #1.0 7
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.
Logical Architecture /Architecture Principles /Version #1.0 8
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.
Logical Architecture /Architecture Principles /Version #1.0 9
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.
Logical Architecture /Architecture Principles /Version #1.0 10
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
Logical Architecture /Architecture Principles /Version #1.0 11
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.
Logical Architecture /Architecture Principles /Version #1.0 12
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
Logical Architecture /Architecture Principles /Version #1.0 13
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
Logical Architecture /Architecture Principles /Version #1.0 14
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
Logical Architecture /Architecture Principles /Version #1.0 15
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.
Logical Architecture /Architecture Principles /Version #1.0 16
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.
Logical Architecture /Architecture Principles /Version #1.0 17
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.
Logical Architecture /Architecture Principles /Version #1.0 18
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”.
Logical Architecture /Architecture Principles /Version #1.0 19
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.
Logical Architecture /Architecture Principles /Version #1.0 20
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
Logical Architecture /Architecture Principles /Version #1.0 21
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
Logical Architecture /Architecture Principles /Version #1.0 22
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
Logical Architecture /Architecture Principles /Version #1.0 23
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
Logical Architecture /Architecture Principles /Version #1.0 24
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
Logical Architecture /Architecture Principles /Version #1.0 25
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.
Logical Architecture /Architecture Principles /Version #1.0 26
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.
Logical Architecture /Architecture Principles /Version #1.0 27
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
Logical Architecture /Architecture Principles /Version #1.0 28
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
Logical Architecture /Architecture Principles /Version #1.0 29
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
Logical Architecture /Architecture Principles /Version #1.0 30
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
Logical Architecture /Architecture Principles /Version #1.0 31
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
Logical Architecture /Architecture Principles /Version #1.0 32
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
Logical Architecture /Architecture Principles /Version #1.0 33
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
Logical Architecture /Architecture Principles /Version #1.0 34
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
Logical Architecture /Architecture Principles /Version #1.0 35
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
Logical Architecture /Architecture Principles /Version #1.0 36
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
Logical Architecture /Architecture Principles /Version #1.0 37
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
Logical Architecture /Architecture Principles /Version #1.0 38
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
Logical Architecture /Architecture Principles /Version #1.0 39
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
Logical Architecture /Architecture Principles /Version #1.0 40
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
Logical Architecture /Architecture Principles /Version #1.0 41
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
Logical Architecture /Architecture Principles /Version #1.0 42
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
Logical Architecture /Architecture Principles /Version #1.0 43
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
Logical Architecture /Architecture Principles /Version #1.0 44
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
Logical Architecture /Architecture Principles /Version #1.0 45
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)
Logical Architecture /Architecture Principles /Version #1.0 46
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
Logical Architecture /Architecture Principles /Version #1.0 47
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
Logical Architecture /Architecture Principles /Version #1.0 48
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
Logical Architecture /Architecture Principles /Version #1.0 49
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
Logical Architecture /Architecture Principles /Version #1.0 50
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
Logical Architecture /Architecture Principles /Version #1.0 51
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
Logical Architecture /Architecture Principles /Version #1.0 52
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
Logical Architecture /Architecture Principles /Version #1.0 53
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
Logical Architecture /Architecture Principles /Version #1.0 54
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.
Logical Architecture /Architecture Principles /Version #1.0 55
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
Logical Architecture /Architecture Principles /Version #1.0 56
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.
Logical Architecture /Architecture Principles /Version #1.0 57
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.
Logical Architecture /Architecture Principles /Version #1.0 58
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.
Logical Architecture /Architecture Principles /Version #1.0 59
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
Logical Architecture /Architecture Principles /Version #1.0 60
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
Logical Architecture /Architecture Principles /Version #1.0 61
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
Logical Architecture /Architecture Principles /Version #1.0 62
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)
Logical Architecture /Architecture Principles /Version #1.0 63
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
Logical Architecture /Architecture Principles /Version #1.0 64
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
Logical Architecture /Architecture Principles /Version #1.0 65
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
but is not limited to:
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
Logical Architecture /Architecture Principles /Version #1.0 66
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
Logical Architecture /Architecture Principles /Version #1.0 67
Principle AP-SLO-006: Capacity
Statement Provincial EHR service solutions comply with the capacity service level objectives
established by eHealth Ontario.
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
but is not limited to:
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
Logical Architecture /Architecture Principles /Version #1.0 68
Principle AP-SLO-007: Scalability
Statement Provincial EHR service solutions comply with the scalability service level objectives
established by eHealth Ontario.
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
Logical Architecture /Architecture Principles /Version #1.0 69
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
Logical Architecture /Architecture Principles /Version #1.0 70
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.
Logical Architecture /Architecture Principles /Version #1.0 71
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
Logical Architecture /Architecture Principles /Version #1.0 72
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
Logical Architecture /Architecture Principles /Version #1.0 73
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
Logical Architecture /Architecture Principles /Version #1.0 74
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
Logical Architecture /Architecture Principles /Version #1.0 75
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.
Logical Architecture /Architecture Principles /Version #1.0 76
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.
Logical Architecture /Architecture Principles /Version #1.0 77
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.
Logical Architecture /Architecture Principles /Version #1.0 78
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
Logical Architecture /Architecture Principles /Version #1.0 79
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.
Logical Architecture /Architecture Principles /Version #1.0 80
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
Logical Architecture /Architecture Principles /Version #1.0 81
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.
Logical Architecture /Architecture Principles /Version #1.0 82
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.
Logical Architecture /Architecture Principles /Version #1.0 83
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
Logical Architecture /Architecture Principles /Version #1.0 84
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
Logical Architecture /Architecture Principles /Version #1.0 85
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
Logical Architecture /Architecture Principles /Version #1.0 86
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
Logical Architecture /Architecture Principles /Version #1.0 87
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
Logical Architecture /Architecture Principles /Version #1.0 88
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.