© 2000 D W Chadwick2 Session T27 Securing Patient Specific Data on the Internet for the UK National...

© 2000 D W Chadwick 2

Session T27 Securing Patient Specific Data on the Internet for the UK National Health Service

Dr David W ChadwickSenior Lecturer, University of [email protected]

Tuesday, 2nd May, 20004.00pm-5.00pm


Securing Patient Specific Data on the Internet for the UK National Health Service

D W Chadwick, A J YoungUniversity of Salford

J NewHope Hospital


Background - Main Players

• University of Salford - Technological University in Greater Manchester, UK

• Hope Hospital - Large university teaching hospital in Greater Manchester

• National Health Service - Policy setter

• Entrust Technologies - the PKI provider

• EPSRC - UK research funding body

• EC IV Framework - European research funding body


Background - University of Salford

• Building networking software since 1970s

• Worked on ISO, ITU-T and Internet standards since 1982– Editors of ASN.1 and X.500

standards, LDAP drafts• Installed first university PKI in

1996


Background - Hope Hospital

• Serves a population of approx. 0.5 million

• Developed a centralised database application (Diabetes Register) to hold medical histories of diabetic patients

• Holds data on all 5,000 diabetic patients in its region (Salford District Diabetes IS)

• Diabetes Register software is at use 35 NHS districts in the UK

– data on 200,000 patients in UK


Background - NHS

• Funds healthcare in the UK

• Sets standards for health and information systems

• Runs a private intranet for all primary (GPs) and secondary carers (hospitals) - NHSnet

• Strict security policy for connecting to NHSnet

• Patient data must be kept confidential


Salford District Diabetes Information System

• Centralised database only accessible over hospital LAN

• Client-server (SQL) interface also available• Relies on passwords for authentication and

usernames for privileges - different doctors can see different records

• But much information flow is paper based (to all primary carers and some hospital staff)


Primary Care Access to SDDIS

• Paper output sent every year to GP (one page per patient)

• GP sees patient for annual review and sends updated results back on paper

• Hope data entry administrator inputs the updates to the database


Problems with current system

• Long time lag between sending update and seeing output

• Double keying of data (by GP and admin) can lead to input errors

• If patient visits GP before annual review, no current data is available

• Paper mail can get lost or misplaced• Data is not protected during transit, so

potential for breach of confidentiality


Attributes of Solution

• Fully distributed and accessible over a WAN (NHSnet or Internet)

• Strong encryption to enforce data confidentiality in transit

• Strong authentication to ensure genuine users (especially if Internet accessible)

• Must be user friendly for non-IT professionals

• Easy to install and manage


Possible alternatives

• Provide dial-in access to the hospital and one time PW cards– requires new hardware and client for each primary carer

– hospital has to manage modem banks (they are not an ISP, and its not a WAN solution)

• Secure the existing SQL client-server interaction– new client for each primary carer

– interface current system to security infrastructure

• Use a Web browser and secured HTTP traffic– Preferred. Primary carers are used to this interface.

– single access to multiple services

– no special client or hardware needed


Chosen Architecture

Web Browser (Client) WebServer

HTTP Requests

and Responses

DiabetesRegisterSQL Requests

and ResponsesDBMS Server

WANSecure with PKI

Hospital LAN

Firewall


Product Choice

• SSL & Internet Certs vs.– Was weak encryption (40 bits)

– Manual checking of CRLs by client

– Trust is managed by end users

– Manual key backup, recovery and renewal

– De-facto standard

– Low initial cash outlay

• Entrust Direct & own Certs– Is strong encryption (128 bits)– CRLs automatically checked

in client and server– Trust is managed by security

officers– Automated key backup and

renewal, managed recovery– Proprietary solution– High initial cash outlay


Conclusions

• SSL seems good for technically aware users who have time to manage their own environment

• Entrust Direct seems good for naïve, busy users who just want it to work, and where security cannot be left to chance


Architecture Implementation

• Entrust Direct client will sit in users machines• Entrust Direct server will sit in a firewall at Hope

– Permission needed from NHS IA Telecommunications Branch to connect Hope intranet to the Internet via a Firewall

• Direct server will send normal http requests to MS IIS on Hope intranet

• CGI scripts called from MS IIS, make SQL calls to Diabetic Register– Scripts mirror the behaviour of the existing SQL client


PKI Implementation at Salford

• Entrust v4 CA running on NT4

• Protected by firewall running on Linux

• MessagingDirect (formerly ISODE) Directory running on Sun Sparc holds certificates and CLRs


System Components

Client(GP/PracticeNurse)

Netscape/IE+

Entrust DirectClient Proxy

HospitalFirewall

(Checkpoint)

Entrust DirectServer Proxy

HospitalDiabetesRegisterServer

Intranet

Internet

UoSTTP Server

UoSX.500Server

EntrustCAFirewall

MS IIS + CGI scripts


Validation Testing

• 36 sets of tests performed July-Sept 1999X 31 completed, 25% successfully

Revocation 100% success

Entrust CA 100% available

MessagingDirect Directory 100% available

IIS Server & CGI scripts 100% available

Time to learn to use, <8 minutes

Time to initiate a request & get a reply <35s


The Bad Results

X Installation, 50% within 15 mins, 86% within 24 hrs

X Entrust Direct server, 66% availableX Note. Possibly due to CRL publication every 4 hours, but never

resolved. It eventually disappeared

X Salford’s network, 93% available

X Time to launch application, 158% insecure

X Incorrect update data displayed >50%X Note. A bug in the CGI meant that only the date and not date &

time was used to search database. Subsequently fixed.


Pilot Results (User Installation)

• Installation for the 10 pilot users (Nov-Dec 99) was problematical and difficult– Number of unforeseen technical problems

• Problems with most free ISPs wanting calling tel no• Some ISPs blocked traffic we needed• One user messed up initial password entering• Technical problem with Database rejecting one user• One surgery with a LAN needed 4 visits to get it working

– GPs had little time to spend if things did not work right first time

– We had to provide PCs to two of users


Pilot Results (Usage)

Interface was intuitive and easy to use

Performance of data access was fine, but

Dialling the Internet and starting the application was too slow for surgeries

Use of smart cards was abandoned– Difficulties are in IEEE Computer, Dec 99

Made their job more difficult/costly– Had to run the paper system in parallel– Prefer to use paper when with patients– Paper system free, had to pay for Internet

X

X

X


Demonstration

1. User invokes Entrust Direct (icon on Desktop)

2. User inputs secret password

3. Direct invokes Web browser which contacts Web server

4. User sees Welcome Page and may optionally re-register as a different database user to the one used last time

5. User types in patient query (one or more fields)

6. User sees patient details


Updating Diabetic Register

• User may update one of several fields and press send button

• Database is automatically updated

• User may check this by re-reading the patient details


Any Questions

?

© 2000 D W Chadwick2 Session T27 Securing Patient Specific Data on the Internet for the UK National...

Documents

Transcript of © 2000 D W Chadwick2 Session T27 Securing Patient Specific Data on the Internet for the UK National...