Blueprint 2015 Interdependent Registries - A Discussion Paper –

Presented byApril 29th, 2010

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

EHRS Blueprint v2EHRS BPv2

JURISDICTIONAL INFOSTRUCTURE

TerminologyRepository

Ancillary Data& Services

Registries Data& Services

EHR Data& Services

DataWarehouse

ImmunizationManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData

Privacy Data Configuration

Longitudinal Record Services

ClientRegistry

ProviderRegistry

LocationRegistry

POINT OF SERVICE

Hospital, LTC,CCC, EPR

PhysicianOffice EMR

EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist

Public HealthServices

Public Health Provider

HIALCommunication Bus

Common Services

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

allowing the secure and appropriate sharing of information

where and when it is needed

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

Full

Functionality

Minimal

Gen 4The Colleague

Gen 2The Documentor

Gen 3The Helper

Gen 5The Mentor

Availability of Products

1993 1998 2005 2010 2015+

Gen 1The Collector

Source: Gartner (December 2005)

End of 2009

12

A Sneak Peak at Emerging Thinking

13

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

14

EHRS Blueprint v2EHRS BPv2

JURISDICTIONAL INFOSTRUCTURE


Ancillary Data& Services

Registries Data& Services

EHR Data& Services

DataWarehouse

ImmunizationManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData



ClientRegistry

ProviderRegistry

LocationRegistry

POINT OF SERVICE

Hospital, LTC,CCC, EPR

PhysicianOffice EMR

EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist




Common Services

15

Wait TimesManagement

Chronic DiseaseManagement

Clinical DecisionSupportConsumer HealthSolutionsHealth SystemServices

Notional Blueprint 2015EHRS BPv2 Blueprint

2015

EHRS Blueprint: Conceptual ArchitectureJURISDICTIONAL INFOSTRUCTURE

POINT OF SERVICE

Health System Services EHR Data& Services

DataWarehouse

SharedHealth Record

DrugInformation

DiagnosticImaging

Laboratory Analytics



Common Services


Decision Support Rules

EHRIndex

Template Registry

NormalizationRules

SoftwareApplication

Instance

ConsentDirectives

AppointmentQueue

eReferralQueue

NotificationQueue

Clinician / Provider

Clinician /Nursing /

Administration

Assessor / Provider /

Administration

Multiple Roles

Nursing /Administration

Homecare Agency

PhysicianOffice EMR

Pharmacy Application

Long TermCare Facility

Hospital CIS Provider Portal

EHR

Pharmacist



Client - Patient

Consumer Heatlh

PHR

…

WaitlistManagementDemand

Management

AppointmentBroker

AppointmentBrokering

Security MgmtData


InterdependentRegistries

Client

Provider

User

Organization

Location

Health Service

Health Program

16



Clinical DecisionSupportConsumer HealthSolutions

Health System ServicesEHRS BPv2 Blueprint

2015Health System

Services


POINT OF SERVICE

Health System Services EHR Data& Services

DataWarehouse

AppointmentBrokering

Demand Management

Domain Information

ServicesAnalytics



Common Services



EHRIndex

Template Registry

NormalizationRules

ConsentDirectives

AppointmentQueue

eReferralQueue

NotificationQueue

Decision Support

Care Assessment &

PlanningOrder Entry

Homecare Agency

PhysicianOffice EMR




EHRPublic Health

Services


Client /Patient

Consumer Heatlh

PHR



Administration


Administration

Multiple Roles


Pharmacist


Client

Provider

User

Organization

Location

Health Service

Health Program

SoftwareApplication

Instance

Security MgmtData


17



Clinical DecisionSupportConsumer HealthSolutions

Health SystemServices

Consumer Health SolutionsEHRS BPv2 Blueprint

2015


POINT OF SERVICE

EHR Data& Services

DataWarehouse

SharedHealth Record

Lab, Drug, and DI Data

Services

PersonalHealth Record

???Analytics



Common Services



EHRIndex

Template Registry

NormalizationRules

ConsentDirectives

AppointmentQueue

eReferralQueue

NotificationQueue

Consumer Health

ClientDelegate

Homecare Agency

PhysicianOffice EMR


Long TermCare FacilityPHR

Client - Patient

ConsumerPortal

PHRHospital CIS Provider

Portal

EHR

Health System Services

WaitlistManagement

AppointmentBroker

DemandManagement

AppointmentBrokeingr



Administration


Administration

Multiple Roles


Pharmacist


Client

Provider

User

Organization

Location

Health Service

Health Program

SoftwareApplication

Instance

Security MgmtData


18



Clinical DecisionSupport

Consumer HealthSolutions

Clinical Decision SupportEHRS BPv2 Blueprint

2015Health SystemServices


POINT OF SERVICE

Decision Support EHR Data& Services

DataWarehouse

Alerting Services

Notification Services

Domain Information

Services

Decision Support Analytics



Common Services



EHRIndex

Template Registry

NormalizationRules

ConsentDirectives

AppointmentQueue

eReferralQueue

NotificationQueue

Content Provisioning

Assessment Services

Care Planning Services

Homecare Agency

PhysicianOffice EMR




EHRPublic Health

Services


Client -Patient

Consumer Heatlh

PHR



Administration


Administration

Multiple Roles


Pharmacist


Client

Provider

User

Organization

Location

Health Service

Health Program

SoftwareApplication

Instance

Security MgmtData


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

Full

Functionality

Minimal

Gen 4The Colleague

Gen 2The Documentor

Gen 3The Helper

Gen 5The Mentor

Availability of Products

1993 1998 2005 2010 2015+

Gen 1The Collector

Source: Gartner (December 2005)

End of 2009

23

Systemic Management of EHR InfostructureBlueprint 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 Paper

Purpose, Scope, Goals &Value Proposition

29

Purpose of the Discussion PaperThis 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 Management and Enterprise 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


• 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


• 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


•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


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


Dr. Bone’s EMR receives an e-referral message that there is a pending consultation request. Dr. Bone accepts the request. The Office Assistant adds 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.

51

The Link Between Interdependent Registries and E-Referral – SDL Registry

• The Physiotherapy Program is offered at an SDL and it is the SDL Registry that David consults to choose one near where he works. The Program is operated by a Delivery Organization that takes responsibility for both the SDL and the Health Program. The geography parameter is part of the SDL, which also has a relationship to the nature of the Health Program(s) offered there.

52

The Link Between Interdependent Registries and E-Referral – SDL Registry

• Dr. Black searches for a location that provides a Health Program that includes ACL reconstruction, with the associated list of Providers. The geography parameter is associated with the SDL, the type of Service parameter is associated with the Health Program and the names of the surgeons associated with the Health Program are returned

53

To Summarize…

54

Key Success Factors - Clinical Ensuring the interdependent registries will not inadvertently

create gaps that will implicate patient safety and privacy Ensuring clear accountability to registries data, e.g. who to

do what and by when. Ensuring the technology will enable and facilitate patient

care and provider practice. Automated processes should be used as much as possible.

Ensuring data management process is user friendly when this cannot be automated

Ensuring proper change management and stakeholder engagement processes are in places

Ensuring clear instructions are in place to assist users to address problems related to wrong or outdated information.

55

Key Success Factors - Management Ensuring the continuity of governance attention

to these registries Ensuring logistics management is in place for

engagement Establishing a governance process (design and

run time) to ensure the HIAL is managed as a jurisdictional program to enable these infostructure registries support the clinical and other requirements

Establish service contracts that include these registry service levels and component interfaces that are designed to allow future changes

56

Key Success Factors - Management Establishing appropriate forums for shared

decision processes for an agreed upon governance process

Apply resources in a joint / collaborative fashion to optimize the desired results

Infoway needs to be able to provide change management guidance for different size projects and organizations to use incremental strategies that result in broader benefits.

CIHI has processes that can be used that recognize and appropriately manages changes to identified registry instances over time

57

Key Success Factors - Architecture Using EMPI person resolution type functions to

uniquely identify Providers & improve the quality of Provider Registry information

Planning for federated infostructure registries provides regions with guidelines to integrate with provincial and other regional initiatives

Managing Health Services, Health Programs, Service Delivery Locations and Service Delivery Organizations as a collection of interdependent registries is a successful strategy

58

Key Success Factors - Architecture The implementation of registry services can be

designed to meet the needs of a jurisdiction, for example a Location registry can be implemented within the HIAL

CIHI Organization Index can be leveraged as a source of truth for Organization / Service Delivery Location information

Establish guidelines and recommendations for Master Data Management (MDM) platforms and strategies related to these registries

59

Summary Points for Discussion • This discussion paper is about transforming

management of interdependent registries at an Enterprise Architecture level using industry best practices to:

• Manage for change • Design for change

• Benefits of Infoway 2015 vision cannot be achieved without both these transformations

• Registries must be managed as a shared resource

60

Summary Points for Discussion • 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

An operational jurisdictional HIAL is mandatory for the success of these registries

• All proposed strategies build on current investments

• Feedback is welcome via forums and other Infoway channels

61

Moving Beyond A Discussion Paper• Think strategically

(from program vs project points of view)• Act Locally

(from Infoway & Jurisdiction & Regional points of view)

• Provide suggestions:• How do we help program managers prepare for and

manage these registries for change?• How do we help plan to migrate these registries to a

systemic, continuous change environment?• How do we design for change and suggest supporting

technologies? Participate through the evolution of this

discussion paper

62

Questions / Comments?

Documents

Blueprint 2015 Interdependent Registries - A Discussion Paper –