Technical Leadership in an Evolving Health Care Climate

MIT Sloan Management Review: When last we spoke, you noted it was important for managers to be able to predict the future as far as technology goes, because if you don’t see what’s coming down the line, it’s hard to prepare for it. Since then, you have gotten more interested in blockchain. Could you tell me a little bit about when and how you became interested in it? What kind of impact will it have on health care?

Dr. John Halamka: It’s very common that I talk to people about blockchain because they think I’m a sort of evangelist or zealot for the technology. I’m neither. With any Gartner-hype cycle in technology, you have to evaluate it and figure out how you get from the era of inflated expectations through the trough of disillusionment to the plateau of productivity.

I ask this question, given the work that I have done in the Bush and Obama administrations by their operability: Are there specific use cases where blockchain would solve a problem that isn’t solved by relational technologies or Hadoop or some other traditional data approach? I see three use cases. I’ll talk you through them and why they probably do require blockchain.

Sometimes Harvard professors are sued for malpractice. But, what happens? A plaintiff attorney comes to me as the CIO of the empire and says, “I need you to pull all the medical records for this patient, going back 17 years.” And I do. And they say, “These are fake. They were altered.” Well, I can pull all the audit trails that show the records have data integrity, and they’ll say, “The audit trails are fake, too.”

We actually spend vast amounts of cycled and malpractice assertions trying to guarantee the integrity of the data we’re presenting in a case. Imagine that in our public ledger we don’t write data, but we hash every note that a doctor writes after it’s signed.

Seventeen years have gone by. Here’s the hash of today’s note. Here’s the hash that was in the blockchain. They match, and there’s no way the data can be altered. Data integrity preservation is an interesting use case for blockchain that a relational data store cannot meet.

You may find the second use case a little bit bizarre. The Bill & Melinda Gates Foundation asked me to unify all the health data on the continent of Africa. Now, it turns out that’s hard. Why is it hard? Have you spent time in Africa?

I have.

Then you probably know bandwidth is irregular and expensive. Power is episodic. The likelihood of finding world-class ISO 9001 certified data centers is near zero. Bill and Melinda asked if it was possible to have a widely distributed, decentralized mechanism for the storage of some very basic health care data around HIV, tuberculosis, and malaria. The challenge is that the data integrity again might be poor.

Can you divide a data layer backed with a blockchain layer to assert the data was pulled in a decentralized fashion and it is accurate? Bill and Melinda helped fund an organization, Factom. Have either of you bought property?

Yes.

How many hundreds of signatures did you do in that transaction?

A lot.

Right. So, here’s what happens: The storm of the century hits, and your basement floods, and you sue because you believe you were never told that you were in a flood zone. The mortgage industry, of course, needs proof of work, and therefore the mortgage industry (and Factom) has a data layer that actually stores a document and its metadata in a blockchain back end, which has proof of your signature.

That’s why the Gates Foundation’s issue is decentralized and federated — but we need dead surety that the data hasn’t been corrupted. Factom does this for the mortgage industry with data and blockchain, and the Gates are helping with that initiative.

In the third initiative — and you’re going to find this one also a little bit wacky —in the Obama administration, we did a reasonable job at creating vocabularies for data exchange. We did a decent job at creating a payload for data exchange and a horrible job on standardizing transport and the economic model around getting data packages from one place to another.

What if you say we’re going to come up with a blockchain-based mechanism to help with the transport: How would it do that? There are multiple ways. One, it’s going to be a micropayment layer; that is, we assert that we are qualified, authorized parties, and here is a payment, a micropayment, for the following record exchange. Suddenly you’ve built an ecosystem where you can actually have a standardized mechanism of requests for data, payment for data, that kind of thing.

Or maybe — and this is what we did in medical records — you need a public ledger of where the patient’s data is stored. Not the data itself, but just a public record of where it is. I’ve been working with a variety of entrepreneurs and researchers doing different flavors of record locator services. With MIT Media Lab research assistant Ariel Ekblaw, we worked on the idea of a smart contract, because remember, blockchain, being a public ledger, was never meant to be private.

Our problem is, even if I have an enumerated ledger of your visits with no data, you can still see that you have a visit to the HIV clinic, the sexually transmitted disease clinic, the mental health clinic, and the substance abuse clinic. But don’t worry — I won’t share any data about you. Right? That’s a problem.

The smart contract at Ethereum allowed patients and their delegates or caregivers to get an enumerated list of where they have been — smart contract, that’s one approach.

Another approach would be to say, just like Bitcoin, here’s a public ledger of stuff. I actually don’t know who the people are. And that’s OK, because you might imagine a situation where a provider can produce data and uses a person’s public key or something like that. Then, when the patient authorizes the receipt or retrieval of that data, the patient uses his or her private key. You actually could put HIV, substance abuse, and mental health information in a public ledger, and no one would know who it referred to. And the patient would help unlock that.

Those are the three use cases I’ve worked on in pilot projects. I did it because MIT wanted to do it with me and because the Gates Foundation wanted a public good to come of it.

If this actually came to pass, it would change a lot of health care organizations, just like that. How do organizations respond to fundamental changes that are brought about by technology like the ones you’re describing here?

I’m sure you are familiar with the work of leadership and change expert John Kotter. What happens at Harvard and Beth Israel Deaconess? If I say, “Oh, there’s a new cool technology, and everyone should use it because it’s cool,” what adoption do I get? Zero.

If I instead express an urgency to solve a problem because of quality, safety, compliance — pain that is felt by stakeholders, and oh, by the way, the technology happens to address this urgent problem — stakeholders will care less what the technology is and want to fix the problem.

I have a 30-member governance committee composed of doctors, nurses, pharmacists, social workers, legal people, and others who come together every month to enumerate the business problems we need to address. With a guiding coalition and senior vision and urgency — this should sound very “Kotteresque” to you — we can get things done. It has to be that formal.

When you’re talking about solving these business problems, what sort of time frame are you using at those meetings?

I’ll ask a rhetorical question: Do you think Epic Systems Corp., Cerner Corp., and MedTech are going to revolutionize the way we operate our health care institutions? I’ll answer it for you: No.

However, will Amazon.com, Facebook, and Google? Yes, they actually will. I have five Amazon employees embedded in my organization right now, and, for example, we moved seven petabytes of patient-identified data to the Amazon data lake and connected it to machine-learning services from Amazon as well as image-recognition services and some analytic services.

We’re taking the electronic health record (EHR) and surrounding it with third-party-provided services on a weekly basis. This is not yearly; this is every week. Why? Because how hard is it to plumb Amazon machine-learning services to the Amazon data lake? It takes minutes. You write scripts.

Or here’s another one: People ask, “Could we have an Alexa interface to a variety of our systems?” In one weekend, we wrote 30 Alexa skills. We meet monthly, and every month we’re showing what we addressed from the previous month. It’s that rapid of a cycle.

One thing that more traditional companies struggle with is dealing with failures. When you do rapid instrumentation, everything can’t succeed. How do you evaluate which ones are worth pursuing, and what do you do with those that fail? How do you do that evaluation process?

We are very structured about that, and I’ll just give you the metrics. First, consider the impact factor. That’s not publications, by the way; that’s how many patients, doctors, nurses, employees, and payers will be impacted by whatever solution we’re implementing. Because if the answer is, It’s two grandmothers and their cats, it’s not going to get a high-priority score. If it’s every doctor, OK. Every patient, OK. That’s the impact factor.

Second, is there a compliance regulatory imperative? I’m sure you have read the 1,000 pages of the 21st Century Cures Act, so when I talk about sections 4,000 through 4,012 you know exactly what I mean.

I’ve read it twice.

The 21st Century Cures Act says provider organizations must make an API available to their patients for use by any reasonable app that comes knocking. Therefore, that’s a regulatory must-do to get the high score.

At times we do what I’ll call sentinel events. We just had one the other day where a nurse took a medication out of a cabinet, put it on a cart, but never gave it. We asked, “How is it that you avoid errors of omission like that?”

We built an app so that as part of our electronic medication administration record, you actually scan the med as it’s going into the mouth of the patient. You can see exactly what was given to the patient. It’s a sentinel event, a quality/safety issue.

Is it strategic? Beth Israel Deaconess, soon to be Beth Israel Deaconess Lahey, or whatever we’re going to call our merged entity, wants to be known as a really innovative place that’s very patient-friendly. If we say we’re going to build a home-Alexa interface to all the scheduling systems, so you can say, “Hey, Alexa, make an appointment with my primary care doctor next week,” and it just happens, that’s strategic.

It’s impact; it’s regulatory, safety, quality, strategic. And I’ll mention the last one — I always find this one particularly problematic — return on investment. I’ve been running large complex IT organizations for 22 years, and at B&L, IT is always an “L.” We keep promising these big ROIs. I’ve actually never seen one.

I suppose that as we move to cloud-hosted services and subscription models, there may very well be some ROI out there somewhere.

Let’s say you come up with the solution that you want to drive, the successful experiment, the successful app. How do you use it to drive change across the organization, or once people see the business case or the impact factor, does it just happen?

After you’ve prioritized a project, you need a “clinical champion.” Let’s say it’s the chairman of orthopedics or the head of nursing. The clinical champion defines a circumscribed geography by which a technology will be rolled out. That could be a floor, a department, a building, or something else. You roll out the technology in that circumscribed environment under the auspices of the clinical champion, who is then responsible for getting that pilot adopted.

After you run a pilot (and that could be for a few weeks), you do a kind of “plan do study act” (PDSA) cycle. You say, “We did it. We evaluated the impact, and now we’re going to revise it. And then we’re going to try again.” You go through a couple of those iterations of agile improvement, and before you know it, either it just wildly fails or it’s been adopted such that people want more. Then you can start to spread it to other locations.

Often you have word of mouth. It’s very bottom-up. Friends talk to friends and say, “I have this cool mobile thing that I can do,” which makes others want it.

There will be, as you might imagine in any adoption cycle, the resisters. This always happens to me. I roll out a technology, and it goes 100% through the organization over a year or two — except in the dialysis unit, for example. Then you find you might need to do a tweak, an incremental improvement, to make it usable in that resister area. You engage those stakeholders, and you do that as sort of a parking lot project. It’s something you just push off until the end. That usually works.

You noted in our previous interview that Beth Israel has historically had more of an edgy digital culture, and it’s been that way for sort of a long time. How did you develop that culture? How do you maintain it over time, especially this willingness to experiment and embrace risk?

We’re poor. You may laugh and wonder how a $5 billion organization can be poor. Well, the IT budget of the $5 billion organization is 1.9% of the organization. Now, compare that to Partners HealthCare (4.5%), Stanford (6%), Mayo Clinic (7%). The reality is that our culture has to be edgy and innovative because there’s never cash available to buy anything.

Isn’t it fascinating that when you have all this money, you are actually empowered to go out and just do stupid things, because no one really cares if you blow $5 million here or there. I’ve talked to many people in our industry who say it helps if you’re underfunded. It forces you to be scrappy. That’s a big part of the culture.

It is also historical. I’ve been the IT leader since 1996. But in the ’70s, a couple of our docs, Howard Bleisch and Warner Slack — and Warner Slack’s student, Judy Faulkner — implemented some very early registration and scheduling systems that became Epic and MedTech. Those two physicians built that at Beth Israel; therefore there was a certain idea in the ’70s through the early ’80s that you can do things using automation that aren’t yet available as commercial products, and that’s acceptable.

Let me give you a caveat: In this merger we’re doing with Lahey, Lahey is an Epic shop. Mount Auburn Hospital, which is part of the merger, is an Epic shop. It’s going to be interesting to watch the next five years or so. It will not surprise me if what we end up doing over the course of the next five to 10 years is seeing more standardized commercial platforms so that everyone is running the same thing everywhere as a base. Beth Israel might end up being a provider of apps and modules and third-party add-on functions around the commercial EHR, as opposed to today, where we are the last hospital in America building our own EHR. We do everything clinical from scratch ourselves. That may end.

The last time we spoke, you said you really didn’t have a lot of turnover in your organization. What skills are essential today for being a digital leader or an effective employee in a digital organization? And then how do you go about developing those skills? Do you go and hire? Or do you cultivate them in-house?

You’ve asked a brilliant question. I’ll give you a different answer than I probably would have given a few years ago. As you may know, I was the first M.D. to graduate from the full Core Six program at MIT. Seven others before me tried and went screaming in terror. What was it that was unique about me? I am an engineer, software developer, doctor, and public policy and economics person. Those skills were really great in the 1980s and 2000s. Today, it’s totally different.

What’s totally different? First, I would argue that as an IT leader, you don’t need to be technological any longer. I speak 14 computer languages. Do I need to write code to be effective in my organization today? No. I need to make Gantt charts. I need to build budgets. I need to be able to have broad communication across my stakeholders and strict processes, as we’ve talked about. It’s sort of funny that we are hiring more and more people now who have very strong project management skills and communication skills, as opposed to programming skills.

I was talking to Pete Szolovits, professor in MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL), and I was reflecting on one of my early traumatic MIT experiences, which is 6001. That was a course where basically the highest grade on the final exam was 27%. I said, “Pete, how’s 6001 going?” He said, “The course doesn’t exist any longer, because today’s IT people simply find an open-source library already developed, or a cloud-hosted service or module already available, and glue them together.”

They don’t write code. Isn’t that interesting? It’s organizational and analytical skills as opposed to just being a technical code writer.

With your employees, how do you go about helping them develop those skills? What can organizations do to help them develop the types of skills they need to succeed in an innovative digital environment?

There are three strategies. Strategy one is you take an internal person and you develop them. We like to do that a lot. I have a project management office staffed with project management professionals, and we always have two or three interns in that office. We’re training internal people how to do this future job.

The second strategy is recruiting from colleges. We are a strong believer in co-op programs with local colleges. We will bring in bright, young people and, through an internship experience, develop them to the point where we often hire them when they graduate. That’s a sort of variation on the internal model.

Only very rarely do we employ the third strategy, what I’ll call the Monster.com search for somebody who already has the skills. I mean, it’s rare, but if there’s a particular domain where it’s extraordinarily challenging to teach someone Oracle from the ground up, you’ll pick somebody from another organization and promote that person. Those are our three general techniques.

When you say you develop the employees, what does that consist of? Do you send them off to a training camp or put them in new opportunities? If you’ve got employees who are maybe not necessarily older but have been around for a little while that you want to help them develop the right skills, how do they get them?

The answer is yes, yes, and yes. Let me give you some case examples. I had a cadre of six or so web developers who were doing traditional webpages and scripting. Do you know that today 80% of the access of Beth Israel Deaconess software applications are for mobile devices? For doctors, patients, everybody.

Yet, we had a cadre of folks who were stuck in a desktop world. So, after a search, we found Kony, an application development platform that enables Android and iOS apps to be developed once and repurposed across multiple operating systems, and we licensed that. But then we also licensed a boatload of services, ran internal boot camps and hackathons, and converted our entire web team into a mobile team without hiring a single new person.

Were they responsive to that, or did that take some cajoling?

The answer is, it depends. You’ll have your early adopters, your “mids,” and your laggards. By and large, a few of the teams see it as a fabulous opportunity. Then the others say, “Oh, I’m not quite sure, but I’ll go along for the ride,” and they eventually come around. Those who never come around, depart.

Sometimes we send them to external trainings. Amazon, for example, has had a significant set of courses for our staff, and we send folks out to Amazon boot camps or Apple developer conferences. It’s a combination of internal and external trainings. Sometimes for our docs we use things like computer-based learning — because getting docs to go anywhere doesn’t work.

You’ve mentioned partnerships with big organizations, whether it be Amazon or Apple. How important are those cross-boundary collaborative partnerships, how do they come about, and how do they help? Are there any drawbacks?

I created something called the Center for IT Exploration, or Explore IT. Basically it is analogous to the 20% thing that Google used to have. Take your best people through a meritocracy and ask them to spend 20% of their time investigating something outside of the scope of their day job.

We collaborated with Google during the Google Glass alpha test. Horrible product but interesting lessons learned. That’s sort of the way it works. We have a center that is permissive of these kinds of collaborations. And once you establish the relationships with Google, Amazon, Facebook, or other third parties, you can get really remarkable ongoing synergy.

I have one follow-up question on Beth Israel having an edgy digital culture. Is that just within your IT organization, or does that extend to the clinicians and physicians as well?

Our digital culture encompasses the entire organization. That’s actually been the blessing and the curse of being the CIO there for more than 20 years because you’ve got docs who say, “What do you mean we don’t have 3-D holographic, telepathic iPad interfaces? You could build anything. Do it.”

Are you hiring doctors with that sort of disposition?

We have a reputation for doing this kind of thing. We attract a vast number of young recruits in all medical specialties who come for the IT. Interestingly, when they’d come, I’d evaluate each one of them. We actually then made hay — 10% of their time, 20% of their time — for them to work inside our IT organization doing crowdsourcing. They develop apps in their domain and then help us deploy them.

You would say you have a pretty tight collaboration and relationship internally with practitioners?

Perhaps the story of how I was hired can answer your question.

Jim Ryerson, the CEO of CareGroup Inc., fired the CIO in the middle of the night on Dec. 10, 1996. The CIO at the time was what I’m going to call an insurance company CIO. He hated doctors. He felt they were the problem — he felt they really needed standardized, one-size-fits-all IT.

Then the next morning I was made the CIO of the empire with absolutely no preparation, job description, or negotiation. Why? Because I was deemed the “clinician friendly” IT leader. Because I was a physician myself, everyone in the empire said, “This is a person who’s on our side.” IT and clinical practice are two sides of the same coin.

What’s interesting is that even today my meetings are still focused on change management — I’m unifying the order sets of three of our community hospitals, so there will be one protocol for every disease. That’s hard work. But they say, “As long as you supervise it, we trust you.” Many organizations have this tension of IT not being aligned, not delivering, being a laggard. It’s a wacky thing to say, but when a clinician says jump, we ask, “How high?”

Clearly that will change a little bit with the merger, right?

That will be fascinating. I’m involved, and I’m not allowed to describe it in detail, but let’s say there are 16 two-hour meetings with all the IT leaders of the merging organizations figuring out how one to three years, three to five years, five to 10 years will work, and what the cultures of the organization are and the budgets that will influence what we can do and when.

The culture will be an important issue. But I think we’ll be able to take the innovative apps and modules that we run at Beth Israel Deaconess and make them Epic- or Athena-compliant so that they can run in other organizations’ IT shops. In effect, we’re leveraging the strengths of the innovator in areas where they don’t quite have the same culture.

My last question: Speaking of what tomorrow will bring, if you look at the three- to five-year time frame as far as technology in organizations, what are going to be most interesting, most troubling things? What keeps you up at night or gets you excited?

What’s happening is this radical transformation of the IT organization from a provisioner of services to a procurer of cloud-hosted subscription services that knit together reasonably well.

What’s exciting is that I’m actually going to completely get out of the data center business, the email business, and the data storage business, because others can do that better, smarter, cheaper, and faster. I will be in a business where I am asking for a business problem, what subscription service I glue together, and how I enhance workflow, and giving the doctors a seamless experience so that they won’t even know what service I’m connected to.

A lot of that is enabled by the work we’re doing with Fyre and APIs so that I can plumb Alexa into the EHR and no one has any idea what’s happening behind the scenes. It’s just seamless. Move to the cloud, subscription models; move to more APIs; move to more and more third parties, reading and writing and connecting in a seamless fashion that integrates workflow.

Now, the challenge is security. You’ve picked up the paper this morning, and you’ve read that every Intel chip that’s ever been made is completely flawed. So, not a day goes by where there isn’t some new threat or new risk. My challenge is, if you read my job description, it says top technology leader of the organization, accountable for all data integrity and security. Great.

Let’s say a nurse buys an Android phone and downloads an infected version of “Angry Birds.” And then that thing steals her password. That’s my problem. The sort of thing that keeps you up at night is that you can never plug every hole. You’re as weak as your weakest link. The nature of the attacks, the malware and ransomware, is getting so virulent and frequent, it’s just a matter of time before every health care organization in the country is hacked in some way.

But my job with the board is to every year bring in external white-hat hackers to evaluate the risks we have. We mitigate the most significant risks. So that’s all I can do. It’s maybe 100 risks. If you mitigate the top 50 every year, you just get stronger and stronger over time and do your best.