When organizations need to solve a problem, they often create a task force, selection panel, or steering/advisory committee. These groups are tasked with developing consensus around new ideas, such as procedures, policies, products, or services.

Unfortunately, research shows that consensus-based problem-solving groups are often where innovative ideas go to die. These groups are highly prone to groupthink – quick agreement around status quo solutions with little discussion or deliberation.

Yet not all consensus-based problem-solving groups engage in groupthink. We wanted to learn from the exceptions — when and how do they keep new ideas alive? We conducted a study in which we examined verbatim transcripts from four virtual task forces established in 2004, by the American Health Information Community (AHIC). Their goal was to figure out and recommend a process to the U.S. secretary of health and human services to make American’s health care records electronic by 2014.

Recommending a new national protocol required embracing tectonic change with tremendous risk. At the time, there was no standard technology platform for health care providers, and no common technical language or coordination efforts across state lines. There were also significant legal, security and privacy concerns ranging from cybersecurity to patient privacy.

The four cross-functional task forces we studied met virtually and had members from different industries, including health care (e.g., doctors, nurses, a hospital president), insurance (e.g., insurance executives), technology (e.g., executives from IT, internet-based medical services, telemedicine experts) and government agencies (e.g., the Veterans’ Association, the U.S. Treasury).

What we found is that the groups that avoided groupthink engaged in the following steps.

[Here’s the first.]

1. They challenged the status quo.

People have a tendency to believe that existing solutions must be good. Groups are tempted to gravitate towards the status quo because they don’t face a high cost if they fail. (E.g., “Others used it before and it worked then, so it’s not our fault that it didn’t work now.”)

What we saw in the groups that overcame groupthink is that it began with one member expressing dissatisfaction with the status quo. For example, one group we studied had the following conversation about whether patients should be able to see who had accessed their electronic health record:

Daniel: The standard way to build transparency is that the technology can and does provide that auditing — and that audit should itself be available to the patient whose information has been disclosed. The more detailed audit, the more transparency.

Ron: So, let me get this straight … what transparency means is that the patient has access to every single point of access to his or her record. They have an electronic paper trail of who it was that accessed their data, when they accessed their data, and where they accessed their data.

Ken: Onerous….

Kevin: Is this data accessible on the network, or is it data that resides within an individual’s application? Because from an audit train standpoint, I would agree, it’s going to be very difficult to submit backup every time a physician may access a patient’s record in their own system….

Dan: Right. … If patients are giving permission for the system to include their data, should that automatically come with permission to view the data?

Ken: Is there a way to propose a less onerous, but still comprehensive account?

Ryan: I have a problem with the pure audit model. Where is the patient’s control in this model? My knowing who has accessed my records after the fact has no bearing on my ability to control who can have access and who cannot.

Kevin: Say a patient gives Dr. Jones permission to view and incorporate their information. Once that permission is granted, you don’t need another audit trail, because the information is now the physician’s information within their own office, right?

Nicky: Is there a recommended wording you think will make this point clear?

Kevin: Can I think about it?

Daniel: It sounds like we have broad agreement about some of these elements. Perhaps we can take all these elements and evolve them into something that is more user friendly once we have full agreement about what we think will work.

Dan: I second the notion that these principles are a good starting point, but they do need to be vetted and discussed and thought through extensively and should not be considered the final word.

When Ken uttered the word “onerous” it changed the direction of the conversation, because it attacked the usefulness of the status quo.

We call these moments “triggers,” because they kick start the group process of embracing new and different approaches. Triggers give members an opportunity to reveal how they each view the problem at hand. In the above conversation, Kevin interpreted the comment “onerous” in terms of how the backup system functioned. Dan spoke from the perspective of the patient, who may not have the time or interest to carefully look through the audit. And Ryan interpreted the audit system not allowing for patient control as onerous.