Health Canada
Symbol of the Government of Canada
Health Care System

WHIC Provider Registry Final Report

Health and the Information Highway Division, Health Canada
April 3, 2003

Table of Contents

Executive Summary

Introduction

The Provider Registry system (PRS) is a standards-based repository of core provider data supplied by authorized sources, and available to authorized consumers, that will facilitate the electronic exchange of health information.

The Provider Registry System (PRS) has the potential to be implemented by any Canadian province or territory, and expanded as a model for national data standards. Each participating province, British Columbia, Alberta, Saskatchewan and Manitoba, is implementing their own Provider Registry within their existing technical infrastructure

The Provider Registry Project has successfully demonstrated that collaboration across regional and provincial domains can work and yield benefits. This project will serve as a model for one of the fundamental building blocks of a pan-Canadian electronic health record.

Benefits

The benefits of implementing the PRS are numerous. The PRS provides consistent, timely and accurate information on who the health care providers are, and how they can be contacted for communication and information exchange. The creation of standard content and format of provider information greatly facilitates information exchange between organizations.

Successes

All but one of the elements in the originally approved work plan have been achieved, or are almost complete.

The Provider Registry Project was successful - on time and on budget.

Impacts

There were two main impacts of this project. The first was the successful construction of a central repository for health care provider information that forms one of the foundation building blocks for a pan-Canadian electronic health record - the PRS product.

The second was proving that four provinces could collaborate in the creation of a portable software application suitable for implementation in any Canadian province or territory - the process of collaboration.

Major Findings

These major findings are discussed within the document in detail:

  • Collaboration is beneficial
  • Offshore development is feasible and cost effective
  • Attempting to develop to embryonic standards introduces significant risk
  • Ensure adequate resources are recruited

The Future

Sponsored by Canada Health Infoway Inc (Infoway), and supported by WHIC and WERC (Western EHR Regional Collaborative) two new "phase 2" PRS initiatives are now getting underway.

The PR1 - Enhanced Provider Registry Project, led by BC, will deliver an enhanced version of the current PRS. The enhanced PRS will better meet the requirements of new jurisdictions by including additional functionality. It will also facilitate the "uptake" of the PRS by improving integration with a broader range of source systems. Accelerated implementation of PRS in other jurisdictions will be supported.

The PR2 - PRS System Integration Project, led by Saskatchewan, will provide a "reusable implementation toolkit" and best practices that can be used by different jurisdictions in the deployment of the PRS. This toolkit will consolidate the experiences and knowledge gained through implementation in the four western provinces. The toolkit will include technical expertise along with best practices related to the adoption of the registry from a business perspective, and will support accelerated implementation of PRS solutions in other jurisdictions.

1.0 Introduction

The Provider Registry system (PRS) is a standards-based repository of core provider data supplied by authorized sources, and available to authorized consumers, that will facilitate the electronic exchange of health information. The PRS supports the transmission of health information between participating organizations and is one of the fundamental building blocks towards the realization of the pan-Canadian Electronic Health Record (EHR). The project is a Western Health Information Collaborative (WHIC) initiative, led by the BC Ministries of Health Planning and Health Services.

The Provider Registry System (PRS) has the potential to be implemented by any Canadian province or territory, and expanded as a model for national data standards. Each participating province, British Columbia, Alberta, Saskatchewan and Manitoba, is implementing their own Provider Registry within their existing technical infrastructure (i.e. servers, message routing, etc.), initially populating it with data from their respective key Colleges. The PRS enables the security of patient health information by employing or enabling proven security and privacy techniques.

This project has successfully demonstrated that collaboration across regional and provincial domains can work and yield benefits. From the initial discussions to the development/build stage, the Provider Registry project has led the way for other collaborative projects in Canada. The Provider Registry will serve as a model for one of the fundamental building blocks of an electronic health record.

Benefits

The PRS forms part of the infrastructure foundation for the efficient delivery of health care. A provider registry is an essential building block for a pan-Canadian electronic health record. Prior to the development of the PRS, health care organizations did not have a definitive source for timely and accurate health care provider information, nor were there standards on how this information was to be recorded. As a consequence, each independent organization maintained one or more separate databases containing inconsistent copies of this provider information. Up to 200 such databases are estimated to exist within BC alone. Needless to say these databases are expensive to maintain and are frequently inaccurate, resulting in reports going astray, requests for service being attributed to the wrong physician and work effort duplicated.

The benefits of implementing the PRS are numerous. The PRS provides consistent, timely and accurate information on who the health care providers are, and how they can be contacted for communication and information exchange. The creation of standard content and format of provider information will greatly facilitate information exchange between organizations.

This information will help enable more cost effective and timely health care services, as well as a significantly reduced risk of error due to the misdirection of clinical information. With consistent provider identification, sources and consumers will be able to accurately identify all the bona fide individual providers that have contributed to the provision of health care for a patient. This will improve information security and patient confidentiality, as access will be limited to those providers who have a need to know.

2.0 Revised Project Description

The following section is the project description originally submitted to CHIPP. There have been minor changes. Additions are underlined, and deletions are struck out.

G3-6F-DY/0021
Provider Registr
HEALTHNET/BC

The purpose of the Provider Registry project was to develop a core health infostructure application. It is a standards based, centralized, electronic application that was built once but can be implemented by any Canadian province or territory and expanded for use as a national registry. A centralized Provider Registry is consistent with the five principles of medicare and the Canada Health Act in that it is comprehensive, supports the universality of health care/information, promotes accessibility, portability and public administration

The vision for all 4 provinces involved in the Provider Registry project is aligned with both ACHI and the EHR Working Committee with regards to the EHR in Canada. Most of HealthNet/BC's focus and energies over the last 5 years have been to build the blocks necessary to support a complete EHR.

The Provider Registry encourages the creation of electronic health records systems so that authorized health professionals and institutions have access to patient's health files, as quickly and efficiently as possible to assist in diagnosis and treatment. Properly designed to safeguard personal privacy, such systems will make it easier and faster for health practitioners to give the best possible treatment and advice, based on complete patient information. A provider registry is a fundamental building block towards the realization of the Electronic Health Record (EHR).

The Provider Registry project was a collaborative effort with BC as the lead province partnering with Alberta, Saskatchewan and Manitoba. All four provinces agreed to use the standards, designs, documentation and computer programs resulting from this project. All four provinces agreed to share costs.

Each province agreed to:

  • implement their own Provider Registry populating it with provider data from their respective College of Physicians and Surgeons and College of Pharmacists; and,
  • implement their own highest priority consumers of Provider Registry data.

    • BC: MSP, BC Cancer Agency, BC Centre for Disease Control, Vancouver Hospital and Health Services Society.
    • SK: Triplicate System, Regions Strategic Systems, Medi Solutions, PHIS Application, Regina Health.
    • MB: Ministry of Health applications.
    • AB: Pharmaceutical Information Network (PIN), Health Authorities.
  • implement within their own existing technical infrastructure (e.g., apply SQL database definition to an Oracle database technology, HL7 message routing, web application within the provincial web 'look and feel' standards).

After the initial implementation and beyond the CHIPP funding timeframe, each province will continue to expand the use of their provider registry, engaging more registrars to feed data into their registry and more consumers to use that registry. The cross-jurisdictional partners will participate in centralized release and change management processes to continue enjoying the benefits of sharing the work and costs of future, joint enhancements.

Scope

To develop and implement:

  • a provider data standard (PDS) including a data dictionary, data model and XML message definitions;
  • a registry infrastructure that can be built once and implemented many times in other Canadian jurisdictions;
  • a registry suitable for use by authorized users in a Health Ministry, health authorities, public bodies, private organizations (labs, doctor's offices), and where appropriate, the public;
  • a repository able to contain data about all health service providers (licensed and unlicensed) as well as suppliers of goods of interest to the healthcare sector, when fully implemented;
  • an application, administrative processes, computer systems and facilities that maintain the Provider Registry;
  • message based interfaces which accept provider data from registrars such as the College of Physicians and Surgeons, College of Pharmacists, etc. and supply provider data to consumers with existing computer systems;
  • a web registry application that performs data collection and distribution functions for those registrars without electronic messaging capability;
  • a web access application that enables authorized access to appropriate provider information;
  • security software to ensure privacy and confidentiality of provider data through controlling and monitoring the access, use and disclosure of provider registry information; and,
  • an administrative structure with responsibility to handle ongoing release management and ensure the accuracy of Provider Registry data as required by each participating jurisdiction.

Objectives

  • Respond to the priorities for improving health care delivery identified by the BC Health Information Standards Council, the Health Authorities Working Group and the Western Health Information Collaboration (WHIC).
  • Positively influence the emerging national standards for a national Provider Registry by incorporating the needs of all jurisdictions that contribute to the funding of the Provider Registry project.
  • Enable the integration of health information required for the advancement of the Electronic Health Record (EHR) and telehealth.
  • Enable appropriate access to and transmission of EHR components by authorized providers and between providers and health data repositories.
  • Ensure the unique identification of a provider in a particular role. Until such time as a unique national identifier is available for all health service providers, providers will be uniquely identified in a role by jurisdiction or by application.
  • Create a common data definition and database structure.
  • Develop technical, business and privacy standards related to the electronic transmission and sharing of provider data.
  • Facilitate electronic submission of accurate provider data from all regulatory and other authorizing bodies in a timely manner according to the standard.
  • Create a secure environment to protect the confidentiality of provider data.
  • Reduce development costs through cross-jurisdictional sharing and collaboration.
  • Reduce ongoing operation and maintenance costs associated with multiple provider databases and differing data definitions and identifiers; multiple proprietary interfaces; and multiple business processes.
  • Eliminate the need for further proliferation of proprietary databases and interfaces.
  • Reduce development costs in the health IT sector through the use of data and message standards.
  • Facilitate the implementation of other standards that require a Provider Registry including the HealthNet/BC Lab Test Standard and the Electronic Health Claims Standard (under development and being proposed through CIHI as Canada's national standard for Electronic Health Claims). And the HealthNet/BC data warehouse (HN/Data)

3.0 Achievements

3.1 Goals Reached

All but one of the elements in the originally approved work plan have been achieved, or are almost complete, and are summarized in the table below. The single goal that was not reached is the "Gold Registrar Application" which was deemed out of scope due to reduced CHIPP funding.

The Provider Registry Project Phase 1 was successful - on time and on budget.

Original Work Plan Elements and Status
Milestone Status Comments
Initiate and Plan and Manage Project Complete  
Develop and Sign Off Requirements & Solution Options Complete  
Obtain Technical Resources Complete  
Evaluation Complete  
Design Business Solution (business & data models, data standard, architecture & security model, initial implementation requirements) Complete  
Business Design Complete, WHIC Sign Off Complete  
Design, Build & Test Technical Solutions Complete HL7 message dev'l. cancelled & replaced with XML message dev'l.
Data Standard (analysis, design & build, implement) Complete  
Gold Registrar Application Cancelled Out of scope
Custom Registrar Interfaces Complete  
Provider Registry & Alternate ID Index Complete  
One Time Load for 4 sources Complete  
Provider Load Application Feature Complete  
Access Control Feature Complete  
Provider Export (Distribution) Feature Complete  
Interactive Access Feature (Web Interface) Complete  
Custom Consumer Interfaces Underway  
Obtain Registry Admin Support Complete  
BC Implementation    
Security Complete HNSecure interface
Implement Corporate Components Complete BC specific components
Implement Registrar Components (4 sources) Underway College of Physicians & Surgeons, Registered Nurses Association, College of Pharmacists, Medical Services Plan
Implement Consumer Components (3 consumers) Underway BC Cancer Agency, BC Centre for Disease Control, Vancouver Hospital and Health Services Society
AB Implementation Underway Target April
Security    
Implement Corporate Components    
Implement Registrar Components    
Implement Consumer Components    
SK Implementation Underway Target April
Security    
Implement Corporate Components    
Implement Registrar Components    
Implement Consumer Components Complete  
MB Implementation Complete Complete
Security Complete Complete
Implement Corporate Components Complete Complete
Implement Registrar Components Complete Complete
Implement Consumer Components Complete Complete
Project Wrap-up Complete Complete
Evaluate Implemented Provider Registry Complete Complete

Contributing Key Factors

Project Management

One of the major contributing key factors to the success of this project was the high level of commitment and hard work of all the project participants, combined with well organized project management that kept tight control of objectives. Milestone status and issues were reviewed regularly, helping the team keep focused and organized.

A Resource Strategy was prepared at the beginning of the project defining a number of small teams. This strategy proved to be well thought out, and enabled the most efficient use of specialized resources. Teams were small enough for good communications, and large enough to get the job done. Each team (lead project team, WHIC co-ordinating group, Sierra Victoria and India teams), was staffed by dedicated, steadfast and hard working people with great attitudes. The teams "gelled" early due to their shared commitment and all were major contributing factors to the project success.

The BC Ministry of Health's issue management tool was used effectively by the lead project team. Major issues were referred to the four western provinces and the tool enabled tracking of issues from identification to resolution.

Communications

The web site developed for Provider Registry saved all participants a significant amount of time in finding information and retrieving documentation. The lead project team was able to refer most information queries to the web site, and get on building the system, while knowing that participants had access to the information they needed.

Structured cross-provincial communications, established timelines and detailed expectations with regard to deliverable reviews were key to success, as was establishing and fostering an environment for open, candid discussion amongst the provincial partners.

Collaboration

Collaborating on a systems development project like the Provider Registry was a new experience for all participants, and all had positive comments to make about the process and the result. The provincial partners' positive attitude to collaboration was one of the contributing key factors to the success of the project. All were willing to compromise for commonality and all were dedicated to making collaboration work.

Collaboration also helped to ensure the project's momentum into future phases (e.g., Canada Health Infoway Inc. and wider deployment across Canada).

Obstacles and Challenges

Legal Agreements

The process for completing legal agreements with data sources for interfaces to the PRS in BC significantly exceeded expectations. Extended and sometimes acrimonious negotiations between representative lawyers finally resolved the issues.

Environments

The coding techniques and software versions used by the development team were appropriate. However, in BC the original plan for the production environment was changed after PRS was developed. When PRS was deployed on the shared production environment, cost overruns and delays to BC's project schedule resulted. To resolve this issue, it was necessary to extend deadlines, cut scope and use contingency dollars.

Documentation

The lead project team assumed the PRS business design was detailed enough to eliminate the need for a traditional high level technical design document. As testing began to ramp up it was determined that a high level technical design was required to write the test plan, test scripts and test cases. "Micro Design" documents were written to bridge the gap.

Transition to Non-lead Provinces

The effort required for successful transition to non-lead provincial implementation teams was underestimated. It was difficult for non-lead province technical teams to pick up the PRS product and begin implementation within their jurisdictions. Although they had been involved in decision-making and deliverable reviews, there were knowledge gaps that existed simply because these teams were not involved in the system development effort on a day-to-day basis.

Extra technical sessions were conducted with the non-lead technical teams to bring them up to speed, support was provided by the BC technical team, and technical Frequently Asked Questions pages (FAQs) were developed and posted on the web site.

Collaboration

The four western provinces agreed that collaboration adds complexity and cost to project management functions; but if it is done effectively, the gains far outweigh the costs.

Collaboration takes goodwill, time and a willingness to compromise for the collective good. It is not easy, nor quickly done. The time taken for the design process likely exceeded that which an individual province might have taken. The "one-size-fits-all" approach made the system more complicated than it might have been, but resulted in a more robust and superior product at a reduced cost for each province, as well as a product that is well-positioned to be adopted as a pan-Canadian standard.

HL7

The four western provinces planned to use the HL7 version 3 message standard for PRS messaging. HL7 is an internationally recognized standard and is widely accepted in the health care sector in Canada. This would represent a leading-edge application of HL7 v3 methodology and messaging in Canada.

The lead project team developed a project plan, after considering the HL7 alternatives, which assumed a mature version of v3 and available tools. This did not prove to be the case and significant problems were experienced in using the immature standard. In February 2002, the four western provinces decided to await a more mature version of v3, including mature tools, before re-engaging in v3 development.

The final impact of the issue was an estimated 1.5-month delay in finalizing the PRS messaging standard. The impact of this delay was mitigated by:

  • The developer successfully defined the required XML messages in a 2-3 week period once the decision to abandon HL7 was taken; and,
  • The fact that the project was ahead of schedule and under budget enabled absorption of the impact without significant project delays.

3.2 Additional Successes

None.

3.3 Unreached Goals

The single goal that was not reached is the "Gold Registrar Application" which was deemed out of scope due to reduced CHIPP funding.

The message development goal was altered. HL7 message development was put on hold, and replaced with XML message development. This is discussed in 3.1 Goals Reached.

3.4 Documents or Products Generated

The list of documents and products below is being copied to a CD and will be sent to Health Canada.

Document/Product Name Available in Paper and/or Electronic Form Licence Fee Required for use (Yes/No) Previously Provided to Health Canada (Yes/No)
Project Management Documentation On CD-ROM No No
Implementation Strategy Overview
Master Project Plans
  • Business Design Phase
  • Detail Design Phase
  • Built, Test and Implement Phase
Privacy Impact Assessment
RFP Evaluation Toolkit
Job Descriptions
  • PRS Business Co-ordinator
  • PRS System Support Analyst
Resource Strategy
Risk Plans
  • Detail Design Phase
  • Built, Test and Implement Phase
Verification and Validation Plans
  • Detail Design Phase
  • Built, Test and Implement Phase
WHIC Privacy Impact Assessment
WHIC Test Strategy
Final Project and CHIPP Evaluation Report
Published RFP
Document/Product Name Available in Paper and/or Electronic Form Licence Fee Required for use (Yes/No) Previously Provided to Health Canada(Yes/No)
Operations Documentation On CD-ROM No No
Business Design Documentation
Flat File Specification
XML Message Specification
HL7 Message Design Documentation
Interprovincial Communications Design Documentation
Maintain Provider Bean
Micro Design Documentation
Non Functional Testing Documentation
Product Release A Documentation
Product Release B Documentation
Reports Documentation
Requirements Document
Requirements Traceability Matrix
Test Plan
Final Implementation Strategies
Provider Data Standard
Performance Test Report
Portability Test Report
Document/Product Name Available in Paper and/or Electronic Form Licence Fee Required for use (Yes/No) Previously Provided to Health Canada(Yes/No)
Operations Documentation On CD-ROM No No
Physical Database Design
PRS Operations Guide
PRS Technical Reference Manual
Document/Product Name Available in Paper and/or Electronic Form Licence Fee Required for use (Yes/No) Previously Provided to Health Canada(Yes/No)
User Documentation On CD-ROM No No
PRS Application Overview
Business Implementation Guide
PRS Code Sets
Registry Administrator's Guide
WHIC Problem, Change and Release Management Process
Training Guides
  • PRS Training Strategy and Plan
  • Registry Administrator Training Guide
  • Registry Administrator Activity Guide
  • Source Training Guide
  • Source Activity Guide
  • Consumer Training Guide
  • Consumer Activity Guide
  • Registry Administrator Training Presentation
  • Source and Consumer Training Presentation
Templates
  • Data Access Agreement Template
  • Source Memorandum of Understanding Template
  • Consumer Implementation Strategy Template
  • Source Implementation Strategy Template

4.0 Main Impact

There were two main impacts of this project.

The first was the successful construction of a central repository for health care provider information that forms one of the foundation building blocks for a pan-Canadian electronic health record - the PRS product.

The second was proving that four provinces could collaborate in the creation of a portable software application suitable for implementation in any Canadian province or territory - the process of collaboration.

4.1 The PRS Product

Both the recently released Kirby and Romanow reports stress the importance of an electronic health record to the industry, and the potential represented by a single, readily accessible database. WHIC's Provider Registry System (PRS) contributes to that effort by compiling an accurate and secure healthcare provider data, a vital element of a larger system that will need to verify who can access the highly personal and private information in the EHR.

Its other applications are equally important: the PRS establishes national standards for provider information and address the high cost of multiple databanks. Today, organizations expend significant resources to obtain, convert and enter provider data into their systems. The PRS offers design development cost savings from the start. The registry building costs were only incurred once, and any provinces or territories that implement the same model will save those costs.

The PRS also addresses the problem of inconsistency in provider data at separate sources. Some patients live near regional or jurisdictional boundaries, and may visit health facilities in more than one region. Currently, provider data is inconsistent within and between regions, and as a result, some health records are disjointed and incomplete. As implementation progresses, each participating province will adopt the PRS registry model, drawing on - and standardizing - data from key health colleges. In time, any other Canadian province can also use the registry model to implement their own registry. Once this is done, data exchange will also improve. Imagine how convenient and cost effective it will be for health organizations across Canada to use centralized, trusted sources of information to authenticate providers.

In the project's first phase, completed in March 2003, WHIC designed, developed and implemented a PRS in each of the four western provinces - to be used by health ministries, health authorities, public bodies and some private organizations, such as labs. This phase also created a provider data standard, a data dictionary, data model and electronic data interchange message definitions. To date, one barrier to extending integration of health information across jurisdictions has been a lack of unique identifiers. The PRS uses a unique identifier for each provider across all jurisdictions that implement the system.

The PRS established a registry infrastructure, including a registry of key provider data, computer application, administrative and governance processes and the technological tools needed to maintain it. Other elements include message-based interfaces that accept provider data from authorized sources and automatically send provider data to consumers, and security software and processes to ensure confidentiality of provider data.

4.2 The Process of Collaboration

In 1999, the premiers of British Columbia, Alberta, Saskatchewan and Manitoba decided that their provinces and the northern territories could reduce costs and speed up results by collaborating on information management and technology projects - an agreement that led to the Western Health Information Collaborative (WHIC). The group co-operation was a vital step. Not only did it identify health care provider data as a strategic area for collaboration, but it also began work on a central repository that would become the foundation for a pan-Canadian electronic health record (EHR).

British Columbia has led the way in this project with strong support from the other western provinces, the Canadian Institute for Health Information, and the data sources and users across western Canada who adjusted their internal systems to populate and utilize the registry. This project has successfully demonstrated that collaboration across regional and provincial domains can work and yield benefits. From the initial discussions to the implementation stage, the Provider Registry project has led the way for other collaborative projects in Canada.

4.3 Human Resources Impact

Not applicable. The Provider Registry Project is a core health infostructure application that is currently in the process of implementation. As system uptake expands across Canada, and front-line systems and processes begin to utilize the registry, human resource impacts may be felt.

4.4 Privacy and Protection of Information

A Privacy Impact Assessment for BC was completed for the PRS project. Several new privacy exposures were identified:

  • The PRS will enable the identification of an individual provider in a jurisdiction regardless of the number of roles they may hold. For example, one would be able to determine that an individual is a physician and pharmacist.
  • A provincial registry may be accessible by other provincial registries.
  • The potential ability exists for compilation of lists for solicitation or other commercial purposes. Agreements between the Registry Administrators and Authorized Sources in each province will contain a reminder that Provider Registry data should not be disclosed for these purposes, and that this prohibition on use should be included in agreements with Authorized Consumers.

The BC Ministry of Health participated in the CHIPP Privacy and Security Survey conducted in August 2002. No recommendations were provided. The feedback the Ministry received was "No immediate gaps were identified with respect to HealthNet/BC's privacy program."

A Privacy Impact Assessment will be conducted at the start of each Phase of the Provider Registry Project. A PIA has been specified in the work plan for the PR1 - Enhanced Provider Registry Project (phase 2 of PRS).

Our project has not influenced privacy policy and process development in BC, due to the fact that BC already has well established policies and procedures for privacy.

4.5 Policy and Research Implications

Major finding #1 - Collaboration is Beneficial

One of the main objectives of this project was to ascertain the challenges of multi-partner collaboration (federal, provincial, territorial). Throughout the course of the project, the following recommendations were identified related to this objective.

Recommendations - Governance

In a collaborative project (five funding partners) there is a need for strong project management. The governance structure put into place for this project worked very well. Organized and consistent project management was the key to success, to meet aggressive timelines and obtain approvals on all deliverables from four western provinces. We found that it is possible for four jurisdictions to work together to achieve common goals when there is a strong commitment and clear direction.

Recommendations - Implementation

It was difficult for non-lead province technical teams to pick up the PRS product and begin implementation within their jurisdictions. Although they had been involved in decision-making and deliverable reviews, there were knowledge gaps that existed simply because these teams were not involved in the system development effort on a day-to-day basis. We found that sharing of resources and knowledge across provinces is essential, and that this sharing must take place at a detailed business and technical level. It is important to not underestimate the effort required for successful transition to non-lead provincial implementation teams. We also found that the extra overhead imposed by the collaborative nature and pan-Canadian visibility of the project, especially during the implementation phase, was not adequately considered. We recommend that in collaborative projects, extra resources should be planned for, especially during the implementation phase.

Recommendations - Communications

Communications are complex in a collaborative effort. Ensuring the consistency of messages regarding PRS was critical. We found that:

  • The Privacy Impact Assessment process used in BC and made available across WHIC was very worthwhile as a communication tool to address issues related to privacy.
  • Common points of contact and limited multi-point contacts within each province are critical to success. Casual communications between project domain experts should be encouraged. Subtle problems will surface earlier and help smooth development. Face to face meetings are beneficial and constructive to ensure/maintain non-lead provinces' depth of knowledge
  • An established, shared list of contacts for each province detailing area of expertise would have been beneficial. A central web site that can be updated by all provinces would facilitate more timely communication.
  • Regular reviews with provincial partners result in a richer product.
  • In addition to structured communications such as conference calls and meetings, periodic follow-ups should be conducted with each province to elicit their concerns and feedback.
  • Tracking of issues and resolutions is very important. This information can be used as a starting point for communications such as web site FAQs.
  • Establishing and fostering an environment for open, candid discussions among collaborating partners is necessary for successful collaboration.
Summary

The consensus among the project participants was that although collaboration adds complexity and cost to project management functions; if it is done effectively, the gains far outweigh the costs. In fact, collaboration ends up being much more cost-effective, because although the end product costs a little more to produce, it is used by all the collaborators, multiplying the savings by the number of collaborators.

It was unanimously felt that collaboration was a worthwhile activity for the provincial partners, and resulted in a superior product at a reduced cost for each province, as well as a product that is more likely to be adopted as a pan-Canadian standard. Many benefits of collaboration were identified, including:

  • One of the products of collaboration is increased ease of collaboration. The methods and tools developed by the partner provinces collaborating on the Provider Registry can be used by other collaborative EHR initiatives to increase their efficiency and effectiveness. This project has initiated significant reusable processes and will be the foundation of future collaborative efforts across Canada.
  • Collaboration across provincial jurisdictions is possible and can result in mutual benefits. Pan-Canadian standards will happen only with collaboration, flexibility and combined effort.
  • Developing a product in a collaborative manner helps to increase marketability of the product to other provinces. Collaboration has resulted in a product that is robust, rich and well thought out.
  • Collaboration takes goodwill, time and willingness to compromise for the collective good. While not easy, or quickly done, collaboration is beneficial.
  • Collaboration has helped the partners to accomplish something in four provinces in about the time it takes to do it in one.
  • Collaboration has helped ensure the project's momentum into future phases (e.g., Canada Health Infoway Inc. and wider deployment across Canada).
  • Common documentation deliverables have increased efficiency and effectiveness of the documentation itself.
  • Some provinces were limited as to the resources available. Collaboration has been extremely valuable to these partners. Manitoba's limited resource base has not prevented full involvement and success - this project may not have been feasible in Manitoba without collaboration.
  • The time taken for the design process was likely exceeded what an individual province may have taken, however the end result is a superior design satisfying requirements across provinces. This one-fits-all approach made the system more complicated than it might have been, but has resulted in a more robust product.
  • All costs incurred by the lead province for a collaborative cross-provincial initiative should be considered 'common' costs.

Major finding #2 - Offshore Development is Feasible and Cost Effective

The development team was located in India, creating both negative and positive impacts. One of the benefits of using offshore resources was increased scheduling flexibility. Aggressive project timelines required development work to be done during off-hours. Due to time zone differences, the development team was able to work during the hours the local team was sleeping. The local team was free to access the system in India during local working hours.

Another benefit was the opportunity to begin testing remotely by connecting to the India environment, before the BC environment was ready. A minor drawback was that testing the application hosted on this remote system added slight technical complications (e.g., firewall issues).

The technical design phase was slightly complicated because the team was located in India.

Major finding #3 - Attempting to Develop to Embryonic Standards Introduces Significant Risk

The four western provinces planned to use the HL7 version 3 message standard for PRS messaging. HL7 is an internationally recognized standard and is widely accepted in the health care sector in Canada. This would represent a leading-edge application of HL7 v3 methodology and messaging in Canada.

The lead project team developed a project plan, after considering the HL7 alternatives, which assumed a mature version of v3 and available tools. This did not prove to be the case and significant problems were experienced in using the immature standard. In February 2002, the four western provinces decided to await a more mature version of v3, including mature tools, before re-engaging in v3 development.

The four western provinces agreed to remove HL7 message development from the project's critical path and ask the development team to deliver an initial version of the PRS product with XML messages based on the PRS data model instead of the HL7 v3 model.

The PRS development team designed the solution architecture so that HL7 messages could be re-integrated into the final product at a future date.

Recommendations
  • Attempting to develop to embryonic or unformed standards with cutting edge tools and technologies introduces significant project risks. Decision-makers need to be aware of the true maturity level of a technology before proceeding down a specific path.
  • If a standard is found to be immature, move ahead to deliver on time and budget by using a modular technique so that as the standards catch up they can be applied.
  • Prototype risky parts of the system before committing to full-scale development. Doing so will surface problems early, save time and money, and leave the project better positioned with alternatives.
  • Resources working on HL7 messages should be integral parts of team, not independent experts. This will help ensure they are aware of changes as they happen during the life of the project.
  • Retain an audit log of HL7 design changes.
  • Use HL7 only where necessary (i.e., essential interoperability) or where it is adding value (e.g. selling feature). Otherwise evaluate simpler alternatives.
  • The complexity of HL7 schemas makes it difficult to spot other schema problems by visual inspection. Determine how you will test these schemas to ensure they reflect your requirements in all use cases.

Major finding #4 - Ensure Adequate Resources are Recruited

At the start of the project, the lead project team prepared a detailed Resource Strategy. This strategy proved to be well thought out, and one of the project strengths. The lead team size was kept small, and the resource strategy enabled the most efficient use of these specialized resources throughout the project.

The lead project team consisted of:

  • Project Director - directs the project activities and communications across all four provinces.
  • Project manager - responsible for day to day activities.
  • Business analyst - ensured business needs were identified and addressed.
  • Technical/Quality Analyst - ensured technical needs were addressed, quality standards were complied with and deliverables conformed to the standards.
  • Documentation Specialist - supported the team in all documentation and communication activities.
  • Project Analyst - prepared work plans, financial reports, assisted the project manager.
  • Test Team - executed the test strategy.
  • Implementation Co-ordinator - worked with Sources and Consumers in BC.

The extra overhead imposed by the collaborative nature and pan-Canadian visibility of the project, especially during the implementation phase, was not adequately considered.

Recommendations
  • In collaborative projects, defend the need for extra resources, especially during the implementation phase.
  • Having a dedicated technical analyst was essential to translating the high volume of technical material and for providing a neutral viewpoint to the project's management.
  • Having a dedicated documentation specialist working closely with the business and technical analysts was an efficient use of resources because it freed up the business and technical analysts to concentrate on dealing with day to day project issues.
  • Having a project analyst to take on maintenance of the project plan and financial reporting was an efficient use of resources, because it freed up the project manager to concentrate on day to day project issues.
  • In a collaborative project (five funding partners) there is a need for strong project management. Extremely organized and consistent project management has been key to success. Established timelines and detailed expectations with regard to deliverable reviews have aided in efficiency.
  • Resources in the non-lead provinces that joined the project part way through the project raised defects and questioned past decisions, due to their late arrival on the scene. Continuity of participation regarding non-lead province participants should be a high priority in order to avoid major effects on the project budget and schedule.

5.0 The Future

Sponsored by Canada Health Infoway Inc (Infoway), and supported by WHIC and WERC (Western EHR Regional Collaborative) two new "phase 2" PRS initiatives are now getting underway.

The PR1 - Enhanced Provider Registry Project, led by BC, will deliver an enhanced version of the current PRS. The enhanced PRS will better meet the requirements of new jurisdictions by including additional functionality. It will also facilitate the "uptake" of the PRS by improving integration with a broader range of source systems. Accelerated implementation of PRS in other jurisdictions will be supported.

The PR2 - PRS System Integration Project, led by Saskatchewan, will provide a "reusable implementation toolkit" and best practices that can be used by different jurisdictions in the deployment of the PRS. This toolkit will consolidate the experiences and knowledge gained through implementation in the four western provinces. The toolkit will include technical expertise along with best practices related to the adoption of the registry from a business perspective, and will support accelerated implementation of PRS solutions in other jurisdictions.

5.1 PR1 Scope

PR1 will develop a production ready enhanced provider registry system suitable for deployment at existing PRS implemented sites, new healthcare organizations and in new Canadian jurisdictions.

Enhancements to the PRS have originated from the following areas:

  • Postponed stakeholder requirements. During development of PRS some requirements identified by stakeholders were considered to be out of scope due to funding constraints. Some of these requirements are included in the Enhanced PRS Project.
  • Employed providers. PRS focused on licensed individual providers with a single trusted source for each role type. The "Employed Providers" enhancements will accommodate multiple sources for a role type.
  • Authentication of individual providers is a key business driver for many stakeholders. PR1 - Enhanced PRS will include functionality to enable authentication of individual providers, however, an Authentication Service is not in scope for the Enhanced PRS Project.
  • HL7 message development. PRS was developed with XML messages rather than HL7. To improve the long-term interoperability of PRS, HL7 messages will be developed.
  • Registry-to-Registry (R-2-R) communication was largely out of scope for PRS. Enhancements on R-2-R communication are part of the PR1 - Enhanced PRS.
  • Stakeholder implementation issues. As each of the four WHIC provinces implemented PRS within their local infrastructure, enhancements were identified to improve portability of the common system and reduce the effort to implement PRS across multiple jurisdictions.
  • The Infoway PR2 project identified enhancements to support improved stakeholder uptake and data standards. The members of the Western EHR Regional Collaborative (WERC) have been Saskatchewan's primary sources for these enhancements.

Assuming a May 15, 2003 start date, a release strategy of four releases has been identified.

1. PRS Release 2.05 to be delivered to WHIC User Acceptance Testing (UAT) by June 2003 will:

  • Improve system performance for the end user
  • Provide better information to users and operations staff when PRS or its environmental components fail
  • Reduce the effort required by WHIC partners to port the system to their own environment
  • Incorporate warranty fixes

2. PRS Release 3 to be delivered to WHIC User Acceptance Testing (UAT) by November 2003 will:

  • Deliver functionality to improve PRS uptake by licensed and employed providers. Wherever possible, enhancements which are required by the Infoway PR2 - System Integration Project, and by the PR1 HL7 message tasks will be included in this release.
  • Incorporate warranty fixes

3. Release 4 to be delivered to WHIC User Acceptance Testing (UAT) by May 2004 will:

  • Provide HL7 message interface ability
  • Support registration of authentication data for providers

4. Release 5 to be delivered to WHIC User Acceptance Testing (UAT) by October 2004 will:

  • Provide code set management across registries
  • Provide user specific dropdown choices and CPN helper on Web application
  • Provide collaboration and communication tools for Registry Administrators
  • Include contingency enhancements not previously identified

5.2 PR2 Scope

The PR2 project has two phases: Phase 1, to be completed by April 01, 2003, will define the specific tools and processes to be developed as part of the System Integration Toolkit. Phase 1 includes the development of the Phase 2 project plan and deliverables, including requirements definition; identification of collaborative jurisdictions; identification of reusable processes and "best practices for the implementation of reusable software components. The objective is to create Phase 2 planning deliverables to allow accurate estimation of the project effort and risks and to have established preliminary business design deliverables to ensure the successful delivery of the implementation toolkit.

Phase 2 is the development and testing of the implementation toolkit to support and enhance the deployment of the Enhanced PRS at other healthcare organizations (including WHIC sites). The scope and duration of Phase 2 will be fully defined in Phase 1.

6.0 Communications

Methods or Tools Date Targeted Audience Documents or PresentationsProduced
WHIC Coordinating Group (WCG) Monthly meeting / status reports Representatives from four western Provinces Steering Committee for project.
External Advisory Group (EAG) Quarterly Regulatory bodies and government health agencies across western Canada Four meetings held over life of project to report on status, elicit feedback.
Business Working Group (BWG) Quarterly Data source and consumer organizations that will implement Provider Registry in the first phase of the project Six meetings held over life of project to report on status, elicit feedback.
Publications April 2002 Health IT shops across Canada WHIC PRS White Paper
Spring 2003 Healthcare Managers across Canada Canadian Healthcare Manager Magazine Technology Article "Granting Access"
CIHI Partnership Symposium Spring 2001
Fall 2001
Spring 2002
Fall 2002
Health IT Managers PRS Brochure, Presentation Material

Extranet Web Site at

http://healthnet.hnet.bc.ca
/catalogu/provider_registry
/index.html

Project inception Any interested party
  • Project Overview
  • Activities and Schedule
  • Some Project Documents
  • Newsletters
  • Project Standards & Guidelines
  • General FAQ

Restricted Web Site at

http://healthnet.hnet.bc.ca
/stakes/provider_reg
/index.html

Project inception Two areas within site.
Restricted area #1: for all stakeholders.
Super-restricted area #2: specific work groups
Restricted area #1:
  • All information on extranet site (see above)
  • Business design documents
  • Technical documents
  • Registry administration documents
  • Templates
  • Technical FAQs
Super-restricted area #2:
  • All information on restricted area #1 (see above)
  • Software releases
  • Sample files