Transcript Document
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.
CURRENT PROBLEM : Dat a Qualit y in
Elect ronic Pat ient Summaries
Data Entry in GP Systems
Patient
Clinical
Data
Application
Read Code
Prioritisation
Applied
•No National Standard Applied
•No National Guidance
•Poor Data Entry Training
•Differing GP Systems
Disparate and Individual Practice
Patient
Clinical
History
Data
Sharing
Patient
Summary –
Available
for
Migration
•Incomplete
•Inconsistent
•Inaccurate
•Misleading
Not Fit for Migration
CURRENT PROBLEM : Dat a Qualit y (in
Elect ronic Pat ient Summaries) –
shared wit h ot her syst ems
SCI-Gateway
Referral
SCI-DC
Data Sharing
Patient
Clinical
History
in GP
System
•No National
.Standard
Patient
Summary
Clinical
Portal
GP GP
Transfer
•Incomplete
•No Data
.Governance
.Framework
•Inconsistent
•No SEF
•Misleading
•Inadequate
Patient
Portal
Emergency Care
Summary Phase II
Local
Systems
Significant Clinical Risk and
Compromise to Patient Safety
PROPOSED SOLUTION: Improving Dat a
Qualit y in Elect ronic Pat ient Summaries
Programme
Audit
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
PROPOSED SOLUTION: Benefit s Realisat ion
SCI-Gateway
Referral
Data Sharing
Patient
Clinical
History
in GP
Systems
SCI-DC
Patient
Summary
•National
.Standard
•Consistent
•SEF
•Reliable
•Provides
.Benchmark
.for Data
.Governance
•Accurate
•Supports
.General
.Practice
.Adoption
•Fit for
.Migration
Clinical
Portal
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
0
1
0
VISION 360 DATA HUB
10
01
100
11
010
VIEWING
FILTER
1
0 1
1 0
0 1
01
10
0 11 0
1 11
0
0
1
0
1
0
1
1
0
1
1
0
1
0
1
1
0
0
1
01 0 1
1 1 1
0
0
1
0
1
0
1
0
1
0
1
0
1
0
PRACTICE
FILTER
Concentric overlapping controls
Concentric overlapping controls could be used to provide the
necessary protection
Ethics and training
Role Based Access
Event Based Access
Control
Patient
Record
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
Ethics and Training
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
General patient information
Summarised clinical
information
Full clinical information
Highly sensitive information
Non patient-related
information
Roles
Clinical
Professional
Clinical Admin
Healthcare
Admin
System
Administrator
Only for
authorised user
Only for
authorised user
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
Legitimate Access: Individual is a
consultant in cardiology and is assessing a
new referral
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.
Dr John Smith
Mr David Evans
Cardiology Consultant
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
Patient CHI:
12345678
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
Access Rules (under development)
In depth analysis established a rule set that is straightforward
and feasible. High level examples are as follows:-
1. Hospital access is time restricted
• starts when a patient is referred/presents to hospital/clinic
• Up to 30 days after discharge.
2. Hospital access to records of patients with Long Term
Conditions lasts while they continue to attend hospital
clinics.
3. 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.
• Build EBAC security into Clinical
Portal to control access in real
time.
• Establish process to report and
investigate incidents.
• Provide access for legitimate
clinical follow-up, and a ‘Break
Glass’ facility for exceptional
circumstances.
• Build on issues encountered to
oRefine EBAC business rules
and
oTrain staff
• Deploy process to investigate all
‘Break Glass’ incidents.
• Sanctions and communication