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

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

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

4. Top 14 Information choices

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

6. Letters Referral letters Outpatient clinic letters
Hospital discharge letters

7. Results Laboratory results Radiology results and Images
Other Diagnostic test results

8. Guidance eBNF ( British National Formulary) Local Guidelines
National Guidelines

9. “ Commonality Supports Change“
Col PSM Rawlinson OBE

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

16. 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.

17. 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.

18. 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

19. 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

20. 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

21. 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

22. 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.

23. 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

24. RESTRICT WHAT YOU SHARE1
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

25. 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

26. 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

27. 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.

28. 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

29. 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:

30. 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.

31. 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