In this section, I argue 3 fundamental challenges faced when building healthcare software.
The first challenge of building healthcare software, is the complexity of modern care.
For example, Practice Management Systems, (such as MedTech 32), can include the following features:
| Patient Records | Storing a complex record of patient history |
| Appointment Management | Scheduling patient appointments |
| Invoicing | Generating and sending invoices to patients |
| Claims | Claiming subsidisations from the Government for medical services provided. |
| Prescriptions | Creating and verifying that prescriptions are safe |
| Patient Population Analysis | "How many of our patients are under 30 and smoke?" |
| Decision Support | Providing references and resources about specific conditions when needed. |
| Staff Scheduling | What shifts are our staff working? |
To ensure these features work, it has to integrate with many institutions - this answer from my survey of New Zealand GP's who are interested in IT said it best:
"As GP practice is so complex with its interactions with so many organisations the PMS has to be able interact with DHBs, Private organisations, Insurance companies, ACC, PHO, MOH (Immunisations, GMS), NHI look up, eSA, eSAM, GP2GP transfers etc"
The scope of functionality and responsibilities a PMS system has is huge. In the world of software development, software like this can be considered to have a 'monolith structure'.
This has the effect that it leads to strange dependencies. For example, you could argue that appointment management and patient records should be handled by the same system. The doctor should be able to view their next appointment, click on it, and automatically open up that patient's file. They should be able to view when the patient next has a scheduled appointment. Likewise, the appointment management tool needs to get a list of current patients,
With that same logic, you could argue that the tools used to analyse your patient population (e.g., "How many cases of the flu have we seen this winter?", "How many patients over 30 are smokers?"), should be connected to your patient records. It makes sense as the analysis tool needs to get its data from the patient record database.
However, this means that your analysis tool is dependent upon your appointment management system. Say if you made a change to your appointment management system, which caused the program to crash. Now you can't use the analysis tool until the bug is fixed.
The other downside of this monolith structure is that it makes it harder to specialise. Let's say you had a fantastic idea on how to improve the patient appointment process - your software could reduce missed appointments by 10%, and the office staff will find it a joy to use. If you went and built this system, it couldn't be easily swapped into their existing system, as a replacement for their previous appointment management tool. If you want to get a clinic to use your system, you'd also have to build all the other parts of a patient management system - patient records, invoicing, prescription management - all of it.
Modern healthcare is complex. However, what makes this even worse, is the variety of healthcare.
Healthcare is surprisingly regional. Earlier I talked about a variety of organisations that a PMS systems have to interact with in New Zealand. If you built that product and tried to bring it to another country - you'd quickly find that they have an entirely different set of organisations to interact with.
Even within nations, such as New Zealand there exists a lot of regional variety. We have a number of 'shared care' record systems. The start of an EHR system - services which store a simplified medical record, which can be accessible at authorised medical locations, such as after-hour clinics, hospitals, and paramedics. Within New Zealand, we have three separate systems - SharedCareRecord, Whānau Tahi and HealthOne.
Variety also exists within users. Karsh et al (2010), state that a user's needs of their software can change tremendously between:
Different medical professionals vary in the information they need to consume and store. For example, your specialist treating your eczema will be interested in very different information, to your physiotherapist treating your cycling injury.
Even when two parties are interested in the same information, they can need to view and interact with it in very different ways. When your pharmacist views your medication list, they want to find out how much medication they can give to you. However, when a paramedic looks at a medication list, they want to know if you've recently taken any medication which could affect the emergency situation. This requires completely different user interfaces, with completely different interactions.