About Robert Bart, MD
Robert Bart, MD, joined UPMC as chief medical information officer in 2017 after previously serving as the first CMIO for the Los Angeles County Department of Health Services and chief medical officer at Cerner Corp. A practicing critical care medicine physician at UPMC Children’s Hospital of Pittsburgh, he oversees UPMC’s industry-leading efforts to advance the use of electronic health records, as well as other technologies — including telemedicine and remote monitoring — to improve the quality, safety, and efficiency of patient care. Dr. Bart received his medical degree from the University of Hawaii, then completed a pediatrics residency, a pediatric chief residency, and pediatric critical care fellowship at Duke University Medical Center.
Tell me about your background and what brought you to University of Pittsburgh Medical Center?
I'm trained as a pediatric critical care physician, and I still work clinically. I've been in healthcare IT now for 30-plus years. It started back when I was doing my training at Duke in one of the early versions of ICU documentation that existed in the late ’90s. I've worked on the commercial vendor side, where I was the chief medical officer at Cerner Corporation (now Oracle Health). I also was the chief medical information officer at the Los Angeles County Department of Health. LA County is the second-largest public urban health care system in the country.
Part of what brought me to UPMC was learning a bit more about the dynamics between a large payer and a delivery organization. And the other piece is UPMC Enterprises, which is arguably one of the better-known healthcare entities that works on bringing products to market and collaborating with startups and early-stage investors.
UPMC has hundreds of thousands of connected devices, 3,900 applications, and terabytes of data under the hood. Given its size and scope, how do you transition your digital strategy from being a laundry list to a more intentionally managed portfolio?
The reason we have nearly 4,000 applications is that UPMC over the last 20 years has been aggressive with mergers and acquisitions, and every acquisition brings in between 500 to 600 applications. We haven’t been as consistent with application lifecycle and portfolio management, so we’re now establishing a more structured process for both. We're moving our portfolio of applications into ServiceNow to catalog and manage them.
We're working through an aggressive decommissioning process with appropriate archiving that will allow us to go full-tilt into portfolio management. One reason healthcare systems struggle with decommissioning is that many systems contain clinical information that must remain accessible for medical-records requests and other purposes. My contention is that no matter how big a healthcare system is, it shouldn't need more than 600-800 enterprise applications, which is part of our goal in creating a standardized technology footprint for UPMC.
What are some of the drivers that help UPMC decide if it needs to sunset or consolidate a technology?
I'm actively involved in the team that's reviewing the different applications we're putting on the path to sunsetting, and the justifications vary depending on the application. There are several drivers for decreasing the application portfolio. One is cybersecurity, because every application that has to connect to the outside world is a risk — that’s another application that you have to patch, upgrade or monitor. The second is cost, where you have “zombie applications” spinning on disks with little to no utility. The third is having IT personnel to manage these applications.
In those three areas we can achieve savings and create value. IT is a cost center in just about every company it’s in. It’s not a revenue generator. Reducing the size of that cost center is important. Moving to enterprise solutions and consolidating multiple endpoints simplifies our ecosystem.
Health systems tend to gravitate towards consolidation yet there's always the next digital startup that's doing something unique. It's the platform vs. point solution debate that seems to never end. Where do you stand on that?
I'm definitely a platform person. I'll use our EHR as an example. Through acquisition and a number of previous decisions, we had nine EHR instances at UPMC. We’re now going through a massive consolidation onto a single EHR instance of Epic. About 40% of our geography is on that de novo instance, with the other 60% scheduled to transition in early October. Each of those EHR instances has roughly 50-150 third-party applications tied to its ecosystem. When we consolidate those nine instances, a whole range of other systems are consolidated as well, including cardiology platforms, imaging systems, etc.
Moving to a single platform significantly smooths data movement and workflow. Then you don't have to worry about a patient being seen at one of the hinterlands of your healthcare system and needing the expertise of the academic center here in Pittsburgh. The academic center has immediate access to those images, and you don't have to worry about moving them or the patient — a lot of that stuff falls away when you move to a platform.
With UPMC Enterprises, if you’re co-developing or funding new startups, what are some expectations or requirements that you introduce to those partnerships?
Scalability is one of the first things I look for when talking with any vendor or working with UPMC Enterprises on the development of any platform solution or technology. It has to be scalable in terms of value and cost. I've seen a lot of promising applications and projects, but when you look at the dollar investment for the first 50 users and realize we have around 8,000 physicians, it’s clear that no one is going to greenlight that expenditure.
I'm also philosophically against piloting. I firmly believe you should understand the problem and proposed solution well enough to know, without a doubt, that you don't need to pilot it. That’s partly because piloting is expensive. You can't turn on technology in isolation anymore. You have to see if that platform integrates with the rest of your technology footprint. It happens all the time: A vendor says, “We'll do this implementation, and we'll do it at our cost.” I immediately respond with, “Will you also include our cost?” Because it's going to cost us $100,000 in time and materials to do a security review over the next couple of months. And then we have interfaces that we have to build. I would reconsider my stance on pilots if vendors were willing to cough up some money to cover our costs for their “free” tool.
Speaking of costs, we continue to see many health systems that are struggling to define return on investment for their digital portfolio. How has UPMC thought about this?
Many years ago, Harvard Business School produced a tool called the balanced scorecard. One of the reasons I like that approach is because in healthcare especially, financial ROI cannot be the only consideration. It’s important, but it can't be the only one.
Take ambient listening for example [UPMC was an original investor in Abridge]. We actually have one of the broadest deployments of ambient AI across the country. It would be hard to go to physicians and say, “We want to deploy this, but you're going to have to see more patients.” That was a nonstarter because one of the reasons I wanted to deploy it was to help address physician burnout. When that opportunity arose, I said, “Let’s invest in our physicians and show them that we're trying to do something for their well-being.”
We assumed there was a chance that, as they get more efficient in their documentation, some of them would decide to see more patients of their own volition; our physicians do have an incentive on the number of relative value units (RVUs) they see during the course of a year. We now have good evidence that pajama time went from 120 minutes on average down to around 34 minutes per user over a full clinic day. And after about six months, about 20% of physicians using it started adding patients to their schedule, generating enough revenue to offset the cost.
So, we can achieve cost neutrality relative to the expenditure because people are starting to get more efficient over time. But the original value was in addressing clinician burnout. And it's the only application I've deployed in 30 years where you get love letters from the physicians about the tool.
In terms of governing all this activity at UPMC, how are digital solutions surfaced, built, and owned operationally?
Within our health system, it ends up being whoever identifies the problem, and that’s usually the people who are closest to the issue. If someone in revenue cycle identifies a gap or a problem, they're going to start looking for technology to close that gap. Over the last 20 years, UPMC Enterprises has built a very strong reputation, and we tend to attract employees who have an entrepreneurial leaning. I'm frequently talking to physicians who have ideas for an application or for some problem that needs to be solved, and I might point them over to Enterprises.
Many times, people are interested in creating a solution, but they haven't really crystallized and identified the problem. There's a quote that's attributed to Einstein that says something along the lines of “If you have an hour to solve a problem, the majority of the time should be spent analyzing the problem and a few minutes solving it.” I think that's part of the challenge: intelligent people are often addressing the symptom of the problem without getting to the root cause.
UPMC’s Center for Connected Medicine released its latest survey on AI adoption. What are some AI trends from that survey that you've been tracking?
I think most healthcare systems have been fairly aggressive in trying to adopt AI. Which is a change, because if you know anything about the technology sales cycle in healthcare, it's typically between 12-18 months before they decide to buy something. It's like endless window shopping. That's definitely changed with AI; no one wants to get left behind but at the same time, no one knows what they're chasing.
The challenge then is that AI needs to be actively monitored. Its behavior can be unpredictable, and most health systems don't have enough data scientists to monitor it well. We're fortunate to be in Pittsburgh, where we can recruit from Carnegie Mellon University and the University of Pittsburgh that both have robust computer science programs. There need to be platforms that help healthcare systems to monitor the AI they deploy so they can scale it effectively.
The other challenge is wrestling with the cost of AI. None of us have had to pay the true financial cost of AI yet. I'll use Epic as an example since it's relatively ubiquitous. Fifteen to 18 months ago, they had à la carte pricing. It was quite expensive, but it may have reflected the true cost. Then they realized the pricing model was slowing adoption, so they flipped to suite-based pricing, which was arbitrarily low. Under that model, anything they developed in AI was ours. But then, a few months ago, they indicated pricing would again change to a consumption-based model. Now the question is: How much will Epic charge us per token? That has yet to be determined. “Tokenomics” will ultimately rule the roost.