Logical Architecture Principles

Transcription

1 Ontario Provincial EHR Logical Architecture Principles Version: 1.0

2 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 ii

3 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 AP-EPS-002: Services to ehealth Ontario internal systems are abstracted from external consumers AP-EPS-003: Limited number of controlled connection points to the ehealth foundation services AP-EPS-004: ehealth foundation services provide different types of service modes AP-EPS-005: External/Public services are secured Internal Services Principles 15 AP-IS-001: Intra-foundation Communication AP-IS-002: Bus to Bus Patterns and Service Consumption Paths AP-IS-003: Separation of Concerns AP-IS-004: Authentication AP-IS-005: Business Context Propagation AP-IS-006: Enterprise Transaction ID Data Messaging Interaction Principles 21 AP-DMI-001: Use of messaging for transactional data exchanges AP-DMI-002: Use of industry standards for message structures and application level protocols 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 AP-DMI-005: Use of request-response messaging pattern for application level interactions AP-DMI-006: Use of web services and web services protocol AP-DMI-008: Business Application Level Acknowledgement AP-DMI-009: Data Messaging Interactions are authenticated and authorised EHR Data Principles 29 AP-EHR.Data-001: EHR Data Trusteeship AP-EHR.Data-002: System of Record AP-EHR.Data-003: Authoritative Source AP-EHR.Data-004: History of EHR Data...32 Logical Architecture /Architecture Principles /Version #1.0 iii

4 AP-EHR.Data-005: Enterprise Identifiers...33 AP-EHR.Data-006: Validation of Enterprise Identifiers AP-EHR.Data-007: Validation of Client Identifier AP-EHR.Data-008: Validation of Provider Identifier AP-EHR.Data-009: Referential Integrity AP-EHR.Data-0010: Semantic Alignment AP-EHR.Data-011: EHR Data Conservation EHR Document Principles 40 AP-EHR.Doc-001: EHR Documents are supported AP-EHR.Doc-002: EHR Document has trusted authorship AP-EHR.Doc-003: EHR Document maintains its integrity AP-EHR.Doc-004: EHR Document conformance AP-EHR.Doc-005: EHR Document preserve their wholeness AP-EHR.Doc-006: EHR Document Secure exchanges AP-EHR.Doc-007: EHR Document metadata Portlet Services Principles 47 AP-PTL-001: Portlets via Web Services AP-PTL-002: Portlet Governance AP-PTL-003: Portlet Consumption of ehealth foundation Services AP-PTL-004: Portlet Look and Feel AP-PTL-005: Portlets Device Independence AP-PTL-006: Inter-portlet Communication AP-PTL-007: Portlet Hosting Services Privacy Principles 54 AP-PRV-001: Collection AP-PRV-002: Individual s right of access AP-PRV-003: Disclosure and use AP-PRV-004: Consent directives AP-PRV-005: Emergency disclosure ( Breaking the glass ) AP-PRV-006: Provision of de-identified information without informed consent AP-PRV-007: Revocation of disclosure is not retroactive EHR Service Level Objective Principles 62 AP-SLO-001: Performance AP-SLO-002: Availability AP-SLO-003: Software Quality Assurance (SQA) AP-SLO-004: Monitoring AP-SLO-005: Business Continuity & Recoverability AP-SLO-006: Capacity AP-SLO-007: Scalability AP-SLO-008: Maintainability Time Synchronization Principles 70 AP-TS-001: Server Time Synchronization AP-TS-002: Directory Server Synchronization Logical Architecture /Architecture Principles /Version #1.0 iv

5 AP-TS-003: ehealth Services Synchronization AP-TS-004: Support of Universal Coordinated Time (UTC) AP-TS-005: Storage of Date/Time AP-TS-006: Support of Pan-Canadian Standards AP-TS-007: Display of Date/Time Security Principles 77 AP-SEC-001: Apply ISO# AP-SEC-002: Take guidance from the Canada Health Infoway EHRS Blueprint Privacy and Security Architecture AP-SEC-003: Personal and Personal Health Information Protection AP-SEC-004: Federated Authentication AP-SEC-005: Federated Authentication Standards AP-SEC-006: Multiple Levels of Identity Assurance AP-SEC-007: Identity Propagation AP-SEC-008: Data Protection (Confidentiality) AP-SEC-009: Data Protection (Integrity and Non-repudiation) AP-SEC-010: Transaction and Security Session Propagation AP-SEC-011: Transaction Independence AP-SEC-012: Assume Hostility Logical Architecture /Architecture Principles /Version #1.0 v

6 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 noncompliant with the ehealth Ontario Blueprint. Logical Architecture /Architecture Principles /Version #1.0 1

7 EHR SOA Principles Principle AP-SOA-001: The Provincial EHR is supported by a formal governance structure 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. 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 o End-users: representing both internal and external clients; and 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 2

8 AP-SOA-002: ehealth foundation services and consumers are categorized 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. 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 3

9 AP-SOA-003: ehealth foundation services are managed ehealth foundation services are managed in an on-going manner in respect to their name, version, classification and to prevent or manage duplication. 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 4

10 AP-SOA-004: ehealth foundation services have contracts based on web services The ehealth foundation services establish standardized contracts between service providers and consumers that are based on the web services paradigm. 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 5

11 AP-SOA-005: ehealth foundation services are discoverable Decisions and descriptions relating to services and their contracts shall be stored in a single, well-known, accessible location, including contextual information. 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 6

12 AP-SOA-006: Provincial EHR Services names describe their business function The names of Provincial EHR web services relay directly the business function of business facet that they support. 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 7

13 AP-SOA-007: ehealth foundation service Policies are enforceable Service policies shall be enforced 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 8

14 AP-SOA-008: ehealth foundation services are based on established standards 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. 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 9

15 External/Public Services Principles Principle AP-EPS-001: Consistent set of interfaces and behaviours 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. 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 10

16 AP-EPS-002: Services to ehealth Ontario internal systems are abstracted from external consumers The ehealth Ontario internal application systems that make up the Provincial EHR are abstracted and not directly accessible to consumer organizations and applications. 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 11

17 AP-EPS-003: Limited number of controlled connection points to the ehealth foundation services ehealth foundation services are exposed externally through few connection points established by ehealth Ontario. 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 o o 1 provincial ESB for public data consumers and systems of record 3 regional hubs 1 provincial hub for private systems of record Logical Architecture /Architecture Principles /Version #1.0 12

18 AP-EPS-004: ehealth foundation services provide different types of service modes 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 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 13

19 AP-EPS-005: External/Public services are secured External/Public ehealth foundation Services enforce security measures that conform to the security policy requirements established by ehealth Ontario. 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 14

20 Internal Services Principles Principle AP-IS-001: Intra-foundation Communication Communications within the ehealth Ontario foundation, between foundational components 2, 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. 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 15

21 AP-IS-002: Bus to Bus Patterns and Service Consumption Paths While traversing the Health Information Access Layer/Enterprise Service Bus, ehealth Services should be consumed via the most direct path possible. 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 16

22 AP-IS-003: Separation of Concerns 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 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 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 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 17

23 AP-IS-004: Authentication Authentication for internal services should leverage the same mechanism(s) as are used for external/ public services. 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 18

24 AP-IS-005: Business Context Propagation The originating business context should be propagated as deeply as possible. 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 19

25 AP-IS-006: Enterprise Transaction ID 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. 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 20

26 Data Messaging Interaction Principles Principle AP-DMI-001: Use of messaging for transactional data exchanges 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 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 21

27 AP-DMI-002: Use of industry standards for message structures and application level protocols 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. 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 22

28 AP-DMI-003: Use of DICOM for exchanges of binary large objects in diagnostic imaging System to system interactions in the context of diagnostic imaging when transacting imaging artefacts will use the industry standard DICOM protocol. 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 23

29 AP-DMI-004: Unidirectional communication pattern from consumer systems 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 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 24

30 AP-DMI-005: Use of request-response messaging pattern for application level interactions Consumer systems rely on a request-response messaging pattern when communicating with the Provincial EHR for data messaging interactions. 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 25

31 AP-DMI-006: Use of web services and web services protocol Messages are encapsulated into industry standard web services and web services level features are used to control communication, reliable messaging and security. 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 26

32 AP-DMI-008: Business Application Level Acknowledgement 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. 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 27

33 AP-DMI-009: Data Messaging Interactions are authenticated and authorised Data Messaging Interactions rely on the use of standards based protocols to authenticate and authorise requesters. 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 28

34 EHR Data Principles Principle AP-EHR.Data-001: EHR Data Trusteeship 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. 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 29

35 AP-EHR.Data-002: System of Record The Provincial EHR identifies the System of Record (i.e. authoring system for every EHR Data). 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 30

36 AP-EHR.Data-003: Authoritative Source The Provincial EHR is an authoritative source of EHR Data. 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 31

37 AP-EHR.Data-004: History of EHR Data 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. 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 32

38 AP-EHR.Data-005: Enterprise Identifiers The Provincial EHR establishes Enterprise Identifiers used to normalize key concepts in EHR Data. 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 33

39 AP-EHR.Data-006: Validation of Enterprise Identifiers The Provincial EHR ensures the validity of all Enterprise Identifiers. 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 34

40 AP-EHR.Data-007: Validation of Client Identifier The Provincial EHR always validates the client identifier. Given the level of responsibility tied to the client identifier and the implications of falsepositive 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 35

41 AP-EHR.Data-008: Validation of Provider Identifier 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. Given the level of responsibility tied to the provider identifier and the implications of falsepositive 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 36

42 AP-EHR.Data-009: Referential Integrity The Provincial EHR preserves the referential integrity of EHR Data. 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 37

43 AP-EHR.Data-0010: Semantic Alignment The Provincial EHR promotes semantic alignment of EHR Data. 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 38

44 AP-EHR.Data-011: EHR Data Conservation 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. 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 39

45 EHR Document Principles Principle AP-EHR.Doc-001: EHR Documents are supported The Provincial EHR supports the processing, persistence and disclosure of EHR Documents. 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 40