Dr Beena Raschkes , Joint IT Clinical lead NHS Tayside October 2010 Clinical Portal Dr Beena Raschkes , Joint IT Clinical lead NHS Tayside October 2010

What is a clinical portal? Patient journey Communication Access to information Good Governance

Why do we need a clinical portal? “There is nothing wrong with change, if it is in the right direction” Winston Churchill

Top 14 Information choices

Patient Information Patient demographics Current problem list Past medical history Current medications Allergies Alerts

Letters Referral letters Outpatient clinic letters Hospital discharge letters

Results Laboratory results Radiology results and Images Other Diagnostic test results

Guidance eBNF ( British National Formulary) Local Guidelines National Guidelines

“ Commonality Supports Change“ Col PSM Rawlinson OBE

“Change is inevitable - except from a vending machine.“ Robert C. Gallagher

Key Challenges & Risks Information Governance Data Items Availability Data Quality/Standards Real Time Information Demographic Service: quality and reliability of the service. Financial: affordability and the potential implementation cost; Resource: availability of both technical and clinical resources to implementation; Infrastructure: due to geographic distances.

Key Challenges & Risks Information Governance: accessing GP data would benefit from a consistent approach to data sharing procedures Real Time Information: to ensure that portal users are confident information is accurate and avoid the need to access separate source systems. Data Items Availability: enabling the Top 14 data items to be accessible to a portal across the majority of Health Boards. Data Quality/Standards: as information is made more widely available and there is a need to agree consistent data standards.

Disparate and Individual Practice Data Entry in GP Systems Patient Summary – Available for Migration Patient Clinical Data Patient Clinical History Application Read Code Prioritisation Applied Data Sharing Incomplete Inconsistent Inaccurate Misleading No National Standard Applied No National Guidance Poor Data Entry Training Differing GP Systems Not Fit for Migration Disparate and Individual Practice

Emergency Care Summary Phase II SCI-Gateway Referral SCI-DC Data Sharing No National .Standard No Data .Governance .Framework No SEF Patient Summary Incomplete Inconsistent Inadequate Misleading Clinical Portal Patient Clinical History in GP System GP  GP Transfer Patient Portal Emergency Care Summary Phase II Local Systems Significant Clinical Risk and Compromise to Patient Safety

Patient Clinical History in GP Systems Audit Programme Patient Clinical History in GP Systems Defined Data New Patient Summary Consistent Current Reliable Accurate Fit for Purpose Fit for Migration Applicable to all .GP Systems Reducing Clinical Risk and Improving Patient Safety

Emergency Care Summary Phase II SCI-Gateway Referral Data Sharing National .Standard SEF Provides .Benchmark .for Data .Governance Supports .General .Practice .Adoption SCI-DC Patient Summary Consistent Reliable Accurate Fit for .Migration Clinical Portal Patient Clinical History in GP Systems GP  GP Transfer Patient Portal Emergency Care Summary Phase II Local Systems Reduces Clinical Risk and Improves Patient Safety

The vision To improve patient journeys and quality of care Maintain patient professional and public trust with a robust Information Governance model Ensure access to clinical records is appropriate and legitimate Peer review and guidance (e.g.”rule setting”) is essential if this is to deliver improved patient care and safety.

Information Governance Background Clinicians need to share information to treat patients safely. Some clinical information is very sensitive. We are obliged to protect the confidentiality of patient data. We need assurance that access to information is always legitimate. Information Governance to protect clinical information might be achieved using the following principles: The relationship of the health care professional to the patient The location of the terminal The current activity or location of the patient The role of the user The type of data to be seen

RESTRICT WHAT YOU SHARE 1 VIEWING FILTER 1 1 1 VISION 360 DATA HUB 1 1 1 1 1 1 1 1 1 1 1 PRACTICE FILTER Currently data is displayed via the Vision 360 Patient Summary web based application. In the future, certain applications like Adastra will be able to view the data directly from their application. 010 1 1 1 1 1 1

Concentric overlapping controls Concentric overlapping controls could be used to provide the necessary protection Ethics and training Role Based Access Event Based Access Control Event Based Access Control is a new concept which enhances existing protection of clinical information to meet the needs of an integrated Electronic Patient Record Patient Record

Ethics and Training Staff are required to complete modules: Staff need regular reminding of their professional obligations Ethics & training: All clinical staff are bound by professional ethics which act as first protection for patient confidentiality Staff are required to complete modules: Information Governance Data Handling Data Protection Freedom Of Information Regular updates on Information Governance issues through staff bulletins and staff magazine Access for staff to Information Governance Policies, procedures and guidelines Reaffirmation of IG responsibilities individually to staff who have been authorised to use encrypted laptops and USB memory sticks within an Organisation

Role Based Access Control RBAC principle: Users can access a record if they have the appropriate role and status in the NHS. 2009 Scottish Government Health Dept RBAC Model Information Category Roles Clinical Professional Clinical Admin Healthcare Admin System Administrator General patient information  Summarised clinical information Full clinical information Only for authorised user Highly sensitive information Non patient-related information Role based access control is embedded in many systems across NHS Scotland.

Event Based Access Control (EBAC) An enhancement to the RBAC approach based on patient events EBAC Principle: Clinicians can only access a record when a patient is in the care of their area of the NHS and they have a legitimate clinical relationship with the patient . . Event base rules look at key events along a clinical pathway such as: Referral into Secondary Care Outpatient Appointment And within a set time frame as well as organisational information of individual accessing record: Speciality/Pathway (ENT, Cancer Pathway) Relationship to Patient (Doctor, Nurse) to assess if an access is legitimate. Benefits Adds a time bounded dimension to controlling access Compliments the RBAC model by defining who might be an ‘authorised user’ Combined with RBAC and audit controls gives a high level of control

Event Based Access Control An example shows how EBAC works Illegitimate: Access -Denied Individual is a Waiting List Coordinator of an unrelated speciality, accessing records a year after discharge….Happens to be a friend of patient who asks him to look up some results. Legitimate Access: Individual is a consultant in cardiology and is assessing a new referral Dr John Smith Cardiology Consultant Mr David Evans Oncology Waiting List Coordinator Health Care Professional in Cardiology access Patients details in Clinical Portal on the 13/03/2009 Health Care Professional in Oncology access Patients details in Central Vision on the 13/03/2010 GP Referral Into Cardiology 12/03/2009 Added to Waiting List 14/03/2009 Book OP Appointment 28/03/2009 OP Appointment 23/04/2009 Discharge 23/04/2009 Patient CHI: 12345678

Access Rules (under development) In depth analysis established a rule set that is straightforward and feasible. High level examples are as follows:- Hospital access is time restricted starts when a patient is referred/presents to hospital/clinic Up to 30 days after discharge. Hospital access to records of patients with Long Term Conditions lasts while they continue to attend hospital clinics. Access requested by clinicians not associated with the speciality to which a patient has been referred will be investigated.

The Future … Implement in phases as both technology and understanding of EBAC rules evolves Phase 1 – Audit Control Phase 2 – Preventative Control Develop functionality that will query exisiting records to detect illegitimate access. Establish process to report and investigate incidents. Build on issues encountered to Refine EBAC business rules and Train staff Build EBAC security into Clinical Portal to control access in real time. Provide access for legitimate clinical follow-up, and a ‘Break Glass’ facility for exceptional circumstances. Deploy process to investigate all ‘Break Glass’ incidents. Sanctions and communication