CC BY 4.0 · ACI open 2021; 05(01): e13-e16
DOI: 10.1055/s-0041-1729984
Original Article

Effective and Collegial Governance of Digital Tools in Health Care

Andrew Auerbach
1   Division of Hospital Medicine, University of California, San Francisco, California, United Sates
Kay Burke
2   San Francisco Health, Nursing Clinical Informatics, University of California, San Francisco, California, United Sates
Raman Khanna
1   Division of Hospital Medicine, University of California, San Francisco, California, United Sates
› Author Affiliations
Funding None.


Digital transformation of health care has provided an opportunity for broad-based innovation using tools and platforms implemented either through electronic health records (EHRs), adding software to EHRs or prescribing the software to patients directly (e.g., mobile apps). Effective use and management of digital health tools requires a coherent governance strategy that incorporates strategic thinking and clear management priorities. This manuscript reviews nine of the authors’ recommendations for achieving this challenging but critical overall goal for digital health.



Digital transformation of health care has provided an opportunity for broad-based innovation. For much of the last decade, this innovation has focused on implementing and optimizing use of vendor-based electronic health record systems (EHRs), but more recently, reimagining health care involves using tools and platforms implemented either through adding software to EHRs or prescribing the software to patients directly (e.g., mobile apps).

While technology governance rubrics exist,[1] [2] [3] these focus on large-item enterprise software platforms rather than the small but vital requests that come from frontline users. How should health systems equitably, effectively, and collegially review and govern these innovation requests? The build and support of new digital tools should be aligned with best practices for clinical care, professional roles, and local goals for care innovation, and balanced by practical considerations such as personnel expertise and the cost to build and maintain the tools in practice. As a result, the question of adopting new digital tools is often not only a question of “can” it be used in the first place, but also “should” it be implemented or adopted at all, and how the process of review and approval is managed with the requestor.

There are several governance tips and approaches we have found useful over our collective 40 years of overseeing digital implementation at our health system. While our list is neither exhaustive nor definitive and admittedly based on both existing standards[1] [2] [3] as well as personal experience ewe share our tips as a way to begin a larger discussion.

  • (1) Focus on problems, not solutions

A key aspect to any form of health care improvement is the idea that problems require a full and detailed understanding before a solution is chosen. With multiple users approaching problems in EHRs differently, it is possible for multiple solutions to be proposed for the same issue. The challenge lies in separating the request “I want ‘x’” from the underlying problem or goal “I need to do ‘x’.”

There are several approaches (SBAR, Lean) that train us how to develop a clear problem statement, with similarly clear description of “current and target conditions,” but these steps are where governance should begin. The intake process represents the best tool for developing a “problem-solving” or “improvement” request, as compared with the usual “fix request.” Problem solving may not be applicable to requests to fix something that may truly be broken, but there is value in ensuring that the problem is one of the functions and not one of the trainings.

  • (2) Do the most important, not the (newest or loudest) work first

Managing an EHR requires supporting the clinical care delivery system while also shepherding the resources and time of people who manage the EHR so that the most important work in terms of quality, safety, user experience, and strategic needs are met.

Governance that works a “queue” based primarily on the order in which a request was received are egalitarian but are prone to getting bogged down by small and relatively low impact “quick fixes.” Moreover, unless systems are able to identify critical clinical needs, they are prone to back channel deals and “squeaky wheel” work priorities. In both cases, work piles up and all stakeholders become dissatisfied both with the pace and impact of improvement.

Our overall goal is to assess incoming work using a rubric that, after asking requestors to describe current state as fully as possible, applies a standard weighted score to all requests. These weights include safety (the most important), compliance and external reporting, the number of people affected and how often the task takes place, the presence of workarounds, and impact of the request on user satisfaction. We then estimate the feasibility of the request and time required to complete the request. Using the weighted score and time required, we then can create a 2 × 2 “pick” chart of requests that fall into high or low clinical impact and high or low effort. Requests that fall into the high impact/low work quadrant are emphasized, those in the high impact/high effort next. Low impact/low effort requests are completed as time allows. Those in the high perceived time requirement and unclear impact are rescoped or sent back to the problem specification stage (Recommendation 1).

  • (3) No zombies or Frankensteins

Electronic health records governance should prevent the creation of tools that have no clinical “owner” or which (through lack of an “owner”) become unrecognizably modified over time. These problems fall into two types. “Zombie” tools are built without an “owner” or clinical champion, content that staggers through electronic workspaces with no clear purpose, and which is difficult to retire or update in the case of real safety or quality issues precisely because its original purpose is unknown. “Frankenstein” content takes ownerless Zombie content and makes it worse by “bolting on” additional content by various requesters over time without any overall standard or strategy. These monstrosities become larger and more unwieldy until they no longer represent any best practice.

A key step to avoiding zombie and Frankenstein tools is to identify at least one clinical owner for each tool in the EHR. Optimally content ownership includes a transdisciplinary team, as very few items in the EHR affect only one user type, but we have found identifying a clinical decisionmaker to be critical. Optimally, the content owner—nurse, physician, pharmacist, or a combination of the three—is a respected leader who has some level of authority over the clinical or administrative change being planned and has a long-term view of the care program, care standards, and people involved with delivering care. More importantly, this person or team is willing to act as the point of contact for changes or updates going forward and can hold teams accountable for training and use of new electronic content.

  • (4) Transparency is clarifying

We have described a set of practices that can be opaque to requestors, clinical informaticists, and the organization. Opacity can lead to substantial problems up and down the chain unless the overall need and the rationale for key steps are made clear. For example, how do you message “the queue” to requestors? Who needs to understand what work is prioritized? How do you permit escalation of requests (e.g., for urgent safety problems) and message those efforts to stakeholders?

It is important to make the priority of requests—why a request is being triaged the way it is—similarly clear. Transparency mechanisms not only help with customer relationship management/user satisfaction, but also dashboards and other data visualizations create insights and foster communication and collaboration. Enabling tools that create such transparency support not only the process of moving a request from start to finish, but also in the best practices the new or enhanced digital tool is trying to support (clinical, informatics, or policy-wise).

  • (5) Protect users from the EHR/protect the EHR from users

Helping ensure that the EHR does not become unusable through poor content governance (protect the EHR from users), while also ensuring user's solutions are not unwieldy in themselves (protect the users from the EHR) is a major governance task. The former happens when governance does not focus on platforms or broad-based solutions, and the latter takes place when requestors' solutions are either poorly aligned with best practices in your EHR or when EHR governance lacks a memory for approaches that worked poorly (in terms of user satisfaction or clinical uptake). A classic example of an issue that recurs repeatedly is requests to gather more codified and computable data (for billing, quality reporting, registries, or research) through use of complex and lengthy documentation tools added to already challenging clinic or inpatient encounters. While the data may be important to one set of users, the gathering of it is detrimental to other users.

We have tried to emphasize training and “self-serve” models as ways to help guide users in ways that will protect them from the EHR, but have learned—particularly for requests that seem to require creating new content, tools to “improve data collection,” or new workflows—the role of a clinical informaticist is key. While there are never enough informaticists to support the work available, strategically utilizing their skills for optimization work has proven very useful.

  • (6) Think platforms

A corollary to item 1 is the idea that you should be working to identify cross-cutting problems and cross-cutting solutions. Picking standard platforms helps streamline work (digital and nondigital) and may help open up team bandwidth for bigger problems. The team will sometimes need to foster user-specific customization and explore innovative solutions, but decisions to pursue a unique or custom solution should be undertaken with caution. Ideally, there should be a suite or ecosystem of preferential vendors or platforms that are considered to satisfy a use case or solve a problem before one-off, niche solutions are considered. The latter lead to ineffective ways to scale and sustain improvement, as integration barriers inevitably present themselves.

Although democratized approaches such as “physician builders” may remove bottlenecks to accessing build resources, they may impair the pursuit of standard solutions and platforms unless carefully governed. A corollary is to be deeply concerned when requestors or your team need to reach out to the vendor or do custom programming to address a problem. Unless you have addressed policies, procedures, and training, such efforts almost always represent an overengineered and likely brittle approach to the problem.

Part of “platform” thinking may also require consideration of a “production pathway” for tools you think are innovative and which might become a care standard, where your team explicitly develops a testing and implementation approach that has a possibility, but not a promise for enduring and enterprise-wide adoption. Focusing on platforms and the formulary of our digital health tools has formed the backbone of our integration strategies and our Digital Diagnostics and Therapeutics (dD&T) Committee efforts.[4] As part of our dD&T work, we lay out testing, validation, and go/no-go scale steps to ensure the broad and effective uptake of tools in our institution. Absent these steps, we would have electronic workspaces cluttered with tools of uncertain usefulness.

  • (7) Foster innovators and improvers that have reached out beyond their core constituency

A key way to be able to transition from one-offs to platforms is to find people—on your team and among your user community—who can build bridges across services, clinics, or care groups. Internal entrepreneurship and leadership, the ability to see opportunities across groups that may not include your peers, are important markers of leaders who can help push informatics solutions in the right direction and move problems to generalizable solutions. The requestor who solves a problem just for themselves may solve that particular issue, but it is equally likely they are creating ones for other users, or the informatics support team trying to manage informatics tools over the long term. Single clinic or provider innovators should be encouraged to consider potential solutions but more importantly see if anyone else is able to use them as well. Although our dD&T process does focus on value and validation, we have found that the work to develop new apps and software tools along those lines catalyzes further innovation, largely by encouraging the developers to do more in-depth user testing and market research during testing and roll out.

  • (8) Try to build a self-serve environment, but expect to provide lots of support anyway

An overarching need for governance is to disseminate the items we describe in 1 to 7 above in ways that users can refer to with their next request or project. Our institution, as is common, spends substantial energy on training tools and reference guides teaching both the appropriate use of electronic tools, as well as the appropriate ways to request updates to those tools. Having such repositories—wikis, document libraries, multimedia training environments, and simulated EHRs—are critical to ensuring that users are able to access learner- and situation-appropriate content as needed.

Ensuring that these resources are used effectively and often is somewhat harder. Our team is working to identify ways to embed our institutional best practices and several EHR best practices into our request intake. In some cases (such as approving order sets for certain high-risk medications or external applications), we are starting to develop intake tools that not only provide a governance checklist, but also move the requestor toward choices that are problem-targeted and achievable.

Having said this, governance is ultimately a customer service-centric process, one that requires engagement with requestors, builders, administrators, and patients. Being able to meet with people in their own clinic or operating room or unit remains a critical—and ultimately best delivered person to person—function of governance.

  • (9) Generate learning as you govern

The most visible measure of the effectiveness of your governance program will likely be your customer service metrics (e.g., timeliness with which you complete work tasks), but the most important measure is the clinical effectiveness of your work products.

Effectiveness measures can be further divided into whether the tools produce a clinical benefit, a user experience or workflow benefit, an operational benefit, or a benefit to your informatics strategy. In this last type, the learning you need to gather is information about how implementation might be improved. We term this the “don't make the same mistake twice” part of governance: understanding how your technical choices influence the tools that are adopted for use and in turn whether they are clinically effective. Your governance program should a priori consider ways to gather and utilize these four types of evidence, most of which can be generated through the management of your program, to create a learning model that speeds care and informs modifications and improvement to your governance program.



In the end, governance needs to be relationship based, fair, and focused on how resources are used to improve care. We hope our high-level principles, learned in part through our own mistakes, help provide a useful starting place for striking the balance necessary to ensure improvement using digital tools proceeds rapidly and in ways that helps patients, providers, and our health systems.


Conflict of Interest

R.M. reports royalty income from Hillrom (which owns Voalte) outside the submitted work.

Address for correspondence

Andrew Auerbach, MD MPH
Division of Hospital Medicine, University of California
San Francisco, CA 94143-0131
United States   

Publication History

Received: 04 June 2020

Accepted: 26 February 2021

Article published online:
06 June 2021

© 2021. The Author(s). This is an open access article published by Thieme under the terms of the Creative Commons Attribution License, permitting unrestricted use, distribution, and reproduction so long as the original work is properly cited. (

Georg Thieme Verlag KG
Rüdigerstraße 14, 70469 Stuttgart, Germany