I am a GP but I am also a programmer by profession. Just like in medicine, there are archetypal rules in programming. One compelling programming rule I think also applies in medicine is the DRY principle.
DRY stands for ‘don't repeat yourself’. The idea is very simple: if a fork in your development path leads to you wanting to split up where you perform a specific action from one to two places you break the DRY rule. Breaking DRY when you don't need to is a brittle design decision. The decision converts a single piece of truth into pieces of identical truths that both need to be kept in sync. If that truth changes you have to go back to fix your code in two places. As such your team will be saddled with the added complexity.
Don't Repeat Yourself design is commonplace in IT. The concept of DRY design, though, is paradoxically rarely followed in Medicine. It's one of those overlapping concepts that makes combining coding and medicine so interesting.
The decision to break with DRY is not about efficiency.
I see this in IT with the constant tug-of-war between management, comms and the programmers. Like in big IT ventures, many ideas in medicine are top-down and are aspirationally conceived. They often are 'deliver this; then we'll figure it all out later' projects. This happens for many reasons.
The reason this behaviour is unlikely to go away is that the disruptive chaos from bad decisions is both a) hard to measure and b)carves out eddies of opportunity and privilege as now you have something to fix again. These eddies can sustain a localized ecosystem, even if it is at right angles to the broader interest of an organization.
We exist in a communications-focused era where there is a need to be new and flashy. This means that ideas that are not entirely tethered to reality can outcompete ideas that are. Reforming a system is not as flashy as creating an alternate DRY-violating add-on. Given this, Faith-based projections are often enough to trigger a launch. In complex IT organizations, the reality of the need to get products to market periodically resets this dynamic as a balance is struck, or the ship sinks.. not so with health.
Strengthening the sophistication and prudence of 'change' governance to look closer at DRY is a challenging concept to sell. This is too bad because IT design has shown me that it is often more cost-effective to evolve a model rather than build a parallel one IF you are leaving the initial one standing too. When a new bright idea arrives flush with $$$ and opportunity, I have felt the downside of inserting sober contemplation. Being the only voice saying this is inefficient and brittle when 30 other Zoom attendees are 'a go' never ends well. Despite my experience as a full-stack developer steeped in the practice of mopping up the downsides of others breaking with DRY design, I often come off as the only Luddite in the room. It is why I do more programming and less meetings these days.
A 'Luddite's' example...
When I think about violations of the DRY principle, I think about how much more difficult it is now to refer somebody to see a specialist than it was 25 years ago.
Back when we just had fax machines and phone lines, the single source of truth in communication sat at the front desk at your clinic. Things were straightforward. This cleared the path to think more about the patient and less about the process. Since then, there have been improvements. However, with this explosion of contact and collaboration options, some unanticipated problems have also arisen. When you bring in something new that is still not good enough in its conception to replace something old for all use case scenarios you violate DRY design. New, digitally enhanced, referral systems, even when well designed, can unexpectedly marginalize medical practices that are forced to run on underfunded patient enrollment models because they lack the resouces for the intermediary referral brokerage layer these systems anticipate to exist. They can inadvertantly become a kind of a violation of the Canada Health Act as they contribute to digital ghettoization of marginal practices and those practices' patients.
I am not opposed to the "Axe the Fax" movement. It is more that it's disciples have not properly contemplated their role in the need for it's continued existence. Are these the people we are to trust with an axe?
Wrapping up
This blog is intended to reintroduce the notion that we may have, as an industry, missed the cross-over value of DRY as a design consideration and that this may be, in some cases, problematic.
Far from helping, technology may make this tendency to overlook DRY issues worse. It's not that technology is terrible (I'm a full-stack developer, I code in NEXT.js these days - that très cool). It's just that people don't pay attention to sound design anymore. We all give up too quickly on repairing what we have because we are infatuated with novel things. Technology can make lousy design decisions look plausibly good; good enough to get funded. Even if something proves to have been a bad idea in hindsight, once it gets funded, people, their reputations and budgets get attached. This leads to a beginning, a middle, and a long-drawn-out end.
While in play, projects that inject DRY violations into an ecosystem can harm, particularly in their later phase. Once they are broadly recognized as no longer helpful, they still exist, driven on by an internal bureaucratic immune system mired in sunk cost bias. Ironically, in this weakened state, they, too, become another siren luring us to contemplate yet another DRY error thinking that will help. Refactoring the two into one healthier whole is too alien in its sophistication to afford consideration by parties which are too insulated from the consequences of getting it wrong.