Lean & Agile DevOps in Academic Health Care: Headwinds

Last time, I discussed at great length the role of autonomous, cross-functional teams in DevOps. But trying to empower teams while placing them right back in the previous organizational structure and culture merely leads to confusion, frustration, and wasted effort. In these posts, I am ultimately heading toward how IT in an academic medical setting ought to be structured and how the corresponding culture should be shaped. But to get there, I need to cover several grounding steps. For what it is worth, I am not claiming to add anything particularly new to the canon of DevOps. Rather, I am exploring how to make best of this approach in my particular organizational sector.

So this time, I am going to address the headwinds facing the instantiation of a DevOps environment in this hybrid setting, which combines education/research (medical school) and medical practice (academic clinics). For those who did not see my earlier piece, I have to admit up front that I have a very expansive view of DevSecOps (or more customarily, DevOps) — the end state is far more than merely a cooperative effort between Development and Operations. DevOps may not subsume all of IT, but its methodology certainly causes changes through all parts of traditional IT shops. DevOps, in this sense, is not something that merely gets tacked on to an existing structure. I refer to this as the emerging New DevOps Manifesto, though there is no one single acclaimed statement I can point to, as can be done for Agile. A primary touchstone for me, though, has been Mark Schwartz’s A Seat at the Table.

All organizations, in all sectors, face significant headwinds when striving to transition toward a DevOps structure and culture. Before moving to what is unique about our sector, allow me to limn some of these common pressures and barriers:

• Ingrained customs, organizational norms, and institutional history
• Legacy infrastructure and technical debt
• Managerial fear of letting go of decision-making and trusting teammates
• Turf wars, across many dimensions (“redundant armories of mediocrity”)
• Constraints and choke points
• Long-lived history of IT being seen as an impediment who always say “No”
• Resistance against horizontal communications across reporting lines
• Resistance to changing organizational structure and culture
• Localized and siloed knowledge

Academic medical centers, like most other places, face all of these common barriers. But the setting also brings unique niche concerns that have to be addressed when moving toward a DevOps environment. These can be bucketed into three groups: data ownership, fear of consequences, and incongruous cultures.

Data Ownership

When I first started working in the health care setting, I took part in a large meeting where the room became divided in a vigorous debate. One side argued that health data belong to the clinicians that collect them. The other side argued that health data belong to the insurance companies that paid for their collection. This took place well before the HITECH Act, but I can easily imagine that today there would be a third side arguing that health data belong to the EHR vendors whose tools are used to collect and store these data. The debate went on for an uncomfortably long time, with everyone in the room fully aware that neither side was about to change their opinion but each side wanting the last say. Finally, a lone voice offered a question — “Don’t the data belong to the patient they describe and from whom they were collected?” Both sides joined together vigorously to scoff at and berate that person for daring to raise such a silly idea, and eventually the meeting concluded, with all but one person feeling refreshingly victorious.

I fully suspect that most people in health care IT have endured, in some variant, very similar discussions. Like many, I do have my opinions on the health data ownership question, but they are beside the point here. What matters is that in the health care setting, IT has to handle and manage protected health information which several competing interests claim to own and control. Much of our troubles stem from this divide.

First, we are responsible for having to protect sensitive and valuable information in use, transit, and storage. There is a rule-of-thumb adage in health care IT which claims that a record of health care data fetches more in the criminal markets than a credit card record. I cannot attest to the veracity of the statement, though it intuitively feels accurate. But even if not true, most people do not want their health data scattered to the winds of the Dark Web.

Second, securely handling and managing data can be quite difficult when competing “owners” put barriers in the way that impede data sharing to protect their valuable assets. Making data appropriately available for clinical care, research, education, and public health needs is difficult enough when the data enter directly into systems you control. When you must maneuver data through governance, technical controls, and disparate data formats which remain inflexible merely in support of ownership claims, it becomes nigh on impossible to work with data effectively. And since security is of paramount importance, what usually fails is the “sharing” part of data sharing. There are lots of health data locked away in data armories, and health care suffers proportionately with the strength of the gates.

Academic medical centers are set in an industry comprised of fear of losing control of valuable information, labyrinthine rules and controls that defy coherence, and inter-organizational conflicts and Kafkaesque legalese. While the recent Cures Act is aimed at changing the status quo, what is most of relevance here is that this environment creates a DevOps-intolerant setting. “Lean, agile, cross-functional team” — each word in the phrase is problematic in health care and academic medical center settings. Lean → redundancy and make-work. Agile → large, slow behemoths insulated from customers. Cross-functional → uncoordinated cross-organizational work and lack of generalized knowledge. Team → siloed expertise hidden behind sharp reporting lines and divided across organizations.

Health IT faces powerful antagonists with strong interests in the status quo. By increasing efficiencies and responsiveness, DevOps can facilitate our participation in the data struggle by providing a unified and coordinated interaction with our partners. By showing others we can be trustworthy with “their” data, we can sidestep the conflict and create better health IT data handling. Nobody has ever accused me of being optimistic, and I do realize that information is both power and wealth. Ownership claims will not disappear soon, so we need to maneuver within those divergent claims to provide a convergent data pipeline.

Fear of Consequences

Whether clinical staff share happily in a patient’s health success or in the painful depths of bad news, they consistently rely on a single motto throughout — “Do no harm.” Thinking about the world from this vantage leads to an inherent conservatism — change is acceptable only when there can be a degree of certainty that nothing worse than current outcomes might occur. As an example, I have witnessed this in discussions about curricula change — the low bar is set at whether the new approaches or material might produce worse doctors than the current approach.

I doubt there are many of us who, in our roles as patients, would seek out health care providers who willingly take the opposite approach: “First do harm”. But a sharp line cannot be drawn between the two adages unless we forbid biomedical and health care progress. Any exploration into potential improvements, by definition, involves risk of harm. Clinical staff and researchers must balance the collective gain from progress with the risk of harm during the research. This is always a difficult choice, and that difficulty is why we require additional institutional review of human subjects research. The burden of consequences is too large for one person to shoulder.

While perhaps not immediately obvious, this approach applies to health IT as well. If new systems and software cause data loss or even physical harm, we in IT must bear the responsibility. This leads to a conservative approach where health IT often lags other industries. This reluctance toward change is broader, though, reaching beyond devices. Changing IT structure and culture, or in other words, how we “do” IT, must also be considered for its potential danger. If a failed team hand-off between revamped teams leads to the disappearance of a social media post, an individual may be angry while others remain unaware of the shared information. But if a similar failure happens during a surgery or even a public-health disaster, the ensuing suffering and loss of life can far outweigh consequences in other industries.

Health IT staff must balance the inherent tendency toward paralysis due to fear of change with the amazing benefits of new IT developments. Stagnation will immensely impede care, research, and education leading to unnecessary suffering. Premature bleeding-edge change will cause intolerable suffering from mistakes. This balancing act applies as much to the outputs of health IT as to the way health IT is structured and its ensuing culture. As I will argue in later pieces, health IT has yet to achieve this balance.

Incongruous Cultures

One of the biggest joys of working in a “major academic medical center” is also the reason we use such an ugly phrase to describe the place. This setting combines educators, researchers, and clinicians, all doing brilliant and fascinating work in so many different areas. Being able to learn from and join in discussions with domain experts in each of these areas is an utterly amazing experience. Even though IT team members may not be on the front lines, we do enable health and health care improvement in a supporting role. We create social good on a daily basis and can take joy in our work.

However, each of these three groups brings a dramatically different organizational culture to the workplace. Indeed, at many places, the three can be found in separate buildings or even on different campuses. At a minimum, they exist in separate reporting structures. No matter where they are physically or organizationally, IT needs to interact with all of them equally well. At the same time, as we know all too well, IT tends to have a distinct culture that hinders communication with others in the organization. Historically, IT has viewed itself as in opposition to its customer base with a perceived need to constrain the damage the end-users can inflict. So we face a four-way culture clash with a general failure to communicate.

Clinical efforts focus on the health of an individual, but such focus rapidly switches between multiple patients throughout the day. This work involves a high level of personalized sleuthing given that each patient is unique in many ways. Yet, at the same time, clinical workflows are also highly routinized with a strong division of labor. The clinical decision-tree may be vast, but the branches make sense. Such a logical workflow lends itself to a tightly controlled IT environment: centrally-managed devices implementing precise imaging with a notable lack of user-facing admin privileges. IT manages almost all aspects of the technology infrastructure and data, with impressive abilities to audit all interactions with the technology and to secure health data.

Education depends on students bring their own computing devices, from which they access centrally-managed applications, such as course-management software. The BYOD aspect introduces uncertainty and an inability to protect/control parts of the IT environment. While there are fewer patient data in transit here, the rules and regulations surrounding student data are on a par with those covering patient data. The BYOD-induced lack of control over sensitive information creates a dangerous situation for health IT (as would be true of any industry where valuable data are combined with a BYOD environment?). Our ace in the hole, however, is the constituency we support. Medical school students are both technologically savvy and quickly become indoctrinated in the care required when using patient data. Education on proper IT behavior can go a long way with this group, but we will never achieve a similar level of control as in the clinics as long as we require the students to provide part of the IT infrastructure of the medical school.

Research labs often must purchase their own specialized equipment and usually retain complete control over the administration of these devices, even when they are Internet-enabled. Partly this is because of the depth of niche knowledge required to best support and use this equipment. But faculty at almost all academic settings have retained a very high level of autonomy and freedom of action over just about all aspects of their research and teaching. Even when research faculty and staff use centrally-provisioned equipment, they still expect a high level of administrative privilege over their equipment. This is usually justified because there is almost never a single set of specific tools faculty require to perform their duties, especially as they interact with peers at other schools. Creating a common image is not feasible, and thus the end-users demand the ability to add software or even to run virtualized environments. IT teams rarely have the staffing to reliably support central provisioning and support for all of the possible various combinations of equipment and software. Even if the equipment is centrally-provided, we end up in the extreme case where all infrastructure is effectively BYOD.

DevOps?

I am not claiming any of these situations occur solely within health IT. But as a set, the three introduce powerful overlapping barriers to shifting from a deeply hierarchical, yet fractured, and historically stand-offish IT approach and toward a lean, agile, responsive IT environment built on fluid, autonomous teams combining skill-sets on an as-needed basis in order to maximize the contribution of IT to business value. As such, we need to understand these barriers so they can be efficiently and properly addressed as we shift to a DevOps approach to health IT. This piece is already too long, so I defer trying to solve this to future discussions.

I also would never claim that health IT can be a leader here. But that does not mean we can justify being so far behind other industries as to be negligent.