PC Services

"From Payroll to Body Scanners"

Established 1994

PC Services (Electronics)

Computer & Electronic Design Consultancy

Tel: 0118 946 3634
Email

Problems with Medical Practice Management Databases in UK

Legal Note

No companies or software products are named here, so for any wannabe lawyers out there as no party is identified, you have no grounds.

Practice Management Software and the GDPR

25^th May 2018, is not so far away and the General Data Protection Regulation (GDPR) comes in to replace the Data Protection Act.

As part of software and servers review ongoing for some of my customers and their wish to go for all electronic documents, I have had dubious honour to analyse various aspects of deploying Practise Management Software to medical practices with all the problems, then the capabilities or even the plan to comply with GDPR.

Ignoring many installation issues that demo packages being setup did not work correctly 'out of the box', until some silly tweaks had to be made, the outcomes were not that encouraging. The full 18 page report is purchasable here, an overview of my findings from multiple packages are outlined in brief below.

1. Introduction
2. Security
   • Authentication
     • System Login
     • Application Login
     • Database Authentication
       • NO Authentication
       • Windows Credentials
       • root/sa password only
       • Several different levels of access
     • Passwords
   • Encryption
   • Breach Detection
3. Well Thought Out
4. Efficient
5. Remove Repetitive and Infrequent Tasks
6. Well backed up
7. Conclusions

Introduction

These problems have been noted on UK deployed Medical Practise Databases, but may also occur in other countries.

On and off over the last year, I have been evaluating medical practice software for some of my customers, with the view of going to all electronic forms and operation. Most have been rejected mainly on security and data integrity grounds.

Why are these issues VERY important?

• General Data Protection Regulation (GDPR) comes in force (25 May 2018)
• Which means -
  • You must notify the Information Commissioner of data breaches within 72 hours
  • Insecure setups could end up with up to 10,000,0000 EUR fines
  • Encryption of data is really a must to prevent problems
  • Holder of data must notify all affected people of data breach if data not encrypted
  • Must show they have technical efforts to stop, detect and remedy data breaches

You would think that software for Medical Practices was

• Secure
• Well thought out
• Efficient
• Remove repetitive and infrequent tasks
• Well backed up

Most of them concentrate (as with most software) on the front end, the pretty bits not the nitty gritty bits behind where the data is stored.

Small practices dominate the number of sites in the UK at least, these generally range in size from 2 (medical practitioner and receptionist) to around 30 staff (practice manger, medical practitioners, nurses, receptionists, etc.). Don't let these sizes fool you as to complexity of tasks and sizes of databases as each of these practices could be dealing with records for 1000 to 30,000+ patients, all of them need access to the databases and at differing levels of access rights.

Each visit by a patient could create extra records in several files or tables, from medical charts and treatments, through prescriptions, appointments, notes, letters to payments (by patient and NHS).

Security

This comes in the main layers (as with most software and usage)

1. Authentication
2. Encryption
3. Breach Detection

Authentication

Authentication comes in many layers some hidden in the software or operating system.

System Login

Despite the preferred need for this to have a password (for when system is disposed of or theft amongst other things), majority of small practices PREFER to run without windows/system login passwords. Mainly due to that is the way they have always done it or how they do it on their home systems.

Due to quite a lot of software being badly constructed, their software has to be run either with Administrator level privileges or as an Administrators group user. This means they have ability to do many potentially damaging things or malware or hackers can have easy access to whatever they want.

This has knock on effects discussed later.

More details in full 18 page report is purchasable here,

Application Login

Whilst MOST practices do enforce different usernames based on the person not the machine or its physical location many have blank passwords. So once you know the username naming convention you can usually guess other usernames.

More details in full 18 page report is purchasable here,

Database Authentication

This minefield is often implemented BADLY as the software developers are

• NOT database developers
• NOT system security experts

Because the main database is connected via the network to a server or a workgroup system being used as a workstation and database server (slowest and worst configuration), the connection over the network has to be authenticated to prove a valid application is accessing it. However many schemes of database authentication are used by different vendors -

1. NO Authentication
2. Windows Credentials
3. root/sa password only
4. Several different levels of access (not seen in use for Medical Practice Database)

That list is in order of worst to best security for the database and application, then ultimately the practices' benefit (along with patients).

More details in full 18 page report is purchasable here,

NO Authentication

Yes, a few use NO authentication. However these are generally older systems more generally deployed in very small practices, often as private patients only.

More details in full 18 page report is purchasable here,

Windows Credentials

Usually in a windows domain uses windows login name and password to determine if they are allowed to access database. The main problem with this is that due to

• Most windows logins have no password
• Most sites have the receptionists system acting as the server as well as being used for normal operation
• Most application software has to run at administrator level or in administrators group
• The user is logged into active login session that can load malware

Anybody can have malicious software or hackers via back-doors or Trojans accessing the database at will.

More details in full 18 page report is purchasable here,

root/sa password only

'root' and 'sa' (short for system admin) are the Linux and Windows methods of denoting the highest level of user in the database. That is they can do anything including delete the whole database. No doubt the username and password when used as this can be found easily hard-coded in the actual software.

More details in full 18 page report is purchasable here,

Several different levels of access

This has not been seen in use for Medical Practice Database use but should be! In some cases it may be but in most cases observed, it was possible to ascertain the level of access was the same for all.

More details in full 18 page report is purchasable here,

Passwords

More details in full 18 page report is purchasable here,

Encryption

With the EU wide (including UK), General Data Protection Regulation (GDPR) coming in force on 25th May 2018, there are requirements to have technical solutions in place to stop data breaches, notify Information Commissioner of data breaches and ensure data is unintelligible if copied.

So one of the major issues is ensuring data is encrypted which few are doing at the moment.

Note that with use of electronic forms and PDF documents to email to patients and hospitals for referrals, ALL patient documents should be encrypted as well.

With databases and associated documents saved regarding patients etc. the levels of encryption generally seen in use so far

• NONE
• Drive level encryption

There are in fact three ways to do encryption as doing NONE is not really acceptable

• Drive level encryption
• Database encryption
• Application encryption

With all methods just like having locks on doors you have keys for encryption, so you have to be careful where they are kept and who can read/use them. Then there is the issue of not saving it permanently onto a locally connected system and ensuring it is stored securely.

If your internet connectivity is not very good you need alternative local key storage.

More details in full 18 page report is purchasable here,

Breach Detection

Part of the General Data Protection Regulation (GDPR) coming in force May 2018 is that those holding data must report breaches to the Information Commissioner within 72 hours. This is described at GDPR Breach Notification. Well the problems with that are

• Most practices would not be able to know when or how a non-destructive data breach happened, as this would be a database copy or similar. Especially if a data breach occurred and all logs were deleted.
• Most of the software vendors cannot give you alarms that this has happened
• Most of the support companies for practices do not have the skills to detect this.

The most any user is likely to notice is their system is slow for a while.

More details in full 18 page report is purchasable here,

Well Thought Out

Often finding buttons, panes and setting up is NOT obvious, in some cases different configuration screens or menu options to enable. Lots of fancy 'Quick Access' toolbars, Pop up Panes and other things that seem pretty and cool to developers and salesmen. However this is often difficult to navigate by users, until they have done it repeatedly for three months.

Many applications have excessive data transfers, in some cases list all patients options which for 5000 to 30,000+ patients is excessive.

Many run automated tasks, only when that user is logged in at that system without using operating system features.

More details in full 18 page report is purchasable here,

Efficient

Most are written from the basis of anybody using it is a developer and spends their time maintaining the software not using it for its purpose (see above error reporting on automated processes).

Excessive specifications for network speed, graphics cards, RAM size, using Solid State Drives (SSD). All of these are indicative of badly written software that requires faster and bigger hardware to cope with excesses of software wasting time on unnecessary tasks or excessive data.

More details in full 18 page report is purchasable here,

Remove Repetitive and Infrequent Tasks

Whilst many have thought through some of the front end tasks, many of the back office functions are still lacking.

Many things are done in such a way to be awkward such as

• Block number of days when practice or consulting room is closed can be done depending on the package by
  • for each member of staff
  • Each day individually not from a start to end date
  • both of the above
• Management of Waiting Lists (most practises uses spreadsheets or pieces of paper)
• Assisting with Archiving and removal of old or deceased patients, not even creating archived patients versions of database

More details in full 18 page report is purchasable here,

Well backed up

This proved to be one of the biggest failings of most packages surveyed, and was stuck in the 1980's style backup you would use with a Payroll package. Backups are mainly triggered by a specific user (sometimes on a specific machine) exiting the application and being asked if they want to do a backup. End of day backups assume that things only go wrong over night whilst computers are turned off or before the first patient arrives. Just losing a day's information could be details for 100 to 200 patients for small practices.

When things go wrong, if you do not have a working backup set, then you will have to re-enter the details taking a long time and some details like appointments may not be able to be recovered. Episodes like this can put companies out of business.

More details in full 18 page report is purchasable here,

Live Database Backup and Open File Copying

Many packages expect that live databases being updated at the same time can be backed up at the same time using straight file copy, well you can make a copy which might have the same size and suitable time and date on the file, but the data will NOT BE CONSISTENT more likely corrupted as copying a database that could be 2 GB in size (one file or multiple files) while updates are happening will have different sections copied at different times from the database. At the absolute minimum the indexes (how to find the related data) will be wrong, some data may only be partially copied. Hence use of this backup data set to restore a system that has had problems will create more problems.

This is known as Open File Copying, might get away with it if it is a standalone file like a Word document, for database files or file sets that are much larger it does not work and has been known about for decades. Anybody who has got away with it once did so by a fluke, as the database was not being updated whilst that backup was taken, the vast majority of other backups will have been corrupted and nobody knew.

Most database software has commands or tools to do this and most developers fail to use them in these packages.

More details in full 18 page report is purchasable here,

Cloud backups do not work

First of all you need to be a lawyer to check what their Terms and Conditions mean for you, have a way of vetting a distant company actually has been certified to meet GDPR and other requirements.

Second you have to consider your broadband speed, unless a practice is within 1 km of the nearest exchange, or you have paid a fortune for a high speed link, most practices will have upload speeds of around 500 kbps to a maximum of around 15 Mbps. So the time taken to upload a typical set of database for a practice of

• 2 GB Patient Database
• 20 GB imaging and other types of information

Will be absolute minimum with following wind in HOURS
(yes these speeds are correct for upload speed which is a lot slower than download speed) -

Broadband contention, network delays, local and remote server loadings and many other factors will slow the figures more. Also these figures do not include any other data like programmes and system configurations, emails or anything else.

Thirdly cloud backup should only ever be considered your fourth level of backup and bear in mind some real world experiences

• One system do a full system cloud backup that had not finished its first pass in background a year later
• One customer site that took 7 hours to download 2 GB of the customer's My Documents folder and nothing else.

More details in full 18 page report is purchasable here,

Conclusions

Most applications out there are NOT ready for the GDPR in May 2018. Let alone the necessary security to fully guarantee full compliance with existing Data Protection Act. Most practices and their software vendors and support companies, could not recognise they have had a non-destructive data breach (copy data), at best some users might think their system has slowed down for a while.

I am really surprised that software for NHS practices does not offer Waiting List and Archival of old patients in standard solutions. The rush for most to support electronic documents on the front end means the back end has been neglected.

More details in full 18 page report is purchasable here,