Case Study – Andrology Lab – Hammersmith Hospital

Case Study – Andrology Lab – Hammersmith Hospital

Over the past few years the Andrology Lab at Hammersmith Hospital has been deeply involved in the development of an electronic Sample Tracking and Laboratory Management software system that is now commercially available.
We discuss the benefits that this software has brought to his laboratory with Dr Kevin Lindsay, Principal Clinical Scientist, of the Andrology Department at London’s Hammersmith Hospital NHS Trust.

Many priceless collections of samples are entrusted to simple ‘pen and paper’ systems with all the obvious risks that entails.  Consequently significant numbers of irreplaceable samples are lost (or misplaced) for a number of reasons.  These include transcription errors, poor handwriting, incorrect placement in the storage facility or incorrect recording of the location.  The financial and human costs of such lost samples, as well as the risk of litigation, can be high.  Furthermore, auditing paper-based systems is extremely difficult and very time consuming, so typically is not done as often as it should be.  This makes it virtually impossible to meet the ever more stringent requirements of the various monitoring bodies and authorities.

Thus there has for some years been a general drive towards electronic systems designed to eliminate as many of the human errors as possible.

Hammersmith, in common with many other andrology laboratories, started the move to a computer based system by using a simple spread-sheet running alongside their paper-based records.  This was proving inadequate, especially as the number of samples grew, and in fact was adding nothing to the paper system.  Thus a few years ago Dr Lindsay set out to install a more reliable and more complete electronic system, which would eliminate the problems they were having, based on a database rather than a spreadsheet.

There were several software packages available on the market, but none which provided a complete solution to manage samples, the sample source (in Dr Lindsay’s case – the patient) and the storage area.  Equally, the mapping functionality available (showing where in the container a sample is located) was very simplistic. Dr Lindsay felt accurate pictorial mapping of the sample storage would be absolutely essential when carrying out an audit trail in order to comply with regulatory bodies.  So another requirement was the ability to create virtual containers of different shapes and sizes to show where in each container the samples are actually located.  Past experience had shown that with sample trays of irregular shapes and sizes (e.g. triangular) two people could often define the same physical location differently.  Thus by defining a virtual world he sought to eliminate this variability in the physical world.

After considering what was available Dr Lindsay concluded that the only way forward was to be involved in developing a new bespoke software system.  He approached the in-house IT people who, although indicating that they could develop such a system, were unable to commence the project within the required timescale.  Equally, suppliers of the packages already available were unwilling or unable to make the enhancements that he required.

Experimenting with the simple spread-sheet system and reviewing other packages had helped Dr Lindsay define some of the features required as part of the new software.  A user had to be able to easily navigate between samples, the source of the samples (patients) and the storage area.  This would enable questions such as “show me all the samples for a given patient” or “show me where in the container a specific sample is” to be answered.

With 20,000 samples on the old spread-sheet system data entry mistakes could (and did) easily occur.  For example, more than one sample could be entered as having the same location.  The new software would need to automatically prevent mistakes like this from happening.

Due to the possibility of cross infection, a requirement was for the software to be able to manage different types of samples with different diseases.  There had to be a mechanism to control what type (or types) of samples could go into each container.

The software would need to support multiple users, either sharing samples or working with their own samples.  As such, it was important the system be able to assign different rights to individual users or user groups.  This involves defining each user’s rights of access to different samples and storage locations – specifying exactly what they can and cannot do.

As with any multi user system it was important to incorporate full auditing functionality and be able to see all the changes that have happened to a sample over its lifetime.  The requirement was to show for any particular sample – who had done what, from where, and when.

As requirements can (and do) change over time it was important that the system would be flexible enough to adjust to the needs of the lab, for example easily add additional storage or extra fields of information.

Having defined his vision, Dr Lindsay approached a software house (MediData Systems Limited) to discuss the possibilities. Together they wrote a specifications document.

After the specifications document was agreed, development began.  Initially there was regular and extensive consultation to ensure that any questions were answered early in the development process.

Various prototypes were examined and the overall look and feel was changed a few times to achieve something that was logical and comfortable for users.

During the early development stages both the book and spread-sheet based system were used in parallel with the new system. Initially bugs and problems were to be expected, but as the development continued these were reduced to produce a stable and workable sample management solution.

Originally the project was to take around six to twelve weeks to complete and install a far more basic version of what has now been developed.  Over time, the scope of the project was gradually extended more and more, so the full program has actually taken over four person-years to complete representing an overall investment of around £150,000.  Further enhancements are also planned.  During the first couple of years of development other packages on the market were monitored.  As there continued to be nothing available with anywhere near the functionality of ItemTracker, a decision was made to commercially exploit the package.

Once the core functionality was in place and working, work started on additional functionality to make the software a more complete laboratory management system.

The first additional element, identified quite early, was integration with an electronic ‘reader’, specifically bar-coding, to eliminate hand-writing and transcription errors.  Today the Andrology Lab at Hammersmith Hospital uses 2D bar codes as these can be reduced to a very small size (8mm by 8mm) which is ideal for small sample tubes.

Other advanced functionality introduced later includes document scanning and handling, mail-merge and advanced auditing.

Traditionally, forms filled in by patients were kept in a filing cabinet.  To later retrieve any of those forms meant going to the correct filing cabinet and retrieving the form.  Now, all forms are scanned and associated (linked within the software) with the patient so the form can be easily recalled without going to the filing cabinet.  To comply with inspection and regulatory bodies, the original signed document must still be kept in the filing cabinet.  However, at Hammersmith scanned documents are immediately consigned to long-term ‘cold’ storage thus releasing laboratory space.  Dr Lindsay questions the need to keep all this paper and feels that the regulators will relent at some stage.

The original way of auditing was a very time-consuming process involving two people – one removing the sample reading out the details, and another writing those details down.  Now, using bar-coding, one person can audit a whole container in a matter of minutes.

Another great time-saving with the new software arises when having to audit patients and mail letters out.  Previously it was necessary to manually fill in the details for each letter to be sent to a patient.  Now, using the mail merge functionality, it is possible to simply write a template and tell the program to print out a letter for selected patients using the template.

When auditing, the software allows double-witnessing, whereby after one lab member has made a change to a sample, another lab member must verify these changes before the sample can be further changed.

Dr Lindsay said, “We are very happy with the current software and pleased to see that the program is now selling to laboratories around the world.  We see growing market and regulatory demand for such systems and having helped develop ItemTracker we are proud to show potential new users how the system works here at Hammersmith.”  “Future developments I foresee are first, a link to patient biometric data that will eliminate the need for retention of signatures/paper documents, and second the replacement of bar codes with RF (Radio Frequency) identifiers built into the tubes” he continued.

In conclusion, Dr Lindsay warned, “The cost of one error can easily exceed the cost of installing a system; so why take risks when a system that is even cost-effective for single users is readily available.”