History & Timeline

We’ve divided this into:

You may also be interested in Research

Early history: creation of Renal PatientView

RIXG (the Renal Information EXchange Group) first met in July 2003, tasked with thinking how to make the best use of modern IT to improve information and care for kidney patients. A number of things were discussed, including better websites to provide information about renal services and organisations. However the strongest feeling at the first meeting was the desire to make a difference to the patient experience.  It was pointed out that despite developments in computing and the invention of the Internet, and a number of notable developments inside healthcare, the experience for patients was largely unchanged.

In further discussions, patients said they would value access to the type of data already held in renal unit IT systems. So a small group explored this, seeking to find out whether this could be extracted and presented alongside explanatory information about tests, diagnosis, and targeted information about treatments such as dialysis, transplants, and general management of kidney diseases.  In many ways this was close to the ‘electronic care plan’ which was one of the visions in the government’s massive NHS IT project at the time. However RIXG thought that as a small minority with particular requirements, renal patients would inevitably receive a low priority in that project. Important background to this was that renal units had been pioneers in investing in IT since the 1980s, creating some of the first electronic patient records, and most units already held a lot of valuable information on dedicated (but often old) IT systems.

The feedback from the exploratory studies was that it was technically achievable, so in 2004 RIXG initiated what became PatientView as its first project. Funding was obtained for a pilot project and suppliers were sought and interviewed.  One was selected to develop the online application, and another to work on the mechanism of data transmission from renal units.  Work began in June 2004, with a timetable to have results for patients from one or two pilot units online inside six months. A lot of effort was needed to work out how to do it, not only technically, but also to make sure that it was easy to use, sustainable in renal units, safe and secure, and to get approval to show patient data to patients in this way.


Alternative ways of giving electronic information to patients were in vogue at the time, including computer terminals in healthcare settings, and issuing a USB stick or CD with records on it. However in order to be scaleable and useful, it was felt that the solution must be Internet-based.

Confidentiality and security

Because of concerns about confidentiality, only patients who signed up for the project were included. It was not easy to find out how to get approval for the project. There seemed to be many ways to get a ‘no’, but nobody empowered to say how this type of development could be done.  After extensive discussions with individuals in senior positions in NHS IT in England and Scotland, and in NHS Connecting for Health, and Caldicott guardians, a way through was reached.

Security policies were established and further developed in response to feedback from patient and staff users as well as IT governance professionals.  ‘Penetration tests’ to ensure system security were undertaken initially and regularly thereafter.

What should it show?

The initial content of the system was agreed in meetings between patient groups, clinicians, and renal IT specialists, to work out what would be most useful to patients, what was feasible technically, and what was likely to be practical and implementable.  Kidney Research UK organised helpful additional focus groups with patients. At the same time, ways to match diagnostic and treatment codes to information sources were explored. Our information links policy was developed.

Local management

An early requirement was that implementation must require minimal extra input from staff in local units, which were and remain hard-pressed. Requiring extra staff time would threaten both implementation and sustainability.

However it was decided that management of users must be local, where the patients were known, and where responsibility lay for the data shown. It also simplified confirmation of identity of patients requesting access, and the same applied to adding staff users. As the information shown (results, letters etc) came from local systems, it was important that local units saw their responsibility for the data quality too. This devolved management also made the system scaleable and reduced the size of the central organisation needed to maintain it.

Agile development

The project initiated as a pilot with a limited dataset and it was not clear what the best way to implement it would be, or how extensive the data shown would be.  We therefore adopted an agile development model in which work was agreed and commissioned in small parcels, rather than as a fully described project.

Where difficult issues came up, it was decided to test a simple solution first rather than build in complexity from the outset.  An example was the uncertain effect of releasing bad news or dangerous results (see below). We were unsure of the best way to manage this; pre-screening would have created significant issues for patients and staff (extra work, delay). So we piloted release without pre-screening. In practice it did not creat difficulties and this experience has been the same with wider implementation, so we have not needed to develop a technical solution.

On the other hand, it emerged that Transplant Status shown in local records could be wrong, and a way to show it directly from the central database at UK Transplant was desirable.

This fitted our agile commissioning model for the work with our web developer. It was very different from the model used for most IT projects at the time, which required detailed advance planning of final functionality. While this may seem to reduce risks, it can make it difficult or expensive to deviate from the prior plan.

Data shown

It was realised that by using the NHS number as the primary identifier we could also aid the care of patients who attend more than one unit, including those who go to another centre to receive a renal transplant. PatientView forced use of the NHS number as the primary identifier, and aggregated data from anywhere that could send it to the same record.

The patient’s diagnosis was shown with links to information about the condition and its treatment, for both patients and for staff – explanations for patients; treatment guidelines and decision support for healthcare staff. Recent test results, particularly important to renal patients, are also shown.

Data format

Data transmission required local IT systems to construct a simple file type in a format that we developed (RPV-XML).  No system for sending this type of data was generally accepted for use at the time. This format has been expanded but remains in use still at the time of transfer to PV2 in early 2015.

Live data, more data

Focus groups and others had detailed discussions about releasing bad or dangerous results  (e.g. very high potassium, or worsened kidney function) to patients without pre-screening by clinicians. Requiring all results to be pre-screened would add extra work for clinicians, and delay return of results to patients. Patients we spoke to said they didn’t want that, but some clinicians were anxious about the possible effects. Building in pre-screening would also have been much more complex technically and in local implementation.

In practice releasing live results has not created difficulties. This is an important area that we have researched further.


Funding for the pilot project in 2004 came from the Department of Health in England supported by proportional contributions from Scotland and Wales. This was intended to permit a pilot for 4-6 units. However in response to early feedback, RIXG agreed to an expansion of the scope of the scheme. Subject to availability of a small amount of local funding, the system was offered much more widely from mid-2005. Maintenance costs continue to be covered by a modest annual charge to participating units, except in Scotland where funding has come directly from the Scottish Government.

Further development

See Timeline


PatientView’s original steering group was Neil Turner, Keith Simpson (Adult Nephrologists), Kate Verrier-Jones (Paediatric Nephrologist), Cherry Bartlett (local IT system manager), Andrew Scott (Consultant to Department of Health) but it also drew on much external expertise from RIXG’s constituent groups.

Responsibility later passed to the Renal Association, where a small steering group continues to make operational decisions.

Comments are closed.