Myth-busting blockchain for CIOs
Understand near-term and long-range uses for blockchain.
Podcast: Managing Healthcare Provider Directories
One of the most important features of blockchain is its ability to bring data islands together in a single source of truth, even among competitors. In this podcast, Mike Jacobs, senior distinguished engineer, and Lorraine Frias, senior director of strategic initiatives for Optum, examine how blockchain can help payers share the burden of provider directory management. These speakers define alliance and consortium models of collaboration, and the near-term benefits of looking at health care data in a new way.
Let's start with asking, why is provider data an ideal place to start a blockchain proof of concept?
Well, provider data is a huge issue in health care. It's one of the core data elements that drives our business, and payers across the US are spending an exorbitant amount of money trying to maintain and update provider data, and it's an issue we all face. And it's an issue that affects not just payers, but it impacts providers. It impacts members and patients through access to care.
And, in fact, it's so important that CMS has stepped in, and CMS can now fine a payer up to $25,000 per day per affected member for inaccurate data in a provider directory.
And in payers, it's not that payers are ignoring this. They're working very hard at this. In fact, the Council on Affordable Quality Health, CAQH, did a study not too long ago, and they've estimated that over $2 billion is spent annually by payers across the US trying to manage, and clean, and improve the quality of provider data.
But they also found that 75% of that cost could be eliminated with one single source of truth. And provider data is a pretty public starting point for a blockchain, pain in that it's available through provider directories, it's pretty noncompetitive, and so it makes a great starting point in trying to tackle a costly issue that we all share.
So why is blockchain uniquely suited to solving provider directory issues?
Well, as Lorraine mentioned, a lot of the costs associated with managing provider data could be solved with a single source of truth, and that's one of the key characteristics of a blockchain. While there isn't a single database, blockchain creates a distributed database that allows every participant in that blockchain to have replicated and up-to-date, accurate information, as the blockchain replicates that information to all the participants of the blockchain. So it creates a single source of truth, but it also keeps all the participants up-to-date with this accurate information as it changes.
And then with the future capability of permissioning not only entities but individuals to that information, we can be sure that we are sharing that information to the most appropriate people. In today's state of blockchain technology, there isn't a strong element of protecting permissioned data. It's really around permissioning participation in the blockchain.
And so that's what-- because provider data is public and the lack of a capability in the blockchain to protect specific data, like patient data, it makes it a really good choice for solving the issue. With a single source of truth, it keeps everybody up to date. But lowering the regulatory risk because of the current capabilities of the technology.
So tell me-- how would a payer start the process of using blockchain to create and maintain provider directories?
The [INAUDIBLE] starts with identifying a problem that you know that other organizations are dealing with, too. And that's part of why we collected provider data as a starting point. So understanding what that problem is, but then also understanding how your competitors view that problem. So building those relationships with your competitors, reaching out-- reaching out to other constituents in health care who might also be struggling with the problem that you're facing, and starting to open up dialogue, and network, and establish relationships in order to start talking about an alliance is where to start.
Who had early permission on the blockchain, and how is that permission defined?
Well, that really depends on the model of the alliance. So there's, generally speaking, two different models for alliances. One is the founding member model, that a founding member or a company is deciding exclusively who's going to participate. And they generally set up some rules associated with criteria for allowing additional participation on their blockchain. So the early permission is the founding member, and then deciding who else can have access.
Then the second model of consortiums is more along the lines of the alliance as a consortium model, where there are multiple founding members. And those founding members tend to get together and define a governance process around who else can join and under what circumstances, and maybe even the rules around dropping members from the blockchain. And so the outcome of that governance process is how permission is given out. So the early permission would be granted to the founding members, and then any additional members would be based on that governance process.
How much time and what types of resources are required to get this kind of a project started?
Well, I mentioned earlier the networking that you need to do in order to get an alliance going, and that's certainly a good amount of time at the beginning from some of your business and probably technical researchers, too. For example, Mike and I tag team on a lot of our alliance building work because he's got the great technical background, and then I bring the business background.
And so definitely a lot of time in the beginning doing that networking. But then as you get going, when you're honing in on the problem, it's important to get some of the other business perspective. In other words, the perspectives of the people who are going to be benefiting from your project. And so in this case, we're looking at providing data. So the heads of the organizations that are tied to provider data and what their needs are needs to be considered, and so getting them engaged is an important next step.
And then, obviously, from a technical perspective, in order to actually start building the blockchain, there's resources required, and Mike can probably speak better to that than I can.
Yeah, so the technical resources and time depends on the role that company is playing within that alliance. So typically, an alliance has some sort of technical contribution from each of the members, and if that contribution focuses on the delivery of the blockchain, and clearly that organization needs to have invested in learning, experimenting, and proving out [? deployment ?] of a blockchain. And so that's a fairly technical set of skills in the IT organization.
The vast majority of the members of the alliance will likely just be using the blockchain, not necessarily building the blockchain. And by using the blockchain, there is typically an Application Programming Interface that they would use to integrate their systems, their existing systems, with the blockchain. And so those resources would need to understand a fairly typical set of skills associated with integrating systems through application programming interfaces.
So once this is up and running, how is success measured?
Well, I would go back to why you're doing this in the first place, and in the case of provider data, we're looking to take cost out of the system for payers, for providers, and also to-- looking to improve the quality of data. And so setting up those metrics at the beginning of your project, and really understanding where the benefits are is important.
And so, you know, if we're able to demonstrate at the end of a proof of concept that we have taken cost out of the system, that we were able to save money from the administration that goes into chasing down and updating provider data, that's a success. If we're able to demonstrate that by collectively putting our provider data together across the blockchain, that we're actually able to improve the quality of provider data for all of the participants, that's a huge success, as well.
Tell me, looking forward, what else should members of this new blockchain alliance seek to learn in order to advance future efforts?
Well, what's really exciting to me is the idea of the collaboration of these competitors and other large constituents in that health care ecosystem. So approaching a problem collectively and collaboratively is super exciting from the possibilities perspective. If we think about what can happen next.
So international alliance like this is great, but now we have relationships built, now we have established a level of trust in working with each other, and the technology helps enable trust in the data. So we're able to look at other business problems that we're all facing, that are common across the industry. And instead of looking at those from our own perspective alone and saying, well, what do we need to change within our own organization? Now we can start to tackle that from a broader perspective, and say, well, if we had the benefit of working collaboratively with a competitor, if we had the benefit of working with another organization in the health care industry, how might we look at the problem differently? How would we tackle it differently? And then to actually do that together through this blockchain alliance.
From a technology perspective, I like to focus on fit for purpose. That is, based on the business problem at hand, does the technology-- the capabilities of the technology make sense to solve the problem? And provider data directory use case for blockchain makes a lot of sense right now because of the state of technology, where there is a lot of public data that's being used and very low risk associated with regulatory or privacy issues.
And so the technology is evolving, and so what I would say-- what members would want to do is monitor the evolution and the improvements of the blockchain technology, specifically around identity of users, security, and privacy.
Thank you, Mike and Lorraine, for sharing your thoughts on how blockchain can make provider directory management an achievable near-term goal. Tune into our next podcast to hear Mike and Lorraine discuss the efficacy of blockchain in longitudinal health records.
Podcast: Longitudinal Health Records
Blockchain is getting a lot of attention for its potential to solve the data disconnects in the health system. In this podcast, Mike Jacobs, Senior Distinguished Engineer, and Lorraine Frias Senior Director of Strategic Initiatives for Optum, examine the efficacy of blockchain in longitudinal health records.
When blockchain can support this type of file sharing, it will have tremendous impact on health care. The transformation will come in phases. Let's see why. Let's get started. What's the implication of having the longitudinal health record on blockchain? And who's going to benefit from it?
So many people are going to benefit from a longitudinal health record, starting with patients having access to their entire health history, no matter what provider they're seeing, no matter what payer they're with at the time. Or even when they transition into Medicare. Having all of that information available not only to them, but to their providers, means that they're going to get better care.
Because they would have access to that information in a consistent format and have all of their patient's history available to them at any time. Again, means that they're going to be able to provide better care and make better health recommendations to a patient. Payers will be able to streamline payment processes.
Today, there's oftentimes a lot of work that's done chasing down records and verifying care that's been given in order to be able to make a payment. And having access to that information from a payer's perspective through an LHR can only streamline the payment process, which is good for the provider and for the patient as well.
And then researchers. I mean imagine having all of that LHR data available to you in an anonymous format, so that you can use that data to study the population, study quality or effectiveness of care plans. And there's just so many ways that a lot of people will benefit from an LHR.
Mike, what's the reality of longitudinal health records on blockchain? How quickly can the industry expect to see this materialize?
Well, my view is that it's going to be several years before we see something like a longitudinal health record or the track and trace use cases on a blockchain. And by track and trace, I'm referring to the supply chain monitoring that could be used in the pharmaceutical manufacturing space, where the quality of the ingredients and the tracking of the delivery of drugs could be tracked on a blockchain.
There's a recent FDA law that, it's called the Drug Quality and Security Act, that sounds like it could definitely be implemented with a blockchain. But there are a number of realistic, even non-technical issues associated with implementing something like that.
One of which is that the technology is still evolving. And there's a degree of confidence that has to be built up in terms of our confidence level in the curing personal health information. And that hasn't been proven yet. And we're going to need to see some solutions actually implemented that help boost our confidence in sharing that information.
And then there's other systems, processes and regulations that may inhibit the adoption of a longitudinal health record. For example, the laws around the ownership of patient data today. In 49 of the 50 states in the US, patient data in EMR is owned by business. It's owned by the provider group. And it's not the patient's data.
And so if we're to get to a patient-centered health care system, some of those laws need to really acknowledge the ability of the patient to control who has access to that information, and what happens to that information after it is shared. From a provider's perspective, some of the use cases associated with provider reimbursement could be implemented with a smart contract on a blockchain.
But when you begin to look at the reality of today's contracts, those contracts are very customized. They're customized at the state level, sometimes even at the county level. And definitely as negotiation between the insurance companies and the provider groups, those contracts are customized. And in order to make that automated on a blockchain, we're going to have to get to some degree of contract standardization. So it goes well beyond the confidence in the technology and into these other areas.
Well, tell me, what is the near-term and mid-term dependencies that need to be resolved before the longer term goal of longitudinal health records on blockchain can be met?
You know, I think they can be classified as technical dependencies and business or business dependencies. I'll cover some of the technical ones. And I'll leave the business one for Lo. The first things that we'd want to solve is identity. Identity is the idea that we're able to clearly and uniquely identify an individual patient to ensure that they are who they say they are. And that we are treating them based on the history that we know of.
Many times, when as a patient or as just as an individual going around the internet, there's a lot of websites that will allow you to sign in with your Facebook account or with your LinkedIn account. And that identity is still owned by Facebook and LinkedIn and any other site. And you have no control over how your information or how your data is used.
And if a patient is to have a longitudinal health record with full control and consent over the use of their information, we're going to need something more along the lines of what's called a self-sovereign identity. It's independent of these existing sites. And so that kind of problem needs to be addressed to ensure that we know the patient and that they have control of their data.
And the second area is one, what I call key management. A side effect of the way the blockchain works is that there's the, cryptology is used. In order to accomplish that, there's the use of public and private keys to essentially sign transactions with your identity and your key, to prove that you are the one that requested that transaction.
The challenge is, is that if those, if a private key is lost, even if you have the identity, your identity squared away, the lack of private key means you're locked out. It's like you've lost your keys to your house. That you cannot access your information, nor can you even provide consent for somebody else to look at it. So key management is an important dependency to address.
OK, so let's say you had the identity and key management in place, then you want to be able to control who has access to your data. So data protection is an area that needs finer grain control and more capabilities on the blockchain. You would want to be able to designate which doctors can see your information. And not only that, you may want to limit what aspect of your health care record you would want to share. So data protection is another dependency.
And then a very large dependency is a multifaceted one around electronic medical record integration. Where we want to be sure that we're not disrupting the workflow of the provider. And that we find ways of hopefully solving some of our existing interoperability challenges that we have in the health care world today.
Blockchain doesn't solve interoperability problem, it provides an open canvas or applications like a longitudinal health record to address interoperability. And so we will have to work with the EMR vendors to create a more uniform interoperability strategy in order to get to longitudinal health record.
And then one of the larger agreement that we would have to reach, is finding a way to have the EMR vendors participate, presumably in a single national LHR, so that if anyone in the US goes into an emergency department, emergency department can go to this single location, a national level longitudinal health record. And finding a way for those existing systems to integrate with this notion of a single national LHR.
I would add that I think we're also going to need some form of incentives. So there's a ton of data, there's tons of information that providers have traditionally had control over. I think we're going to need some form of incentives to encourage them to share that information in a way that they haven't necessarily done in the past.
And then also incentives for the patients to be able to or to encourage them to manage their own information, which leads me to my last point about this, which is that consumer education is going to be really important. If consumers are truly put in control of their own health data, are they prepared for what that might mean?
Today, managing who has their health data is handled by the providers. They don't get really involved in that. The providers do most of that behind the scenes. And they have a ton of trust in their provider. And now we're going to say that the consumer has to do all that on their own.
So I think the user experience needs to be very carefully thought out for both the patients and the providers. And we have to be careful not to increase the work or the burden on the existing players in the system or make it harder for them to get done what they already get done today. Because if we do, it's just not going to work. It's just going to fail.
As they look ahead to blockchain, what should payers or providers be thinking about or doing now in order to prepare?
At a minimum, these organizations should be monitoring the evolution of the technology. Because what you read about in the media may not align with the reality of what the technology can really do. And my view is that the rollout of this technology is first going to be adopted by payers, quickly followed by larger provider groups.
And then ultimately, smaller provider groups and the patients. So you should have a plan on what to do beyond the monitoring of the technology. And the activities associated with going one step beyond monitoring really depends on your organization's appetite for risk and the adoption of new technology.
The first couple steps really align with more of a traditional approach to adopting a technology. First you should probably do some experimentation and discover what the current capabilities are, and that will help complement the monitoring of the evolution of the technology. Because then you'll have firsthand experience in understanding what the current state is.
The next step that part of that classic evaluation is, defining business-focused use cases that would be uniquely solved with blockchains. The third step would be to then take those use cases and assess the implications of implementing those in your organization.
And that might involve collecting existing pain points or existing cost structures, understanding which systems are involved, and even the processes and organization that might be impacted by implementing blockchain technology with those use cases. And then the last step, the unique step associated with blockchain that's going to be somewhat, a different way of thinking.
Because the technology is well suited or best suited for cooperating among different companies, you're going to find yourself with an alliance that is the cooperation of competitors. You have to get into a mindset of understanding that there is strength in numbers when it comes to these alliances. And that you're going to have to overcome maybe some cultural issues associated with cooperating with your competitors.
But that the real value of the blockchain technology is going to be when multiple companies come together to share information and automate those processes that will ultimately reduce the collective costs and improve the quality of health for everyone involved.
Thank you, Mike and Lorraine, for sharing your perspective on the viability of longitudinal health records and blockchain. Tune into our final podcast to hear Lorraine Frias' practical advice for building a blockchain alliance.
Podcast: Building A Blockchain Alliance
Blockchain is finding its way into health care. And today we are speaking with Lorraine Frias, the Senior Director of Strategic Initiatives for Optum about how organizations can build an alliance to launch and support a blockchain initiative.
Lorraine, where do you start?
You know, it really helps to start with a use case, something that you're trying to tackle within your organization. And we like to say that blockchains are most useful when you bring together loosely coupled organizations to share in audit information and help automate mutually beneficial practices.
So focusing on a use case that crosses company boundaries, especially when you're thinking about things like managing and exchanging data can offer significant business value. And companies need to form alliances to get this done, and that's the best way to really fully exploit the technology. Ultimately, the use case, though, needs to be driven out of a business need.
Once you've identified prospective participants, how do you pitch them on your prospective use case?
Well, you want to identify the right contacts in the organization. We've been starting with IT, because it's a technical solution blockchain, and so it's a good place to start. And innovation areas are often also a nice place to start. You probably have your own contact list or your own network, and that can be a natural guide for you to think about who you want to reach out to and where to start.
We suggest putting together a high-level conceptual overview of what you're proposing. And be sure to demonstrate the value in that. It's really important, of course. And then some indication of how the collaboration itself will work is really important to helping who you're talking to understand what you're trying to get done and how this is really a shared collaboration.
And as you're having discussions with them, what reservations do you typically need to address with these prospective allies?
You want to initially start out with some way to build that initial level of trust to be able to open up the conversation. And so starting with even a non-disclosure agreement just to be able to talk about what you're thinking about. And then if the conversation progresses, we think that a memorandum of understanding is a nice place to go next. A memorandum of understanding just kind of gives you the guardrails on how you're going to work together as you continue to figure it out, because as you are forming the alliance, there's a lot of things that you'll need to make decisions on as a group. And so you won't have a full-blown agreement right off the bat, but you need to have those guardrails in place to be able to figure that out together.
A lot of organizations are going to want to understand how much control or how much say they're going to have. Will the playing field be level across all members? Do you want to address that? If there is any risk to participation, think about how you're going to answer that or how you're going to mitigate that risk.
And then they're likely going to want to know what kind of resource commitment do I need to make, both from a human resource perspective and then a financial resource perspective? So as your alliance gets going and as you think about your use case, you want to have some thought around what kind of investment that's going to take and then how that investment will be shared across the alliance.
But then once you start to build some momentum and have multiple players engaged in wanting to form an alliance, then you need to start formalizing those interactions with things like project charters, documenting a governance process, decision-making frameworks are all really important, because everybody comes from different organizations with different ways of doing things. So collectively deciding on how we're going to do those things together is important. And then all of that eventually leads to a definitive agreement, a definitive legal agreement, that all of the organizations come together on.
So let's say you might be collaborating with some competitors. What are some of the reservations likely to surface with your internal executive team as it relates to this alliance?
It's so important to have that support, because you're working with outside collaborators in a totally different way than what you traditionally do. And so it's important to educate your internal execs about the project and, in particular, about the alliance and how that's going to work and what role your organization has in that alliance.
They're probably going to wonder about things like intellectual property, about what you're building. Alliance ownership rights and who owns what within the alliance. Who owns the blockchain and who doesn't own the blockchain and all of that. And then even things like branding and marketing, because as you start to gain momentum and start to publicly talk about your project, that could have an impact on an organization's brand, and so they're going to want to think about how they want that portrayed publicly.
And then I think the other thing is when you talk about high-level executives who are really used to driving and calling the shots, they're now having to come together, and so you want to reconcile any cultural differences as early as you can and find a way to provide an avenue for open dialogue around hot subjects.
How do you know when there are enough members for you to get started?
That is really dependent upon your individual project. However, I think that it's a little bit easier to get started if you start small and then grow from there. So if you're thinking big and long term, we want to have an alliance with 150 members and here's why and this is why it's going to be so great, that's awesome that that's your long-term goal, but it's really a lot easier to start small and test and learn early. And you can be nimble if you have a small number of partners.
As an example, the Provider Data Exchange Project that we're a part of, the overlap of providers between participants in this particular alliance is critical. The higher the overlap, the more valuable the potential contributions of that alliance member and the more they're going to get out of it as well. So it's really important to consider the right number of members but the right type of members as well. And then you can start to think about things like the network effect. And you need to have enough members to build momentum as it relates to value. But again, it's a little bit of a balancing act with the right number of members to build that network effect but also small enough to stay nimble and move quickly.
And you mentioned that Optum is part of a new health care blockchain alliance. Can you tell us a little bit more about that?
Yeah. We are super excited about this. We're partnering with other health care leaders in the industry-- Humana, MultiPlan, Quest Diagnostics, and of course, United Healthcare. We're all coming together to look at the issue of provider data in a new and different way. And payers and the industry in general spends over $2 billion a year tackling provider data and trying to keep that up to date and manage that information.
And so we believe that by sharing provider data updates with each other, we can actually improve the timeliness and the quality of provider data updates and help take cost out of that whole process for everybody in the health care ecosystem. In fact, the alliance is running a pilot, and all the parties that we just mentioned are going to be writing and consuming provider data changes with a blockchain. And that's all in an attempt to affirm the validity of this theory that by sharing, we can improve the process. And we expect to be able to assess the results of that in the fall.
Thank you, Lorraine, for sharing your thoughts with us today. Listeners, we hope you found this Optum podcast series on the health care blockchain informative. You can read more about blockchain and other technology innovations on our blog at healthcareconversations.com.
Podcast 3 – Building a Blockchain Alliance
Lorraine Frias, senior director of strategic initiatives, closes out our blockchain podcast series by providing practical advice for building a blockchain alliance.