Health and the Information Highway Division, Health Canada
December 29, 2003

Table of Contents

• 1. Introduction
• 2. Project Description
  • 2.1 Context
  • 2.2 Background
  • 2.3 Project Restart
  • 2.4 Construction and Deployment
• 3. Achievements
  • 3.1 Intended Outcomes
  • 3.2 Goals Reached
    • 3.2.1 Pre-Bridges Status
    • 3.2.2 Post-Bridges Status
  • 3.3 Additional Successes
    • 3.3.1 Discharge Summary
    • 3.3.2 System Integration
  • 3.4 Unreached Goals
  • 3.5 Documents and Products Generated
    • 3.5.1 Systems
    • 3.5.2 Clinical Documents
• 4. Main Impact
  • 4.1 Human Resources Impact
  • 4.2 Privacy and Protection of Information
  • 4.3 Policy and Research Implications
• 5. Future Potential
  • 5.1 Technology
  • 5.2 Standards
  • 5.3 Human Resources
  • 5.4 Systems Integration
• 6. Project Communications
• 7. Project Metrics
  • 7.1 Timeline
  • 7.2 Effort
  • 7.3 Costs by Project Phase and Timeline
  • 7.4 Costs by Project Category
  • 7.5 Sustainability
• 8. Lessons Learned, Recommendations
  • 8.1 Contract with IBM
  • 8.2 Project Management
  • 8.3 EHR & Evaluation
  • 8.4 Teamwork
  • 8.5 Health Canada Process

1. Introduction

In 1999, the Federal Government announced a series of programs designed to explore the opportunities and potential for building better data systems supporting geographically distributed health care services.

During 2001, C&W presented a proposal to Health Canada to develop a system to allow the pediatric oncology clinics at Victoria General and C&W to share patient data and build a common patient chart that could be viewed and updated electronically.

In November of 2001, the Bridges project formally began, with contract negotiations and a design concept that included electronic data from several C&W systems feeding the Electronic Health Record. Health Canada, IBM, C&W and VGH (Victoria) have contributed time and resources to establish the software and infrastructure that make up the EHR system. The project receives funding from Health Canada, of up to 56% of the total project expenditures, to a maximum of $1.8M.

With the change of Health Regions in early 2002, and specifically with the establishment of the PHSA (Provincial Health Services Authority) the fundamental basis for the development of an EHR changed. Business drivers, including the sustainability of the IBM HDN system and the existence of a well established EHR within the PHSA led to a project review and the subsequent changes to the project charter. As a result of this review, the underlying technology for Bridges was changed from IBM HDN to the BC Cancer Agency CAIS environment. The scope of work, and the intent of the project remained the same - specifically to establish a sustainable EHR in support of paediatric oncology in BC.

The Electronic Health Record is a patient-centric view of their medical history, constructed in a way that allows the chart to contain electronic clinical information originating from many different source organizations. The primary goal of the project is to construct a limited scope EHR environment and to explore the implementation issues associated with developing a multi-site clinical record.

This report is the final report from the "Bridges Project" which summarizes the achievements, lessons learned and the costs associated with the project activities. Included with this report are several documents which were generated during the project lifecycle, which provide more detailed information. Specifically the two clinical evaluation reports, interim and final, summarize the measurable outcomes of the project based on user interviews, evaluation forms and observations by the project evaluators.

In addition to the Appendices, a complete archive of the documentation produced over the course of the project is available on CD-ROM, which has been included with the final submission to Health Canada.

2. Project Description

Project Vision

Through the use of an electronic health record, all care providers across all jurisdictions have access anytime and anywhere, to up-to-date clinical patient information for paediatric patients in B.C.

2.1 Context

There are about 10-20 new patients per year that are seen by the Oncology Clinic at Victoria General Hospital (VGH). In this group, there are about 20 active cases at any time, plus another 60-75 on follow-up. There are about 500 total patient visits per year. C&W physicians follow about 50 of these VGH patients per year, for about 200 visits annually.

In BC, all pediatric oncology patients are seen at C&W, with continuing treatment and consultations provided by community hospitals closer to the patient's residence. Other treatment centres that are of interest for Bridges include Nanaimo General Hospital, Prince George, Surrey, Kamloops, Kelowna and several other sites with significant patient populations.

2.2 Background

The first phase of the project attempted to establish an infrastructure for a cross-regional Electronic Health Record, based upon on the Ontario eCHN "Health Information Network", and using IBM's Health Data Network (HDN), with support from the partner organisations and other clinical data providers.

The HDN infrastructure was intended to support the creation of Electronic Health Records for the selected patient population. This systems that feed clinical data to the EHR could be expanded, at later stages, to include more comprehensive clinical data and to serve other patient populations and other jurisdictions.

2.3 Project Restart

At the mid-point in the project, several significant technical, financial and business issues drove the search for a more effective EHR system to replace the HDN environment while meeting all of the objectives of the original CHIPP-BRIDGES project.

The BC Cancer Agency EHR was selected as a full-featured replacement for the IBM HDN system in October 2002. The Bridges Project continued to meet its objectives using this technology while using the business processes established at the BCCA as far as possible.

2.4 Construction and Deployment

Beginning in October 2002, the project team focussed on adopting the BC Cancer CAIS system which was developed at BCCA using internal resources. CAIS was quite different technically and operationally than the IBM system and the absence of technical documentation and competition for BCCA resources caused significant delays to the project. Initially the timeframe called for a client installation in April, with a "go-live" date targeted for June 1^st, 2003, which allowed approximately 7 months for the construction and deployment process, plus 5 months to gather sufficient data for the evaluation team to generate a statistically significant dataset for the clinical evaluation report.

In fact the project was substantially delayed due to conflicting BCCA priorities and resource issues, which deferred the beginning of actual construction to April, and a go-live scheduled for July 1^st 2003. When the system was turned on, it was discovered that the BCCA system was associating C&W pediatric records with existing adult oncology patient records. It was subsequently discovered that the CAIS system did not recognise the unique facility based Medical Record Number (MRUN) used exclusively at C&W and VGH, and was matching a C&W MRUN with similar numbers in patient records that originated at other facilities. The system was immediately disabled and the pediatric data removed manually from the adult CAIS system.

The consequence of this error was a further delay in the live date to October 15th, 2003, when the project team were once again confident that the system was stable. Unfortunately, the remaining time available for the clinical evaluation was now too short to produce statistically significant data, and this had a detrimental effect on the value of the final evaluation.

A detailed historical review of the project status can be found in the Status Report and Executive Summary folders provided on the project archive CD-ROM.

3. Achievements

3.1 Intended Outcomes

The Project Charter identifies the goals and expected results from the project as follows:

• Improved continuity of patient care, through providing immediate access to patient information to the entire care team
• Reduced risk to patient safety since no assumptions are made about the patient's care or treatment.
• Increased patient and family confidence in the care process, since the providers are all seen to have the same information about the patient.
• Reduce the number of patient visits and tests as a result of more complete and timely information in one electronic chart.
• Up- to-date information on the patient's care plan at the time of discharge from each facility.
• Complete accurate information on medications and dosages as set out in the interim Discharge Summary.
• Better support to VIHA clinical staff, by providing information about patient status earlier in the treatment cycle.
• Increased staff confidence in each facility, by understanding exactly what treatments have been provided at time of discharge.
• Stronger linkages between the teams at C&W and VIHA that come from shared information.
• Establish a framework to develop a more comprehensive multi-facility EHR in the future.
• Establish a secure health data infrastructure that complies as far as possible with the ISO 17799 guidelines.

In addition, the following operational expectations were established:

Authorized users from any partner site will be able to:

• Access the CAIS server via a VPN connection
• Search for a patient using selected demographic information;
• View/update patient demographic information;
• View/update encounter history and encounter detail information in CAIS;
• Retrieve and view Clinical Chart in CAIS
• Add specific data to the Clinical Chart in CAIS
• View Diagnostic images including DICOM information

3.2 Goals Reached

3.2.1 Pre-Bridges Status

From the initial evaluation report, it can be seen that the C&W and VGH oncology departments had a significant number of patient visits during the first 6 months of the project.

It was determined by process modeling, interviews and surveys that there are problems with the paper-based method of exchanging data between C&W and VGH.

Process modeling revealed that the current paper-based charting system had problems ensuring that patient data was consistent at both sites. It was also discovered that the process for ensuring that patient data transferred between C&W and VGH is not considered reliable by the clinicians interviewed. Furthermore, no controlling process existed to ensure that data transfer occurred in a timely manner. Clinicians indicated that there was no process for ensuring that emergency room staff at either hospital had the patients' most current clinical data.

Surveys issued to clinicians revealed that 80% of clinicians considered the transfer of data between VGH and C&W to be problematic. Furthermore, 62.5% of clinicians surveyed indicated they would like the method by which data is transferred between C&W and VGH to be changed. An additional 25% indicated they would like the system changed if there was a 'significant improvement to patient care'. 75% of clinicians surveyed indicated they perceive that the manual method of data transfer negativity impacted patient care.

'Per visit' surveys indicated that 14.7% of patient visits at VGH were missing some form of patient data for which the nurse had to search for prior to the visit. For visits that were recorded as 'first visits at VGH after treatment at C&W' 73% were missing data. Of the visits missing data, the clinician indicated a possible negative impact on care in 78% of cases (20 out of 26 visits). In 38.5% of visits missing data, the clinician indicated that he/she had to make assumptions with which they were not completely comfortable in order to provide care. For the visits that were missing data, 69.2% of the time the clinician at VGH indicated that the information missing was not collected by the time of the patient visit. Telephone calls and Facsimile were indicated as the primary method for gathering data in 64% and 74% of cases missing data respectively.

Of the parents of paediatric oncology patients who voluntarily completed a survey¹, 92.3% (12 out of 13 surveys) indicated that they had been in a situation where they perceived that information regarding their child's illness had not been conveyed between healthcare professionals. Of these parents, 66.6% indicated that they had been in a situation where documents were lost or misplaced when transferred between hospitals. Another 66.6% indicated that they had been in a situation where appointments or treatment had been delayed because of missing documentation. None of the parents surveyed indicated that they were 'against the use' of electronic patient records for exchanging data between hospitals.

92.3% of parents surveyed indicated that they felt that an EHR would improve security of their child's information from inappropriate use and access; the remaining parent indicated it would have no impact on security.

¹ The parents who completed this survey were self-selected and only 23.2% were from Vancouver Island. Their experiences and attitudes toward electronic health records may not be reflective of parents on Vancouver Island

3.2.2 Post-Bridges Status

Due to delays in implementation the post implementation phase of the Bridges evaluation was cut from the originally planned 5 months to 2 months. Further delays in use due to the learning curve associated with a new program and technical difficulties in providing clinicians access resulted in a further shortening of this evaluation period to two months. As a result of this shorter evaluation period fewer clinicians and project team members were qualified to complete surveys (since they had not used the program or were not sure of its impact). This shorter evaluation period also resulted in fewer 'per visit' surveys. This small survey sample size should be taken into consideration and the many results are not conclusive.

It is the recommendation of the evaluation team that further time is given and more data collected in order to determine more conclusive results.

Aside from the technical difficulties in implementation which were to be expected in the initial stages of the EHR implementation the most common reason given by clinicians for not using or liking the system is its "unintuitive nature". Clinicians feel the system is difficult to negotiate and "data is hard to find".

The 'per visit' surveys indicated that 20% of patients (3 out of 15) were missing information when the Bridges EHR was used. For 'first visits' to VGH 75% (3 out of 4) were found to be missing information. Both of these are a slight increase in error rate compared to pre-Bridges but due to the small numbers of data are not conclusive. Clinicians interviewed were not sure if this missing information was a result of information not being in the EHR or the clinicians not being able to access or find the information in the EHR.

Based on the actual post implementation data collection period of 2 months and the number of 'per visit' surveys collected, the success rate of data delivery between VGH and C&W needed to improve by approximately 85% before the change would be significant at an ? <= .05. Bridges would have to improve the observed success rate of data delivery for first visits after treatment at C&W by approximately 60% before the change would be significant at an ? <= .05. Consequently, we could not detect a statistically significant change in the outcomes.

The operational expectations set out in the Charter were all achieved. Although the connection to CAIS is not a "VPN" connection, the technology used (CITRIX) is a private, secure access method which achieves the same result.

3.3 Additional Successes

Fundamentally, the goal of the Bridges Project was to enhance communications between the clinical teams. It can be seen from the initial clinical evaluation that many of the clinicians expressed concerns over the manual exchange of patient information. In essence while all of the clinicians had found ways to offset problems arising from missing data, their confidence in the manual system was not high and their frustration was evident.

3.3.1 Discharge Summary

Very early in the project, a very significant improvement in communications was achieved. The C&W and VGH oncology teams relied on a clinical summary form to be completed by the nursing team when a patient was discharged, prior to receiving treatment at another hospital. There were several forms involved, each facility having their own versions. The clinical teams at C&W and at VGH collaborated to derive a consistent, standard form which contained all of the relevant discharge information. This "Discharge Summary" form was subsequently printed and is now used universally within the Pediatric Oncology Program in BC, reducing workload and substantially improving clinical communications.

It was not only the form itself, but the substantially improved interpersonal communications between the clinical teams that was a success factor which greatly assisted the project team during the project lifecycle.

The second valuable effect was that the Discharge Summary was established as an eForm and fully integrated into the CAIS environment, as well as being available in a standalone format. This eForm was initially designed to generate a Word document and to also generate XML data, compliant with the Compound Document Architecture (level 2). As such, this type of eForm could be used to satisfy document centric clinical systems (such as CAIS) as well as data centric systems (e.g. Cerner) where individual data elements are stored. The final version of the Discharge Summary does not have this XML capability, although it could be easily added as a subsequent activity.

3.3.2 System Integration

System to system communications are generally built on established standards. In the medical community, HL7 is a well recognised method for the exchange of clinical data between systems. At C&W, many systems are not HL7 compliant and this introduces a level of complexity and expense to all systems integration activities. Compounding this, was the unfortunate fact that CAIS was not HL7 compliant either. The Bridges team had two primary integration issues to resolve - how to interface the ADT (Admitting Discharge Transfer) system at C&W (which was HL7 compliant) with CAIS - and how to transfer laboratory results from the C&W Lab system (not HL7 compliant) with CAIS.

The ADT interface to CAIS was constructed using Microsoft BizTalk which could accept an HL7 message from the ADT system, parsed by a NeoTool translator, that called a SQL server stored procedure on the CAIS system. This allowed an almost real-time update of C&W patient demographics into CAIS.

Once the demographics were in CAIS, and a patient record existed, the C&W and VGH lab systems could produce a lab report which was directed to print to a remote printer at BCCA - in fact the "printer" was a parsing program that read the lab report and associated it with the patient record in CAIS.

These two solutions allow a clinician to recover a lab report for a patient from the CAIS system more easily and usually faster than using the LIS (Laboratory Information System) directly.

Secondly, the experience gained while integrating the BizTalk system with the ADT system has provided C&W with the tools and knowledge necessary to convert the old HL7 interface engine to a more modern and more versatile system based on BizTalk in a much faster time than would have been possible previously.

3.4 Unreached Goals

Not all of the intended outcomes have been achieved to the degree expected. Specifically, the CAIS system is not being used universally by the oncology teams for a number of reasons:

Limited data coverage
Electronic data for all pediatric oncology patients admitted at C&W is sent to CAIS. This is the ADT record and any lab reports ordered during the admission. Only a patient that is also seen at VGH will have their record electronically updated with a lab report. Therefore a C&W patient from a non-Bridges site will not have their chart updated with a local lab report. This means that the clinical teams must revert to their paper chart and other manual processes for non-Victoria patients. Since all C&W patient charts are maintained manually, most clinicians use their paper chart, rather than rely on an incomplete and limited electronic view of the chart for a specific set of patients. This ultimately leads to a confidence issue.

Unless the EHR contains a "complete" dataset, any clinician will be forced to find an alternative and more reliable source of patient data.

Usability and workload issues
Workload is a major factor that prevents busy professionals from adopting new practices or technologies. When their workload is increased there is significant resistance to change. When their workload is increased and their ability to use the system is frustrated by usability issues, system reliability and limited benefits, the result is that the users will generally revert to the system that works best for them. One example of this frustration is the "action list" feature in CAIS which was specifically not provided to C&W users by BCCA. Action lists are a method for the CAIS user to organise their pending work and to route documents between users for revision, signing and filing.

Without workload support features, the additional work needed to track and process documents in the CAIS system is significantly increased.

Limited benefits for the clinicians
The value of the EHR to a clinician lies in having timely access to patient information that is easily accessed and used. The clinical team at C&W is responsible for all pediatric oncology patients in BC and while a fully deployed EHR such as CAIS would certainly encourage better communications and provide a valuable benefit, the system as it stands now, adds workload, reduces reliability and is only of benefit to those caring for VGH oncology patients.

While it is quite possible for the CAIS system in use at C&W to be broadly used within the C&W domain, it must be recognised that the information already exists in other formats at C&W - not least of which are the ghost charts, ADT system, LIS system, radiology and pharmacy systems and a multitude of paper based formats.

CAIS at best contains a subset of this data and therefore expending energy to feed the CAIS system at C&W, adds little or no value to the clinical process or patient care.

3.5 Documents and Products Generated

3.5.1 Systems

The existing LAB and Admitting systems at C&W were adapted to feed electronic data to the CAIS environment.

In the case of the TripleG Lab system, no standard data formats (e.g. HL7) were available, so the simplest solution found was to redirect a print stream to a CAIS program instead of a printer. The same solution was applied to the VGH Lab system.

This "print parser" simply matched the report header data and copied the following text report into the CAIS database, without interpretation of any kind. The key data matched was the C&W Medical Record Number, Provincial Health Number, Patient Names and Date of Birth. When an exception occurred, e.g. a partial match, or a missing PHN, the record matching process reverted to a manual process.

The ADT system was capable of generating HL7 2.2 standard messages. The CAIS system however has no native HL7 capability, so the interface system translated the HL7 data structure into an SQL stored procedure call through a BizTalk server. This system allows almost real-time transactions and is a prerequisite for the LAB interface.

The system is considered secure due to the access control provided by the CITRIX server, and by the inherent security provided by the HealthNet network. There are two access methods available - either a user works within a hospital network with the usual security policies applied, or the user can be supplied with CITRIX credentials and connect to the CITRIX server via the public internet through the NFuse subsystem. When an NFuse connection is validated, the user must then sign in to each CAIS application just as if she was located withing a HealthNet facility.

User access and audit control are managed by the BCCA CAIS system operators.

Information Flow Diagram

3.5.2 Clinical Documents

Document Type	Template(s)	Chart Section	Mnemonic (Chart Sub Category)	CW clerk	CW Nurse	Victoria nurse	CW phy- sician	Victoria phy- sician	OT	Psych- ology	Social Work
Interim Discharge	Summary Discharge Summary e-form (CW or Victoria)	Discharge	DISCH		yes	yes	yes	yes	yes		yes
Final Discharge Summary	Discharge Summary e-form (CW or Victoria)	Discharge	DISCH		yes	yes	yes	yes	yes		yes
Discharge Summary Addendum	Discharge Summary Addendum (CW or Victoria)	Discharge	DISCH		yes	yes	yes	yes	yes		yes
Physician Summary	Physician Summary Victoria	Narrative	PROGRESS					yes
Physical Assessment	Physical Assessment Victoria	Narrative	ASSESSMENT					yes
Initial Clinical Summary	General Oncology	Narrative	CONS	yes			yes
Ongoing Treatment Report	General Oncology or Ongoing Treatment	Narrative	PROGRESS	yes			yes
Treatment Note	General Oncology	Narrative	PROGRESS	yes			yes
Pre BMT Family Conference	Pre BMT Conference Checklist or General Oncology	Narrative	CONF	yes			yes
Oncology Follow up Report	General Oncology	Ped LTFU	LTFU	yes			yes
Discharge Clinical Summary	General Oncology	Ped LTFU	DISCH	yes			yes
Pediatric Oncology Conference	Ped Oncology Conf	Narrative	CONF	yes			yes
Pediatric Oncology Conference Summary	Ped Oncology Conf	Narrative	CONF	yes			yes
Summary of Treatment (BMT)	Summary of Treatment (BMT)	Ped LTFU	LTFU	yes	yes	yes
Summary of Treatment	Summary of Treatment	Ped LTFU	LTFU		yes	yes
Nursing Note	Nursing Note (CW or Victoria)	Nursing	NOTE		yes	yes
Nursing Note - LTFU	Nursing Note LTFU	Nursing	NOTE		yes
Clinical Nurse Specialist Note	Clinical Nurse Specialist Note	Nursing	NOTE		yes
OT Assessment Report	OT Assessment Report	Support Services	OCCTHERAPY					yes
OT Feeding Study Report	OT Feeding Study Report	Support Services	OCCTHERAPY					yes
Psychology Assessment	Psychology Assessment	Support Services	PSYCHOLOGY						yes
Psychology Consultation	Psychology Consultation	Support Services	PSYCHOLOGY						yes
Psychology Treatment Summary	Psychology Treatment Summary	Support Services	PSYCHOLOGY						yes
Social Work Checklist	Social Work Checklist	Support Services	SOCIALWORK							yes
Social Work Progress Report	Social Work Progress Report	Support Services	SOCIALWORK							yes
Social Work Report	Social Work Report	Support Services	SOCIALWORK							yes
DOCUMENT FOR DELETION	NA	NA	XXX	yes	yes	yes	yes	yes	yes	yes	yes

4. Main Impact

4.1 Human Resources Impact

Overall Bridges has neither increased nor reduced the staffing needed within the Oncology teams, largely due to the very limited scope of use of the CAIS system.

Several roles have changed to adapt to the clerical support needed to load data into CAIS, and new responsibilities have been added within the IS departments at C&W and at VGH to support the technical aspects of the system.

4.2 Privacy and Protection of Information

A separate Privacy Impact Assessment has been completed for the Bridges system which is available on the project archive CD-ROM. However in summary, since the system resides entirely within the secured network domain of C&W and VGH, with wide area communications over the secured Healthnet network, no new security exposures have been introduced.

Personal data is collected by the C&W ADT system and transferred electronically (and securely) to the CAIS server. No new information is collected by the hospital. Hospital systems at C&W and VGH have the appropriate policies in place regarding security of data, confidentiality and access controls.

Bridges is essentially a systems integration project, which unites existing hospital technologies and processes with the BCCA CAIS system and processes. The PIA does not attempt to examine the CAIS and BCCA internal processes or security models.

4.3 Policy and Research Implications

Throughout the project there has been an implicit recognition of the role of the parent as part of the care team. At C&W, parents have the right to request a copy of any information in the child's chart, to be provided by Health Records. While parents of sick children have this access to information, there exists some confusion regarding their right to access such information electronically. Furthermore if a patient chart exists in a format that can be accessed over a secure internet connection, it would seem that the parent should also have access to this under C&W's current policy.

As a matter of public policy, some thought must be given to the basic issues of "ownership" vs. "custodianship" of an individual's information. In the case of the EHR, the organisation storing the data may have policies in place which restrict or inhibit access to that information by third parties, e.g. parents, while the organizations which individually provide pieces of data freely permit such access.

The "Partners in Care" Committee is a BC Provincial group of parents who are actively seeking a resolution to this issue. The contact for this group is Mr. Dan Mornar at the Department of Oncology and Haematology, at C&W.

5. Future Potential

5.1 Technology

Looking to the future, in the healthcare sector there is a very definite trend towards data centric clinical systems and away from document centric systems. More significantly, CAIS as it stands is largely a manual document index and storage system, relying on a very significant amount of human intervention to collate and match paper documents (scanned, FAXed) with patient records.

Fundamentally, CAIS works for the BCCA business processes and purpose for which it was initially designed. It is, however difficult to adapt in a way that allows non-BCCA organizations to electronically share data.

From the Bridges experience, the integration of established hospital systems with the CAIS system was difficult and awkward. This is in part due to the fact that CAIS was never designed to incorporate external systems, but also due to the system design, architecture, technologies, and level of documentation available from BCCA.

5.2 Standards

Interestingly, data standards within the healthcare sector are well published, although adopted and applied only in a very limited way. HL7 in all its variations has been a mainstay of clinical data integration for some time, but the evolution of this standard and the slow pace of vendor compliance has limited its use, in Canada more than in the US.

Within the health regions in BC, there is no "standard" adoption of HL7 for Lab, ADT or other clinical data. While CAIS itself does not inherently support an HL7 dataset, the potential for further electronic integration in BC is very limited. The solution developed by the Bridges team was to "translate" an inbound HL7 message to a format directly useful to the CAIS SQL database. This might be feasible as an integration solution for other systems, however the underlying CAIS architecture is not specifically designed to operate on discrete data elements with the complex data relationships found in commercial clinical systems.

Technology "standards" may also prove to be a limiting factor to any further expansion of this EHR solution. The C&W environment is built on modern, current Microsoft products such as Windows XP and Office XP. Other organizations may neither use Microsoft products, nor be as up to date as C&W. The consequence of this is the technology lag effect, experienced acutely by the Bridges project when integrating Office XP documents with CAIS.

Communication standards and infrastructure in BC are very well defined and managed. A provincial healthcare network called Healthnet, links all major clinical centers with a secure high speed ip network. While individual organizations may use alternative networking technologies, the overall infrastructure is consistent and very suitable as the backbone for a provincial EHR.

In BC the client registry is notorious for being out of "synch" with hospitals and their view of the patient's demographics. As such, the Provincial Health Number is not universally used as the definitive patient identifier in BC. Hospitals rely on their health records systems and their own MRN/MRUN or Medical Record Number to uniquely identify their patients. Unfortunately the MRN is not a standardized number and it is facility specific. The fact that the PHN is not universally used, combined with the confusion surrounding the MRN and identifying healthcare facilities, means that until a functional eMPI (electronic master patient index) is available in BC, real electronic systems integration will be difficult and expensive to implement safely.

5.3 Human Resources

Any well designed EHR will have the potential to positively impact human resource demands on an organization, by shifting the manual and clerical aspects of health records management to a more automated and self-validating model. Conversely, a poorly articulated EHR will add a significant burden to those who would potentially use it.

The CAIS environment is largely a manually oriented document indexing system and as such, further expansion of the use of CAIS to other community sites or as a component of other hospital support systems, e.g. transcription, will add to the human resource requirement.

5.4 Systems Integration

The future potential for the Bridges - CAIS system is very limited due to the complexity and expense associated with systems integration. As previously stated, the CAIS system was designed specifically to meet the document management needs of BCCA, and it was not designed with integration of external systems in mind.

At the core of the systems integration issues are data standards which may be "defined" within the technology industry, but which have not been widely deployed in BC. Those organizations that have implemented modern clinical information systems, for example Vancouver Island Health Authority and their Cerner systems, already have a standard, multi-facility EPR and EHR. Clearly integration with a standards based system will be much simpler than attempting to integrate with a proprietary non-standard environment.

Those organizations without a data-centric, standards based system will remain at a significant strategic and cost disadvantage when the EHR opportunity is presented.

6. Project Communications

Throughout the Bridges Project, external communications activities have been kept to a minimum. Initially, the communication plan reflected the "marketing" aspects of the project, seeking to improve awareness of the project vision and approach. With the false start in mid 2002 when the IBM HDN system was seen to be less than successful, external communications activities essentially stopped.

Internal communications, within the healthcare community at C&W and VGH have also remained low-key.

The project team has been well supported by a diverse steering committee membership which included representatives from both the Vancouver and Victoria area, senior managers from the BC Ministry of Health, Health Canada, patient advocacy and the Directors of the Provincial Pediatric Oncology team. It is through the steering committee and inter-hospital bulletins that the majority of project related communications have occurred.

The Communications Plan developed in early 2002, identified the following objectives which were achieved.

Objectives	Measurement	Current Estimate	Target
1. Increase C&W internal awareness of the project	IS and Oncology team able to describe the purpose of the project	none	50%
2. Increase VGH internal awareness of the project	IS and Oncology team able to describe the purpose of the project	none	50%
3. Increase BC MoH awareness of the project and the solution
4. Increase the visibility of the Bridges Project among other parties interested in an EHR system	Active meetings with minutes	None	1 per calendar quarter per group
	Media attention	None	Increased coverage
5. Improve the two-way flow of information between various stakeholder groups and the Project Team	Active meetings with published minutes or other written content.	None	1 per calendar quarter per group

In addition, several members of the project team maintained a dialogue with and contributed to the Health Canada Infoway Electronic Health Record planning process, attended COACH and CIHI seminars and maintained communications with their peers in other healthcare organisations.

7. Poject Metrics

7.1 Timeline

Phase	Deliverable	Start	Duration
Initiation	Project kickoff	July 2001	4 months
Initiation	Project kickoff	July 2001	4 months
IBM HDN
Preparation (IBM)	Resource & financial planning	September 2001	4 months
Planning (IBM)	Technical readiness	January 2002	3 months
Design (IBM)	User & system design sessions	March 2002	3 months
Development (IBM)	Product customization	May 2002	3 months
BCCA CAIS
Planning	Resource & financial planning	September 2002	3 months
Design	Data, process and system design	December 2002	2 months
Development	Customization and interface development, testing	February 2003	5 months
Deployment	User training, system installation, evaluation	July 2003	6 months
			33 months

A more detailed view of the project sequence and major activities is contained in the project plan (Microsoft Project) archive.

7.2 Effort

Throughout the project the amount of effort expended was collected through timesheets and other data. This information was maintained to verify project tracking vs. deliverables and to provide a useful data source for future project estimates.

Two primary measurements are of interest; the labour expended against project phases and the "burn rate" for a project of this scope and magnitude.

Partner	IBM Days	C&W Days	VIHA Days	BCCA Days	Total Days	% of total
Phase
Project Management	137.1	550.8	18.2	2.1	708.2	28%
Initiation	54.5	93.9	13.87		162.27	6%
Planning		78	0.9	3.8	82.7	3%
Design	41.7	192.1	18.5	30.5	282.8	11%
Construction	180.8	702.1	42.4	140.6	1065.9	42%
Evaluation		241.3			241.3	9%
Total to end of Q10	414.1	1858.2	93.87	177	2543.17	100%
% of total	16%	73%	4%	7%	100%

By most industry normal benchmarks, the distribution of effort for a research and development project of this magnitude would be expected to be approximately 20% project management, 20% planning design, 50% development and 10% deployment.

For the overall project, the burn rate was calculated as $660/day averaged over the project until the end of the Q10 accounting period.

This rate accounts for labour costs only, calculated from internal burdened labour and external labour from invoices received.

7.3 Costs by Project Phase and Timeline

Table 7.3 Costs by Project Phase and Timeline

7.4 Costs by Project Category

Table 7.4 Costs by Project Category

7.5 Sustainability

The Bridges system will be maintained for a minimum of 12 months starting October 1st, 2003. The system is supported by C&W salaried Staff and VIHA salaried staff within the normal context of the IS Department's systems support role. The system is a contiguous part of the BCCA operations and is also maintained on that basis.

Funding for ongoing operational support is provided through the staffing and operational budgets of C&W and VGH hospitals.

8. Lessons Learned, Recommendations

8.1 Contract with IBM

Negotiating a contract of this type, without the flexibility to reset and renegotiate as a result of a changing business climate, introduces a significant financial risk to all of the partner organisations. Contract terms should be included that provide an opportunity to validate the business requirements and constraints as new information becomes available.

Establishing a vendor relationship based on a limited understanding of both the product capabilities, and the business requirements puts the vendor and the client under considerable stress throughout the life of the project. Any contract should include a clear expression of requirement and capability. Where neither is known, an explicit provision in the contract and pricing structure should declare when and how this discovery and negotiation should take place

8.2 Project Management

This project was initiated without a Charter, without a useful Project Plan and without a validated budget. The actual sequence of events that occurred prior to the project initiation, severely constrained the technical teams from exploring alternative solutions that might have uncovered potential cost savings or technical improvements. Fundamentally, there was no opportunity to test the fit of the product or the proposed approach prior to concluding the contract arrangements; this should be a basic requirement for all projects within the organization.

While any vendor should be encouraged to share their knowledge and experience, that vendor should not be responsible for creating internal budgets or internal project activities. There is a real conflict of interest established when a vendor is required to profit from their business and the financial planning for the project is handled by the same vendor. For future reference, a policy to this effect should be established to prevent this type of situation in the future.

Due to the limited planning that took place before initiation, the actual resource requirements that defined the budget were found to be unreasonably optimistic. This was in part driven by the funding formula that recovered 50% of the actual internal staff costs. When it became apparent that the resources were unavailable or unnecessary, the budget was unachievable. A budget and feasibility review at the end of the design stage would give all parties an opportunity to understand the financial and technical risks more clearly. A formal review of this type should be included within the project plan for design-development projects of this type.

During construction, any development project will uncover minor design issues or improvements to the solution. This new information must be clearly communicated to all parties in a timely manner or there can be an immediate impact on the budget and project risks. It is recommended that for those projects where there is a "vendor team" and an internal project team, that a collaborative and effective team relationship is established very early in the project. Unfortunately in the case of Bridges this took several months before communication issues were resolved.

8.3 EHR & Evaluation

The primary issue that has surfaced during construction is the question of how to uniquely identify a patient record that may exist under many guises in a wide range of clinical systems. This is one of the learning experiences from this project, but for other EHR related projects, this question needs to be addressed very early in the feasibility study. The key to the solution is to evolve a single Master Patient Index for the Province, with other systems interactively accessing data from the master. The PHN is part of this solution, but until a specific strategy is developed to clean up the myriad of inaccurate patient databases, the uniqueness issue will not be resolved.

The second learning experience is related to document standards. Unfortunately each organisation maintains clinical documents to meet their local standards and objectives. An EHR however must accept a wide range of information in many formats, and, if it is to be effective, the EHR must then present this information in an organised way to the clinical user. The Bridges project has defined a set of clinical documents that are of immediate value to the clinicians involved with Pediatric oncology in two clinics. Adding more clinics to the EHR adds the potential for more document types and reduced legibility in the chart.

For future EHR initiatives it would be of immense value to establish common document types, names and formatting standards within the project scope. For example, the recently published HL7 committee's CDA and Document Standard definitions would be applicable to most EHR projects. An alternative trend, and one that is being explored in the Bridges project is to capture the actual data inside a document using XML and use that within the clinical chart. If this proves to be feasible, formatting and presentation standards for documents would become unimportant.

Prioritisation of clinical information in the chart is often a matter of individual preference by the medical Staff. Given the range of documents available and the various medical disciplines, it becomes a very difficult task to develop one electronic chart that satisfies everyone's opinion. While this may never be fully resolved, at the early stages of an EHR/CIS project, some standards and expectations should be set early.

In the case of Bridges we are dealing with critical and urgent care issues, for patients with a well-documented history and frequent visits. In this case, medical Staff are most interested in the last two, or at most, three clinical events. Rather than focussing on building a fully comprehensive chart covering years of documentation, the emphasis for this type of EHR should be on delivering the essential information in a clear and intuitive way.

8.4 Teamwork

With any project involving multiple organizations, there will inevitably be some rivalry and territorialism. Such was the case with C&W and BCCA, largely due to the personalities and interpersonal issues that existed between BCCA and C&W Staff. While not unusual, it must be stated that these difficulties were, and still are, a major reason why the Bridges-CAIS system has fundamentally failed in its intent and is unlikely to reach its potential.

Teamwork implies sharing a common goal. In the case of this project, the Bridges goal was not accepted by the BCCA team, nor their management. Without that cooperative support, a cross-organizational project of this type will always struggle to meet its goals. This is without doubt the most significant risk factor encountered during the course of this project and every effort should be made in future activities to gain the genuine support of all of the staff in all of the organizations involved.

8.5 Health Canada Process

The Health Canada funding formula encourages a project to maximise spending (to recover the maximum possible from Health Canada) while at the same time requiring the project fill the maximum amount of time available. In other words, there is no incentive to complete the project under budget or ahead of schedule.

The Health Canada project teams have been exceptionally helpful and supportive throughout the project lifecycle. However the Bridges project team and presumably other CHIPP projects would benefit from a more structured approach to collaborating and sharing information between the various projects. There is some value in a shared WEB site or similar resource, but a more useful format for this would be a seminar session held over several days, with the opportunity for the project teams to network and meet each other.