Blueprint 2015 Interdependent Registries - A Discussion Paper –

1. Blueprint 2015Interdependent Registries - A Discussion Paper – Ron Parker

2. Today’s Presentation • The material we are discussing today is still in development • It is not yet in implementation in Canada • It does not dictate what “should be”, that is the subject of ongoing stakeholder engagement and investment strategies • This presentation starts with the context of the evolving EHR Solutions Blueprint in Canada • Then speaks to the identification and management of interdependent core concepts needed to realize the vision of EHR in Canada

3. Purpose of the Presentation • The purpose of the presentation is to introduce a discussion paper on Interdependent Registries • Reviewing: • The requirements as the team perceives them • A proposed model for solving for those requirements • Strategies for managing the interdependent concepts

4. Longitudinal Record Services Common Services EHRS BPv2 EHRS Blueprint v2 Communication Bus JURISDICTIONAL INFOSTRUCTURE The original Blueprint for Electronic Health Records Solutions is best described as: An enterprise architecture for the EHR It addressed the foundational problems of: correctly associating health information with clients / patients and their providers Ancillary Data& Services EHR Data& Services DataWarehouse Registries Data& Services ImmunizationManagement PHSReporting SharedHealth Record DrugInformation DiagnosticImaging Laboratory HealthInformation ClientRegistry ProviderRegistry where and when it is needed BusinessRules EHRIndex MessageStructures NormalizationRules TerminologyRepository LocationRegistry Security MgmtData Privacy Data Configuration HIAL allowing the secure and appropriate sharing of information Public HealthServices PharmacySystem RadiologyCenterPACS/RIS Lab System(LIS) Hospital, LTC,CCC, EPR PhysicianOffice EMR EHR Viewer Public Health Provider Pharmacist Radiologist Lab Clinician Physician/Provider Physician/Provider Physician/Provider POINT OF SERVICE

5. Vision 2015 (paraphrased) “Vision 2015 - Advancing Canadas next generation of healthcare” is a report commissioned by Canada Health Infoway It describes a health system where: • Canadians actively participate in events affecting their health • Enjoying streamlined access to appropriate health services; coordinated across disciplines, organizations, geography and over time • Taking optimal advantage of available health service resources

6. Vision 2015 (paraphrased) It is the result of: • More effective communication and information exchange between people • Coordination across organizational processes • Enabled by interoperable software solutions • Sharing commonly understood information

7. The Blueprint 2015 Project • The next iteration of the EHRS Blueprint is a project largely scoped by Vision 2015, along with other work done by Infoway • This project is extending, not replacing, the existing EHRS Blueprint • There is no funding envelope or investment strategy associated with today’s material • 2015 is neither a start or an end date • This project is about defining what “could be” • It’s early thinking • It does not dictate what “should be” • that is the subject of subsequent stakeholder engagement and investment strategies

8. Blueprint 2015 Project Scope • It is determining the technology architecture, standards, and information services • To enable: • Electronic Orders • Decision Support • Consumer Health • Chronic Disease Management • Timely access to available services • At a systemic level: • across point-of-service systems (EMR, CIS, etc…), care settings, and organizations

9. Project Objectives • Define a Business Architecture derived from the project themes • Define patterns for workflow, functional, security, and information requirements • Refine and extend existing use cases to describe how these patterns would be implemented • Describe how these patterns leverage or would require change to clinical / professional practice • Determine standards, architecture, and solutions to support the Business Architecture • Define how these business patterns can be accomplished using existing and new Blueprint architectural components • Define the requirements for standards to accomplish the business patterns and map to existing or new standards • Describe potential implementation models

10. Health System Objectives • Enabling Improved Client-Patient Access and Participation • Enabling Inter-professional Collaboration • Enabling Integrated Service Delivery • Enabling Information for Decision Support, Utilization of Health Care Services & Quality Improvement

11. Generations of EHR Capabilities Gen 5The Mentor Full Gen 4The Colleague Gen 3The Helper Functionality Gen 2The Documentor Gen 1The Collector Minimal 1993 1998 2005 2010 2015+ End of 2009 Source: Gartner (December 2005) Availability of Products

12. A Sneak Peak at Emerging Thinking

13. Blueprint 2015 Graphic Examples (Caution! Work in Progress!)

14. Longitudinal Record Services Common Services EHRS BPv2 EHRS Blueprint v2 Communication Bus JURISDICTIONAL INFOSTRUCTURE Ancillary Data& Services EHR Data& Services DataWarehouse Registries Data& Services ImmunizationManagement PHSReporting SharedHealth Record DrugInformation DiagnosticImaging Laboratory HealthInformation ClientRegistry ProviderRegistry BusinessRules EHRIndex MessageStructures NormalizationRules TerminologyRepository LocationRegistry Security MgmtData Privacy Data Configuration HIAL Public HealthServices PharmacySystem RadiologyCenterPACS/RIS Lab System(LIS) Hospital, LTC,CCC, EPR PhysicianOffice EMR EHR Viewer Public Health Provider Pharmacist Radiologist Lab Clinician Physician/Provider Physician/Provider Physician/Provider POINT OF SERVICE

15. Consumer Heatlh Provider Portal PHR EHR Longitudinal Record Services Common Services EHRS BPv2 Blueprint 2015 Health SystemServices Consumer HealthSolutions Clinical DecisionSupport Chronic DiseaseManagement Wait TimesManagement Notional Blueprint 2015 Communication Bus JURISDICTIONAL INFOSTRUCTURE EHRS Blueprint: Conceptual Architecture Health System Services EHR Data& Services DataWarehouse WaitlistManagement AppointmentBroker InterdependentRegistries Client Provider User Organization Location Health Service Health Program AppointmentBrokering Work in Progress Demand Management SharedHealth Record DrugInformation DiagnosticImaging Laboratory Analytics … Decision Support Rules EHRIndex Template Registry NormalizationRules ConsentDirectives TerminologyRepository AppointmentQueue NotificationQueue eReferralQueue Security MgmtData Privacy Data Configuration SoftwareApplicationInstance HIAL Public HealthServices Long TermCare Facility Pharmacy Application Hospital CIS Homecare Agency PhysicianOffice EMR Client - Patient Nursing /Administration Public Health Provider Multiple Roles Assessor / Provider / Administration Clinician /Nursing /Administration Clinician / Provider Pharmacist POINT OF SERVICE

16. Consumer Heatlh Provider Portal PHR EHR Longitudinal Record Services Common Services EHRS BPv2 Blueprint 2015 Health SystemServices Consumer HealthSolutions Clinical DecisionSupport Chronic DiseaseManagement Wait TimesManagement Health System Services Communication Bus JURISDICTIONAL INFOSTRUCTURE EHRS Blueprint: Conceptual Architecture Health System Services EHR Data& Services DataWarehouse InterdependentRegistries Client Provider User Organization Location Health Service Health Program AppointmentBrokering Demand Management Decision Support Care Assessment & Planning Order Entry Domain Information Services Analytics Decision Support Rules EHRIndex Template Registry NormalizationRules ConsentDirectives TerminologyRepository AppointmentQueue NotificationQueue eReferralQueue Security MgmtData Privacy Data Configuration SoftwareApplicationInstance HIAL Public HealthServices Long TermCare Facility Pharmacy Application Hospital CIS Homecare Agency PhysicianOffice EMR Client /Patient Nursing /Administration Public Health Provider Multiple Roles Assessor / Provider / Administration Clinician /Nursing /Administration Clinician / Provider Pharmacist POINT OF SERVICE

17. ConsumerPortal Provider Portal PHR EHR Longitudinal Record Services Common Services EHRS BPv2 Blueprint 2015 Health SystemServices Consumer HealthSolutions Clinical DecisionSupport Chronic DiseaseManagement Wait TimesManagement Consumer Health Solutions Communication Bus JURISDICTIONAL INFOSTRUCTURE EHRS Blueprint: Conceptual Architecture Health System Services EHR Data& Services DataWarehouse WaitlistManagement AppointmentBroker InterdependentRegistries Client Provider User Organization Location Health Service Health Program AppointmentBrokeingr DemandManagement SharedHealth Record Lab, Drug, and DI Data Services PersonalHealth Record??? Analytics Decision Support Rules EHRIndex Template Registry NormalizationRules ConsentDirectives TerminologyRepository AppointmentQueue NotificationQueue eReferralQueue Security MgmtData Privacy Data Configuration SoftwareApplicationInstance HIAL PHR Consumer Health Long TermCare Facility Pharmacy Application Hospital CIS Homecare Agency PhysicianOffice EMR Client - Patient ClientDelegate Nursing /Administration Multiple Roles Assessor / Provider / Administration Clinician /Nursing /Administration Clinician / Provider Pharmacist POINT OF SERVICE

18. Consumer Heatlh Provider Portal PHR EHR Longitudinal Record Services Common Services EHRS BPv2 Blueprint 2015 Health SystemServices Consumer HealthSolutions Clinical DecisionSupport Chronic DiseaseManagement Wait TimesManagement Clinical Decision Support Communication Bus JURISDICTIONAL INFOSTRUCTURE EHRS Blueprint: Conceptual Architecture Decision Support EHR Data& Services DataWarehouse InterdependentRegistries Client Provider User Organization Location Health Service Health Program Alerting Services Notification Services Content Provisioning Assessment Services Care Planning Services Domain Information Services Decision Support Analytics Decision Support Rules EHRIndex Template Registry NormalizationRules ConsentDirectives TerminologyRepository AppointmentQueue NotificationQueue eReferralQueue Security MgmtData Privacy Data Configuration SoftwareApplicationInstance HIAL Public HealthServices Long TermCare Facility Pharmacy Application Hospital CIS Homecare Agency PhysicianOffice EMR Client -Patient Nursing /Administration Public Health Provider Multiple Roles Assessor / Provider / Administration Clinician /Nursing /Administration Clinician / Provider Pharmacist POINT OF SERVICE

19. Adaptive and Agile Service Delivery • Provided the baseline architecture is in place • Any of these patterns can be implemented at any time • Allowing incremental value, cost, and change management • Trigger events and thresholds can be adjusted and the affect of that adjustment can be known quickly • Contextualized decision support, notification, and alert mechanisms allow health service providers to: • Be mutually aware, improving collaboration and continuity of care • Be more responsive to their clients-patients’ changing circumstances • Make more effective and appropriate use of available health system resources

20. Significant Implications – Real Value • The implications of enabling these basic mechanisms at a systemic level are big • The implications for process transformation are significant – clinically, administratively, and from policy perspectives • It means bringing research and statistical analytics much closer to delivery at the point of service • It requires standardization at a process level • It will require a whole new level of governance, collaboration, and standardization to achieve

21. A Fundamental Challenge

22. Generations of EHR Capabilities Gen 5The Mentor Full Gen 4The Colleague Gen 3The Helper Functionality Gen 2The Documentor Gen 1The Collector Minimal 1993 1998 2005 2010 2015+ End of 2009 Source: Gartner (December 2005) Availability of Products

23. Systemic Management of EHR Infostructure Blueprint 2015 requirements means we are now moving from EHR Gen 2 to EHR Gen 3 types of capabilities This will require systemic management of EHR Infostructure Systemic Management of EHR Infostructure means moving from isolated registry projects to interdependent registry programs which should evolve in the following way: • 1) Program Management (Infoway & Jurisdictions) • Manage for change • 2) Enterprise Architecture* (Infoway & Jurisdictions) • Design for change • 3) Solution (Jurisdictions) • Incremental development • 4) Implementation / Deployment / Migration / Configuration / Adoption etc

24. Managing Core Registry Concepts and their Relationships In the early stages of Blueprint 2015 work, it has become apparent that the use of Client and Provider registries alone will not be sufficient to meet the requirements being identified in the project.

25. We Need to Better Understand • The relationships between health care providers and the organizations they act on behalf of • Locations where health services are provided and the organizations that use them • The correlation of software user identity and provider and client identities (in the case of Consumer Health Solutions), • What health services are accessible to patients • How health services are combined / coordinated to meet certain program objectives (e.g. diabetes management, home care, rehabilitation, etc…) • How appointments / schedules for health services provision can be negotiated and booked across organizations and software solutions • How to support the collaboration of service providers in achieving a shared patient’s health care goals and objectives & outcomes

26. Core Registry Business Concepts - overview Note: These are interdependent registry business concepts as opposed to an ERD model or descriptions of separate registry system implementations.

27. A Pattern for Interdependent Registries • These core registry concepts were all established in the EHRS Blueprint v2, but going forward need to consider: • These registry concepts are shared subjects of interest • across organizations and software solutions • These shared subjects must be managed operationally: • Uniquely identified and maintained • Relationships between established and maintained • In the same fashion as Client or Provider registries • The shared subjects are interdependent and need to be managed as such • Hence: “Interdependent Registries”

28. Interdependent Registries Discussion PaperPurpose, Scope, Goals &Value Proposition

29. Purpose of the Discussion Paper This discussion paper is intended to: • initiate discussion with our stakeholder communities on how we can re-factor our existing registry investments and • promote dialog around proposals for incremental business and technical change strategies building on current investments in these areas. • augment these registries with other Infostructure components to allow us to address that list of capabilities (and derive other benefits as well). The paper should be of interest to primarily two communities • the teams that are currently building Infostructures, and • the communities who would value the ability to collaborate actively around a patient’s care and to better use the information available to them in their care planning, decision making, and use of health system resources for administrators

30. Discussion Paper Table of Contents • Executive Summary • Introduction, Scope • Assumptions • Background • Current State Survey, Challenges, Success Factors • Support for Blueprint 2015 Use Cases • Strategies for Management • Conceptual Model • Migration Strategies • Appendices

31. Themes of the Discussion Paper • This discussion paper is about transforming management of interdependent registries at a Program ManagementandEnterprise Architecture level using industry best practices to: • Manage for change (Program Management) • Design for change (Enterprise Architecture) • Benefits of Infoway 2015 vision cannot be achieved without both these transformations • All proposed strategies build on current registry concepts such as Provider, Location, Organization etc

32. Themes of the Discussion Paper • Registries must be managed as a shared resource • Registries need prerequisite establishment of the appropriate decision making forums • Registries will need to support a more complex world of interdependent business processes and underlying technologies than just supporting PoS to EHR exchanges of information

33. Core Concepts and Definitions

34. Interdependent Infostructure Registries Focus

35. Interdependent Registry Summary Definitions • Organization Registry • A legal or formally designated entity, with a common purpose or function, of interest to the health and/or social services which may have governing, financial or monitoring responsibilities. • Organizations can take on different roles, but Organization Registry is responsible for uniquely identifying each organization and it’s relationship to other organizations. • Types of recognized organizations may include Delivery Organizations, Accrediting Organizations, Funding Organizations and organizations submitting data to different CIHI data holdings.

36. Interdependent Registry Summary Definitions • Delivery Organization Registry • Is responsible for providing Health Programs at SDLs using accredited applications. • May be owned/managed/governed/funded by another organization, or be under contract to another organization to supply goods or services. • May have associated Providers, as employees or agents.

37. Interdependent Registry Summary Definitions(continued) • Service Delivery Location Registry • Provides a comprehensive directory of all Service Delivery Locations (SDLs) where patient care is delivered (hospitals, clinics, physician offices etc). • Also describes where health services are delivered in more dynamic or incidental locations such as Home Care, Immunization Clinics, Emergency Services, etc. • A Delivery Organization is responsible for an SDL and the associated resources to be able to maintain the capability to provide the services included in the related Health Programs.

38. Interdependent Registry Summary Definitions(continued) • Provider Registry • A Provider Registry is a centralized directory providing a comprehensive and unambiguous identification of all persons practicing in the jurisdiction as healthcare professionals. • A Provider may be a person or organization that provides goods or services to (within, or on behalf of) the health system. • Providers are authorized to provide health care services by a recognized authority or agency (Accrediting Organization) and may be assigned to work for a Delivery Organization that also participates in an EHR infostructure system solution.

39. Interdependent Registry Summary Definitions (continued) • Health Services Registry • Contains standardized activity definitions that define all resources required to provide the Health Service to an anticipated target population. • Defines services in terms of qualified skills, equipment, dependent structure and types of clients they are intended for. • Provides standardized Health Service definitions for Health Programs

40. Interdependent Registry Summary Definitions (continued) • Health Program Registry • Packages standardized Health Services offered to target client groups by Delivery Organizations either independently or in cooperation with others. • Includes target population description and eligibility criteria, service bundles, capacity, process standards, and evaluation criteria and other measures. • Deployed in one or more Service Delivery Locations which can be either dedicated to a particular health program or shared by more than one health program. • Defines resources such as accredited Application Instances used in Service Delivery Locations by authorized Users

41. Interdependent Registry Summary Definitions (continued) • Application Instance Registry • Defines the software and dependent hardware devices installed and used by a Delivery Organization to manage Health Programs and deliver Health Services. • Includes for example, the vendor, product type, version, configuration parameters, and software / hardware capacities and functional capabilities. • Accredited Applications are used by authorized people in recognized user roles.

42. Interdependent Registry Summary Definitions (continued) • User Registry • A User Registry and its related services is a Policy Decision Point that provides agents and/or Application Programming Interfaces usable by applications and Health Information Access Layer (HIAL) Policy Enforcement Point services. • Enforces a person’s authorized use of secure EHR systems supporting Health Service delivery. • Contains information related to the role a person plays as a health service Provider or other authorized role as well as the access rules permitting or restricting access to records or functions.

43. Walkthrough of a Clinical Use Case

44. Torn Anterior Cruciate (ACL) & Medial Meniscus Use Case - Overview • Use Case focuses on e-referral functionality required for Blueprint 2015 • Dr. David Lambert injured his right knee while hiking. David’s family physician, Dr. Black, diagnosis David’s knee injury as a torn right anterior cruciate ligament (ACL) and medical meniscus and decides to refer David to an orthopedic surgeon,

45. Torn Anterior Cruciate (ACL) & Medial Meniscus Use Case - Overview • Dr. Black initiates an e-referral and selects Dr. Abram from an orthopaedic surgeon’s results list meeting the criterion. Dr. Abram reviews the e-referral request and determines that he is not able to accept the e-referral • Dr. Black initiates a second orthopaedic consultant search based on the original criterion specified and selects Dr. Bone from an orthopaedic surgeon’s results list and submits the request.

46. Torn Anterior Cruciate (ACL) & Medial Meniscus Use Case - Overview • Dr. Bone’s EMR receives an e-referral message that there is a pending consultation request. Dr. Bone accepts the request. The Office Assistantadds the appointment the e-referral and an acceptance message is sent to Dr. Black & David. • David reviews the message and submits a request to change the time. Ms. O. Assistant, selects the next available appointment with the shortest wait time and sends an appointment update to David via his PHR

47. Torn Anterior Cruciate (ACL) & Medial Meniscus Use Case – Overview Cont’d • David receives the appointment update. David accepts the appointment and a confirmation message is sent to Dr. Bone’s and Dr Black’s EMR. Dr Bone’s Office Assistant receives the message and confirms the appointment. Dr Black’s EMR receives confirmation that the e-referral has been scheduled • Dr Black recommends to David that in addition to the specialist that he see a physiotherapist. David agrees. Dr. Black completes an electronic order for physiotherapy. David uses his PHR to select a physiotherapy clinic that is in close proximity to his work place and request an appointment.

48. Walkthrough of an Administrative Use Case

49. The Link Between Interdependent Registries and E-Referral – User Registry • Dr. Black, the Office Assistant, Dr. Abram, David and the Physiotherpist and Staff at the Physiotherapy Program must be registered in a User Registry for a registered application instance that has been pre-authorized in the Application Instance Registry, prior to log on to the SDL Registry

50. The Link Between Interdependent Registries and E-Referral – Application Instance Registry • Dr. Abram’s EMR, Dr. Black’s EMR; and David’s PHR would also need to be a registered instance in the Application Instance Registry to receive e-referrals and notifications via the HIAL.