Digital health needs dogfood not disconnect
Like many clinicians I went through my career generally bemused by the weird digital systems we had available to do our job.
I remember once working in a hospital pharmacy which had a license to a large international dispensing program. It worked OK for most patients, but if you opened the record for a frequent flier you would have to walk away from the computer, go and do something else for 5-10 minutes, then come back when it loaded (it would often just crash).
With another system, we used to have a technician who had to manually click through an electronic medications platform and click "reviewed" on prescriptions which did not have a pharmacy service allocated, because otherwise there would be a review backlog and the system would slow down.
One very high budget project had a fault where patient data imported from other systems was sometimes missing. To its credit, it could identify that the record count didn't match between systems but didn't know what was missing, it could be a patient appointment or a cancer result, you would never know.
Rather than delaying implementation or fixing the underlying problem, the solution to this problem was a pop-up warning saying, "some medical information is missing, look at other records".
As you would know, the odds of a doctor, nurse or pharmacist reading the popup, then actually acting on it are about zero...
The Root of the Problem
I could go on all day about clinical information systems I have encountered which do stupid things, and in my opinion, it is all caused by the same problem.
These big enterprise systems are built via a big project involving teams of business analysts and expert clinicians (who often haven't worked in a hospital or clinic for decades).
The project then builds a system that looks great on paper, but if you use it every day you will start to see thousands of little things that can be improved. The issues might not even be apparent until a few years of use, and usually aren't obvious to the people who make the platform unless they use it day to day.
A great deal of money might be spent pulling clinicians from the floor to sit in workshops and writing lists of thousands of requirements, but when that is all done you are still passing a transcript to a development team, who have never worked in a hospital, and then expecting them to translate that into practice effectively.
Clinicians themselves don't even know what they want. They are not developers, they don't know what is even possible on the platform, and it is extremely difficult to conceptualise what it is that you need unless you are right in the thick of a ward round or dealing with a backlog of discharges.
At that point though, you don't have the time to get your thoughts on paper to pass on to the development team.
Instead, clinical staff tend to work around small problems they have because it is too hard to get your message across at the time when it is needed (and still fresh in your mind).
The Challenge of Feedback
That has been the struggle we have had, we often survey people using Clinical Branches and routinely get the same feedback "It works great, I can't give any recommendations".
I know that is a lie, there will have been moments when people use the platform where it hasn't done what they needed it to, but the bar is set so low in health tech that they just work around it like they have with other health technology systems.
That is where dogfooding comes in.
Dogfooding, or 'eating your own dogfood' is a term used in the software industry for software development teams who use their own software. Typically, this is done with things like cybersecurity platforms or customer relationship management platforms, but I rarely see it done in health tech.
We have been dogfooding for quite a while now, by building pathways for use in other services, by using the clinical credits system to track our review process, and by using the platform daily for patient prioritisation. Other services have also been 'eating our dogfood' and making recommendations right at the point when something has been bothering them. This is because they can speak openly clinician to clinician through an email or MS Teams message. No workshops, no business analysts, no barriers to being heard.
We have even added direct feedback mechanisms within the platform. System generated hints receive a like or dislike just like in YouTube and Facebook. This has uncovered some great improvements.
A good example was just a few weeks back.
A hint was being generated by Clinical Branches identifying a spike in creatinine (which may signify deteriorating renal function), but it was being downvoted for low body weight patients.
It turns out that it was falsely identifying malnourished patients who initially presented with a low creatinine level, and then had levels return to normal after being fed well in hospital. In this case a rising creatinine was a great thing, not a sign of imminent renal failure at all.
This type of insight would not have been possible without a strong connection to the hospital floor, you just can't workshop effectively for things like this.
I can say unequivocally that the insights we have gotten from using our own product have been more insightful than what you can get from millions of dollars workshopping and surveying clinicians.
A Call for Change
If we keep doing things the same way we are just going to end up with more of the same.
For this reason, I am interested in starting a new role here in Kraken Coding, filled with clinical software developers. We are certainly keen to find other clinicians out there who have a passion for eating their own dogfood.
I think this is the way health software needs to be developed.
Coding is getting easier with introduction of LLMs, and I think this opens opportunity for a new role in healthcare that is sorely needed.
If you share the same thoughts then please shoot an email through to info@krakencoding.com
Written by John Shanks - Antimicrobial Stewardship Pharmacist and Software Developer at Kraken Coding