Electronic Patient Records

The Toronto Star reported that the CEO of Ontario’s eHealth organization, Sarah Kramer, has been fired. Sarah has been blamed for a host of audit points raised in an audit of spending habits on the $647M CAD (to that point) project. Among the points raised was the award of a contract for software development to IBM without a SOW. We reported on that story October 5, 2009 (see the news story). A recent study by University College London, and corroborated by Harvard Business School, casts doubt on the value of the entire program.

An article by Ian Grant in today’s (December 16, 2009) edition of ComputerWeekly.com reported that the study revealed that paper records are more efficient for clinical interpretation of patient records than EPRs (Electronic Patient Records). The study also found that small localized EPR systems can be more efficient than large centralized ones. The Ontario eHealth program was initiated to centralize smaller local systems and paper records into one central EPR system. This result seems to indicate that not only is the program hampered by some poor program management and project oversight but also that the program’s key goals and objectives were not well thought out. Granted that the UCL study was not initiated until well after the implementation phase of the eHealth program and the study was conducted in Great Britain, but it would seem to me that much of the information gathered for the study was available to eHealth and could have been studied before planning the program.

Since well over $600M CAD has already been spent on this program its too late to redefine the scope of the program but it does tend to make one feel sympathy for ex-CEO Sarah Kramer. Its difficult enough trying to follow good project management practices and deliver the project when your business/executive sponsor (in this case the minister and deputy minister) insist on making all key decisions themselves and ignore project management best practices in the process. It becomes impossible when the solution can’t possibly meet the project’s goals and objectives. The program started with Smart Systems for Health Agency (SSHA) back in the Harris era. The program at that time was focused on the conversion of patient records into electronic form, or EPRs. Sarah came on board in September 2008 as CEO when SSHA became eHealth Ontario and the program was expanded to deliver a centralized IT system to manage EPRs. It’s difficult to say what influence Sarah had over defining the scope of this program but I believe it is fair to say that it wasn’t great, given that Ron Sapsford, the deputy minister, approved contracts.

There is a cautionary tale here for program and project managers. To be successful in any project or program you must lead one which will produce the deliverables needed to solve the customer’s problem. In eHealth’s case the objective was to deliver a system which standardized patient records and make them available to the doctors and clinicians who need them in real time. The solution defined was a centralized system which collected and dispersed EPRs in the health care community. That solution will cost tax payers roughly $1BN CAD if the program stays on track and will end up delivering a system which likely won’t meet the stated objectives (if the study results are accurate). The next time you are handed a program or project which already has defined objectives, scope, and objectives, take some time to review the business case and satisfy yourself that the objectives and approach will meet the customer’s needs. Do some digging around on your own if you can’t satisfy yourself that the stated approach and solution are right. Don’t be afraid to raise a yellow flag (your doubts amount to a caution, not a 5 alarm blaze) with your sponsor. There may be information that you haven’t been exposed to which will verify the approach and solution. If that information isn’t available and the solution and/or approach were chosen based on someone’s hunch, because someone else is doing a similar project, or because "that’s what the (fill in the job title) wants”, and your sponsor is unwilling to invest time and effort into validating the project, don’t be afraid to walk away. Sometimes its better to avoid the train wreck altogether rather than try to successfully deliver a project which can’t possibly deliver the solution the customer needs.