Medicine has been around for thousands of years and throughout the vast majority of this time, it has gotten on fine without computers. Even today, more medical practices use good old-fashioned pen and paper than electronic systems. Even though there are many important and potentially life saving advantages to using these systems, users will only […]
Medicine has been around for thousands of years and throughout the vast majority of this time, it has gotten on fine without computers. Even today, more medical practices use good old-fashioned pen and paper than electronic systems. Even though there are many important and potentially life saving advantages to using these systems, users will only adopt them if they can see the benefits. The greatest impediments to this are poor performance and unreliability.
At first glance, this should be obvious. If a system is unreliable, users will not want to use it. If a system is unavailable when they need it, the very nature of medical care will require them to revert to tried and trusted pen and paper. Speaking of trust, the less reliable a system is, the more likely users are to lose confidence in it, feeding into the normally strong desire to return to the ‘old way of doing things.’ This is not human fallacy or laziness. A physician in an emergency situation is not going to resort to a tool they don’t trust and a tool that is untrustworthy and unreliable has no place in an area as serious as medical care. Consider the hypothetical scenario where you are lying twitching on a hospital bed, in anaphylactic shock, unable to speak, to inform the doctor that you suspect there might have been peanuts in your lunch. Do you want your potential saviour reading your allergies list off a computer that keeps crashing or off a clean sheet of paper pulled from a file?
Performance is equally important. If an electronic system is slower than the old way of doing things, users will not embrace it. If it takes two minutes to pull down your patient list when you can just read it off a white board, you will be forgiven for putting down the iPad. More seriously, in time critical scenarios, it is simply dangerous to force a physician or patient to wait for a slow system to respond.
All this is a long way of stating that, if healthcare systems are to provide real benefits to patients and medical practitioners, then at the very least it must be more reliable and performant than the systems they are replacing. Otherwise, in the bestcase scenario, it will not be accepted. In the worst case, it can cost lives.
So how then, in Infocare, do we reach this important standard? Firstly, there are hardware considerations. The brick and pipes that make up the physical system are critical to a good quality framework and merit a blog of their own. Today, we will discuss the software. Well designed healthcare software will follow some basic rules to ensure it is always available and will reply promptly when requested.
Rule one of reliability is to ensure errors are handled correctly. It is a fact of life, that things will inevitably go wrong. No system has ever been built that can 100% guarantee that nothing bad will ever happen. A user might enter bogus data, or accidentally abort an important process, or misuse the interface. A network connection might die, or a third-party service could go down. In every case, these errors and glitches should not be allowed to take down everything. In digital systems, the default behaviour upon encountering something anomalous, is to shut down, often reporting a bewildering error to the user. But a properly designed framework will capture these errors, report something useful to the user and attempt to either recover, or else protect the rest of the system from falling over.
Take for example, the infamous HTTP 500 error, often the last thing seen by users of a buggy website before they vow to never visit it again, while the owners desperately try to reboot the server before other people notice something has gone wrong. A reliable system will capture the fault, recover the service and return a useful, friendly message to the user. It will attempt to fulfill the request, or any part of it that it can and also alert the administrator to the problem so it can be investigated promptly. In the image below, see how a popular website like reddit handles such scenarios.
Compare this to the default behaviour of less well-designed websites:
Clever systems will attempt to anticipate errors before they happen and head them off. We call this defensive programming. If, for example, a patient’s date-of-birth is in the future, or their social security number contains letters, we can add code to validate these inputs and request the correct information before it enters the system and potentially cause more serious issues. We can check that data exists, is valid and is consistent, before processing it, thus avoiding what is known to programmers as null pointer exceptions, the cause of so many server crashes. The more failure scenarios we can predict, the more we can prevent from tripping up the system.
In Infocare, we make sure to validate data from users and from third parties before processing it. We check for the availability of services before calling them and we attempt to anticipate failures before they happen. In the rare cases where errors do occur, we handle them gracefully, contain the effects, log it and provide meaningful feedback to the user. As well as being reliable, healthcare systems must perform well. In this area, there are a few good practices that we follow. The golden rule of performance is ‘if you don’t need it, don’t fetch it’. If a physician needs a patient’s insurance information, don’t bring their entire medical record along as well. If they need an address, they just get that. Systems often grind to a halt under the strain of trying to retrieve and transport too much information, much of which is not even needed.
The second, rather complementary rule of performance is ‘Don’t fetch it more than once’. This is better known in software development as caching. There is no sense in constantly requesting information that doesn’t change. A patient’s insurance or home address is unlikely to change during the course of a consultation, so once we have got it, there is no need to keep asking the server for it every time the user moves around the application.
At Infocare, we endeavour to ensure that only the information the user needs is fetched and processed, and nothing else. We identify data that only needs to be fetched once and cache it. In doing so we can be certain that our products will respond as quickly as possible and not add unnecessary load to your network.
A good healthcare system is always available when you need it and responds promptly when queried. Sticking to the guidelines described here has helped us produce software that users want to use and extract real value from. That is a win for us, our customers and their patients. Now that really is a good performance.
Writer – Technical Development Team