Organ Transplant Tracking Record System Analysis and Design
Health Care System Analysis and Design
The OTTR system at UHN’s Multi-organ Transplant Program is widely considered to be a resounding success. Systems analysis and design played a central strategic role...
  • Project Year
  • Creator Name
    Kevin Grant
  • Organization
    West Park Health Care Centre
  • City
  • Creation Date
    30 November 2012
  • Modification Date
    13 March 2021
  • Version
    30 November 2012


The Organ Transplant Tracking Registry (OTTR) is the IT solution implemented by the Multi-Organ Transplant Program at the University Health Network for the management and follow-up of transplant patients. The increase in prevalence of many chronic diseases susceptible to be treated – and in many cases, cured – by organ transplantation, and the improvement in survival rates achieved by better immunosuppressive therapy led to mounting numbers of patients that needed to be followed by the program. Not surprisingly, paper based methods became inefficient, and a technology-based solution was sought. Eleven years after its initial implementation, OTTR has proved to be a resounding success among care providers in the Multi-Organ Transplant Program thanks to a well executed system analysis and design process. The following discussion about the specifics of this process was elaborated by integrating the experience of technology specialists, care providers, and research personnel, who provided a 360 degrees view of the scope of the system.

State of the Nation before Health Informatics

Before the OTTR system was in operation patient information was recorded using hand-drawn spreadsheets. The need for a computer-based solution became apparent because of improvements in surgical techniques and immune-suppressant drugs translated into higher survival rates. There was a dramatic increase in the number of patients being followed by the transplant program (Levy, 2012). Manual data collection became time-consuming, hard to retrieve, prone to errors and insufficient to meet health care demands. Patient care was being negatively impacted and UHN decided it was time to begin developing a technology-based solution.

First Steps towards IT Adoption: Milestones and First Steps

Given the budget of the project it was decided that a software solution would be purchased and no custom built software would be built. The team expended significant effort evaluating different software solutions and select the vendor carefully to ensure the system would meet the needs of the end-user.

A project milestone schedule was developed (Appendix B). The vendor and software review began in 1998, was selected in March 1999, was tested in September 1999, and went live in January 2000.

A heavy emphasis was placed on knowing the end user and understanding their needs so what was implemented would be adopted and improve efficiency. The project was very successful, focused on the end-user from day-one, and this was a major contributing factor to the overall acceptance.
System Requirements and Technology Summary
This section will briefly discuss the most important system requirements for the OTTR system. Many of these technology features are related to reliability, security, health care standards, and end user usability requirements.

Privacy and Security Requirements

The OTTR solution had a number of security and privacy requirements that were essential and non-negotiable during the software selection and implementation phases:

  • Limits on data import and export of secure information (specific security rules, logging and audit trails).
  • There was a requirement to allow custom Microsoft Access databases to be able to connect to the Oracle OTTR system (required special security implementations).
  • The OTTR system has centralized security settings that needed to work with Microsoft Access databases and end user workstations.
  • SPSS is used to perform statistical analysis on OTTR data which often has to be transformed manually and required strict security rules to ensure only aggregated data was generated and no patient-specific private information was exposed.

System Robustness

The OTTR system had to be robust and built on a solid technology foundation. Because the system was primarily a health information system is had to be built on robust database technology.

  • Oracle database: required for robustness, security reasons, compliance with health Infoway health care standards, and ability to hot-swap databases for uninterrupted system maintenance (Oracle, 2012).
  • Backups: daily backup every night, full back up every week.

Security and Reliability

Health care demands high availability, high reliability, and unprecedented safety. The OTTR system had very high security and reliability design requirements that are typical for any health care system in Canada.

  • 99.99% availability: There has been a total of 4hrs down time in the history of the system (in operation for over 10 years).
  • Offsite data centre: For security and safety reasons and for 99.99% availability.
  • Redundant power: For 99.99% availability during power-loss events and emergencies
  • RAID5 data redundancy: Hard drives are backed up to mirror drives in real time and can be hot-swapped if they fail without disrupting operations in any way (Wikipedia, 2012)

Health Data Standards and Infoway Standards Compliance

OTTR did not exist as an island and it became a powerful system when it was able to collaborate and communicate with other health care systems at UHN using health data standards and middleware.

  • HL7: Oracle health information data interchange to HL7 format was required for Infoway standards compliance and interoperability with the UHN's EHR system (Infoway, 2012).
  • Middleware: coordinates information exchange to and from OTTR from different systems in UHN and their EHR system.

Technology Limitations

The OTTR system has a long and successful history spanning over 10 years. However, as any other system, there are limitations to its performance. These include the following:

  • The lack of integration with Trillium Gift of Life Network (TGLN), the governmental agency in charge of the distribution and allocation of organs across the province, forced double data entry into both databases. This was time consuming and a source of human transcription errors (TGLN, 2012).
  • OTTR is only compatible with IE6, and this is holding back UHN from migrating to newer, more stable, secure versions of the IE browser. Software upgrades have been slow, due to three main reasons: (1) standard software upgrades are estimated to require approximately three weeks of downtime, which is an amount of time the Transplant Program cannot afford to dedicate to this activity, (2) OTTR upgrades require updated background software –in this case, Oracle Databases– which took around one year to update by the hospital’s IT support service (SIMS) the last time it was required, and (3) the Transplant Program does not take on any upgraded version that has not proven to be successful in other institutions first.
  • The OTTR system is very efficient at integrating with and retrieving data from other platforms, however, data queries are difficult to create and are limited in complexity.

Because of the age of the system, the user interface is beginning to show its age and has become dated and no longer adheres to the current user interface standards for health care software. An updated user interface would make the application more user-friend and enhance the user experience, which would improve overall productivity and reduce the training costs.

Organ Transplant Tracking Record System Analysis and Design




Contact Details and Map