A Deep Dive into "Flexible Health IT Models and the use of custom data structures."

One of my very good friends, colleague, and role model is Shereese Maynard. We met at HIMSS18, and my career has not been the same since. We all know that Shereese is one of the "Top Health IT Influencers" in the industry, and with good reason. Shereese can cut through the noise to identify the salient issues of the day for her clients and the rest of us. She has used her platform to bring to light pressing issues such as diversity, equity, and inclusion in the Health IT space and elevate the discussion related to the inequities in maternal health and the measurably poorer outcomes they experience. Shereese recently moderated one of the best break-out sessions I have ever attended in my many years at HIMSS (Women in HIT Meetup – DEI Initiatives in Healthcare IT). The speakers and those attending (see pic below) heard straight talk about the DEI issues facing women in our industry and some exemplary ideas on how to bring about change in our circle of influence.?

A few weeks ago, I read Shereese's post on Medium titled "Flexible Health IT Models: the use of custom data structures." Understanding the problems caused by the industry's lack of a standard data model and its negative impact on interoperability, I was unsure what she meant by "custom data structures." Knowing Shereese is a subject matter expert, I read with the intent of figuring out what I was missing.

The two-overarching themes of Shereese's article are that 1) the current state of EMRs does not meet the needs of specific users or user groups, and 2) the way to address this is through Flexible Health IT Modeling and custom data structures. I wholeheartedly agree with the first premise. Despite early optimism regarding the potential benefits of EMRs, they have not lived up to their expectations. Common complaints are poor usability, time-consuming data entry, inefficiency, lack of interoperability, taking away time with the patient, and provider burnout. Having beaten the proverbial horse to death, all can agree, we didn't get what we had hoped. However, I wasn't sure that "Flexible Health IT Modeling and custom data structures" were the answer.

Shereese and I met so she could help clarify my confusion. My first question to her was, what does "flexible health IT modeling" mean? As we worked through Sheree's piece, premise by premise, I shared my thoughts with her from a Clinical Informaticist's perspective. Shereese explained that the current way EMRs are built, for example, does not provide enough flexibility for the level of customization required to meet end-user needs. We talked about the level of burnout that healthcare providers experience due to years of using tools optimized for billing and not designed to simplify, streamline, or elevate their work. As we talked, I realized that Shereese was describing the result and impact of not using a user-centered design (sometimes called a human-centered design) approach to Heath IT implementations. In this scenario, the "users" in user-centered design are the clinicians taking care of patients in the healthcare industry. And I couldn't agree more.

Before we jump into my thoughts about Shereese's piece, I should add a disclaimer here. I readily admit that I have an incredibly unique perspective on the industry, given my education and experience. I began my Health IT career with a solid foundation of a master's degree in clinical informatics, requirements gathering, and a working knowledge of healthcare from a clinical, administrative, and patient perspective. Over twenty years, I've been blessed with opportunities to apply my clinical informatics expertise to performance improvement, quality measurement, quality improvement, case/population health management, health plan quality, regulatory, accreditation, licensing, product development, data modeling, and harmonization, and healthcare analytics. I also was fortunate to start my career and work with the best of the best, including Dr. Steven Lane and Dr. Paul Tang at the Palo Alto Medical Center, implementing one of the first Epic MyChart go-lives in the industry. In addition, I've worked with Cerner, Allscripts, NextGen, eClinicalWorks, Meditech, GE, and other EMRs. I have also lived through a few different maturity cycles in Health IT, starting with early adopters of the EMR ten years before Meaningful Use.

On "Not all EMRs are created equal."

Shereese's point here is well taken. I agree that from the end-user perspective, this is true. I would also say that they are mostly the same when you look under the hood, meaning that the data in the EMR backend is the same. The data may not all be stored in the same tables with the same fields, but the data is there (more on that later). Let me expand my thinking on the considerations in play here from one clinical informaticist's perspective.

As background information to understanding EMR builds, everyone should know and acknowledge that healthcare is one of the most regulated industries in the country. To obtain and maintain a license to provide services, healthcare organizations must meet specific clinical, patient safety, operational, reporting, human resources, and accreditation standards/laws. Collectively these "standards" represent some of the business, clinical, functional, and operational requirements that all EMR vendors must meet to enable their clients to obtain and maintain licensure (more on business, clinical, functional, and operational requirements in a later post). These standards are so pervasive that they drive the underpinnings of EMR design and functionality 80% of the time, regardless of which vendor is used. Frequently, especially in the hospital setting, these standards dictate what data needs to be captured or produced and how people and processes need to work together to collect and deliver that information.?

Some may dismiss this premise but think about it. Medication prescriptions are a good example. When a patient gets a prescription from a provider, it will include the following data (which may vary slightly by state).

Regardless of which EMR a provider uses, the user interface (UI) will guide the provider through fields to capture the above data elements for a prescription/medication order. It seems straightforward, right? If this is the case, why do providers have radically different experiences with EMRs? The answer is that EMRs are highly configurable. When we say something is "highly configurable," it means something can be customized, arranged, organized, set up, shaped, adapted, and adjusted in multiple ways with the intent of meeting or supporting a specific purpose. Let's walk through a few "configurable" options for ordering medication in an EMR.

When writing a prescription, the sequence of the data fields presented may or may not align with the order of information a provider considers from a cognitive decision-making perspective. The provider may or may not get a medication alert or contraindication popup. The alert may or may not be sensitive or specific enough to prove beneficial and avoid alert fatigue. The fields may or may not be prepopulated from a previous prescription. Refill requests may or may not be routed to a nurse who can process the refill under a protocol before sending it for approval and signature by a provider, thereby freeing up provider time. If a medication is part of a standard order set, that order set may or may not align with what the clinician needs at the point of care.

Another fitting example is from my experience as an interim Chief Quality Officer at HCA. Before HCA started using Epic or Meditech Expanse, the Far West Division used an older version of Meditech. The version of Meditech used at the hospital was not windows based. The nurses had to literally tab through tens of fields as they worked their way to the one field they needed to complete. When I saw it, I could not believe my eyes. I had been working with Epic at this point for fifteen years. Overseeing the submission of CMS's Inpatient Quality Program (IQP) Core Measure submission, I thought to myself, getting data out of this EMR ought to be fun. And you know what, it was! Finding data in the backend of Meditech was one of the more accessible databases I have worked with for analytics.

The main takeaway is that EMRs are highly configurable on the front end while still meeting the data and process requirements mentioned above. Once an organization decides on an EMR vendor, hundreds of configuration decisions must be made at the local level before the implementation or go live. For this reason, providers using the same EMR can have wildly different experiences leading to dissatisfaction and burnout. And the research backs this up.

KLAS Research and the Arch Collaborative have done extensive usability research on the impact of vendor design (build) and local configuration (build) and implementation. They surveyed 250 organizations and over 200,000 providers on their ability to provide quality care to their patients, and these are the results. (From the KLAS Arch Collaborative Update and Emerging Technology Insights, AMDIS - Physician-Computer Connection Symposium. June 8-11, 2021)

As you can see above, there is an almost 60% difference between the highest and lowest satisfaction ratings by providers using the same EMR due to decisions made at the local level! I can't explain why decision-making differs between organizations, but I will share two.

EMR vendor representatives sold organizations on the notion that order sets (et al.) are already built into the EMR and, therefore, the organization doesn't need informaticists. If the EMR implementations taught us anything, software vendors don't know how their products create complete solutions in the real world or what skills organizations need to ensure successful deployments and secure an ROI. Most of the vendors I meet do not understand the end-user, underestimate the complexity of real-world challenges in healthcare, and therefore, don't have the ability to create a sustainable solution to the client's needs. EMRs, and other Health IT software, are tools that need to be used to develop capabilities that, in aggregate, form solutions. Vendors shot themselves in the foot by arguing against the expertise added by Clinical Informaticists and are now paying the price. And many organizations didn't accurately assess the risk of taking that advice.

Being a certified EMR builder myself, I know that what providers need is possible with EMRs. At the same time, I have also experienced sitting in Health IT steering committee meetings where providers ask the vendor or local build staff if an EMR can perform a particular function or support the desired outcome, and they are told no. I believe the reason this disconnect occurs is common sense. Clinical Informaticists will immediately apply the software's capabilities to real-world situations while being trained to configure (build) an EMR. They can imagine the practical problems the tool addresses and, therefore, will acquire a mature and sophisticated understanding of a tool's full capability during build training. They will identify configuration options or collections of options, increase usability, improve clinical workflow, and ensure providers realize the benefits of using the technology. This impact aligns with the principles of how adults learn (Adult Learning theory). Compare this level of expertise with an "application coordinator" who has little to no clinical or operational experience. They will learn the tool's mechanics but will have limited working knowledge of its applicability beyond the abbreviated "happy path" use cases presented during training and will therefore have limited problem-solving prowess.

I love the video below from a colleague, Dr. Dirk Stanley, MD, MPH, and CMIO of UConn Health. It depicts additional ways Clinical Informaticists' skills could be leveraged in organizations. As an industry, we are just beginning to understand the value of Informaticists. If you have more questions about Informatics, schedule fifteen minutes of free consulting time here. If you don't follow Dr. Stanley, he's got some of the best visuals of clinical informatics out there right now.

In summary, I agree with Shereese that "flexible health IT models" can address the usability issues we have with the EMR. Having a foot in both camps, Clinical Informaticists have the expertise required to configure and integrate technology to optimize clinicians' capabilities seamlessly. When local configuration decisions support the customization necessary to meet the needs of specific users, groups, or use cases, it will improve life for the providers. And when providers are taken care of, they will take good care of the patient.

We hope to build a community of robust thought and discussion with this newsletter to elevate the industry's understanding of what is possible with healthcare technology. What do you think? Please add your comments below.

Our next newsletter will continue with thoughts on EMR training and "custom data structures". Be sure to sign up!