J S Briggs and M P Bradley.


The problem

The National Health Service (NHS) is based on a primary health care model. A patient's first point of contact with the NHS is usually their general practitioner (GP). Often the GP is able to treat the patient but sometimes the GP decides to refer the patient to another doctor who specialises in the illness affecting the patient. These specialist doctors usually work in hospitals and are known as "consultants". The GP might ask the consultant for advice about the patient, or ask the consultant to take over management of the patient's condition.

There are several factors that may affect the GP and patient's choice of consultant:

Firstly, there will usually be several suitable consultants working in one hospital and within a wider area many suitable consultants at many hospitals. A GP and patient may have a wide choice. Yet it may be that only one of these consultants takes a particular interest in the patient's particular condition. The GP and patient may well think that this consultant is best qualified to treat the patient. Unfortunately, unless the GP is personally acquainted with the consultant's work or has heard about it on the grapevine, this information is hard to come by.

Secondly, although treatment is free to patients at the point of delivery, the NHS has a limited amount of money available each year for treating patients. Demand for treatment is often greater than supply, so queues build up and patients have to wait to receive specialist treatment or an appointment with a consultant. The waiting list for an appointment, however, often varies between consultants. A GP and patient might be keen to find a suitable treatment with a short waiting list. Unfortunately, up-to-date information about waiting lists is not usually available to the GP and patient when they decide about a referral.

Thirdly, cost considerations often need to be taken into account. Whether the GP is a non-fundholder with several Health Authority contracts to choose from, or a fundholder seeking to make best use of their resources, the cost of a treatment offered by different hospitals may be a factor in deciding between suitable consultants. Again this information is not usually available to the GP when wishing to refer a patient.

The Internet

In years gone by every computer hardware manufacturer had technology that allowed its computers to talk to other computers, but only as long as the other computer came from the same manufacturer. So, if you were an organisation wanting your computers to talk to another organisation's computers, you both had to have the same sort of computers, or spend money on special translators to allow the two to talk to each other. These obstacles made it very difficult to develop large scale network applications, that is computer programs that could be used by lots of different people in lots of different places.

However, time led to the development of a set of standards so that all computers could talk to one another. As much by accident of history as any other reason, the set of standards that came to predominate was the one developed on behalf of the US Advanced Research Projects Agency for its ARPANET. Because the standards were designed to work on top of existing proprietary network protocols and link these networks together, it became known as the Internet. That this was successful is proven by the extent to which the Internet has in recent years become a part of everyday life for many people.

The Internet standard is fundamentally a set of protocols for computers to talk to each other, but what really has caused the Internet to catch on is the range of services that have been built on top of the low-level transmission protocols. One of the first of these was Email, the ability to send electronic mail messages from one person to another. Later came FTP, allowing files of data or programs to be transferred from one machine to another. The capability to search another machine for particular information was provided by the Gopher facility, and there are many others, less well known.

Despite the usefulness of these facilities, it was not until the World-Wide Web came along that the Internet became popularised outside the specialised field of computing. The WWW was the so-called "killer app", an application so obviously useful that millions of people have got themselves connected to the Internet to be able to use it.

The WWW was invented at CERN, the European particle physics research facility in Switzerland, by Tim Berners-Lee. He was looking for a way to disseminate information among physicists as easily as possible. Rather than designing an application, he decided to create a protocol (HTTP or Hypertext Transfer Protocol) for requesting documents from a computer over the Internet. Every document is identified by its Uniform Resource Locator (URL), an address which combines the name of the computer where it is located with where on that computer the document will be found.

Part of the same work was the development of a notation called HTML (Hypertext Mark-up Language). HTML defines the structure of a document - headings, paragraphs, etc. - but not the way it looks on the viewer's screen. The viewing application decides how to format and display the information. A prime feature of HTML is the ability to embed links to other documents within a document. These links can be used to direct the reader to other documents - an action that is performed when the user points at the link. The similarities between the structured formed by these inter-linked documents and a spider's web gave the service its name.

Computers that hold documents are called "web servers" and the documents themselves are called "web pages". A program that requests documents from servers, and allows the user to view them, is called a "browser" - the two most commonly used browsers are Netscape Navigator and Microsoft Internet Explorer.

Normally a document is static - that is its contents don't change (except when its author amends it). This makes it difficult to interact with the user. The Common Gateway Interface (CGI) is a standard for getting information from the user (usually by means of their filling in a form) and passing it to a program running on the server. Typically this program creates a web page on the fly and sends the page for display by the browser. This provides a simple mechanism for interaction.

The next step however was to provide programs that could be run on the user's computer rather than the server. This has been achieved through the invention of the Java programming language by Sun Microsystems. Java's key feature is its portability - any Java program can be run on any machine that provides a Java Interpreter. Nowadays many browsers have the interpreter built into them, and web pages can be constructed so that mini programs (called "applets") can be downloaded along with a web page, and executed automatically by the browser. There are some restrictions on what an applet can do, motivated by the desire not to compromise the security of the user's computer.

NHS net

The NHS has much of the infrastructure of its own network, NHS Net, available but does not yet have many applications to take advantage of it. In this paper we describe how Internet technology can be used to bridge the gap in the flow of information between consultants and hospitals on the one hand, and GPs and their patients on the other. Such an application might be the "killer app" which gives GPs and hospitals the incentive to join NHS Net. Once more organisations are connected, other applications might become possible.

An Internet-based patient referral system


Requirements for the system were elicited by talking to GPs, practice managers and representatives of two hospital trust IT departments in our region. Not all the doctors interviewed were existing users of computer systems.

When asked about the factors that affect their referral decisions, the GPs revealed different preferences and often widely different priorities. Among the factors mentioned were locality to the patient, waiting time for treatment, patient preference, knowledge of the consultant, performance of the consultant or unit and cost of treatment. The theme that ran common to all was the desire for better information. At present waiting list information is distributed on paper, at best monthly, often quarterly. The information is out of date before it leaves the printers. Information about individual consultants' expertise is normally not published by hospitals.

There are a few issues that would need to be resolved such as there is no standard way of calculating the average wait for an appointment, nor of assigning an urgency level to a case, hospitals are sensitive to the association of cost with a specified treatment (particularly since the consultant may decide on a different treatment at a different cost once they see the patient), and the contention attached to the publication of performance indicators.

The other part of the system the GPs wanted was the ability to book hospital appointments from their own surgery. One GP already has access to his local hospital's computer system, but is barred from using the booking facility because it would exclude the consultant from a decision about the priority to be attached to the patient, and because it would give his practice an advantage over other ones.

A first step towards automating the process would be to automate sending the referral letter. Currently referral letters are dictated for typing by secretarial staff and there can be a significant delay between the GP seeing the patient and the letter arriving in the appropriate consultant's in-tray. At the very least, sending the letter to the hospital electronically would reduce the delay.

From the point of view of the hospital trusts, the priority is to have discharge summaries sent to GPs quickly when patients are discharged, particularly those requiring the immediate care of their GP. Much of the information that GPs want is already available with the hospital's own computer systems; the only issue is how to make it more widely available. Hospitals seem keen to provide GPs with a "window" on to their information systems.

Design and implementation

Our prototype patient-referral system was constructed without using "live" data. It was decided early on that referral letters would be emailed to the hospital rather than that GPs should have direct access to the booking system.

Within those constraints, we decided to adopt a conventional client-server architecture. The user (typically a GP) requests information from one or more remote databases. The information is sent to the user's computer, where it is displayed in an appropriate format. Further information about a hospital and each of its consultants is available on a web page. The user can then send an email to a remote system. One additional facility is for the user's system to hold a list of remote databases to access. This would be used to store the identities of all the possible hospitals a GP might wish to refer to.

The system is implemented at the GP end by a Java applet launched from a WWW browser (such as Netscape). This allows the user to specify a choice of one or more hospitals and specialisms. At the (simulated) hospital end, information matching the GP's request is extracted from a database and sent to the applet. The applet presents the information in a form that allows the GP to browse it and finally select an appropriate treatment.

We devised an information format in Structured General Mark-up Language (SGML) for the data describing the treatments available at a hospital. SGML is an ISO standard; a definition is called a Document Type Definition which specifies the tags which describe the structure of the information. The best known application of SGML is HTML, described above, although it has long been in use in many fields particularly publishing. As its name suggests, SGML is useful for describing the structure of information. Our hospitals have consultants, consultants have treatments, treatments have performance indicators, and so on.

There were a number of practical problems caused by the security features of Java applets. Because an applet can only make a network connection with the server it was downloaded from, it was necessary to implement a program on the server to fetch the desired information from the hospital databases, collate it and forward it to the user's computer. We used the CGI forms facility for this, as well as to provide the network interface to the hospital databases.

As it stands, the user can select a treatment, a speciality and an urgency, and get a list of treatment hospitals to query. Once the user has selected which hospitals to query further, the application sends a request to the server which makes further requests to each hospital database. Information returned to the application is displayed to the user. If the user clicks on a hospital or consultant, the application invokes a new browser window to display their web page if the hospital supplied a web page address.

The implementation involved the development of approximately 3000 lines of Java code and 350 lines of Perl (in the CGI scripts).


The prototype system has shown the feasibility of an application to support the referral process. We believe it proves that the concept of a patient referral system using Internet technologies is valid.

The GPs and trusts involved showed considerable enthusiasm when the system was demonstrated to them, indicating the demand for such a system. The system shows the potential for providing GPs with more extensive and up-to-date information than existing paper-based systems. It also shows scope for decreasing some of the delays in the existing system. Trusts appreciate that such a system will enhance the quality of their service.

There are a number of issues that remain to be tackled, including:


The work was carried out in collaboration with Integrated Media Systems, Southsea, ( We would like to record our appreciation of the help given by GPs and hospital trusts towards the success of this project. M P Bradley held an EPSRC studentship during the period of the work.