Few of the commercially-available clinical decision support systems support a best-practice approach for team-based clinical workflows. Given the high failure rate and low effectiveness of existing CDS implementations, this oversight must be urgently addressed to improve patient outcomes.
In the spring of 1968, Melvin Conway was different. At Case Western University, where Conway had studied mathematics and computer science, the counterculture was blooming. Martin Luther King was dead, and on campus, students rallied to keep Richard Nixon and George Wallace out of the White House.
That year, Conway was more interested in building organizations than tearing them down. He would later collaborate on MUMPS, the computer language used to create the first electronic health record (EHR) systems, and eventually work for Apple, but in 1968, Conway the computer hacker, made an observation that would eventually become known as Conway’s Law:
"Any organization that designs a [software] system will inevitably produce a design whose structure is a copy of the organization's communication structure.”
At the time, his was not an obvious point. In fact, the Harvard Business Review rejected the paper in which he stated it. Software, after all, was designed by experts to get a job done, and there were no clear connections between the design of a software system and the structure of the team involved in its creation and use.
Since then however, our view on software design and its relation to organizational teams has evolved, and the effects of Conway’s Law have been observed across numerous software projects (PDF), many of which have failed. Forty years after that turbulent spring, a 2008 study by Harvard researchers found evidence that Melvin Conway, thinking differently in 1968, had the right idea.
Unfortunately, the medical leaders and technologists building today’s clinical decision support (CDS) systems have not always heeded Melvin’s message.
Clinical decision support systems are supposed to provide clinicians with timely, patient-specific information to enhance the quality of healthcare. Studies from the U.S. Agency for Healthcare Research and Quality recognize that well-designed and targeted clinical decision support can improve outcomes for patients. But according to a recent survey by a U.S.-based research consortium, healthcare providers have struggled to implement CDS systems effectively.
Of the 249 health providers surveyed, 75% tried to build custom CDS software from scratch. A quarter (25%) of those projects had failed before completion, and a majority of the providers (51%) reported that their CDS systems were not fully integrated into their teams’ workflows, and were therefore being used only for reference, if at all. More disturbingly, an international study found that the rigid, hierarchical design of some CDS systems led directly to unintended outcomes, including mistakes in prescription dosing, misleading or outdated medical advice, and failed transitions of care from one provider to another.
The failures of these CDS software systems give a hint that Conway’s Law may be lurking in their designs. Or stated more precisely: the same rigid, hierarchical pecking order that hinders the effectiveness of clinical teams - the traditional relationships between doctors, clinical staff, nurses and patients - may be leading to equally inflexible and ineffective clinical software.
Among forward-thinking healthcare organizations, there is growing recognition that the traditional structure of clinical teams is broken. A 2012 report by the Institute of Medicine found that clinical teams, especially those in hospitals, have tended to organize into silos of expertise, instead of more effective cross-functional teams. According to the report, “the silos found in so many hospitals don’t support dynamic, real-time teamwork. The spaces between silos are vulnerabilities, like geological faultlines, places where an earthquake or failure are more likely.”
Some leading medical centers, like Children’s Hospital in Minneapolis (PDF), have taken proactive steps towards a more team-based approach by retraining staff to better understand and leverage the interdisciplinary nature of their work. A recent article in the Harvard Business Review (HBR) cites the improvements in Minneapolis, and outlines the ways that clinical teams must change in order to ensure better outcomes. The solution to inflexible healthcare teams, according to the HBR, is to reorganize clinical groups around a workforce management term called “teaming” - which they define as "fluid, collaborative, interdependent work across shifting projects and with a shifting mix of partners, often across organizational boundaries.” Of course, this definition describes perfectly the work that happens during almost every episode of clinical care.
As a corollary to Conway’s Law, it seems clear that the design of clinical decision support software can either lock clinical teams into old ways of working, or, along with better leadership, training and cultural changes, help nudge teams towards more helpful habits. For leaders of medical organizations aiming to improve care through improved teamwork, it makes sense to consider the design of the team’s software tools and their potential role in reinforcing these new patterns of work.
A current (early 2016) search of medical literature and vendor publications finds no clinical decision support systems either available to buy or proposed to build that support a best-practice approach for team-based clinical workflows. Given the high failure rate and low effectiveness of existing CDS implementations, this lack should be considered an egregious oversight that must be urgently addressed.
How does a clinical decision support system optimized for a multidisciplinary team look? Here are nine considerations that any new CDS software design must consider and solve to be effective in a contemporary team-based clinical environment:
Scoping - articulates the current definition of the work to be done (or procedure). In an EHR/CDS setting, scope would include the real-time status of the patient, including in-process procedures, tests, current medications and all providers currently engaged in the patient’s care. The scope of work around a given patient is continually changing in nature, so a successful CDS should emphasize and communicate acute changes instantly.
Structuring - is the identification of appropriate team resources based on the scope, and the ad-hoc provisioning of structural support - including tools for coordination and communications for the currently engaged care providers. A CDS might suggest a specialist based on the current patient status, specialist availability, and provide simple, purpose-driven text or video based communication between them.
Sorting - is the prioritization of tasks based on the scope of work and the currently deployed team structure. In a clinical setting, sorting refers not only to prioritization of tasks per-patient, but also the optimal ordering of tasks per clinical team member. The CDS could suggest task ordering to engaged providers based on the status of each patient under care, and could more intelligently raise alerts before critical conflicts arise or when new team members need to be added to the ad-hoc team.
Emphasizing Purpose - in a clinical setting, the obvious purpose is to care for patients in the most medically-effective and cost-effective ways, but CDS design can help reinforce these goals by suggesting effective actions, linking patient status to relevant science, and aggregating data on outcomes over the course of care.
Psychological Safety - in some clinical settings, the organizational hierarchy of teams may preclude lower-ranked members from speaking up or sharing pertinent information with the team. Although this is primarily a cultural leadership challenge, a CDS can contribute a feeling of psychological safety by emphasizing the cross-functional nature of the team. By providing information about team member capabilities and also direct communication between team members, the CDS will prioritize team member strengths over organizational position, giving team members a more equal stake in better outcomes.
Learning From Mistakes - Given the myriad variables that a team must navigate on the way to a positive patient outcome, mistakes inevitably occur. The best teams view these failures as an opportunity for improvement, first by setting aside blame, by characterizing the mistakes and their causes, and then by incorporating changes that will eliminate or at least mitigate the same mistakes in future cases. The CDS can support this process by providing comprehensive data surrounding a sub-optimal case, which will help team members focus on fact-based causes and solutions, rather than blame.
Learning From Conflicts - Similar to learning from mistakes is learning from conflicts that arose during an episode of care. Using after-action reviews based on data collected by the CDS, teams can compare actions to outcomes, and aggregate comparisons to identify trends towards the most effective treatment options.
Continuous Improvement - Apart from teaming-based workflows, the Institute of Medicine has identified continuous improvement (PDF) - the continual "measurement, comparison, evaluation, systematic introduction of accepted therapies, sharing of experience and information, and coordination of these activities among organizations" as a key goal for improving healthcare outcomes. A well-designed CDS system should support these data collection activities, perhaps paired with new deep-learning techniques to help flag areas for improvement.
Microservices Architecture - One overarching trend for large software designs of all kinds is a move away from monolithic systems towards smaller “composable" services. Software designed in this way tends to be more scalable, easier to adapt to changing technologies and workflows and less expensive to build and maintain over the many years that clinical software remains in service.
** Of Course Melvin Conway didn't, as far as we know, hurt anyone.
Bryan Young is a software developer, bassoonist and founding member of the Poulenc Trio. As founder at Intertwine Systems, Bryan developed electronic health record (EHR), and clinical decision support (CDS) and medical education systems for Johns Hopkins, the University of Maryland and the country of Trinidad and Tobago.