Governance in Health IT Transformation

Governance is a hot topic these days. In the past few months, organizations across Canada have asked me to speak about physician governance in the context of health IT transformation. At first, I thought I understood what people wanted. I imagined explaining the importance of physician engagement, physician advisory committees, education for physicians on their electronic systems, and the introduction of processes to drive change. But I quickly realized that “governance” has become a catch-all term, signifying many different things to many people.

In hospitals, most system-wide challenges are summed up as “governance” problems. Physicians not feeling engaged? Must be a governance issue. Physicians not doing what we want them to do? Blame governance. Physicians feeling hopeless, helpless, angry and generally burned out? Let’s call that a governance issue as well. But is it, really? I thought it was time to make sure I understood what “governance” really means.

What is governance?
“Governance” comes from the Greek word “Kubernao”, meaning “to steer”. Plato uses the analogy of steering a ship for his discussion of political structure in The Republic. Steering involves knowing where you want to go, understanding the mechanisms of navigation, and being able to create action that moves the whole ship in the intended direction. It’s a lovely analogy. In health IT, we might define steering (or governance) as a collection of processes that help us communicate with stakeholders, collect information that informs decisions about a problem, and leads to a solution. In other words, governance helps us define and identify problems, imagine solutions, and plan routes to a desired future state.

Where is our destination?
In health IT (and healthcare in general) there is one overarching problem: We are tasked with reducing human suffering using scarce resources and too few qualified staff. Utilizing health information to prevent illness and better align resources should, theoretically, decrease suffering.

Beginning with this definition of the objective of health IT – decreasing suffering – let’s focus on health information system (HIS) implementation. It is worth taking some time to outline exactly what outcomes we might expect after a hospital successfully implements and adopts HIS.

These are some desired outcomes:

  • Patients are healthier and happier with the service they receive
    • Patient satisfaction scores increase
    • Clinical analytics reveal less disease burden
    • Research shows improvements in health outcomes
  • Access to care improves
    • Wait times decrease
    • Patients and their families report satisfaction with access
  • More people are experiencing health benefits for the same resource investment
    • General population health improves without an increase
      in expenditure
    • More people are receiving care without an increase in budget or employee turnover/burnout
  • Users believe the system improves their ability to do their work
    • User satisfaction scores increase
    • Employee turnover or burnout stays the same or
    • All stakeholders see the value of the tool and want to
      leverage it to make more improvements
    • Improvements and new uses are regularly requested
      from all stakeholders
    • All the above measures continue to improve in subsequent years

Who are the authorities?
By examining these desired outcomes, stakeholder authorities can determine if HIS project goals are being met. But who are the authorities? They must be experts who both understand the desired outcomes and the factors that influence them. They must be decision makers in the implementation process, and should be held accountable for their decisions. When these kinds of authorities have project input from start to finish, positive outcomes are likely to be achieved more rapidly.

First and foremost among the stakeholder authorities are patients, along with experts who measure, study and attempt to improve patient satisfaction. Most organizations aren’t familiar with including patients in governance, but the Health Standards Organization strongly advocates patient involvement in healthcare planning, and accreditation requirements will soon make this mandatory.

Holding patients accountable for decisions to improve their own outcomes has specific benefits. Uninformed patients find it easy to ask for the moon, but when they are engaged in the resource management required to effect change, they understand the real-world constraints. Patients should also be charged with engaging other patients to ensure the broadest possible view is obtained. Additionally, it is important to recognize that people who are waiting or needing access to care are also patients, and should be included in the consultation pool.

The next group of stakeholder authorities are clinical analysts and researchers who measure health outcomes. These experts may not even exist within an organization prior to HIS implementation. If they do exist, they may be accustom to manually identifying and excavating relevant data, but lack the skill to understand health IT needs in a world increasingly filled with electronic data. These authorities should be developed and engaged from the beginning. If they are only involved after implementation, inefficient data gathering and reengineering of processes and systems will slow the improvement of health outcomes.

Medical practitioner Users are the initial key stakeholder authority. The HIS system will only provide the desired outcomes if users embrace the system. Users will be the ultimate judges of whether the system is accessible, easy to use, provides value to their job and improves their effectiveness. They will also demonstrate, through adoption and interest, if they have been taught how to use the system and understand its benefits. Success requires users to lead system design. They must be educated and supported in system use both during go-live and well after.

The final group of authorities are information system specialists. These experts understand the software and help translate the needs of the other stakeholders into the new HIS. Health information systems are highly complex and can be customized to achieve particular outcomes. Often, organizations only use a small percentage of their HIS’s functionality and as a result, realize only a small percentage of potential gains. Keeping a running tally of the percentage of HIS function currently being used versus the function owned helps show the degree to which an organization is tapping their system’s potential.

Who are the crew?
Engaging stakeholders and authorities is not enough to raise the sails. A successful implementation requires a full crew with expertise in adult education, human factors design, IT infrastructure, project management, change leadership, communications, human resources and, of course, adequate funding.

Here are some questions to ask about the quality of support you currently have in place:

  • Do you have an education department? Is it held accountable for adoption? Their methods should result in changed behaviour and measurable outcomes. Projects will only be successful if people know how to do what they need to do.
  • Do you know how to design an intuitive workflow that leverages the natural human tendency to action? If not, it might be useful to invest in a human factors expert to support the design team.
  • Is your IT infrastructure designed for big data? If you lack expertise in big data management, get it. Expertise from outside the healthcare sector may be required.
  • Are your project managers knowledgeable about your system and can they drive action? Are they recording decision points and consulting with stakeholders? Do they have clear and transparent procedures to track progress?
  • Does your organization understand that behaviour change is not just about communication and education? Do you have leadership with the expertise to facilitate behaviour change by working with communications, education and the steering team?
  • Is there a team skilled in crafting communications both inside and outside the organization to support change? Are they up-to-date on all of the options for communications, including social media?
  • Do your employees have yearly objectives for which they will be held accountable and that prioritize the project? Do you have HR recruiting teams ready to find the people you will need?
  • Do you have the budget? And is there an understanding that the system must be upgraded and maintained after go-live? This will impact operational budgets before savings are evident. How will those financial investments be absorbed, and is there a plan for reporting financial impacts throughout the project?

How to sink the ship
Before moving forward with a description of structure, we should look at some of the common ways things go wrong. In fact, just tap into your own experience and make a list of where you have seen issues arise. It is important to be honest with yourself, and now is the time to do it. Once you are done, take a look at the list below and see how it compares. There is no better way to improve on governance than to make mistakes and learn from them:

  • Fail to learn from prior mistakes and successes. If you do not take the opportunity to identify your organization’s strengths and shortcomings, then you will waste time and resources learning the lessons again.
  • Fail to engage expert authorities. For example, one of the reasons I’m asked to talk about “physician governance” is that many projects fail to engage physicians adequately. When engagement fails, and it becomes time for the unengaged expert authorities to adopt the new system, challenges arise. Projects can be delayed or completely de-railed. System builds and organization-wide processes have to be modified to meet the needs of the unengaged expert authorities.
  • Create rubber stamp decision-makers instead of engaged architects. If decision-makers are not actively engaged and held accountable for their work, their decisions will be less well-informed. Poor decisions may affect the overall system architecture. In addition, rubber stamp decision-makers are less likely to be effective system champions.
  • Have too many people at the table. Although it is important to engage all stakeholders, large teams can be an obstacle. Larger groups lead to diffusion of responsibility, group think, and social loafing. The ideal working group is 5-8 people. Steering committees may have a few more members, possibly up to 12. Finding a way to represent all of the stakeholders and still have a nimble functioning team is one of the challenges in good governance.
  • People are not paid to come to the table or the project is not prioritized on their yearly measurable objectives. When this happens, people do not show up and, if they do, they are unlikely to have the time or level of engagement to do the work required outside of meetings.
  • Users are only engaged in silos. Health information systems are very integrated systems. One person’s data entry leads to another’s person’s action. If systems are designed in silos, instead of integrated interdisciplinary workflows, they can be clunky and disjointed, or even fail to perform the desired function.
  • People who are not stakeholders make decisions that affect stakeholders. Engaging users can be challenging. They are, after all, often employed in clinical duties. If architects are not actual users, then it is likely that the people making decisions are managers, who tend to be disconnected from end-users needs. In addition, managers have different agendas than users. For example, managers often have trouble getting their employees to communicate effectively, but Health Information Systems are not communication solutions. The HIS is used to address communication problems, it may lead to unnecessary data entry requirements while the true problem remains unaddressed.
  • Stakeholders such as IT and clinical staff don’t understand each other. IT and clinical staff speak different “languages,” and often adequate translation services are not developed or promoted. I have heard it said that health IT might be easier if IT and clinical staff actually did speak completely different languages because it would bring awareness to the issue. Systems must be designed with an awareness of these different languages, with people trained to understand both IT and user needs. If not, it may lead to nonsensical workflows and costly rebuilds.
  • Multiple site deployments only consider the needs of the largest hospital. Smaller hospitals have unique and specific requirements. Neglecting their needs results in lack of engagement, challenges with adoption, and inappropriately designed systems. Complete current and future state workflows and full user engagement are required for all sites. In a phased roll-out, later-phase hospitals must be engaged from the beginning, or a complete rebuild may be needed between phases.
  • The HIS project is just one among many projects. When an organization fails to prioritize their initiatives, adequate focus may not be placed on the project. When a person is seconded to the project, they must have an appropriate operational replacement, or they will be in the position of doing two important jobs simultaneously. This slows milestones and increases burn-out and staff turnover, which increases both project and operational costs.
  • Implement complex projects using decentralized teams. An example of this would be expecting each clinical department to build their own order sets instead of providing requirements to a centralized team. When work is decentralized, all participants need to have an in depth understanding of the future state. This is a challenging perspective to gain and trying to educate a large number of people on future state, prior to their experiencing future state, can lead to a lot of trial and error. Mounting the resources for an effective decentralized team can weigh the project down at its start and fail to create a core of necessary experts to drive decision-making. This results in non-compliance with standards, confusion in build and the eventual need for additional rework. Centralized, well-educated teams that understand future state make better progress at introducing and implementing change.
  • Centralized working groups fail to transfer knowledge and decentralize function once the system is implemented and new processes must become the norm. The whole organization needs to be educated about how the system works, while ensuring that operational processes are updated to reflect new and evolving need. Failure to do this results in frustrated users and stressed IT staff, which leads to turnover and possibly the loss of much-needed educators. The system satisfaction decreases and return on investment may never be realized.
  • Rely on structure and process to replace good leadership. Though good plans and robust structures are requirements for a successful project, successful projects ultimately come from good relationships. Leadership must be able to respectfully hear and respond to their team’s needs. All project members should be empowered to speak their minds without worrying about being shamed, overlooked or disrespected. If not, the project will lose the benefit of the brilliance and experience of all team members and the project’s potential will not be realized.
  • Think the project is done when the system is turned on. An integrated health information system must be maintained, monitored, optimized, and upgraded. Failure to plan adequately for this can lead to inefficient systems and budgetary problems. Post-implementation planning needs to start with establishing new norms and resilient change processes.
  • Let IT run business. Once the organization is fully electronic, they are also fully dependent on IT. This can lead to the propensity for IT to drive the business, but the IT department is likely to have very different priorities than the patient care areas. If prioritization of work is left to the technical people, it will be difficult to ensure that efforts are always focused on positively influencing patient outcomes.

These are some of the ways the ship can sink. Perhaps you have found yourself nodding in agreement with some, and likely you have a few of your own. To better understand your organization’s risks, engage your teams in an exercise and imagine how to sink your own ship. When approached in a playful manner, people can be extremely creative. Be sure to capture the results and you will have a lot of good information to inform your structures and plans.

How to get it right
Knowing the ways your ship can sink enables you to plug holes and make good plans to move forward. Based on the challenges listed above, the following elements would be necessary in a good plan.

  • Take the time to hear everyone’s view of how things have gone in the past so you can learn from prior mistakes and leverage successes and strengths.
  • Clearly identify all of your stakeholders, craft a plan with them to outline their engagement and have them approve it. Be willing to modify and improve upon the plan if it is found to be inadequate.
  • Select a team of users and authorities with a systems perspective, and ensure they have the knowledge or skill set to learn what is necessary to build a health information system. Pay for an adequate amount of their time to fully participate in the project as lead architects. Hold them accountable for the engagement of users, and the design, implementation and adoption of the system. Team members should both represent and engage their stakeholders. Foster effective team work and positive relationships among team members. The design of the system will only be as good as the relationship between the architects.
  • Divide the work into meaningful functional sections with teams of 5-7 architects. Cross-pollinate architects into sections to ensure integration of the solutions from the beginning. For example, it may be reasonable to have a team for the financials and human resources, a team for data and analytics and a team for clinical work. Ensure that members of each team also sit on another team so they can identify possible integrations between the sections and prevent silo formation.
  • Ensure that architects and analysts are capable of understanding both clinical language and IT language. Creating a guide for the most commonly misunderstood terms can help increase awareness on all sides.
  • When a project includes multiple hospitals, engage end-users from all facilities from the beginning. Smaller hospitals will need a disproportionate amount of representation to their size in order to capture their unique needs. They may also need financial support to provide the necessary engagement.
  • Implementing a health information system can be all-consuming. Make it your organization’s number one priority for the project duration and educate the entire organization about the use, function and purpose of the system. If possible, put other projects on hold.
  • Centralize working groups to accomplish project-oriented tasks. Educate these teams in how to use the health information system for their task. For example, ordering, documenting and medication management will all require multi-disciplinary working groups.
  • Plan a post-implementation project to establish the system as the new norm. Review all processes and ways of changing within the organization. Engage thoroughly, educate, decentralize knowledge and processes and ensure that the purpose of the business – patient care – is the driver of information services.
  • Choose leaders who put relationships first. Ensure that leaders understand the population they are responsible for engaging, and establish performance measures to support the personal engagement of users.

Use your own lessons learned to come up with further elements for a successful plan.

How to engage the authorities and crew?
Engagement occurs in many ways, and on many levels. A team of architects will visualize and understand the entire system and how it fits together. Subject matter experts will support specific workflows and functions. Influencers will engage end users, create enthusiasm, acknowledge needs, and feed these needs back to the architects. Unique interdepartmental relationships will form to do the team work necessary to design, build, revise and implement.

Architects should make up the project steering committee and the committees for the main functional systems. Architects represent their stakeholders and forge alliances with the other architects. The system build will reflect the synergies of this team.

The steering committee should include architects from the following groups:

  • Nursing/Allied
  • Physician
  • Information System and Technology
  • Pharmacy
  • Finance
  • Analytics
  • Technical
  • Patient
  • Ancillary Services (lab, medical imaging, dietary)
  • Health Records
  • Human Resources/Education

Architects have experience in high level visioning, system-wide perspectives and, preferably, information systems. They understand the ultimate interdependency of all decisions and workflows. Each member should be fully invested in the project and engaged with working groups. Since their role is critical, each architect should train and maintain an understudy who can take on their role if necessary.

The steering committee should be able to speak freely and respectfully with each other. Their ability to create a consistent and harmonious architecture will determine the ultimate usefulness and user satisfaction of the end product. The steering committee holds the ultimate accountability for project success.

Subject Matter Experts
Subject matter experts are end users intimately familiar with workflows and are experts on best practice. They should include both system advocates and resisters. They should be engaged in their areas of expertise, and do not need to make big picture decisions.

Since subject matter experts provide requirements for details within the overall structure, it is beneficial to ensure they are educated in how the system works. Frequently subject matter experts are already in place, contributing to governance for quality and performance management. Tapping into existing leadership and expertise can be helpful.

Some examples of possible pre-existing physician governance models are:

  • Medical Advisory Committees (MAC): Often high-level leaders within each physician specialty, program and/or hospital department. Their participation in high-level decisions is important, however they will not have the system expertise for making design decisions. Your architects will need to support their education and obtain their buy-in for the decisions they are making to the system’s over-all design. It may be useful for the MAC to delegate decision-making authority to the architects. Architects should be held responsible for engaging and educating the members of the MAC.
  • Specialty bodies: In Provincial or multiple-organization initiatives, there are likely formal or informal networks for each physician specialty. Engaging these specialty bodies for work on order sets, care plans, documentation and workflow is important.
  • Medical Staff Associations/Provincial Medical Associations: These bodies represent the physician’s needs in the system and will advocate for respectful working conditions. They are key stakeholders throughout the process and should approve communication and engagement plans. Regular communication and engagement through these bodies throughout the project will enhance input, adoption and satisfaction.

Also consider existing leadership models for other stakeholders including nursing/allied, clerical, support services, pharmacy and, of course, patients and their communities.

Rock stars
Rock stars are your well known, outspoken, frequently extroverted clinicians who rank high on the influence scale. Sometimes they can be called your “Champions,” though often they may also represent your “Resisters.” If you take the time to build personal and project relationships with rock stars, they may be enlisted to educate, model and promote change. Rock stars who are initially resisters become pure gold as champions. Take extra time to convert them. If you’re not successful, ask yourself honestly if they have good reasons to resist. Acknowledge their perspective, and perhaps even make modifications to the plan based on their input. Engage the rock stars as subject matter experts in gathering requirements, current state and future state workflows, testing, training and communications. Do you have patients who are rock stars as well? People who are well known and willing to put their face to your project both internally and externally? Patients can be wonderful motivators and supports for clinicians struggling through change.

Change does not happen in masses, it happens in people – hopefully lots of them. Every individual is important and needs to be engaged. Keep a master list of impacted individuals and have the project teams record their interactions with each one. Consider keeping track of peoples’ competencies, lack of competencies, learning styles, self-care methods and areas of particular passion or vexation. Just as patient information is important to help them change, so too is it important for individual employees or staff. If your human resources or medical affairs department is well-supported, they may be able to participate in some of these efforts.

Organizations are often already gathering feedback from patients via a post-discharge survey tool or other engagement process. Consider adding questions to understand their view of the health information system.

Assessing your ship
No one governance model will fit all. It is important to start with your current state, leverage the committees and teams that exist and fill in the gaps where needed. Start by drawing current


state charts to reflect organizational structures and committee structures. Identify areas where expertise is missing and determine if new governance is necessary. Identify problematic silos and cross-pollinate to break them down. See which current committees can change scope instead of crafting parallel governance structures. For committees that would benefit from a complete overhaul, perhaps plan a slow transition with a parallel committee. For example, in an HIS implementation, forms committees fade out and documentation committees surge ahead.

Create your future state governance model with the objectives and cautions identified earlier. Now, craft your plan to move from current to future state as smoothly as possible.

Keep in mind that changing tides and winds require adjusting of the sails and perhaps the entire structure or crew. Implementation requires an increase in crew, as do times of transitioning back to normal operation. Operationalizing means the crew will decrease after change has spread across the entire organization. Though your governance may be ideal at some point in the process, it will need to evolve as circumstances change. Re-evaluate regularly.

Suggestions for Shipbuilding
It is always handy to have a few models available when you are trying to craft a future state. Here are some examples of real-life governance models for HIS implementations:

Image 1.
Image 1 depicts a structure for a regional implementation of an HIS. The work progressed successfully, but the team struggled with silos, and specifically with engaging physicians adequately for build decisions. Understanding how the participants of each of the committees interrelated and the make-up of the committees would have helped enhance the structure.

Image 2. (see below)
Separating backend functions and clinical functions is a common and understandable trend, though any separation risks silo formation and loss of full system integration. Sharing some committee members between the clinical and financial teams can facilitate integration.

In Image 2, the physician role was articulated in the governance structure. The physician advisory committee was distinct from

Image 2.

the clinical documentation committee and there was good communication between the teams. Integration could have been improved with even more shared committees and committee members, especially between nursing and physicians.

Image 3.
Image 3 represents a proposed model for clinical governance. The left side of the image represents project governance, and the right side represents a typical operational governance model. The intersecting lines show the membership of project working groups.
Members of each of the representative operational bodies should sit on relevant working groups and report back to their operational teams with education, decision options, and the direction of the working groups. Working group members are responsible for adequately representing the viewpoint of their operational department, and should be charged with vetting questions and decisions with those they represent instead of assuming their individual knowledge and opinion is adequate.

A word or two on Physicians
Image 4 is a suggested model for physician governance, though each organization should customize to their needs.

In this structure, the Medical Advisory Committee (MAC) delegates authority to the Physician Advisory Committee (PAC) for all IT decisions. The MAC chiefs are still important supporters of the vision and approvers of policies and procedures. They receive regular communication and education


from the chair of the PAC. The PAC prioritizes system integration. It includes physician and non-physician architects, with representatives from nursing, IT, pharmacy and health records.
Each of the PAC physician members chair or co-chair a working group sub-committee. Not all listed committees would be required during the entire timeframe of the HIS project, and some other committees may be necessary at specific times, such as inter-professional communications or infection prevention. During go-live, Order Sets, Documentation and Medication Management committees would have priority.

In addition to chairing subcommittees and taking responsibility for the architecture of the system, PAC members are responsible for engaging physicians. PAC members will lead open forums, present at committee meetings, identify subject matter experts, leverage rock stars and engage individuals. They are responsible for the system adoption. Their role is critical, exhausting and requires significant knowledge, effort and resilience. Pay them.

Ahoy Mate
Now that you are ready to set sail, a word or two on navigating. Psychotherapist Dan Siegel has an analogy for mental health that I find also applies to the challenges of steering within an organization. He says being of sound mind is like trying to sail your ship down a river and avoiding crashing into the banks on either side. On one side are the rocks of rigidity and on the other are the jungle of chaos.
Within organizations, steering toward the rigid shore can sometimes veer to being overly autocratic, lacking engagement and devoid of fun, while steering into chaos can lead to decision paralysis in the tangled webs of multiple committees and quick sands of consultation without accountability. On the chaotic side, the ship is detained and projects go over budget or collapse under their own weight. Staying in the middle of the river requires multiple micro-adjustments to achieve that liquid blend of engagement, rapid decision making and accountability.

The Ever After
Your ship will weather storms and ride many waves. When problems arise, ask the following questions:

  • Who is the authority on the subject and do they have the final say?
  • Which stakeholders are impacted and are they involved?
  • Is there a non-stakeholder expressing an opinion, and why?
  • Do you have qualified architects, or do they need more education?
  • Do the crew consult with those they represent?
  • Are people being held accountable?

If the people making day-to-day decisions address these questions but still struggle with a decision, they should escalate to the steering committee and from the steering committee to senior team, or even to the board if necessary.

Discovering New Lands
When implementing your Health Information System, you create new lands to explore. Take the time to thoroughly understand, investigate and inhabit them. If your physicians or staff are not engaged, unresponsive, feeling hopeless, helpless, angry and generally burned out, ask yourself if you are following the principles of good governance:

  • Learn from your mistakes
  • Engage and listen to your stakeholders

Image 4.


  • Invest in an accountable team of architects
  • Keep teams small
  • Avoid silos in structure and cross pollinate
  • Create translation texts for the languages spoken
  • Give the Davids the same voice as the Goliaths
  • Focus on one thing
  • Centralize your change forces for implementation
  • Decentralize knowledge and processes for operations
  • Pick good leaders who will be accountable
  • Educate, educate, educate
  • Re-build governance after implementation
  • Stick to the flow, avoiding chaos and rigidity

If all of these elements have truly been addressed, but foul winds still blow, it may be better left to therapy. It is always possible that our obsession with the term “governance” is a last ditch hope that we can fix the challenges we are encountering without having to truly turn inward and fix ourselves.

share this article...
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn