In a computer system, each subject has access to certain objects. This access information may be stored by subject or by object. In the former case, the access permissions are called capabilities, and might have the form `Dr Jones may read the records of Farid Abdullahi, James Adams, Wendy Adams, Henry Addenbrooke, ... ' If the permissions are stored by objects, they are called access control lists, and might have the form `This is Farid Abdullahi's record and it can be read by Dr Jones, Dr Smith and Nurse Young'. The latter approach leads to simpler engineering, as the number of patients per doctor is much larger than the number of doctors per patient.
In the normal course of events, any clinician with access to a record may not only read it, but also add information to it (we will deal with the deletion of information later). Our first principle is therefore
Principle 1: Each identifiable clinical record shall be marked with an access control list naming the people or groups of people who may read it and append data to it. The system shall prevent anyone not on the access control list from accessing the record in any way.
In many current systems, the access control lists are implicit. If a record is present on the practice database, then all the doctors in that practice may read it and append things to it. However, with the introduction of networking, access control lists need to be made explicit and consistent across a range of systems, and must be enforced by mechanisms that are not only technically effective, but that support practices such as deputising and caseload sharing.
To facilitate this, groups may be used instead of individual names. For example, if Dr Jones, Dr Smith and Nurse Young together staff the Swaffham practice, then the records to which they all have access might simply be marked `Swaffham'. This idea was inherent in the development of Community Care; the teams involved doctors, nurses and social services staff, and written consent was obtained at the start of the assessment for information to be shared. In this way, the patients knew whom they were signing up to trusting.
However, sometimes the only sensible groups include a large number of people. In large hospitals and community health trusts, there might be hundreds of nurses who could be assigned to duty in a particular ward or service. Some extra restrictions may then be needed in defining groups; for example, the group might be `any clinical staff on duty in the same ward as the patient'. Such an approach would be the electronic equivalent of a traditional note trolley, but with the added advantage that a record can be kept of who consulted what.
Whenever groups are used --- whether simple groups including a few clinicians, or complex ones with location and other constraints --- a record must always be kept of which individual read a record or added anything to it. We will discuss attribution more fully below; here, we merely emphasise that groups are not virtual clinicians, but mechanisms that simplify the access mapping between identified clinicians and identified patients. Designers should bear in mind that a given system user may belong to many different groups: she might simultaneously be a patient, a doctor, a trainer, a trainee, a practice manager and a consultant to a health authority. Unless provision is made to manage this complexity, it is unlikely to be managed well; ad hoc methods should be avoided.
It is not acceptable, for example, for a group to be implemented by a password shared by all the staff on a ward, or by leaving a terminal permanently logged on to the consultant's account. Such abuses mean that actions could no longer be attributed to individuals, and they can cause serious harm: we are aware of a case where a psychiatric patient used a ward terminal to alter prescription data with murderous intent.
When a patient registers with a practice or otherwise commences a clinical relationship with a care team, and a record is opened for him, he should be given information on the team's access control policy. He must also be given the opportunity to object and request that his record be restricted to one or more named clinicians. For this reason, role-based systems must still support more restricted access control lists, and in particular lists containing a single named clinician (plus of course the patient).
Such a list may even be the default in the case of highly sensitive data. The actual sensitivity of a record is a decision for the patient or patients concerned. Examples of data which are prima facie highly sensitive include psychiatric records, records of sexually transmitted disease and all information given by or about third parties (for a fuller list see [GC95] p 44). However, an AIDS campaigner might make his HIV status public, while a Jehovah's witness might consider even a blood transfusion to be deeply shameful. So the patient's consent remains paramount, and no-one may be added to the access control list without his being notified. We will discuss notification in greater detail below.
Finally, there are some users, such as auditors and researchers, who have no write access at all to the primary record. We will discuss their special problems below, but for simplicity's sake we will not make separate provisions for read-only access in this policy. We will rather assume that they get full access to a temporary copy of the primary record; and this is in fact a better model of how they actually work.