Informatics 97nov5

Journal of Informatics in Primary Care 1997 (November):13-15


Temple House Surgery Computer Program

Dr Prit Buttar

Temple House Surgery, Keynsham, Bristol, BS18 1EJ.  Tel 0117-986 2406, Fax 0117-986 5695, e-mail

Last year, after a particularly troubled time with our current clinical software suppliers, we decided that perhaps it was time to consider changing systems. We started by listing the disadvantages of our existing system:

  • an old-fashioned, slow, text-only interface
  • a very unfriendly operating system, that does not allow us to run any software other than that provided by our supplier
  • high costs for support, which is rarely as good as we would like it to be
  • unreliability

This automatically gave us a list of things that we wanted to avoid at all costs in a new system, and we added some further suggestions:

  • the capacity for paperless practice, if and when we choose to implement it
  • a system that fits in with our needs, rather than one that forces us to adapt our working practices in order to get along with the software

After a review of the existing commercial systems, we concluded that there was no system in existence that did not have substantial limitations in one respect or another. So, we thought, how about writing our own system?

We started by asking various people for their views and ideas. The information technology people in our Health Authority were very helpful and gave us a list of contacts within the NHS; almost without exception, though, these contacts proved to be extremely pessimistic about the whole project. We sought the views of people both within the NHS and people completely outside medicine; generally, the latter group were both more encouraging and constructive than the former group, who either seemed to regard our intentions as extremely optimistic or completely mad. Not in the least disheartened, we started planning our new system.

The original idea was to use components of Microsoft Office, but this phase of the project foundered on two issues. The first was speed – any Microsoft Access database was going to have severe performance limitations, and this was felt to be unacceptable. The second was rather more fundamental – the Access indexing mechanism is not case-sensitive, which would have made implementation of the Read Code system impossible.

A little bit of research followed, and we decided to try writing our system using Borland Delphi. This programming system allows full use of Paradox database tables, and has proved to be both very powerful and extremely easy to learn and use. Although our programming experience was very limited, we managed to go from never having written a line of code in Pascal – the language used in Delphi – to a working version of our program in a mere four months.

The program that we have created is, as far as we are aware, the only clinical system designed to run under Windows 95™ / Windows NT™. We use NT on the main server, a 200MHz Pentium; most of the other machines are 133MHz Pentiums, with a mixture of 486 DX2/DX4 platforms also connected. All workstations run Windows 95™. The program has a fully configurable appointments system, and was written to RFA 3 specifications.

Several parts of the program have been implemented by using ‘off-the-shelf’ components. We will use the eBNF as our prescribing reference, though the program contains a configurable formulary. Similarly, we will use a Read Code browser provided by CAMS, rather than programming all Read codes into the system. Users will be able to type in Read codes directly, or select them from configurable ‘folders’ within the program – for example, common codes such as ‘Hypertension’, ‘Maturity onset diabetes’, etc., can be stored in a folder entitled ‘Common conditions’, and these Read codes can by inserted into patient records as required. The screen-shot below shows the entry of a new Read code item. The top half of the screen shows two grids, one on the left listing the Read code folders, and one on the right showing the contents of the currently selected folder. To enter a Read code, simply select one from the appropriate folder and click the ‘Apply’ button. Alternatively, details can be typed into the boxes in the lower part of the screen, but it is obviously far faster to use the folders. This will result in a selected subset of Read codes being used, which we hope will result in more coherent entry of data.

Adding a new entry

Another item that we have decided not to write ourselves is the Links module. We have decided to buy the VAMP stand-alone Links program, and will configure our program to identify new items of service, registration details, etc., and to write them into a text file; the VAMP program will then read this text file, prepare and conduct transmissions, and write incoming data to a similar text file, which can then be read by our program. In future, we will use a similar arrangement for pathology links.

The main disadvantage of this system is that we are very much ‘on our own’. Any problems that arise will have to be fixed by ourselves, with whatever help we can obtain. In this respect, we have already benefited greatly from a semi-formal network of Delphi developers, one of whom has very kindly helped us with converting our existing data into its new format. The advantages of our new system, though, are numerous. We have devised a system that precisely suits our needs and the way in which we work, and all members of staff have contributed to its design – for example, the reception staff played a large part in designing the appointments system. This level of ‘end-user input’ is probably unique. We will no longer have to pay large amounts for support services that often fail to deliver, and have in place an excellent network of up-to-date computers, with hardware support by a local firm that is literally next door to the surgery. Even if our system founders, the investment in hardware will stand us in good stead for implementing any new system.

The cost of the system has been substantial, mainly revolving around the hardware. The new cables and hub cost a little over £2,000, and purchasing nine new Pentiums and upgrading five old 486s to 16Mb RAM cost about £12,000; this figure includes the purchase of Windows NT™ server V4, together with enough licences to set up the network. Software costs have also been considerable: a multi-user licence for Delphi was required, together with a multi-user licence for the eBNF and a single-site licence for the Read Codes system. Links costs are additional to this, but are currently 100% reimbursible. So, the cost overall has been about £15,000, which is 50% reimbursable. There is also a ‘hidden cost’, the time spent on writing the program – this was done by employing a locum once a week, and spending long hours in the evenings and at weekends and holidays. Nevertheless, the cost has been substantially less than that of buying any commercial Windows™-based system. Also, given that there will be no heavy annual software support costs, we estimate that we will be ‘in profit’ compared to our previous system within three years, and will have all our new hardware in place into the bargain.


  • There are currently no refbacks.

This is an open access journal, which means that all content is freely available without charge to the user or their institution. Users are allowed to read, download, copy, distribute, print, search, or link to the full texts of the articles in this journal starting from Volume 21 without asking prior permission from the publisher or the author. This is in accordance with the BOAI definition of open accessFor permission regarding papers published in previous volumes, please contact us.

Privacy statement: The names and email addresses entered in this journal site will be used exclusively for the stated purposes of this journal and will not be made available for any other purpose or to any other party.

Online ISSN 2058-4563 - Print ISSN 2058-4555. Published by BCS, The Chartered Institute for IT