RISC OS at the Vets

David and Andrew Vawer describe the use of RISC OS machines in modern veterinary practice at the Downland Veterinary Group

DVG logo


A few example files in Draw format are provided with this article. They may be accessed directly by using the icons to the right.
Zip See


When the Downland Veterinary Group wanted a computerised management system in 1994 to control all aspects of the practice business, from managing client and patient records to controlling stock, labelling prescriptions, and supporting secretarial and accounting activities, they looked very carefully at the systems which were on offer at the time. The partners found them in most cases to be clumsy and slow, and to involve long training and be unreliable, despite the promises of the salesmen. Having had stock and dispensing controlled by Archimedes A440s for some time, running custom-designed software written by one of us (Andrew Vawer), and having been very pleased with the results, it was natural that they should ask his opinion on having software written to their specification to do the larger job properly. Andrew agreed that he would look into the proposition, and the Andysoft Veterinary Management System was duly born, utilising Risc PC 700s and A7000s, and runs with great success.

Perhaps we should introduce ourselves first, and then go back to the history a little and explain how all this came about.

About ourselves

David Vawer (BVSc MRCVS) qualified as a Veterinary Surgeon in 1973, and moved with his wife to the Downland Veterinary Group in Hampshire in the Spring of 1976, when Andrew, David's son, was just 6 months old. David became a partner in the Group in 1979. Their first BBC Model B was purchased in 1981, when CJE Micro's was still operating from Chris Evans' front room, and both learned to program in BBC Basic as a result of trying to get magazine listings to run.

Andrew Vawer (MA VetMB MRCVS) became quite an accomplished programmer and had his first program published at the age of 11 in A&B Computing. He has since written many programs and published articles. Computing remained a hobby, however, and Andrew entered Cambridge University, qualifying as a Veterinary Surgeon in the Summer of 1999. He joined Downland Veterinary Group at the Chichester branch, where he currently works.

Downland history

The Downland Veterinary Group was founded in 1946 in Chichester in West Sussex. It has grown steadily, and currently is one of the major small animal practices in the south of England. There are now three major centres and two smaller branch surgeries. The practice is currently controlled by five partners, and they employ a further ten assistant veterinary surgeons.

The original practice in Chichester consists of a partner and two assistants (one of whom is now Andy himself). This is also the base of the main overall practice administration. There are eight additional members of staff at Chichester as backup.

The Veterinary Hospital in Bognor Regis is also headed by a partner, who has five further veterinary assistants, including consultants in Imaging (i.e. X-rays and Ultrasound), Cardiology and Orthopaedic surgery. There are no fewer than eighteen nursing, reception and secretarial staff at the hospital.

The largest of the main branches is at Emsworth. There are three partners, and three further assistants. Emsworth partner Martyn King is one of the highest qualified Veterinary Ophthalmic surgeons in Britain. David is one of the other partners. There are fifteen nursing, reception and secretarial staff at Emsworth.

The Branch surgeries at Havant and Barnham are staffed by vets from Emsworth and Bognor respectively, but have their own lay staff of receptionists and nurses.

This is a large business, with a significant turnover, which aims to keep itself at the forefront of modern veterinary practice. Administrative efficiency is paramount to the provision of a quality service to its clients.

The computer revolution

Way back in the dim and distant past of 1986, the practice, like the vast majority of others, used a card index system to maintain case records, payments and so on. It became evident that the control of over 500 drugs and dispensed medicines, with respect to accurate and consistent pricing, was becoming a problem. Andy was asked to write a program which would create price lists in a variety of formats for use by vets and reception staff to be able to price properly. This was done with an old BBC Model B and a dot matrix printer. Wholesale prices were put in, and the program did the rest. A spreadsheet could have been set up to do the same thing, but it would have been far less user-friendly.

With the introduction of new prescribing laws relating to the labelling of drugs, Andy expanded this basic system to comply. It was 1988, and David conned his wife into buying him a new Archimedes for his 40th birthday. Andy monopolised it to create a complete stock control, pricing and drug label printing program which more than satisfied the law. The practice ran the system at each of its surgeries with A440s and continuous tractor feed labels on a 24-pin dot matrix printer.

One of the steps which Andy took helped to set up the database for the future system, although it was not evident at the time. The drug label had to have the name and address of the client clearly printed on it. To create this manually every time was a bore, so Andy added a database of names and addresses to the program, and the client was identified by a number preceded by a #. When a member of staff entered a new name and address, the system allocated the number which was noted on the client's record card. The dispensing job became very easy.

The basis of the current stock control system is still very similar to this original, though handling more than twice the number of entries. The window which controls stock is a combination of the two windows which controlled the old label printer.

The problem with a record card is that it can and will disappear as soon as you take your eyes off it. (This only happens, however, if the information it contains is truly vital.) As the practice grew and became more specialised, the need for a proper management system became pressing. As such, in mid-1992, discussions with Andy began on the creation of such a system. Although he was still at that time a sixth form student, he had been financing his computer hobby with a number of programming feats to try to cover his costs.

The needs for the system were, on the surface, straightforward:

  1. There was a need for there to be details of the client and, linked to this, details of each individual pet.
  2. Each pet had to have an individual case record, to summarise all details of examinations and treatment, drugs administered and dispensed, lab work and surgery carried out etc., and the costs incurred.
  3. The costs had to be detailed in an account which was summarised and printed out for the client.
  4. Payments had to be recorded, debited and printed to a cashbook, which noted not only the payment but the method: cash, credit card or cheque.
  5. Unpaid accounts had to be registered together with any further accounts sent in an aged debt register.
  6. Any dispensed item had to be dispensed, legally labelled, from any computer, the label being printed in the dispensary for the dispensing nurse, and the stock levels of the item had to be checked and decremented. If this was not done, the client could be charged for an item when it was not available to be dispensed.
  7. All surgical procedures had to be itemised in separate data files for simple accounting.
  8. The whole system had to be tamper-proof, with user password protection. Once a record was entered, it had to be impossible for even an informed user to alter the details in the record. Client records have to be produced in courts of law, and are not acceptable if they can be altered like a word-processed document.
  9. Speed was essential to save staff and clients from twiddling fingers while they waited for things to happen.

There is a common misconception that, to computerise one's business enterprise, one has to follow a single route which uses the same software packages and interface as everyone else. This is known as the 'industry standard'. In fact, however, when looking at a number of software packages and networked systems for specific jobs in commercial use, a number of points become evident:

  1. The programmer has utilised the system to offer his own 'front-end' rather than the graphical interface provided by the manufacturer. PC World sells Windows systems, but look at the displays on their tills and stock systems. See what interface exists in your bank, travel agent or insurance brokers. There is often not a Windows environment in sight.
  2. The computer network is very often used for the specific purpose for which it was installed, and runs little or no other software. In fact, there is a great fear that the introduction of software from outside will introduce viruses into the system, which will collapse the whole enterprise.
  3. The users curse the system for all sorts of reasons: speed, inefficiency, regular breakdown and, particularly, the complaint that "the bloke who wrote this $%!*& doesn't have to use it."
  4. Secretaries and similar employees who do not have to use a networked computer, and have access to the general program system, have stand-alone computers to run their document processors, as the networked ones are too slow.

When these points are taken into consideration, the idea of an 'industry standard' becomes rather silly. A system user wants software that does the job reliably, whatever the badge on the front of the box, and causes them the least interference and stress as they carry out their job.

There is no reason whatsoever that IBM- and Microsoft-compatible machines are more acceptable than any other when looked at in this light. The operator wants a keyboard and a screen, and as easy a life as possible. As a result of the discussions carried out along these lines, we opted to continue using the (then) Acorn machines.

There were a number of reasons.

Opting for Acorn

All Acorn machines have the operating system in ROM, making them more reliable (e.g. far less vulnerable to computer viruses) and enabling the A7000 client stations to be disc-less. Thus they are simpler than typical PCs, and more like network computers. They also do not have big, noisy fans or hard discs to distract you while trying to listen to subtle changes in a patient's heart!

The Archimedes computers had never, ever broken down, and in fact had hardly ever even 'hung up'. The system had to be reliable and able to be back on line quickly if there was a problem. Any problem also needed to be sorted out by a middle-aged lady receptionist who was under pressure and not computer literate, though an effective typist. Most problems can in fact be sorted out by turning the RISC OS-based computers off and then on again, without getting rude messages as to what one should have done (but couldn't). A little education was necessary to get the staff to understand that they had to have an idea which computer needed resetting, however.

Speed of access to records was vital. Some of the available systems could take 20 to 30 seconds to open a file in the consulting room. Typically these were, at the time, 120MHz Pentium PCs running Windows NT. This we considered unacceptable. In fact, we got access which appears instantaneous to most people, but was just less than a second. This went turbo-speed when StrongARM was introduced later.

We needed a system which looked familiar and friendly. Many of the systems available had cluttered windows holding masses of information in black and white in frames. Acorns, however, had these lovely windows which displayed the information clearly and in an attractive manner. They were easy to read and so less tiring for the operator. We were also able to make the pet record look just like the original card format. Things appeared where they always did, so there was little resistance to the change.

The system had to be simple to use. A number of practices which we contacted were still using their old systems of card indices etc. six months after installing £15,000 networks. By contrast, our Havant branch went solo just a week after we installed our own system, without even having Andy present to look over their shoulders.

Backing up with efficiency

Backup of data was vital. The original system was used up to about 18 months ago, and consisted of removable hard drives (from Pineapple). We used two of them which we alternated. Backup was automatic and very easy, with Alarm being set for repeating tasks. One backup is made during the lunch hour, when use is minimal; the other after the close of the routine surgeries in the evening. The server computers display a window prompting the changing of the disc once backup is complete. David once contacted another practice for notes about a referred case. He was asked to ring back later as the computer was off-line while it backed up. We backup in the background, and there is no interference with normal running whatsoever. We have now converted all our systems except the Chichester one to backup onto Jaz drives, but the method is still the same.

It was absolutely essential for there to be top quality backup for the hardware and network. We were lucky to be in striking distance of AlSystems Ltd. Keith Faulkner, Gary Partis and the others were invaluable help when it came to installing and running the system. We were sad to lose them with the demise of the company, but have since had very reliable help from Chris Evans at CJE Micro's in Worthing.

Devising a personal system

The accompanying screenshots show the way in which some of these criteria are implemented in practise. The basis of the system was created according to the above plan, and the beta version was installed as a three-computer network at the Havant branch, as this was the smallest branch. Careful backup was maintained on the old record card system, just in case, for some time, but we have never referred back to it. The current Havant system consists of five computers: two Risc PCs and three A7000s.

There were problems, but they were ironed out remarkably quickly, and it was not long before the Emsworth vets were complaining that they wanted the system at their branch, as Havant's system was so easy to use. An eight-computer network which was considerably upgraded was installed there early in 1996, and the other sites followed rapidly. All members of staff made notes of any clumsy or difficult procedures, and also suggestions for improvements. Andy then worked on these according to the priority necessary.

The first priority was to get rid of the old paper diary and install a diary system linked directly to each vet and his or her clients. This was an unqualified success, using desktop colours to allocate tasks to individuals. Reception has a master diary, while individuals have a version solely for themselves. We also now have similar diaries for operations etc., too.

The Havant Surgery Reception area. The Risc PC 700 clearly shows the Jaz drive used for backup. This computer drives the diary server; the current day's diary can be seen displayed on the monitor. The other 'box' below desk level is the till! Havant Surgery Reception photo

Part of the fun was that Andy was a student at Cambridge University at the time. The initial installation began at the start of his Summer vacation. and most of the problems were ironed out before he went back in October. However, we installed modems and a protected access program so that any problems were left detailed in the root directory as a text file (appropriately named Cockups), and Andy read these on a nightly basis. He then corrected the problems and left us a print-out on the laser printer to read the next morning, explaining what he had done.

The system was written in modular form using C, ARM code and BBC Basic, depending on particular needs. There were many other extensions which were added to the basic suite as time went on to expand the facilities available for the vets and for the administrative staff to make their lives easier. These included the automatic generation of a reminder list after vaccination. Address labels are automatically produced every month for boosters which are due, significantly saving administration time.

A typical icon bar showing various features of our system: Icon bar

1  Shared disc icon: we have a number of shared partitions accessed from here.
2  The icon that gives access to the Jaz drive.
3  The network icon.
4  Leigh Park laser printer icon (Printers front-end) used for all routine printing in black & white. This is the printer connected to this computer, which is not necessarily the printer to which the computer output is going.
5  Printer selection icon: there is more than one printer on the network, and this icon displays which printer is currently selected for use by this particular computer (in this instance, a colour bubblejet printer).
6, 7, 8  Diary module, client manager and accounts module icons: confirm that the associated software modules are installed and running.
9  User manager icon: confirms that the user manager is installed, and displays the initials of the user currently logged in.
10  Fresco icon: DVG subscribes to Argonet for Internet access, but we also use Fresco to access data CDs containing drug information in HTML format.

Drawing unique benefits from RISC OS

All forms and charts are created by the system using the information from the databases, printed off on plain paper from the laser printer in a unique way: we use Draw! The output is exceedingly professional, and far surpasses anything else on the market, which tends to use dot matrix output with fading ribbons. The output includes: admission forms; anaesthesia monitoring; hospital records; surgery consent forms (e.g. for neutering/spaying); care of pets after surgery of various types; and Euthanasia consent forms, amongst others. All of these forms are created initially as templates in Draw format, which are then simply adjusted as necessary by the program. This format makes the creation of new forms and the changing of the format of old forms very simple. Draw is a great freebie!

Here we see Draw's ability to produce detailed forms on request; in this case, an Anæsthetic Monitoring form. Compare the two top areas of the form: the printout is on the left and the template, on which it is based, is on the right. The program takes the relevant data from the client record and inserts them at the coded variables in the Draw template. Draw file anaesthetic record

This system allows headed paper etc. to be produced 'on the fly', unlike than the other systems, which needed two paper trays and pre-printed paper. One software supplier told us that this was impossible to do in practice, as the method would be far too slow! This was worth its weight in gold when BT decided to change all our telephone area codes. A simple adjustment to the Draw file template was all that was necessary, and we were instantly up to date. A neighbouring practice had four different styles of paper, and ditched reams of each.

This is the statement request window. Various levels of detail can be requested, depending upon requirements, and the statement may be previewed by reception prior to printing or can be just printed off directly. Sometimes a statement is for client information only, but for aged debt accounting purposes the system will register that a client has had a statement issued and the date. Create statement window
This is a copy of a statement printout. The template is created in Draw and the information added by the Accounts programs. The whole thing is then printed out onto plain paper. Draw file output

We use Draw to add diagrams and graphics to our notes, too. Other systems take a base diagram and add a circle to show the site of a problem. We can actually draw the accurate shape using Bézier curves!

Draw is used to add detail to the case history. Image banks are created, which are modified and attached to the client record. It is then possible to create accurate assessments of progress as a case continues. The clients love the printouts, too! Note the green cursor in the screenshot. The area of record accessed to view the picture is an area of the case history which is sealed for security purposes (see below). Case record window
Draw file output

The operations diary: red markers select the cell to be edited, and the details are entered for each operation to be performed on any day. The printed output uses Draw to produce an Ops List for the theatre for convenience. Operations diary window
Draw file output

There is a stock update program which allows a delivery to be integrated rapidly into the system of stock control, as the wholesalers produce a CSV file of their catalogue, for which Andy wrote a program to link in and update all price changes automatically.

The drug editing window: stock levels, pricing, dispensing and labelling details are all controlled from here. There are eight separate files for stock, depending on the way in which they are dispensed. Editing Tablets window

Able labels

We use a thermal label printer (Seiko Smart Pro 11) in each dispensary, which produces high-quality labels that do not fade even in direct light. Andy had to write his own driver for this printer. As the data sheets were not initially available from Seiko (who at that time considered their software adequate), Andy arranged for their software (running on the x86 card) to print specific graphic files onto labels and recorded the output which was sent to the printer. The format then became evident (to him, anyway) and so he could write an appropriate driver for the Acorns. One interesting consideration was that these printers are almost silent; a particular contrast from the clatter of the previous dot-matrix models. As such, dispensers were missing the fact that there were drugs to dispense. Andy's remedy was to make the computer beep when a label was printed. They didn't like the beep, though, so we now have a chord of C Major! No more comments. (Data sheets for the label printer are now downloadable from the Seiko site on the Web, incidentally.)

The corner of the Emsworth Dispensary with the dispensing printer setup. The neat little Seiko label printer is to the right of the keyboard. Dispensary photo
The dispensing label queue window is displayed on the dispensary computer. The label printer queue is held in memory for 20 minutes; any label can be requested to reprint during this time, after which it will delete itself from the queue. The dispenser is informed of the drug or product to dispense, the amount, and the location from which the request was received. Label print queue window

The system in practice

A typical layout is at the Emsworth Surgery. There are eight machines at this branch. Two are StrongARM Risc PCs, one with 18Mb of RAM and the other with 42Mb; both have 1Gb hard discs. The smaller Risc PC holds the diaries and drug list and the other holds the client (currently 16,000 with room for plenty more) and animal records. There is a minimum of one animal record per client record, and often two or three, and so far our maximum for one client is 76 pets!

The client details window is fairly self-explanatory, with editable areas in white and areas of data created by the system in grey. Some items of interest are noted on the diagram. Client details window

1  Confidential notes can be appended to a file and read by pressing <Ctrl-N>. If a note is present, the icon is red.
2  If stage payments are made, it is useful to know when the last payment was received; it will be different to the date on the record card.
3  It is always useful to know if a client has a future appointment and when it is. Often the client rings to ask, or we have results of tests to pass on, or the secretary may be gunning for them!
4  A credit limit can be set. While the client's account stays below the limit, the flag stays green. A penny over the limit and it turns red, as a visual aid to reception to request payment. These days, the vast majority of credit limits are set to 0.

The pet details window: all pets have an individual record which is then attached to a client record. One Emsworth client has 76 records attached to her client file. Animal details window

'Blue menus' are used to shorten data input times. Here, the first two letters (any sensible number is possible) of the breed have been typed, and the program reports all known breeds starting with these letters. Pressing the corresponding number on the menu inserts the data. These menus are used for addresses (districts, towns and counties are all entered on lists) as well as for breeds. A big advantage of this method is that, once entered correctly, there are no typing errors and spelling mistakes later! Blue pop-up menu

The case record window: all case history details are entered here and are priced automatically and accounted for by the system. Security is essential for legal reasons. Text is entered and will be placed on the case record at the level of the yellow cursor once the <Return> key is pressed. Text can only be inserted below the level where the case record was initially entered. Once the record is closed, the text and details of treatments etc. cannot be edited further, but are fixed. The case record is then legally acceptable and able to be produced in evidence as a record made at a particular time. Case record window

There are various groups of fees, which are edited in the procedure editing window. The four main groups of fee type are shown with radio buttons. The buttons can be set to update the record automatically, so that the sex of an animal can be changed to neuter after a relevant operation, or a record card can be properly updated after the animal dies. Keyboard shortcuts are shown for convenience when making selections. Edit fees window

We use Acorn's Level 4 Fileserver software for user areas, and Access for shared resources. This is so reliable that the Risc PCs act as both fileservers and clients, which reduces the cost. This is much faster than using a single fileserver.

The machines with 18Mb+ of RAM are also fitted with a PC (x86) co-processor card, to allow Windows software to be run. However, this was not very satisfactory, and is no longer used. There is a basic stand-alone PC running Windows which is used for non-compatible software, such as learning and nurse teaching programs which assume that every computer uses Windows as its operating system. The PC also links us to our wholesaler's computer software for computer ordering (their programmer is not very flexible!).

The larger Risc PC is also used as an office computer, running Computer Concepts' Impression for correspondence etc., and other software as required, and drives a small laser printer (just changed from a HP LaserJet 1100 to a Brother HL 1250). The main print jobs are carried out on a central networked HP LaserJet 5, which is very reliable and a good workhorse.

The remaining client machines are low-cost A7000s, with 8Mb of RAM, but no hard discs, and all the machines in each branch are linked via Ethernet.

Soon the branches will be linkable via modems and telephone lines, allowing remote access to the data for clients and animals of other branches. A beta version of the software is currently running between the branch at Barnham and Andy's house. The fifth branch is being refitted and cabled, and will then be equipped with eleven machines: two Risc PCs and nine A7000s, plus a stand-alone PC. The current total is 37 Acorn machines for the practice as a whole, plus a spare A7000+ and a Risc PC which we keep as backups just in case. There are just four Windows machines, none of which are networked.

Bognor Hospital Partner Paul Tucker in his office: note the Risc PC 700 with two slices, which is one of the Bognor main servers and which also houses their Jaz drive for backups. Office photo

The computers and networks run 24 hours a day, though monitors and some client machines are switched off when not in use. This is essential as, in the group, there are never fewer than two vets on duty, 24 hours a day, 365 days a year. We are proud to say that our reliability as vets is of the first order. We are also very pleased that our computers are equal to the task which we set them, and are just as reliable.

The future for our software

We are aware that many practices have good networked hardware arrangements, but are dissatisfied with their software. Andrew has recently been working on a Linux conversion of the programs, which is now beginning to work very well. This will give much more scope to the project, and hopefully give it greater commercial viability. By installing Linux operating systems, the software could easily be run on these networks. We have proved that the converted programs will run without problems on a network with a mixture of RISC OS and 'conventional' machines.

However, the major developments of the programs are still RISC OS-based, for the reasons which we have stated above. Although the use of alternative equipment would be an advantage when there is already a network present, our preference on installing new setups would be to advise most firmly the use of a local RISC OS supplier who could give good hardware support, and install the software in its RISC OS form.

So, what happened to the original A440s? They're still working faithfully. They have just been installed with Andy's Teletext emulation software, which allows clients to access a number of pages of information about a range of topics in the waiting room. Waste not, want not!

In conclusion

We are aware that this overview of our system has to be a scant one. Perhaps in the near future we will write separate articles about specific modules of the system, and look in more detail at the programming approaches necessary and our methods of avoiding some of the problems and pitfalls inherent in creating large suites of programs for business use.

Anyone interested in more information about the Downland Veterinary Group may like to visit our Web site at http://www.downlandvets.co.uk/.


Our thanks to Gordon Taylor for his initial contributions to this article.