Accessing Personal Information on Patients and Staff:

Accessing Personal Information on Patients and Staff: A Framework for NHSScotland Purpose: Enabling access to personal and business information is a key part of the NHSScotland Information Assurance Strategy and access cuts across many areas identified by boards for focussed improvement activity. For example: Acknowledgment that the ability to successfully apply sanctions against individuals depends on the robustness of board polices and procedures [e.g. on how access permissions should be agreed and being clear on identity ] General support for introduction of a software package which could assist with system audit of staff activity [e.g. on audit trails which cover access activities] Robust methodology in place to assess the business impact of access to information and apply the correct protection [e.g. to use technical controls combined with greater staff awareness] The NHS holds more personal information by volume - on both patients and staff - than any other organisation in Scotland. Much of this information constitutes sensitive personal data and needs to be captured, managed, stored and disposed of securely in accordance with the Principles of the Data Protection Act 1998. But the information is of no value unless readily accessible to clinicians and other staff tasked with providing healthcare. Recent investment in tools such as Clinical Portals and Single Sign On are designed to enable greater information sharing and access. A balance needs to be struck between protecting privacy and reducing security risks, with the need to access information quickly in a complex healthcare environment heavily dependent on Information and Communications Technology (ICT). The aim of this document is firstly to provide an access framework comprising ten interconnecting components or spokes (see Fig 1) to help organisations achieve this balance, and secondly to outline the practical steps that support the access framework. 1

Fig 1: The ten interconnecting components that enable access Accessing personal information: framework * Access here describes logging onto any IT systems which holds data as well as viewing or processing it in any way. ** data ; in this context is used to describe the digital component parts (which may be just codes, names, numbers) which when taken together form information on an individual. Although the prime focus here is on information held digitally, the 10 components described below are still just as valid for the paper file environment. One of the many advantages to accessing information electronically is that the audit trails are more granular and sophisticated and can be used to check that each access activity is within the agreed rules. 2

1) Patient Consent all access must respect any informed decisions made by the patient 2) Clear Identification all access is from named individuals who are who they say they are 3) Appropriate Authority all access is authorised by a suitably qualified person 4) Legitimate Relationship all access is based on a legitimate relationship with the patient 5) Clinical and Business Need all access is on a need to know basis to provide healthcare and associated business services 6) Time-bound - all access is related to the period in which there is a relationship, as well as clinical and business need 7) Legal Requirement - all other access is in accordance with the law 8) Technical Control all access permissions are replicated as far as possible by technical controls that prevent unauthorised access Description of each component 9) Audit Trail access activity by staff on systems is recorded and monitored 1) 10) Patient Accountability Consent all access all staff must are accountable respect any informed their decisions actions when made by privacy the patient or security breaches occur 1) Patient Consent all access must respect any informed decisions made by the patient The NHSScotland Code of Practice on Protecting Patient Confidentiality sets out the ways in which patients can provide consent to disclosure as well as circumstances where access can be obtained without consent (e.g. vital interests of subject in an emergency situation or where there is incapacity). Consent also needs to be informed: i.e. patient is clear which part of the clinical record is being discussed, the purpose for sharing and those it is shared with. During routine clinical care express permission to share is not usually required as most patients understand that their information must be shared within the healthcare team. 3

Patient consent is an ongoing process and based at the point of care: any verbal or written evidence from a previous care cycle may need to be revisited. It is not always possible to physically separate some types of data in order to respect patient disclosure decisions. In such circumstances there needs to be a dialogue: i.e. explanation that effective care cannot be provided without access to several linked data sources or documents. Any decision within the organisation, or at a national level, to capture new types of personal information on patients and staff (or to allow a wider group of professionals access to existing information) needs to take into account privacy and consent issues (i.e. commissioning and then acting upon Privacy Impact Assessments). 2) Clear Identification all access is from named individuals who are who they say they are Identity management is fundamental to the operation of access policies. It needs to be clear which named individual is accessing the data at any one time (e.g. by unique identifiers). The named individual needs to be working in an official capacity whether it be temporary, contracted or permanent for the NHS and to have signed statements recognising access principles and local policies. Password sharing and generic accounts linked to job titles or teams seriously undermine all the access principles and security. Solutions such as single sign-on enable staff to work more quickly and remove the common reasons for noncompliance (e.g. cannot remember multiple passwords) but can also increase risks if real identity is not clear. There needs to be clarity over naming conventions across multiple systems and staff directories to minimise the risk of persons being confused with others and duplicate identities being created. Joiners, movers and leavers processes need to be orchestrated across corporate services especially ICT, HR, Finance and Estates so that the list of personnel with access to systems is up to date. It needs to be clear how far employees are responsible for updating their own credentials and whether any changes made are synchronised across multiple staff lists (e.g. email address book and corporate 4

directories). Staff need to be removed from systems quickly and to have handed in all assets once they have left the organisation. 3) Appropriate Authority all access is authorised by a suitably qualified person The permission to access particular systems, applications, datasets or data segments needs to be granted by a suitably qualified person with the correct level of authority. These decisions need to be formally recorded and reviewed. The registering authorities (e.g. managers, application and asset owners, clinical leads etc.) making decisions may need to view any relevant background information to confirm the identity and employment status of the person requiring access (e.g. student, locum, contractor or permanent). HR systems will hold evidence that formal checks (e.g. Disclosure Scotland) have taken place. Formal change and review processes need to be in place so that permissions can be added or rescinded quickly when circumstances change (e.g. when a person is no longer performing the same role or has left the organisation). A log needs to be kept and reviewed of access permissions relating to individuals rather than to generic job titles: e.g. a clinician may perform several roles which are different from someone with the same job title or grade. The authority needs to make clear to the employee exactly what the access permissions mean and whether access is read only or gives the ability to modify or delete. For example, an employee should know that although doors to some rooms are left unlocked (i.e. the technology enables browsing across multiple records) entering them would go beyond the access permissions granted. And that the employee would need to justify what appears on the audit trail at all times. 4) Legitimate Relationship all access is based on a legitimate relationship with the patient Relationships with patients take many forms; ranging from regular visits to the same GP, several hours spent with a large team in Accident and Emergency, to a single contact with a Health Visitor. The common denominator is legitimacy: the staff clinical and administrative need access because they are directly involved with the person s healthcare. 5

It needs to be clear that simply having a family or personal relationship with someone does not constitute a legitimate relationship. Accessing information on partners, family members, friends, work colleagues, associates, neighbours etc. constitutes a serious breach of confidentiality. Personal life needs to be separated from professional roles when accessing information at all times. Accessing one s own healthcare records also constitutes a breach of confidentiality. Data Subjects, including healthcare staff, can access their own records using the official routes (e.g. Data Subject Access request). This ensures that the privacy of third parties is protected and that the medical and other exemptions on disclosure are applied where necessary. 5) Clinical and Business Need all access is on a need to know basis to provide healthcare and associated business services Staff with a legitimate relationship should only access the data which they actually need. Most patients are aware that allowing access to various datasets held locally or nationally (e.g. allergies data held in Electronic Care Summary) is in their clinical interests. But in other cases the need to access data can be less obvious: e.g. for a secondary care clinician to access GP notes from a patient s childhood in order to fully understand the context in which a medical condition arose in adulthood. It is important to have a dialogue with the patient as to what data is needed and why. There is a complex network of support staff, such as medical secretaries acting for hospital consultants, records managers and technicians, who play a pivotal role in ensuring that data is presented to clinicians in a timely way. In such cases it needs to be clear that they are accessing specific data on behalf of clinicians for a particular patient s need. Accessing patient-identifiable data for medical research needs to follow formal procedures: i.e. obtaining Caldicott Guardian permissions and data anonymisation. 6

It is not always technically possible to segregate strictly administrative data from clinical data. But it is vital to distinguish between direct clinical need and secondary purposes when accessing data: i.e. personal identifiable clinical data should not be used in order to perform tasks such as financial planning. 6) Time-bound all access is related to the period in which there is a relationship, as well as clinical and business need Most healthcare activity is time-bound and event driven. Access should only occur during the period in which there is a clinical relationship which might be minutes or decades. Access permissions should not be granted on a just in case basis. Instead, the authority will need to look at the roles being performed within a limited period. For example an access permission might be for system A; but only for patients being treated. The employee has the flexibility to access data on a new patient for example without having to ask for new permissions or change technical controls each time. Matching up the audit trail with the dates of care would flag up where the employee has gone beyond his original permissions. Some applications and systems are directly linked to a specific area of healthcare (e.g. sexual health). It is essential that when an employee moves to another area of work that the permissions are reviewed (and if necessary revoked) rather than simply adding to them. Such snowballing of permissions provides far more access than is actually required and increases privacy and security risks. Although access to information is for a limited period the clinician may still need to read older records within that timeframe (e.g. specified staff may need to access medical histories from different sources during a patient s two-week stay in hospital). 7) Legal Requirement all other access is in accordance with the law There are special circumstances where patient consent is not required to access information: i.e. vital interests of a patient and where it is in the public interest. Examples might be the disclosure of information to the police to help in the prevention and detection of crime or to assist in the planning of public services. Such a decision is not taken lightly and a health professional will need to balance the interests of the patient (and any third parties) 7

with the wider public interest. The courts, tribunals and other statutory and regulatory bodies also have powers to access a range of personal information. Officials, lawyers and police officers requesting patient data need to provide necessary documentation such as a court order or warrant. Disclosure should not be made just because the person is in authority. There needs to be clear process for approving such requests (clinicians and Information Governance leads) and documenting actions (i.e. exactly what data was approved for disclosure and by whom) To consider data handling issues; whether the original or copy data is provided, whether it needs to be redacted and how it is going to be securely transferred to a named recipient. Regular data sharing with other bodies needs to take place within the constraints of pre-agreed protocols and codes of connections. Access to patient records in order meet other regulatory and professional purposes (e.g. clinical audits for quality improvement and benchmarking) is within agreed rules and needs to be proportionate (i.e. the audit trail will show whether more data was accessed than necessary for the task). 8) Technical Control all access permissions are replicated as far as possible by technical controls that prevent unauthorised access Access permissions are not one and the same as the technical controls that exist in IT systems. This is because it is not always practical or cost-effective to design a set of controls that cover every possible scenario or role. Adding too many barriers or layers of complexity can actually hinder clinical decision making (in some instances putting lives at risk). Even in the physical environment where controls are simpler there is usually a degree of trust: an administrator may not have permission to look at the contents of some filing cabinets (but holds all the keys); or a contractor s security pass is not valid for entry to sensitive clinical areas (but there may not be a swipe card reader to check). 8

In most cases simple front door key controls can be used to ensure there is access only to those persons who need to view data on a specific IT network, system, application or dataset: e.g. you should not be able to sign-on to an application or network in the first place if there is no need/access permission. However, clinical portals, make the situation more complex as they are made up of groups of data-fields or portlets pulled out from several applications. Access permissions still need to be applied to each of the applications that are linked to the portal (i.e. the portal remembers which applications you have access to and can create a new layer of technical controls to replicate them). Some individual applications offer role based or team based access controls offering a greater degree of granularity (e.g. to ensure that persons performing only nonclinical tasks do not have access to clinical data on the same application). However, there are no plans for an overarching national role based access model because of the multiplicity of systems (there is no single clinical record spine ) and no amount of technical roles designed for IT can ever reflect all the situations where there is legitimate, time-bound, clinical need. IT System administrators and some record managers often need to override normal technical controls in order to perform tasks necessary to run the system or manage the data. Here risks need to be mitigated by ensuring that staff with such access are a) kept to an absolute minimum; b) given the correct level of vetting and training; c) required to understand and sign a code of conduct that makes clear that routine administration tasks do not usually require actually accessing patient data. 9) Audit Trail access activity by staff on systems is recorded and monitored The audit trails relating to a user s activity can be used as a powerful tool to check that access to patient data has been in accordance with permissions. Basic activity (such as login details, dates, items viewed etc) is gathered automatically. Monitoring, of which audit logs are part, will follow Lawful Business Practice Regulations. Automated activity audit logs are extremely accurate. But if the identity of the person is ambiguous any future investigation is seriously compromised. 9

Core NHS systems produce system logs that match up an ID to activity; but some legacy applications have no or limited audit functionality. Employees have a right to know that they are being monitored but not of the exact methods being used or which applications are being monitored more comprehensively than others. Tools can be used to aggregate audit logs from several systems and generate reports which shows patterns in activity. This can be a powerful aid to privacy and security investigations. 10) Accountability all staff are accountable for their actions when privacy or security breaches occur All staff, regardless of grade or position, will need to account for their access to patient or staff data at all times, particularly, where access has gone beyond the legitimate, timebound, clinical need principles. Ignorance or pointing to the absence of technical controls is a weak defence from staff being investigated, given signed codes of conduct and assurance prompts when logging in. In some cases the system may even generate automatic warnings designed to deter staff from inappropriate access activity. Audit trails are a means rather than an end in themselves. They need to be taken with other contextual business data to ascertain whether unusual activity constitutes a privacy or security breach. The severity of the privacy/security breach and therefore any disciplinary action will be measured in terms of actual or potential impact rather than any simple algorithm (e.g. a single instance of accessing data on one application may have more potential impact than dozens of activities on another). Each audit event (or pattern of events) will be reviewed by appropriate personnel to assess whether any formal investigation which may lead to disciplinary action should take place. If this is deemed necessary, Local Board disciplinary policies and procedures will then be followed. 10