2. © 2000 D W Chadwick2 Session T27 Securing Patient Specific Data on the Internet for the UK National Health Service Dr David W Chadwick Senior Lecturer, University of Salford d.w.chadwick@salford.ac.uk Tuesday, 2nd May, 2000 4.00pm-5.00pm

3. © 2000 D W Chadwick3 Securing Patient Specific Data on the Internet for the UK National Health Service D W Chadwick, A J Young University of Salford J New Hope Hospital

4. © 2000 D W Chadwick4 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

5. © 2000 D W Chadwick5 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

6. © 2000 D W Chadwick6 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

7. © 2000 D W Chadwick7 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

8. © 2000 D W Chadwick8 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)

9. © 2000 D W Chadwick9 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

10. © 2000 D W Chadwick10 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

11. © 2000 D W Chadwick11 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

12. © 2000 D W Chadwick12 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

13. © 2000 D W Chadwick13 Chosen Architecture Web Browser (Client) Web Server HTTP Requests and Responses Diabetes Register SQL Requests and Responses DBMS Server WAN Secure with PKI Hospital LAN Fire wall

14. © 2000 D W Chadwick14 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

15. © 2000 D W Chadwick15 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

16. © 2000 D W Chadwick16 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

17. © 2000 D W Chadwick17 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

18. © 2000 D W Chadwick18 System Components Client (GP/ Practice Nurse) Netscape/IE + Entrust Direct Client Proxy Hospital Firewall (Checkpoint) Entrust Direct Server Proxy Hospital Diabetes Register Server Intranet Internet UoS TTP Server UoS X.500 Server Entrust CA Firewall MS IIS + CGI scripts

19. © 2000 D W Chadwick19 Validation Testing 36 sets of tests performed July-Sept 1999 X31 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

20. © 2000 D W Chadwick20 The Bad Results XInstallation, 50% within 15 mins, 86% within 24 hrs XEntrust Direct server, 66% available XNote. Possibly due to CRL publication every 4 hours, but never resolved. It eventually disappeared XSalford’s network, 93% available XTime to launch application, 158% insecure XIncorrect update data displayed >50% XNote. A bug in the CGI meant that only the date and not date & time was used to search database. Subsequently fixed.

21. © 2000 D W Chadwick21 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

22. © 2000 D W Chadwick22 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

23. © 2000 D W Chadwick23 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

24. © 2000 D W Chadwick24

25. © 2000 D W Chadwick25

26. © 2000 D W Chadwick26

27. © 2000 D W Chadwick27

28. © 2000 D W Chadwick28

29. © 2000 D W Chadwick29 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

30. © 2000 D W Chadwick30 Any Questions ?