March 31, Dear partners and collaborators:

Transcription

1 March 31, 2006 Dear partners and collaborators: I am pleased to present the revised version of the Electronic Health Record Solution (EHRS) Blueprint, Canada Health s road map guiding the sustainable development of the interoperable Electronic Health Record (EHR) for all Canadians. Based on interoperability (the ability of different systems to communicate seamlessly with one another), the Blueprint addresses the challenge of providing healthcare professionals with the patient information they need to support informed decision-making. It provides a framework for accessing and consolidating information and presents the information in a way that meets the needs of healthcare professionals. It takes into consideration the fact that tens of thousands of health information systems could be part of the Electronic Health Record across Canada. It supports the sharing of patient health information between health services providers -- including GPs, specialists, nurses and pharmacists -- across care settings, including hospitals, emergency rooms, clinics and homecare settings, and across geographical distances. The Blueprint guides all of s investment decisions. First published in 2003, the Blueprint has recently been enhanced to provide more detail on how standards-based technology can be used to support sharing of EHR information. The current version also integrates elements of the Privacy and Security Architecture, which provides for the private and secure sharing of health information. It shows how Telehealth and Public Health Surveillance fit in with the Electronic Health Record. The Blueprint was developed based on extensive consultations with stakeholders. I wish to thank all of the representatives from the jurisdictions and the privacy and security community as well as technology vendors, healthcare professionals and others for the time and energy devoted to enriching the Blueprint. I am pleased to note that many stakeholders who have previewed the enhanced Blueprint refer to it as a detailed, practical and valuable tool to guide EHR planning and implementation. The Blueprint is a foundational piece guiding our efforts to ensure that the EHR becomes a standard of care in Canada. The end result will be a renewed, sustainable healthcare system providing improved quality, productivity and access to health care for all Canadians. Thank you again to all who have contributed for your continued support. Sincerely, Richard C. Alvarez President and CEO Canada Health

2 Version 2 March 2006 Please take note of the Legal Disclaimer found on the last page of this document

3 FOREWORD It is my pleasure to introduce the second version of the Electronic Health Record Solution (EHRS) Blueprint. This is a very significant evolution from the first version, and is the result of significant design evaluations and collaborations with many stakeholders and subject matter experts across the country. There is consensus in Canada and other countries about the value of health information technology in the healthcare industry. Our efforts around the interoperable EHR are about providing each individual in Canada with a secure and private lifetime record of their key health history and care within the health system. The interoperable EHR will ultimately be available electronically to authorized health providers and the individual anywhere, anytime in support of high quality care. Additionally, this record is designed to facilitate the sharing of data across the continuum of care, across healthcare delivery organizations and across geographies. In order to achieve these objectives, the information technology solutions must be founded on interoperability. This is the fundamental driver for developing and publishing the Blueprint, and associated health information systems standards. The Blueprint is a set of standards and guidelines for our jurisdictional partners and vendors such that systems will be compatible and interoperable. Interoperability is a critical factor in renewing our healthcare system. Without interoperability, there can be no interoperable Electronic Health Record and information will continue to be trapped in silos, to the detriment of healthcare providers and patients Allow me to provide a high level overview of what you will find in this document. Objectives of EHRS Blueprint Version 2 While the first version of the Blueprint was helpful in defining the vision for EHR Solutions in Canada, it was understood from the outset that more work would be needed to successfully apply the concepts effectively in real-world solutions. With this in mind, the recent work on extending the Blueprint had the following objectives: - To improve its breadth and depth in terms of the scope of investment programs and in the level of detail in expressing architectural components. - To ensure its relevance and coherence as a vision statement for stakeholders, by furthering the business case for the use of EHR Solutions in health services, and by better illustrating how the EHRS is used in the context of service delivery. - To provide a fuller specification to guide: solution vendors, service provider organizations, regions, and federal/provincial/territorial jurisdictions in actually building and implementing EHR Solutions and their associated Infostructures (the software services common to and reusable among the diverse set of healthcare point of service systems). What is New in Blueprint v2 Just after the first version of the EHRS Blueprint was published, s mandate was increased to address two additional health domains; Telehealth, and Public Health Surveillance. Given the vast geography of the country and population distribution in Canada, and the sobering lessons learned from public encounters with SARS and West Nile virus, it is easy to understand the importance of these mechanisms for delivery health services and in preserving and promoting the health of Canadians.

4 The Blueprint incorporates the requirements for these domains into the evolving EHRS architecture, in support of the respective investment program strategies and with an objective of leveraging the EHR Infostructure to support real world projects in these domains. Telehealth For Telehealth, the key requirement is the ability to share consistent and comprehensive EHR information to health service providers and their patients at distances from each other. The essence of the Blueprint is enabling this sharing of information wherever it is required, and in the ability to see a consistent view of that information, regardless of the viewer s location and in addition to the abilities of local applications and the information they hold. For this reason, Telehealth requirements were met in the Blueprint by extending the representation of how the EHRS would meet these needs for different purposes. The EHRS architecture was already well suited for supporting this program as we already had a key requirement of sharing clinical information across geographies. Public Health Surveillance In the case of Public Health Surveillance (PHS), the impact to the Blueprint was much more far reaching. When considering the needs of PHS, it became clear that the concept of EHR infostructure was much more than a convenience, it could and should be an integral component of a set of applications that are being developed in conjunction with the development of a consistent set of standards for capture and use of information for PHS purposes. As a result, PHS introduced the concept of value-add Ancillary services that take advantage of the infostructure to leverage EHR data for health surveillance purposes. For example, public health provides rely heavily on information that is core to the EHR, such as immunization history and laboratory test results. In addition, the PHS program brings to the Blueprint the need to represent the use of Data Warehousing in a secure context for analysis. Privacy Security Architecture This version of the Blueprint is also aligned with the Privacy and Security Architecture (PSA), another project funded and led by. The PSA is a Canadian first, developed with the collaboration of all Canadian jurisdictions, in consultation with numerous other stakeholders, and with the privacy and security subject matter experts. It addresses the requirements for protecting the confidentiality and privacy of personal health information in the EHR on a pan-canadian basis. This is a complex and critically important component of the Blueprint. While each jurisdiction has its own policy related to securing personal health information, every jurisdiction and its stakeholders must be able to trust that their requirements are satisfied with the most appropriate privacy enhancing strategies and technologies when placing or accessing information in the EHR. The Privacy and Security Architecture has been available publicly for some time now, and it is being formally published in concert with the Blueprint v2 as it has shaped many aspects of the architecture, particularly in the Common Services section.

5 EHRS Reference Architecture Another major addition to the Blueprint in this version is the EHRS Reference Architecture (ERA). The Reference Architecture defines the set of formalisms, or documentation patterns, which express in a structured manner both the requirements for the interoperable EHR and the components and mechanisms to meet those requirements. The ERA includes: o o o o Clinical Reference Framework or the Life of the Lamberts. This is the set of use cases developed by to document our assumptions about the context for use of the interoperable EHR and the clinical requirements for communicating information. These use cases are not intended to represent every possible process in health care, but rather to focus on how EHR information is to be collected, shared and used in clinical decision making. EHRi Conceptual Data Model. This model provides a representation of how the Shared Health Record component of the EHR should be structured to flexibly support information collected and used in many different care settings and disciplines. EHR Interoperability Profiles. These are high level specifications of the mechanisms used by Point of Service applications to interact with the EHR infostructure. Infostructure Interoperability Profiles. These are high level specifications of how requests for placing or accessing data in the EHR are handled within the EHR infostructure. All of the information in the ERA has been represented using Unified Modeling Language representations and captured in an automated tool that has resulted in a repository of specifications that can be reused by projects with UML capable software engineering tools. Functioning Principles As Blueprint v2 evolved, there were many assumptions made that, once implemented in the architecture, can no longer be considered assumptions anymore: they are now principles about the function of EHR Infostructures and EHR Solutions that need to guide detailed design and development of solutions. What is Different in Blueprint v2 The current version of the Blueprint expresses many aspects of the architecture in more detail, expanding on the previous work and providing additional information. Longitudinal Record Services (LRS) The Blueprint diagram exposes the concept of Longitudinal Record Services (LRS). The LRS is responsible for all the business services (e.g. rules, data quality, normalization) and data access services (e.g. find, read and write a person s personal health information) that are required at the heart of an EHR solution. None of the services represented within this concept are really new, however it was realized that specifying these services separately from the Common Services greatly facilitated understanding of how the multiple repositories and registries are managed in the EHR infostructure. Extended Services Description This version of the Blueprint provides additional detail on the many services expressed in the original version. Basic execution patterns for invoking Infostructure services have been provided and more detailed descriptions of the various functions within the services are provided.

6 Infostructure Configurations and Potential Interim States The Blueprint now more fully expresses the possible deployment models for Blueprint based architectures in small, medium-sized, and large jurisdictions. Proposed COTS Configurations The use of Commercial-Off-The-Shelf (COTS) products as components of a functioning EHR infostructure is also addressed at a high level, providing various configurations for the use of currently available commercial products that would meet the requirements expressed in the Blueprint. New and Extended Value of the Blueprint The new version of the Blueprint is expressed in terms that should allow vendors and service provider organizations to more confidently engage in high level component and systems design. The Blueprint provides more information on how the various architectural elements must work together as a coherent set of EHR services. The UML modeling in the EHRS Reference Architecture can be reused by design and development projects, providing a quick start for solutions based around a shared perspective on the high-level requirements. The Life of the Lamberts has been very well received by many audiences, and will serve as a powerful baseline for continuing to refine and express requirements for EHR Solutions. How the Blueprint is Applied Today In the course of creating version 2 of the Blueprint, shared much of the work-in-process with our jurisdictions. Working closely with, some jurisdictions have already used the Blueprint v2 materials in their tendering processes for EHR related products and services. In addition, the early EHR projects across Canada have been relying upon the new representation for their planning and EHR Solutions design. The Blueprint is actively being used by the all of our standards projects, which were underway at the time of this publication. This project is tasked with the core set of messages for Point of Service applications to interface with the EHR infostructure. The message and terminology specifications produced by these projects are a direct extension of the Blueprint. How the Blueprint Will Be Maintained and Extended Looking to the Future (Near and Far) fully understands that we have a responsibility to our jurisdictional partners to sustain and continue to evolve the Blueprint as the roadmap for interoperable EHR solutions.

7 The EHRS Blueprint v2 is the last planned major revision. From this point forward the Blueprint will be decomposed into its various logical sections and the resulting documents will be loaded into the Artefacts Repository (AR) where they will be managed and new releases version controlled. The Artefacts Repository is a tool that includes a web-enabled database that holds many knowledge artefacts from the Blueprint, as well as from s standards projects, and the projects in each investment program. The AR categorizes the content and provides information on each artefact stored in it. It is publicly accessible, and can accept submission of artefacts from external sources as well. In Conclusion: Many Thanks is both inspired and humbled by the incredible energy, passion, and dedication to this work shown by our collaborators and stakeholders across the country. We understand that adherence to a higher level architectural framework means that EHR project teams must think beyond their local requirements. With many pressing issues needing to be addressed, thinking on a pan-canadian scale is not easy. Yet we have seen a willingness to embrace the Blueprint concepts and embed them in planning and actions that go beyond the imperative of Blueprint conformance as eligibility criteria for investments. Our team at hopes this document reflects those contributions. As jurisdictions invest in implementing the Blueprint, it has become much more than an artefact. This belongs to the Federal / Provincial / Territorial jurisdictions, it belongs to the country. All Canadians should be proud of the commitment and passion that their health community has for realizing the benefits that Electronic Health Record Solutions can bring. The Blueprint is one component of bringing the vision of the EHR to life for the benefit of all Canadians. Santé! Dennis Giokas Chief Technology Officer Canada Health Inc.

8 CONTENTS 1 VERSION TABLE EHRS BLUEPRINT CONTEXT KEY DEFINITIONS AND OVERARCHING CONCEPTS Design Levels (Conceptual vs. Logical vs. Physical) Enterprise Jurisdiction Patient vs. Person vs. Client EHRS EHRi EHR Service LRS EHR Data and Services (Domain Repositories) Ancillary Data and Services Health Information Data Warehouse Registries HIAL: The Health Information Access Layer EHRS Locator Overarching Concepts Primary Use vs. Secondary Use USES AND BENEFITS OF THE EHRS BLUEPRINT Promoting EHR Standardization Across Canada Reference For Strategic Planning For Provinces For Healthcare Organizations For Provider Associations For Providers (Healthcare Professionals) For Healthcare Informatics Solution Vendors For Privacy and Security Initiatives Enabling Project Specific Architecture, Design and test Phases...13 Critical to the Mission of Base to Engage In International EHR Standards Initiatives Base to Engage In Pan-Canadian EHR Standards Initiatives Enabling education and training initiatives KEY ARCHITECTURAL DECISIONS BLUEPRINT VALUE PROPOSITION September 2004 Milestone EHR in action EHR Value Timing EHR and telehealth BUSINESS CASE FOR THE EHR The International Experience Interoperable EHR Benefits GUIDING PRINCIPLES EHRS BLUEPRINT EVOLUTION Objectives in Evolving the EHRS Blueprint Blueprint v2 Deliverables...32 archinfo@-inforoute.ca EHRS Blueprint Version 2 Page i

9 2.7.3 Process for Producing Blueprint Version Blueprint v2.0 Validation with Stakeholders EHRS Blueprint Version 2 Publication EHRS Blueprint - Beyond Version STAKEHOLDER ENGAGEMENT Structure Key Events Looking to the Future BUSINESS ARCHITECTURE BUSINESS AND SOCIO-ECONOMIC DRIVERS Base Business Requirements Life-long longitudinal record of clinical data Focused on clinically relevant data shared beyond organizational boundaries Support for accurate, complete and timely delivery of information Shared across multiple organizations and jurisdictions Private and secure Adaptive to the future of healthcare delivery in the 21st Century Requires governance and operation management Key Economic Driver A large integration problem Different approaches have different costs The only economically viable approach BAH Study on 10 years cost Complexity of EHR Solutions Supporting Availability and Scalability Semantic Interoperability Integrating Information Flow Across Jurisdictions BUSINESS DOMAINS Healthcare Delivery Healthcare Management Healthcare Research Public Health...72 Telehealth THE PROPOSED SOLUTION Overview of diagram Components...81 Objectives EHR GENERATION ROADMAP A common language for generations of EHR capabilities Gartner Generations Model for CPR Systems Context for use of the Gartner model in the EHRS Blueprint Incremental Approach EHR Infostructure as a service CONCEPTUAL ARCHITECTURE OVERVIEW CLINICAL WORK PROCESS ARCHITECTURE Document Business Process Capture Process Flow Capture Structure: Domain Analysis Model and Glossary archinfo@-inforoute.ca EHRS Blueprint Version 2 Page ii

10 4.2.4 Capture Business Rules: Relationships, Triggers, and Constraints Harmonize the Domain Analysis Model with HL7 Reference Models SYSTEM ARCHITECTURE Service Oriented Architecture (SOA) Key Areas of System Responsibilities Registry Services Client Registry Provider registry Location registry EHR Data & Services Shared Health Record Domain Drug domain Diagnostic Imaging Domain Laboratory domain EHR Index Notification Process Ancillary Data & Services Data Warehouse Longitudinal Record Services (LRS) Business Services Data Services Transaction Handling and LRS Operators Health Information Access Layer (HIAL) HIAL Communication Bus Services HIAL Common Services The EHR Viewer Gen 2 Solutions (EHR Thin Client) Gen-2 (plus) Solutions Gen-3 (light) Solutions Gen-3 Solutions EHR Viewer Services Architecture Breakdown Visual Integration with PoS applications via CCOW EHR Viewer Requirements Interoperability Profiles INFORMATION ARCHITECTURE EHRi Conceptual Data Model EHRi Data Domains Clinical Terminologies What do we mean by clinical terminologies? What groups of information will be the object of clinical terminology standards? What is the process to standardize clinical terminologies? Data Communication Data Persistence Data Integrity TECHNICAL ARCHITECTURE Functioning Principles: No home EHR framework EHRi Identifier Management (Client, Provider, Location) HL7 V3 (Messaging and templates) EHR Index EHRS Locator PoS to EHRi interface archinfo@-inforoute.ca EHRS Blueprint Version 2 Page iii

11 Level of parameterization Other uses of the HIAL (PoS to PoS) Multi-lingual capabilities Runtime environment Level of transparency of EHR to PoS applications Performance principles targets PoS Integration environment Transaction scope Error Handling Trust Models Valid for an EHRi Authentication & Authorisation Informational Consent Directives OIDS as a principle Normalization Auditing, Logging and the Use of Logs Prospective Events Primary Purpose of EHRi data Mapping Services to Standards and Technology (Use of COTS) COTS and Standards Categories of technology solutions in an EHR Infostructure Key COTS Considerations for EHR Infostructure solutions USING THE BLUEPRINT IN EHRS PROJECTS TOOLS: ARTEFACT REPOSITORY METHODOLOGY: EHR DESIGN AND SPECIFICATION Investment Project Phases HL7 Message Development IHE Integration Profile Development Standard Security Management Interface Development Standard system management interface development DESIGN ARTEFACTS Clinical Activity Use Case EHR Interoperability Profile (EHR IP) EHR Communication Step (EHRCS) Infostructure Interoperability Profile (I-IP) EHRi System Services Data Model ONGOING SOLUTION DEVELOPMENT Diversity of EHR solution development settings An evolutionary path ONGOING STANDARDS DEVELOPMENT Scope of Standards Related Work The Standards Development Lifecycle Ongoing Work Timeline Accessibility of EHR Standards Work DEPLOYMENT MODELS EHRI DEPLOYMENT MODELS Assumptions Deployment Architecture The Logical View archinfo@-inforoute.ca EHRS Blueprint Version 2 Page iv

12 Physical View Deployment Model Examples Model 1: Single EHR Infostructure Model 2: Shared EHR Infostructure Model 3: Distributed EHR Infostructures OPERATIONAL CONSIDERATIONS FOR THE EHRI Governance Functional Requirements of EHRi Operation POTENTIAL APPLICATIONS ENABLING THE EHR INFOSTRUCTURE EXTENDING CURRENT APPLICATIONS NEW CLASSES OF APPLICATIONS SECONDARY USES APPENDIX A MODEL BY HEALTH CANADA APPENDIX B - INTERNET APPENDIX C - GLOSSARY APPENDIX D - ACKNOWLEDGEMENTS APPENDIX E - FUTURE CHANGES APPENDIX F - CONTACT INFORMATION APPENDIX G - LEGAL DISCLAIMER APPENDIX H INDEX LIST OF FIGURES Figure 2-1 Key EHRS Architecture Concepts...7 Figure 2-2 Integrated View of an EHR...20 Figure 2-3 Increasing Value of an EHR...23 Figure 2-4 Blueprint Versions and Level of Content...31 Figure 2-5 Stakeholder Engagement Process...38 Figure 3-1 Health continuum of care serving the client...44 Figure 3-2 The Changing World of Healthcare...48 Figure 3-3 Formula for integration of systems...51 Figure 3-4 Why pursue the EHR?...65 Figure 3-5 Sharing Information From Multiple Systems...66 Figure 3-6 The Proposed Solution...81 Figure 3-7 The Gartner Generations Model for CPR Systems...84 Figure 3-8 No EHR Services...87 Figure 3-9 HIAL without Longitudinal Record Services...88 Figure 3-10 HIAL with first level Longitudinal Record Services...89 Figure 3-11 Full featured EHR Infostructure...90 Figure 4-1 EHRS Conceptual View - Detailed...92 Figure 4-2 EHRS Blueprint scope...93 Figure 4-3 Life of the Lamberts Timeline...97 Figure 4-4 Use Cases Diagram part archinfo@-inforoute.ca EHRS Blueprint Version 2 Page v

13 Figure 4-4 Use Cases Diagram part Figure 4-5 EHRS Conceptual View Figure 4-6 Service Oriented Architecture Figure 4-7 Infostructure Interoperability Profile (I-IP) Pattern Figure 4-8 Delineation of System Responsibilities Figure 4-9 Registries Data & Services Figure 4-10 EHR Data & Services Figure 4-11 Ancillary Data & Services Figure 4-12 Data Warehouse Figure 4-13 HIAL Longitudinal Record Services Figure 4-14 HIAL Communication Bus Services Figure 4-15 HIAL Common Services Figure 4-16 EHR Viewer as PoS application in an EHR Solution Figure 4-17 EHR Viewer Services Figure 4-18 EHR IP Figure 4-19 Infostructure IP (I-IP) Figure 4-20 PoS to EHRi Interaction Figure 4-21 EHRi Conceptual Data Model Figure 4-22 ECDM View - Register New Patient Figure 4-23 Reference Terminology, Classification and Group Figure 4-24 s role in the standards life cycle Figure 4-25 EHR as a network of peer-to-peer EHR Infostructures Figure 4-26 Components of the Longitudinal Record Services Figure 4-27 EHRS Locator Conceptual Definition Figure 4-29 Centralized Locator Service Figure 4-30 Distributed Locator Service Figure 4-31 LRS Integrated Locator Service Figure 4-32 Client Registry Synchronization Figure 4-33 EHRi Interface Protocols Figure 4-34 Aspects of HL7 Messaging Figure 4-35 SOA Multi-Tier Components Figure 4-36 CIS with an Integrated Viewer Figure 4-37 EAI Centric LRS Capability Figure 5-1 Artefact Repository Sample Screen Figure 5-2 EHR IP Interaction Diagram Figure 5-3 I-IP Process Flow Diagram Figure 5-4 Sample Service Class Part Figure 5-4 Sample Service Class Part Figure 5-5 Sample Data Class Part Figure 5-5 Sample Data Class Part Figure 5-6 Standards Collaboration Process Figure 5-7 Standards Development Life Cycle Figure 5-8 Standards Development Timeline Figure 6-1 Model 1: Single EHR Infostructure Figure 6-2 Model 2: Shared EHR Infostructure Figure 6-3 Model 3: Distributed EHR Infostructures Figure 6-4 The EHR seen as a Business Service Figure 7-1 Business Opportunity Around EHRi Figure 7-2 EHRS Data - Value Enabler for Existing Applications Figure 7-3 EHRS Data Potential Application Areas archinfo@-inforoute.ca EHRS Blueprint Version 2 Page vi

14 1 VERSION TABLE Version # Published Date Comments First public version of the EHRS Blueprint Second public version of the EHRS Blueprint archinfo@-inforoute.ca EHRS Blueprint Version 2 Page 1

15 2 EHRS BLUEPRINT CONTEXT This section presents elements of definition that were considered key in establishing the context for the EHRS Blueprint (Electronic Health Record Solution Blueprint). Most of these elements emanated from the Business Plan of and the many surveys and studies that accompanied its creation. The elements presented here include key terminology, overarching concepts, forefront elements of the value proposition and business case, as well as guiding principles for the architecture. 2.1 KEY DEFINITIONS AND OVERARCHING CONCEPTS Design Levels (Conceptual vs. Logical vs. Physical) The objective of the EHRS Blueprint is to provide a collaborative and shared vision of an interoperable EHR (iehr) for all jurisdictions in Canada. In keeping with the practice of enterprise architecture, the EHRS Blueprint presents a number of views or perspectives of the envisioned future state representing the points of view of various stakeholders involved in EHR initiatives. Due to its Pan-Canadian scale and the complexities inherent to implementing solutions across large numbers of jurisdictions, organizations, and facilities, the EHRS Blueprint has been intentionally articulated at a high level of abstraction. Several principles guided this design to create a common, interoperable architecture that leveraged existing systems and solutions while remaining extensible to support future growth and innovations. Reconciling these goals requires a flexible solution that is inevitably influenced (and constrained) by the general EHR strategies already underway across the country. Consequently, the project team was allowed to take some liberties in regards to the formalisms typically applied in more conventional enterprise-level architectures. First, the conceptual view contains some aspects of logical components to better reflect common aspects of many of the EHR strategies currently in development in Canadian jurisdictions. Secondly, a physical view is not provided as it would bind the architecture too tightly to specific hardware configurations, vendor applications and operating systems, which is not a goal of this piece of work. The Blueprint addresses the following perspectives of the definition of an EHRS: 1. Business Architecture: The EHRS business architecture section presents the key business requirements that drive the definition of the proposed solution. These requirements have been matured through the various initiatives that led to the creation of Canada Health, among them the Advisory Committee on Health Infostructure (ACHI). These requirements are also representative of the evolution of thinking that has occurred in various Canadian jurisdictions since the inception of and the publishing of the first version of the EHRS Blueprint. The main objective of this section is to establish the business requirements that influence key architectural decisions in leading to the solution described in the document. 2. Conceptual Architecture: The conceptual architecture addresses the what question for different aspects of an interoperable EHR Solution including: what work processes are supported, what system services are required and what information is manipulated. The conceptual architecture also archinfo@-inforoute.ca EHRS Blueprint Version 2 Page 2

16 identifies key technical challenges that need to be addressed in the form of functioning principles for an EHR Solution. 3. Logical Architecture (Using the Blueprint in EHRS projects): This section provides an introduction to the EHRS Reference Architecture, a fully documented architecture driving into logical level definitions. The scope of diagrams and definitions provided addresses all aspects of the architecture including: a. people and system use cases; b. data models; c. sequence diagrams for processing flows; and d. other representations as they have evolved in our dialogs with our stakeholders. While integrating the conceptual level of definition, this reference architecture also explores the description of dynamic interaction and processing patterns in order to provide examples of how transactions could be processed by EHR Solutions. This architecture is provided as a separate document and is generated from a CASE (Computer Assisted System Engineering) tool so that it can easily be reused as a framework for documenting and building EHR solutions. 4. Deployment Models: The EHRS Blueprint incorporates features from many different EHR strategies that are currently being planned and/or deployed in various Canadian jurisdictions. This section provides emerging models for EHRi deployment in Canada and outlines the architecture s flexibility and adaptability. 5. Potential Applications: Finally, this section surfaces the different potential uses of the Blueprint architecture in interoperable EHR solutions. This section describes both a short term perspective in terms of the availability and usage of EHR Solutions as well as a longer term view Enterprise The EHRS Blueprint focuses on the enterprise architecture for the electronic health record (EHR) in Canada. Enterprise, in this context, refers to the health system in Canada which in turn is made up of the healthcare and public health service delivery as governed and operated by the Provinces and Territories, or across jurisdictions as in the case of Federal payer organisations such as Veterans Affairs, the Military, first nation communities, correctional services and others Jurisdiction A jurisdiction refers to a geopolitical entity that governs the administration, operation and delivery of public health or healthcare services and the governance of an Electronic Health Record Solution and is typically represented by a Federal agency, Province, Territory, or Regional Authority Patient vs. Person vs. Client Throughout this document, the terms patient, person and client have the same meaning and refer to an individual needing or accessing care through the health system. These terms are used interchangeably in the document EHRS archinfo@-inforoute.ca EHRS Blueprint Version 2 Page 3

17 An Electronic Health Record Solution (EHRS) is a combination of people, organizational entities, business processes, systems, technology and standards that enable the interaction and exchange of clinical data to provide high quality and effective health services. At an enterprise level, this includes the broad range of existing Point of Service (PoS) applications, the health information they hold, as well as the EHR infostructure (EHRi) articulated in this Blueprint that allows this information to be securely and appropriately shared. It is made up of: Mechanisms to find and uniquely identify people, providers and locations; Patient-centric Electronic Health Records (EHR); Presentation solutions and intelligent agents; Common services and standards to enable integration and interoperability; Workflow and case management; Decision support services; Services to support health surveillance and research; Services to ensure privacy and security; Physical infrastructure to support reliable and highly available electronic communications; EHRi An EHR Infostructure (EHRi) is a collection of common and reusable components in the support of a diverse set of health information management applications. It consists of software solutions, data definitions and messaging standards for the EHR. It is made up of: Registry systems to manage and provide the information required to uniquely identify the actors and resources in the EHR. Specifically, these are the patient/client, the provider of care, the location of care, the end users of applications and the terminologies used to describe diseases, acts or other clinically relevant information. Registries which hold patient/client consent information are part of the EHRi as well. EHRi domain repositories that manage and persist subsets of clinical data pertinent to the clinical picture of a client. A diagnostic imaging PACS solution is an example of a Domain Repository. The Shared Health Record repository that holds information on health service events and the clinical observations associated with those events. A Longitudinal Record Service to coordinate the patient centric accesses, updates and location of data across multiple domains and registries. Standardized common services and communication services to sustain the interoperability of the different components within the infostructure, as well as to sustain interoperability and a high degree of abstraction between the EHR infostructure and the Point of Service (PoS) applications. Standardized information and message structures as well as business transactions to support the exchange of information in and out of the EHR; An EHR viewer as a generic presentation application allowing end-users to access, search and view relevant and authorised clinical data about clients. archinfo@-inforoute.ca EHRS Blueprint Version 2 Page 4

18 2.1.7 EHR Service An EHR Service provides each individual in Canada with a secure and private lifetime record of their key health history and care within the health system. The record is available electronically to authorized health care providers and the individual anywhere, anytime in support of high quality care LRS In an EHRi, the Longitudinal Record Service (LRS) is the central component that coordinates and manages the existence and location of clinical information about clients. One of the main features of the LRS is an index of all events tracked or maintained in an EHRi. Through this index, a consistent longitudinal and cross-domain view of the clinical information of a client is always available EHR Data and Services (Domain Repositories) An EHR Domain Repository is a component of an EHRi that stores, manages and persists a specific clinical subset of data, typically at a jurisdictional level. While such systems play a key role in enabling sharing of certain types of information across the continuum of care, they may also play the role of operational level systems in a jurisdiction. The extent of the clinical information sustained by an EHR Infostructure may vary based primarily on the presence or absence of EHR Domain Repositories. The key data domains recognized as part of an EHR are the shared health record, drugs, laboratory and diagnostic imaging. In Canada today, some of these data domains may already be the subject of deployed jurisdictional level systems. In order to provide the complete clinical picture of a patient/client, the EHR infostructure must be able to assemble information transparently from these EHR Domain Repositories Ancillary Data and Services Ancillary data and services represent a generic class of auxiliary capabilities that rely on, need or complement EHR domain data in order to support health services delivery. Examples of potential ancillary services include: outbreak management, communicable disease reporting to support the realm of public health. Other valid examples could include: enterprise scheduling, wait list monitoring, cross-continuum workflow services and others Health Information Data Warehouse The Health Information Data Warehouse represents a separate capability to compile, aggregate and consolidate EHR data for reporting and statistical or research analysis. The EHR data domains, ancillary services or registry services data will be highly optimized and preserved to support online patient centric accesses to Electronic Health Records by caregivers and other types of end-users. While this is the primary goal of the EHR Infostructure, a lot can be said for the healthcare value derived from being able to use this information for research, analysis and health prevention initiatives. Key examples of such uses include public health surveillance, public health reporting and tracking of key health indicators, health research analysis, cancer care research, etc archinfo@-inforoute.ca EHRS Blueprint Version 2 Page 5

19 To support these types of uses, a separate data analysis environment is required and online transactional data needs to be moved to a data warehouse environment where data can easily be manipulated and transformed to meet such analysis requirements Registries A Registry is a directory-like system that focuses solely on managing data pertaining to one conceptual entity. In an EHRi, registries store, maintain and provide access to peripheral information not necessarily clinical in nature but required to operate an EHR. The primary purpose of a Registry is to respond to searches using one or more pre-defined parameters in order to find and retrieve a unique occurrence of an entity. Examples of registries include: Client Registry, Provider Registry and Location Registry HIAL: The Health Information Access Layer The Health Information Access Layer (HIAL) is a gateway that acts as an abstraction layer to separate PoS applications from the EHR Infostructure. It is made up of service components, service roles, information models and messaging standards required for the exchange of EHR Data and the execution of interoperability profiles between EHR Services. The HIAL is broken down into two layers of services: the common services and the communication bus services. The common services layer is an aggregation of services that provides common and reusable functions for the systems that participate in an EHR Infostructure. It is focused on integration, privacy and security, system configuration, management and monitoring functions and makes those common functions available for all services in a given EHRi. The communication bus services layer is an aggregation of services that pertain specifically to enabling communication capabilities. It is focused on the receiving and sending of messages and the support of valid communication modes primarily between PoS applications and an EHRi, EHRi to EHRi and possibly between components within an EHRi (e.g. LRS to Client Registry) EHRS Locator The EHRS Locator maintains information describing which EHR Infostructure(s) keeps a record for a given individual. It allows each EHRi to trace and retrieve the address of other EHR Infostructures where clinical data is maintained about a person. It is used in the context of transactions to know where data is located and to subsequently enable an LRS to query those locations. archinfo@-inforoute.ca EHRS Blueprint Version 2 Page 6

20 Overarching Concepts Figure 2-1 Key EHRS Architecture Concepts The above diagram describes the previously defined key concepts and illustrates how they assemble into the architecture for an EHRS. The key business architecture and technical architecture elements of the EHRS include the following: The information stored in the EHR Data and Services Repositories is patient/client-centric and longitudinal. Logically it forms a womb to-tomb health history for the patient/client. Together the PoS applications participating in an EHRi and their associated databases form the complete electronic health record of a patient/client; Across a network of EHR Solutions a patient/client is perceived by the PoS applications and their endusers (caregivers) as existing logically in one single EHR. Given the way healthcare is delivered in Canada it is important that there be flexibility in the solution architecture with respect to where a patient/client s physical EHR data is located. By way of example, the EHR data about a client will typically stay physically in the province/territory where they received care. Over time, this may mean that a client s EHR data is distributed across several EHR infostructures. However, each time that a caregiver is accessing this client s EHR, the EHR infostructure handling this request will compile all the data relevant across any number of EHR infostructures where relevant data is kept. From the system s perspective, and more importantly the users of those systems, the person s data is perceived as being in one EHR; archinfo@-inforoute.ca EHRS Blueprint Version 2 Page 7

21 The EHR is an authoritative and reliable source of the clinical information. It is meant to be used as a valid source of information in support of health services providers assessing and making clinical decisions for clients on a continual basis; Conceptually, an EHR is a structured set of clinical information for a patient/client. Information for the patient/client may be organized into multi-dimensional categories such as time, clinical data type (e.g. encounter events, lab order or result, drugs prescription or dispense, clinical notes), practice area, disease classes and others; The EHR holds a history of health service delivery events for each patient/client. Events can be flexibly associated with, or organized as, an Encounter, or as part of a larger Episode of Care. This allows the organizing of a patient/client s health history in a way that is meaningful to providers of services; All clinically relevant data required to share the clinical picture of a patient/client across the continuum of care is kept in the EHR; An EHRi is NOT an on-line transaction processing (OLTP) store for any clinical system used in a point of service; An EHRi is enabled by registries, a LRS, EHR Data domain repositories, ancillary services, a health information data warehouse and a HIAL; The PoS applications are key elements of the solution. PoS applications are used by authorized caregivers to view and navigate the EHR of a patient/client. These include applications at the point of care that a provider is interacting with. This may be a piece of medical equipment that is generating or reading clinical data for a patient/client or an intelligent agent (i.e. without a human-computer interface) implementing some specific business rules; Data produced in PoS settings is pushed or published into the EHRi from PoS applications; PoS applications store encounter related data in their local data store and are also publishing or replicating the parts of this data that is declared as clinically relevant for sharing, in near real-time into the EHR via the EHRi. The same set of PoS applications read and use data out of the EHRi. Thus, the EHRi is used for clinical purposes by these applications. EHRi data is viewed from PoS applications that caregivers or providers use in their daily activities. For example, a primary care doctor using an electronic medical record (EMR) application may be viewing four sets of data on their system. One set of data coming from the patient s EHR; another from the EMR application order entry module (i.e. for a new prescription or lab test); another from the EMR s local database regarding the patient s latest visit; and a fourth set for an input screen for the doctor s clinical notes pertaining to the visit. The interface between PoS applications and EHRi must comply with pan-canadian EHR standards. Several modes of communication have to be supported in order to cover the different types of interactions that are needed. Most of the communications rely on a service oriented messaging framework for the purposes of reading and writing clinical information in and out of the EHRi. Some communications rely on streaming protocols (e.g. diagnostic imaging). Pan-Canadian EHRi communication standards are based on industry standards such as HL7, DICOM, EBXML, SOAP, SHTTP and TCP/IP Primary Use vs. Secondary Use This descriptor of primary or secondary use of the Electronic Health Record is intended to distinguish between the different purposes for accessing the EHR. The perspective driving this definition is that of the archinfo@-inforoute.ca EHRS Blueprint Version 2 Page 8

22 end user and the work processes carried on by such users. The qualifier of primary versus secondary uses refers to the data coming from an EHR and the way in which the data contained in the EHR contributes directly to the functioning of work processes involved in the provision of care to a patient. Primary Use Primary Use of the EHR refers to usage of the EHR data to directly contribute to the provision of care for a patient/client for a given encounter or episode. In most provinces today, primary uses are conducted under some form of implied consent with or without notification. In general we recognize the following categories as representing uses that would be considered as primary: 1. Health services provision 2. Patient-focused outcome analysis where names are required Examples of primary usage would include, but are not limited to, the following: A General Practitioner (GP) using their Electronic Medical Record (EMR) to access the referral summary from a Cardiologist for a patient/client they are seeing. A radiologist contributing the digital image and report for a CT Scan to a patient s/person s EHR. A pharmacist, in a drugstore, accessing a patient s/person s electronic prescription and medication profile to fulfill and contribute an electronic dispensing event. A patient/client contributing blood glucose results from their digital glucometer for the purposes of monitoring gestational diabetes. A health care facility nurse accessing demographic data to contact a specific patient/client in the context of a product recall for a faulty heart device; An Emergency Room (ER) nurse accessing the health history of a patient/client and contributing a summary of the assessment and treatment provided during the encounter. A physiotherapist, in a community-based clinic, contributing observations in the context of an interdisciplinary rehabilitation care plan for a burn victim; Secondary Use Secondary Use of the EHR refers to usage of the EHR data for activities that are not directly related to the care of a specific patient/client for a given encounter or episode. In most provinces today, secondary uses of the data are done via anonymized data and require some form of consent. Secondary uses may also pertain to identifiable data and in that case always require explicit consent from the patient/client. In general we recognize the following categories as representing uses that would be considered as secondary: 1. Governance and health service delivery administration 2. Program management conducted by Programs and Health Authorities 3. Education e.g. teaching hospitals etc. Where education is bundled with care provision it is considered care first and foremost, not education. 4. Insurance 5. Research 6. Public health surveillance archinfo@-inforoute.ca EHRS Blueprint Version 2 Page 9