Fridsma: Yeah. And I think our approach, although I wouldn't necessarily call interactions between the policy committee and the standards committee "agile," we have this notion that it shouldn't be waterfall. We should think about small incremental and iterative approaches to doing our development. Because we'll learn a whole lot more from actually getting stuff out there and taking a look at it.
This notion of being able to create small bites in incrementalism, I think makes it much easier. It's a much more robust system to be fault-tolerant; if you didn't get something quite right, you just iterate the next one and you have only a small piece that you have to fix. Whereas if you try to get all your requirements done first, then you throw them over to the implementers and you've got it all wrong, it becomes much harder.
Although we do internally a lot of agile development and things like that in our work, ultimately we're trying to create this incremental, iterative, risk-focused way of addressing the problems that is, I think, aligned with a lot of the Lean approaches and the agile approaches that are in software development.
InfoWorld: Right, and I get the point that agile is not the specific process. I was using it as a metaphor for the notion of interplay.
Fridsma: We totally get that. And it's just such an important piece of what we work on.
Project Direct: A supplement to HIEs for when pass-along makes sense
InfoWorld: I want to ask you a little bit about -- you mentioned this briefly earlier -- Project Direct. What's going on there? What should people know that's coming down the line, or how this might affect them? Because people I've talked to have heard of it but are not quite sure really what Project Direct might do for them.
Fridsma: Sure. Direct is an important part of our portfolio. It's a piece of the puzzle. It's not the only way to exchange information. We've got other ways to do that with the HIEs and things like that. But it's an important piece of the puzzle that we saw early on. We brought the industry together. They looked at a whole variety of options. They chose one to move forward and that became the Direct specifications.
Direct is just, in simple terms, a secure way that's based on email protocols of sending information from one system to the other. It's based around secure email, and so it's pretty well tested. I think there are issues with regard to integration within the health care system or into personal health records and things like that. But it has served an important function in just getting some of the information moving.
Part of the issue was that when we started Project Direct, which I think was in early 2010, we were working very, very diligently to get people to adopt electronic health records. We had all these people that were working toward putting all their information in electronic formats and creating ways to capture the notes electronically. But at that time, the state of the art for getting information from one EHR system to another electronic health record system was using two devices, one called a printer and the other called a fax. The only way to really get information out of one system and into another was to print it all out and to scan it back in for the other system. Direct was really intended to help bridge that gap.
There was a need for an electronic connection between the two systems to be able to keep the entire conduit -- from the collection of the data, through the exchange, to the use -- in an electronic format. My hope is that success in Project Direct occurs when people recognize the value that it provides without necessarily having to understand the fundamentals of what the Direct protocol is, so making sure that certificates that are encrypted are managed in the background, and that when you send it you can trust that it's been both signed and encrypted in a way that will secure it from one system to the other system.
I would hope that the interfaces that doctors and patients and others have to work on aren't necessarily going to specifically call out Direct. But it's like you'll write a consult to a particular provider, you'll drop down their name [in the EHR], and it will then make sure there is the appropriate encryption that occurs to the consult that's sent. When you click OK, it goes from your system to the next system. It will connect those two systems and allow that information to flow from one to the other in a secure fashion.
InfoWorld: With the notion of daisy-chaining the connections as an approach, in addition to the notion of having an exchange hub, it sounds like you're trying to provide approaches for both ways of interacting because they're both valid and both exist.
Fridsma: Absolutely. I use an analogy often when I give talks or presentations. I ask the audience, "How many people keep in touch with their families?" Most people raise their hands. Then I say, "Well, how many of you use email? And how many of you use Facebook? And how many of you use your cellphone? And how many of you text your family?" What you find is that people use all sorts of ways to keep in touch with their families. If they're going to post a bunch of pictures, they do it on Facebook. If they need a quick text message, like "What's for dinner?" they send that off with a text message. If they have something a bit longer and want to send it to a variety of people, they might use email.
The thing is, I think our health care system is as complicated -- perhaps more so -- as many people's family connections. We don't have a single way of doing that with our families. Likewise, I think we can expect in health care that there will be different ways that serve different purposes, depending on the urgency of the request, the amount of data that needs to be exchanged, whether it's a push of information or whether it's a pull of information in response to a question. All of those approaches are valid. It's not an either/or, but it's an and, because what you want is you want to use the right technology for the right purpose.
We anticipate that there will be a variety of ways in which that communication will occur. Our job is to maintain a consistent portfolio of standards, so there is going to be probably a couple of ways that you might exchange information. There may be a couple of content standards, whether it's a summary record or a laboratory test or a radiology image. There are also going to be vocabularies and terminologies and other things like that that we need to use so that computers can understand the words that are being exchanged.
We really see this notion of a portfolio. It's not a one-size-fits-all. Project Direct is an important piece of the puzzle, but there are opportunities I think for other things.
Why health IT can't be like ERP or AOL: Avoiding the path of least regret
Fridsma: I like to remind people that five years ago we didn't realize that we had to summarize our entire life in 140 characters, because we didn't know about Twitter or tweets. I think it's humbling to realize that was just a few years ago. In my lifetime I remember using links from Web pages. I'm dating myself when I say that. But who would envision that we would order most of our Christmas gifts using the protocols that were developed in a physics lab to support researchers exchanging information?
InfoWorld: I used to work at the IEEE in the mid-'80s when we had access to ARPAnet before it became the Internet. We had email, and a few dozen other organizations in the world had email. We were early users and had no clue how this would go.
Fridsma: I remember the difference between Bitnet and ARPAnet, and there was different syntax. We in health care are at that point where there is this new technology, or maybe there's this new functionality that we're trying to enable with various standards. And it's not entirely standardized yet. We have the equivalents of Bitnet and ARPAnet and there's different syntax,; we have all the different early players in the space.
InfoWorld: What's interesting, though, is this issue of standardization, when you were talking about Project Direct and how it was part of a portfolio of approaches. I've been telling people that the health care industry is going through something like what many businesses went through at ERP a decade or 15 years ago, except ERP was about standardizing processes and creating a set of standards that people had to adapt to.
What you're describing is much more complicated. You're not trying to do an ERP for health care, which says this is the way the process should work, how things should work. You're trying to support multiple approaches that are valid and contextual and situational. Yes, there are standards around them, but it's not saying here's the way to do it, which is what ERP did, and why a lot of ERP efforts actually failed in the early days because they were too restrictive. It's a much harder problem, I think, that you're trying to address at the ONC.
Fridsma: Yeah, I think what we're trying to do is the equivalent of what you've got in the Internet, which is horizontal integration rather than vertical integration. You create the ability to take a common transport mechanism -- TCP/IP, whatever -- and you create the mechanism that I can take my computer, and I can plug it into a wired network and I can unplug it and it will connect to the wireless network, and my application or email doesn't miss a beat, because there're layers of abstraction between those systems.
I hope that the Direct and Web Services protocols, and other things like that become that horizontal integration, that allow you to say, "What's the appropriate mechanism to exchange the information? And what's the appropriate format to use so that the user just says -- I need to make sure this consult goes from my office to their office and it needs to happen in an expeditious way. I want to know that it's been received and it's an urgent request." Just by outlining that, the systems will understand how to route that information using the correct protocol.
We've done a lot of work looking at what other countries have done, and we've tried to learn from those experiences. Rather than trying to build this top down and create restrictions, we're really trying to ask, "What's the path of least regret in what we need to do?"
Because technology is going to go far faster than our ability to change and modify health care delivery, how can we make sure that there are fundamental building blocks? We know we're going to need vocabularies to help us in critical decision support and identify drug interactions. We know we're going to have to have syntax that computers can parse and understand. We know that we're going to have to have ways of exchanging information, and to solve a problem that says, "I want my patient to have a copy of her lab test at the same time that I have it" might require a vocabulary, a content standard, and an exchange specification that can be bundled according to whether it's urgent or not urgent or the like. We'd like to get to the point where whether it's on a mobile platform like an iPad or whether it's on your computer, the underlying infrastructure all works to provide that.
We've taken inspiration from the World Wide Web and the way in which it's approached a lot of the standards and tried to create the health care equivalences and do it in a way that's incremental. I don't think that we will ever have success if we try to get all the requirements ahead of time and institute a system that addresses them. Because as soon as you've completed the requirements, the world has changed -- and you have to start over.
InfoWorld: It's true. And your analogy of the Internet is an apt one, because it also has evolved. There were standards early on but they've all evolved and new ones have come into play and some have been discarded because people don't use certain things anymore, so they still exist technically but no one cares. It has adapted and we have adapted to it.
Fridsma: Yeah. You remember the early days when some Web pages would load in Internet Explorer and others would load in Mozilla, but not all of them would work in Safari?
InfoWorld: We're barely out of those days.
Fridsma: We're up to HTML5 now, which has a lot more functionality and the like, so the gap has closed considerably.
There is a sense of urgency and there's a sense of impatience, because I think people look at what is happening in the rest of their life and the way in which they can do their online banking -- you don't even have to deposit your checks anymore; you just take a picture of it, for God's sake, with your smartphone and they deposit the money in your account. Who would have thought that when the first ATM came out that might be the evolution that we would see?
InfoWorld: Fifteen years ago those banking systems were horrible to use. They did not work very well. What we experience today didn't just come out of nothing, and I think that's maybe one of the frustrations people have is they've seen other technologies move to this being a sort of "normal" part of their lives and health care is behind that. But these things never started that way.
Fridsma: Yeah, I remember Quicken. I was an early adopter of Quicken, and I entered all my checks in individually to balance my checkbook. Then I started to get these QIF files that I could download and import, but if you imported it twice it created duplicates. Then you started getting data feeds you could download directly, then you started to be able to have a two-way, where you could actually write checks as well as download transactions. Then we moved to online banking and now we've got Mint.com.