Search the website

Remotely held records and centralised servers

February 2002

Introduction
It could be argued that one of the most influential forces in UK healthcare has been the concept of the medical list, ie that each patient has a personal medical advocate. This system has driven the improvements in UK primary care and has, to a large extent, protected patients and the NHS as a whole against unnecessary intervention.

The concept of the medical list is symbolised by control of the paper based medical record – the Lloyd George envelope or A4 folder. GP records, even first generation electronic records, have always been held within the GP’s practice premises. However, technology now threatens this model as it is now possible for records to be stored remotely (remotely held records - RHRs).

There are many possible technological configurations for RHRs. Currently most RHR systems are based on the centralised server approach, where the records from multiple practices are held in one location. The RHRs may be held in a common format or the central server may host several different software systems. However, an RHR could take the form of a distributed record where components are held separately but ‘collected’ together to be viewed as a whole.

Many primary healthcare organisations, eg primary care trusts and local health care co-operatives, are considering investing in centralised systems as a possible solution to problems involving data collection, analysis, incompatibility and variation in GP computer systems, as well as seeking to remove the issues of managing increasingly complex systems from individual practices. Other primary care organisations (PCOs) are encouraging GPs to adopt common software systems within their practices as a prelude to moving to centralised servers. However experience of using centralised servers and overcoming these perceived problems is currently limited.

This is interim guidance that summarises the main issues GPs should consider before agreeing to store patient data on a centralised server. It does not attempt to make conclusions regarding the potential risks/benefits of participating in such a scheme, as each GP must assess these in the context of his/her individual and local circumstances. It is not possible to consider in detail every conceivable technological configuration, however, the main issues will apply regardless of the local arrangement. Further guidance will be issued in due course.

Principles of remotely maintained records
Custodianship
This is a key principle:
There should always be a clearly identifiable GP who is responsible for the record. Except in exceptional circumstances, this would normally be the patient’s registered GP. It is accepted that, generally, patients prefer this arrangement.

Custodianship should be established whatever the technical configuration.

Access
This is the second key principle:
The GP as custodian of the RHR must retain control and remain ultimately responsible for access by others to the information. Access controls and protocols must take into account the patient’s consent (both internally in terms of access by practice staff and by external parties), the status of the party seeking access to the record and the reason why access is required. Access controls and protocols should be updated and reviewed regularly. Access controls should, of course, also exist in practices that maintain their own electronic patient records.

GPs (and practice staff where applicable) must not be able to access the RHRs of any other clinical domain as a default, ie practices sharing a remote server should not be able to view another practice’s records. However, under certain circumstances, the custodian of the record may grant other clinicians access rights. (For the purposes of this paper, ‘access’ means the ability to view data. There are considerable legal, ethical, professional, operational and technical challenges involved in extending ‘access’ to include the right to modify or edit another custodian’s RHRs). Access rights must take account of the role of the enquirer in the patient’s treatment and comply with professional guidelines and the Data Protection Act 1998. It is unlikely that another clinician would need to see all the information contained in the record and access should, therefore, be limited to relevant information. Any disclosure of personal data where it is not actually necessary would be likely to contravene the requirement under the Data Protection Act 1998 (third principle), that disclosure of personal data should not be excessive.

As with practice systems, a centralised system should be able to recognise inactivity and should automatically revoke the access rights of any person (other than the patient’s registered GP and, where applicable, other GPs in the practice) who failed to access the data over a 60-day period. Persons whose rights have been revoked should approach the custodian to regain their access rights.

Patient consent
Patients may assume that their medical record is stored on the practice premises and may not understand the concept of a RHR. Patients should be informed about how their data will be stored, in accordance with the first principle of the Data Protection 1998. Wherever the record is held, the custodian GP should be willing to address patients’ concerns regarding the robustness of access and data security arrangements. GPs will need to consider alternative arrangements for patients who wish to opt out of a RHR scheme. This may require a separate, practice-based electronic record system or possibly reverting to paper records.

If, by exercising their rights as data subjects, patients elect to have their records held separately from the usual arrangements, the GP should advise them of the potential implications this may have for their healthcare.

Withdrawal
Should the custodian (or the subject of the record) at any time wish to withdraw from a RHR scheme, the relevant patient data should be made available to him/her and removed from the system within 1 month of his/their serving notice.

Data conversion
It is likely that some data conversion may be required when moving to a RHR system. Converting data to a new format, whether from one practice system to another or from individual practice systems to an RHR system, risks the integrity of the record, therefore, we strongly advise that either the original data or a copy is retained for up to one year. A working installation of the pre-conversion software must also be maintained for up to a year following conversion to ensure that the original data can be read where necessary.

Where data conversion is necessary, a trial must be carried out on a full copy of the information that is to be transferred. Only when the custodian of the records is satisfied that the conversion has been accomplished accurately should approval transfer be granted. For example, transfer should not be allowed to proceed if unique patient identifiers have not been converted with an accuracy rate of 100%.

We strongly advise against the permanent deletion of any electronic records and GPs must abide by statutory requirements for the retention of patient records. (Further information on patient record retention is contained in the GPC guidance ‘The Data Protection Act 1998: An updated code of practice for GPs’, which can be found on the BMA website ). If a practice decides to delete electronic patient records from an old system, the safest method of data disposal would be to destroy the storage devices. ‘Wiping’ or formatting hard drive is not sufficient and does not result in the permanent deletion of the records.

The custodian must be assured of the following before agreeing to participate in a RHR scheme:

Encryption
Information held in a RHR must be encrypted using appropriate technology. Requirements for NHS encryption are described in the “Strategy for Cryptographic Support Services in the NHS” . Encryption should be applied to at least the level of each clinical domain (ie each practice’s data).

Security of connections
Connections from the practice to the server should be secure. It is BMA and NHS policy that all data should be encrypted during transmission and this applies to RHR systems, whether browser based or message based. Browser based approaches should, as a minimum, have the ability to ‘remember’ disabled passwords and operate SSL connections. (SSL is a low level temporary encryption that is in use only while logged on). Connections between the practice and the server should automatically disconnect after a set period of inactivity.

Performance of connections
The performance of the system (ie how quickly screen refreshes or picking lists appear) should be no less than that of an equivalent, practice based system and should not interfere in the consultation process. ‘Bandwidth’ must be adequate for all practices at all times.

Virus protection
Using an RHR system in no way diminishes the need for adequate virus protection. Virus checkers should update every computer every 24 hours.

Security of location
The installation must be housed in a location that is secure from unauthorised access.

Disaster recovery
A back up system must be in place to ensure that data is available to participating practices within a reasonable time should any part of the system fail, ie the system must have 100% redundancy/’mirrored’ resources.

Technical support
A technical support service must be available (on site if necessary) 24-hours a day and should be sufficient to be able to meet the agreed disaster recovery requirement whenever necessary. Agreed protocols should be developed and followed. Practices should bear in mind that they routinely operate outside normal office hours and the support arrangements should reflect this.

Backups
It should be possible to restore either the whole system or just one particular practice’s records. Backups should be made on a daily basis, however, where 24-hour access to the RHR is available, backing up the data should be a continuous process.

Compliance with accepted professional standards
RHR systems should comply with all mandated NHS standards and the current Requirements for Accreditation of GP computer systems.

Funding
RHR schemes should always be supported by a business case, which, in England, should comply with the local health community’s local implementation strategy (LIS - this details the how national and local IT prioritises will be developed in the area). The business case should take into account all associated change management and future costs. Funding should come from appropriate sources. The NHSE in England has instructed local healthcare communities to be prepared to divert existing funding flows to areas which demonstrate a better return on the investment when considered at a community-wide level (HSC 1999/200). Local initiatives in Scotland should be developed in accordance with the relevant NHS health board local information management and technology plan. In Wales, local IT initiatives should be developed in line with the ICT foundation programme for general medical practice, which was published by the National Assembly for Wales in August 2001. We are not aware of any plans currently to implement RHR schemes in Northern Ireland.

Local medical committees
The local medical committee (LMC) should be involved in development and approval of the business case.

Caldicott guardian
A RHR system should have its own Caldicott Guardian with responsibility for monitoring and improving confidentiality and security. The NHSE’s latest guidance on confidentiality can be found at on the Department of Health's website .

Contracts
The above principles should be reflected in the contractual arrangements or service level agreement between the purchasing body (eg a primary care trust (PCT)) and the system supplier and agreement between the purchasing body and the local GPs. The local GPs, as the ‘custodians’ of the RHRs, should have the right to review the contract or service level agreement between the purchaser and the supplier to confirm that these standards are met.

Liability
If the RHR system fails, the GP may not have access to the information he/she needs to treat his/her patients. It is unclear as to who would be liable for any harm caused to a patient or patients arising from such a failure. We imagine that the liability would at least be shared and the GP would be strongly advised to seek assurances from the RHR supplier regarding their indemnity arrangements. This matter should be explicitly addressed in any contract.