HIStalk Interviews Darren Dworkin, CIO, Cedars-Sinai Medical Center

Darren Dworkin is senior vice president for enterprise information systems and chief information officer of Cedars-Sinai Medical Center of Los Angeles, CA.

Give me a brief overview about yourself and about the health system.

I’m the chief information officer at Cedars-Sinai Health. I’ve been here for almost seven years. Before that, I was the chief technology officer at Boston University Medical Center.

The health system itself is made up primarily of our large hospital. We’re a single-hospital facility located in Los Angeles, California. Like most large organizations, we’ve diversified through physician groups and other stuff that made us more of a health system.
We’ve been spending most of our time over the last four or five years setting and implementing our clinical IT strategy.

What’s different about working in a hospital that some people call “The Celebrity Hospital” or “The ER of the Stars,” where you got a lot of movie star patients and their supporters?

We don’t really think of it that way on a day-to-day basis. The reality is that we have a small percentage of famous clientele that use our organization, but for the most part, we try to define ourselves through the quality of care that we deliver and the programs that we offer.

That being said, I think there is no question that being here in Los Angeles, we end up having a little bit more scrutiny or an eye on us that sometimes weaves itself into our planning and even some of our communications. When it comes to implementing clinical IT, we try to make sure we do things well, but I think between our past CPOE failure and the media market it can sometimes feel a little like a fishbowl.

The one case where the Hollywood connection definitely worked against the hospital was the heparin incident with the Quaid babies. That must have triggered quite a bit of internal review. What was the IT involvement in those discussions about patient safety?

For obvious reasons, that is a hard question to fully answer, but I think that’s where Cedars has been good to not to look at errors specifically through one department, but really approach them as a system review. There’s no question that highlighted a system failure

The incident had us look at lots of different components that were part of the chain of events. But back then very few of them were directly IT related since we were busy implementing and most was not live yet.

Not to brag, but today we believe we stand in the top 5% with our use of barcoded med technology at the bedside. We scan in the high 90s on a fairly regular basis. But your readers are well informed about the complexities of the real workflows in a busy hospital, so while having bedside barcoding is great, it far from solves every problem.

The hospital has come a long way since back in 2003 when the decision was made to shut down the CPOE system after physicians protested. What do you think were the lessons learned that helped you get where you are today?

The decisions to implement and ultimately build the CPOE system are complex. They’re complex now and they were complex then. That story really starts in 1998 or 1999, as the Medical Center began looking for the right system for itself. I think back then, looking at the choices of what was available and the complexity of the organization, I think Cedars made a good decision to try to self develop.

Obviously, it didn’t end well. That story is well documented, maybe even over documented. But a lot of good lessons were taken from that failure that have since helped us, we could probably write a whole book.

It’s cliché now to talk to the idea that you have to involve clinical teams and make sure you do the right things from a training and engagement perspective, as today I think everyone understands that. Back then, these projects were seen much more as IT-centric things. 

As much as we knew we had to keep everyone engaged this time around, it was still hard to keep applying it. Especially the discipline to really focus on training — which by the way if someone insisted on me giving them only one piece of advice for a successful CPOE project, I would say besides the idea that there is not just one thing, focus on training.

The second area is the idea of a pilot and what you really want it to mean. The first time around, we used pilots as a substitute for a phase with the intention and plan to carry on to the next step regardless of the outcome. This last time around, we left real time to get input and to modify our approach.

We installed in seven phases. Epic tells us that is a record for a single site. While I would not recommend it, as we had too many, it allowed us time to tweak our approach. By the time we rolled out CPOE big bang in the hospital as the last phase, we did pretty darned well. We hit over 90% utilization — using real math — our first weekend ,and have stayed that high five months later. Remember, this is with very large private medical staff.

The last stuff is around how hard it is for organizations like hospitals to build and sustain large development teams to design and implement good clinical software. At the end of the day, a big problem of the original CPOE system was it was not great software. This drove us to select a vendor-based system as a core requirement. We chose Epic and are very happy with it.

Speaking of that, if a peer asked you what it was like to go through the selection, implementation, and now the support of Epic and to manage an IT organization throughout that process, what would you say?

For every organization, it’s different. A lot of it is where you’ve been that will shape how you decide you move forward. For us, obviously, given our history as a failed implementation, we spent a lot of focus on selection.

Selection for us was purposely run for a fairly long period, probably longer than other hospitals. It was a way of building initial engagement across the medical center in terms of helping people understand what the right type of system was for us.

The story I like to share is that shortly after selection, the good news was that it was unclear whether nurses had picked the system or the physicians had picked the system. Both constituencies thought they had played the pivotal role. I think it’s an example of having known where we started, we spent a lot of time focused on making sure that selection was done just right. We made sure we involved everybody that needed to be involved in participating in what ultimately became large-scale enterprise workflow design sessions.

People always want to know about what Epic’s secret sauce is in getting their customers live in a predictable fashion without too many surprises. How are they different from other vendors?

There are a couple of things that are unique with Epic. It’s strong software that delivers what it says it’s going to deliver. It has a strong user interface which clinicians relate to so when they’re demoing the system, they can more easily imagine how they’re going to use the system.

But most important — and I think to Epic’s credit — their secret sauce is that they rolled in an implementation methodology into the product itself. Very few people will implement Epic in a way that doesn’t use some portion of Epic’s methodology. I think that they really appreciated and understood well that it’s not just about the software. It’s how you put it in and how you ready your organization to begin to accept it.

How are you engaging with physicians now vs. before?

It’s hard for me to answer directly because I wasn’t there then, but I’m certainly part of it now. What we’ve done is more than just say we’re going to involve clinicians, which as you know sometimes involves showing it to physicians and nurses in the eleventh hour. They were part of the work teams. They were part of the teams that helped validate design. We had physicians as part of testing. We had physicians as part of the design sessions.

What we did effectively was bring together all the different members of the hospital into the same room, so that as things were worked on between the different constituents, they didn’t change so that people couldn’t recognize them as they went through a committee.

As much as possible, we brought all the people to the same place at the same time. In some ways, that resulted in 200-plus people being involved in a hotel ballroom going through something. But in the end, while at the time felt rather tedious, it paid off in terms of making sure that things were well integrated together.

Of course our challenge now, with a little bit of irony, is that as we continue to optimize the system. The number of people that want to come back into the room to really address system changes because the system is so integrated is enormous.

How did that get you on your journey to Meaningful Use and where do you see that playing out?

I’d characterize Meaningful Use more as a side trip for us rather than the journey. What I mean by that is that Meaningful Use was and still is a very important catalyst in driving IT adoption around the country, but for Cedars, our plan was well in motion and our strategy — and frankly, the tactics underneath that — were well understood prior to meaningful use being created. While we certainly knew that Meaningful Use was an important piece of the equation, we didn’t retool tactics to accommodate Meaningful Use. We knew that the end points would ultimately lead to the same destination.

When you’re looking at projects, especially when you talk about multi-year ones, you really have to make sure you demonstrate a discipline and a commitment to make sure you get to your goal as originally designed no matter how tempting the side trips may be.

You mentioned changing conditions. There’s a lot going in state and federal government. How do you see the developments that are happening changing the long-term strategy and thus the IT strategy of Cedars?

Some stuff is having a big influence. Some stuff is still yet to be defined.

Maybe speaking to the popularity of the product that we chose, it’s an integrated system that brings together ambulatory and inpatient as well as financials. As organizations ready to look at what it will take with accountable care, there’s no question that all those pieces of the puzzle need to come together. The better organizations are positioned in terms of seeing that information across the continuum merged with financials, the better equipped they will be. To that respect, not a lot has changed. I think that will continue to position ourselves to leverage our investment.

With regards to what’s ahead, there’s no question that as the demand moves higher upstream and organizations are transitioned from a fee-for-service world to accountable care, where you begin to blend in more population health management tools, we’re going to need to make sure that IT is at that center point to be able to provide it. The way we’re seeing it take shape, our agenda going forward is very much focused on the tools that will help us manage risk as we begin to take on risk in the new world and whatever form of contracting or arrangement that takes. As well as just become smarter and better at using the data that we have in a way maybe a little bit outside of that transactional lens that for a lot of years — probably going back four or five years ago — people really thought of as the objective or the goal.

Said maybe a slightly different way, I think that four or five years ago, it might have been a little bit easier to craft a goal around some of these projects — EMR projects — because you’d measure them in terms of physician orders written electronically or nurse documentation. The goals are moving well beyond that and the focus will be on the outcomes of the data that you’ve now collected.

That’s a criticism of Epic, that they were late to the database party and use a lot of gimmicks to move the data from their non-relational database to a usable form. What technology will you need to take advantage of your data?

I’m not sure I so much agree with the context of the question. We’ve not been struck by a challenge to get our information. I think our challenges have been more in terms of how we want to begin to use that information.

The reality is that perhaps for some smaller organizations, it’s true that out of the box tools or the automagical buttons might not exist in sufficient quantity to produce the data. But At the end of the day for us, the name of the game is trying to understand what we want to do with the wealth of the information we have.

To be perfectly candid, it’s relatively new to us. We went live on March 2 with CPOE , so we’re still learning which data we should begin to mine first and what we want to build.

I’ll give you a small example. For a very long time, we held back on a lot of decision support, largely because our focus was around engagement, usability, and adoption. While we knew that decision support is certainly an important tool of any EMR, we wanted to make sure we were very conservative in what we applied to maximize the usability. Now that we’ve lifted that veil since we’re successfully live, it’s been an interesting journey for us to figure out how to decide what decision support gets thrown into the system and how to ultimately prioritize that. In the end, as we better learn to manage the data that we’re collecting, I think that’s where all the work will be.

To go back to your question though, I think I would add that we do see, at least for ourselves, always a place to externally keep all of this information since it’s as critical as the EMR is for us. Our teams, have a long history of managing a clinical data repository. We will continue strategically to imagine ourselves as holding that data at a higher level than the transaction or application layer.

There’s a debate over whether implementing Epic means you’re being innovative or in fact being anti-innovation. What do you think innovation means in a hospital or health system environment and how do you practice it?

Our philosophy with Epic is that Epic does a lot of things great. Frankly, Epic provides us the innovation out of the box, which I think is maybe the theme of some of the accusations out there. But we embraced that as an opportunity in that, “Great, if somebody else has that covered, we’ll work on the next thing.”

We think of one of our roles in innovation as filling the white space between functional modules or between applications. But we try not to take too much pride of ownership in the innovation as when we see a commercial vendor — either an existing one or a newly emerging one — meeting the need, we are happy to yield the space back and look for the next opportunity.

Our challenge lately has been that healthcare IT continues to be such a hot sector that younger companies that we often look to partner with aren’t surviving long enough in their core ideas. The popularity of the sector has brought in a lot of new money with sales and growth expectations that are hard to deliver with providers. Everybody wants to expand quickly into other areas to make numbers. Nobody wants to stay and innovate in their box long enough to deliver complete end-to-end workflows. 

As we work with some of the smaller companies that start with a really good idea and fill a need, they quickly can represent to us a collection of functions intertwined with companies with intersecting business plans and colliding products. It makes you think about how private companies with strong backing can probably stay focused for longer and might be better positioned to grow an end-to-end workflow company.

How do you see the market playing out over the next 5-10 years?

I think parts of the market — as others have predicted and I will tag along — will continue to consolidate and some parts of the market will likely dwindle away. The EMR market just feels ripe for more consolidation. The niche clinical product market that’s out there — my guess is we’ll start to see that continue to dwindle away as enterprise clinical systems take over.

I still have lots of faith in the capital markets and innovation. I think that as new problems emerge, there’ll be new companies that will come up and help hospitals and health systems solve them. I have little doubt that we will continue to see data intelligence as a big focus for the next few years.

The tricky part is going to be how some of the bigger organizations like Cedars and obviously many, many others continue to learn to manage the integration challenge. Especially as health system appear to be acquiring. While we think internally that we moved away from best-of-breed, we have not moved away from deep investments in our integration technologies. Because we know that ultimately there’s always going to be a role for putting small pieces together to serve the whole. I believe this will be a big area in the next few years as well.

Does it worry you that an awful lot of hospitals have chosen Epic and that its large application set means you’re putting a lot of eggs in their basket?

I think at times there are some things we worry about, but overall I wouldn’t say that it’s a worry. I think that healthcare is still new in the consolidation business. While Epic is big, it’s not uncommon in other industries to start to see dominant players like that.

In a lot of ways, I think there are some positives with it. California is just beginning to see the potential of leveraging Epic for information exchange. Other states have been able to leapfrog some other efforts by joining together already. I also think there has been some great group think and group input that we’ve benefitted from in terms of more rapid maturity of the applications because there’s such a wide and diverse customer base.

In the end, it always gets measured in terms of what organization’s specific needs are. For us, we’re comfortable– and in fact, frankly pleased — to see a large, healthy vendor behind what is obviously a fairly large and significant investment for us. We’ve not been afraid to innovate or seek small partners if we were looking to do something that was out of their sphere.

Any concluding thoughts?

Yes, two.

The first is on people. It may sound weird, but it’s still amazing to me how much people play a big part in everything that we’re trying to accomplish. I know that there’s a lot of focus often on the software vendors and the products, but I’d tell you the same thing that we talk about internally. The largest reason for delay or the largest inhibitor to moving forward with a new project — besides funding — is most often the ability to find the right people to work on the project with the right skill sets. We spend a lot of time encouraging and growing our own teams, knowing that ultimately that’s the secret to our ability to deliver. We are recruiting and so is almost every fellow CIO I meet. We need to find a collective way to start to solve our people shortage.

And second, thank you for interviewing me. You have a great product with a rather shocking reach.