The savvy tech strategy behind Obamacare

The U.S. health care industry is undergoing several massive transformations, and the Office of the National Coordinator (ONC) for Health Information Technology in the Health and Human Services Dept. is spearheading the technical requirements and interpreting the legislative mandates into the specific policy requirements.

Its efforts started during the George W. Bush administration, which mandated in 2004 the use of interoperable electronic health records (EHR) systems by 2014 in what is known as the HITECH Act, and its efforts have become even more important due to the 2010 Patient Protection and Affordable Care Act (ACA), aka Obamacare, that changes the rules to ease citizens’ access to medical care and to further require electronic systems use by providers and patients alike, so the use of such systems matters more in achieving the ACA’s cost and eficiacy goals.

Doug Fridsma, an M.D., is chief science officer and director of the ONC’s Office of Science and Technology, and thus helps lead the federal efforts to make the HITECH requirements happen at a technical and medical level. Fridsma spent an hour with me discussing the issues that many health care IT and medical providers have raised as the deadlines get closer. The interview took place as the feds prepare to roll out the national signup registry this fall for individuals long denied health care to get it, though funds starvation by Republican congressmen has slowed the technical deployment and caused some rollout delays.

My key takeaway was not to think of the health IT efforts as the equivalent of ERP — as I had been doing — but as like the Internet. An ERP system prescribes process and procedure, whereas the Internet provides a framework for multiple kinds of uses and values. The feds want the latter, even if in the short term a single set of rules implemented via technology might have more appeal to health care providers that want a simple answer as to what they need to do. That’s not an obvious approach in traditional IT thinking — nor the approach used in many other countries — but it makes a lot of sense given the constant change in technology.

The following is the edited transcript of our interview. Here are the key sections:

• Meaningful Use requirements: Why does it seem so hard?
• Health information exchanges: How to think about interoperability
• Patient engagement: Are portals too separate and locked down to gain adoption?
• How to keep sensitive information separate but accessible in a federated system
• Why incremental efforts are a better approach than a top-down specification
• Project Direct: A supplement to HIEs when pass-along makes sense
• Why health IT can’t be like ERP or AOL: Avoiding the path of least regret

Meaningful Use requirements: Why does it seem so hard?

InfoWorld: In talking to practitioners and IT people both, it’s clear that there are a lot of issues they’re confused by — perhaps afraid of — that we’d like to help them understand a little bit better. I’ll start off with the Meaningful Use requirements. When I was at the HIMSS conference earlier this year, people were really wringing hands around the requirements, and from someone who’s covered technology a long time, they didn’t seem that onerous. I was really struck by that, so I wonder what I’m missing.

Fridsma: When it comes to establishing the criteria, the sort of the technical specifications that are required, we try to do that on a very open and inclusive process. We have our HIT [Health IT] Policy Committee and our HIT Standards Committee. We issue an NPRM [notice of proposed rule-making], then we get feedback from that and we incorporate that. In some sense,we’ve been pushing the industry, perhaps a bit more than it’d like to be pushed, to create the interoperability specifications that we need. We recognize that there’s a lot of both our programs and other programs that are pushing the goal that having consistent, interoperable, and electronic means of sharing, collecting, and using information is important. So there’s work with the Center for Medicare/Medicaid to implement new specifications around the standards for billing, such as the ICD-10-CM Codes — an important aspect of that that I think the EHRs are working on.

We really do want to move beyond what have typically been siloed operations, and get to where the rubber hits the road. Interoperability isn’t an easy thing, and I think you have to get it out there and start getting people to use it, and then refine that over time. We tried to address the right balance with this.

I think there are other pressures occurring. The kind of change that’s occurring is really relatively quick. And I think there’s a range of vendors. There are some that think that we’ve not pushed hard enough; they tend to be smaller, more innovative, newer companies. There are those that think we’re pushing too hard because they’ve got legacy systems that need to be integrated and incorporate this information.

We’ve tried to hit that magical point where not everybody is perfectly happy, which means we’ve probably hit it about where we need to be.

Health information exchanges: How to think about interoperability

InfoWorld: There seem to be a couple of sets of issues that people are wrestling with. One is the exchange among providers. There’s this whole notion of health information exchanges [HIEs] and so forth. The impression I get is that they’re all over the map. Some won’t even sign BAAs [business associate agreements, obligating them to legal responsibility for information management], which sounds to me as if they’re really not in the business if they won’t do that. But there seem to be questions around “Who do I trust?” “Is there really a set of common exchange formats?” “What does it mean to have exchanges of batch processing for transferring a patient from one facility to another?” “Is it supposed to be more real time, such as if it’s an emergency room situation or you’ve got personal multiple providers who may have several appointments in the same week, so you don’t want to have information that is outdated?” I’ve talked to providers who do all these models, and each seems to focus on one model or another. I wonder if there’s something about the model that isn’t clear, or maybe that’s just life — there’re several models and they need to shake themselves out.

Fridsma: The first thing is that when they talk about interoperability and exchange, I think people have different definitions of what interoperability is, so we follow the IEEE definition. Basically, interoperability has two parts. The first part is the ability of two systems to exchange information, so to be able to move information from one place to another. Then the second part is the ability of the system to use the information that was received. There are these exchange and use pieces.

A lot of people will talk about exchange as kind of moving information around, and using it as being kind of semantic piece or the ability to understand the information and know how to use it effectively.

Given that, it’s important to recognize that there are a lot of different uses that people have, and you articulated some of those in your question. Health care as an industry is complicated, and there are lots of different ways to communicate. We’ve taken the approach that we’ve tried to model after the Internet, the TCP/IP framework that basically has different layers of the architecture. The technical details of it are less important, but it means we want to provide the fundamental building blocks that people can use to solve the use, the kind of interoperability they want to achieve.

Within the exchange piece — distinct from the interoperability piece — we’ve essentially said we want to enable ways of pushing information from one system to another. So we have put into the 2014 Certification Criteria this notion of the Direct protocol as a way of pushing information from one provider to another. We found there’s a lot of use cases in which that’s a very valuable way to do it. Some people have said, “I just want to be able to send a consult in my multispecialty practice down the hall or into a different building on the campus or whatever, and it seems silly that I need to upload it to an HIE and then they have to download it and I have to query for it,” and there’re all these other complexities that might be about that. For their use, we want to be able to push that information, so we included the Direct specifications as a way of creating that functionality.

We also included, as an optional certification criterion in the 2014 edition, a protocol called Web Services, which is a more system-to-system way of having the communication occur. It’s based on a slightly different protocol, and it serves as the underpinning for some of the standards that many of the vendors use already. It certainly was one of the standards used as part of the Nationwide Health Information Network and now what’s called the eHealth Exchange.

Many of the HIEs are using those kinds of protocols to help exchange information. I think we would likely not succeed if we relied on a single solution to solve the complex communication and exchange problems we have in health care. So providing ways to push information from one place to another or to be able to query and ask questions of different systems and get responses back is going to be important.

What we want to create is those building blocks: the way we format the data so that it can be computer-readable, and the way we exchange that data. We’re really trying to create a portfolio of solutions, both for exchange and for the different uses that people might have for the data.

Patient engagement: Are portals too separate and locked down to gain usage?

InfoWorld: That’s fair enough. Let me ask you a little bit about the patient engagement part, because there’s a data exchange with the patients. I’m a Kaiser Permanente patient, so I’m probably working with one of the more advanced versions of that. But one thing I’ve noticed in most implementations is that they are essentially locked environments. If a patient has multiple providers — for example, my dental and optical providers are not the same as my medical — and assuming all providers have some sort of patient portals, they don’t really federate. It’s not really a portal; it’s three portals.

There also seems to be a notion that the information has to stay locked, even when given to the patient. It’s not that easy to bring information into something else. I know Blue Button is an effort that seems to be pushing toward that. But it strikes me that we have a bunch of proprietary silos being built on the patient side similar to what we have on the provider side. Am I overreacting to what I see in the early days or is that a justifiable fear?

Fridsma: One of the things that I can say is that making sure that patients are not just the thing to which we deliver health care, but a full participant in health care, is going to be a really important part of our work going forward. If what happens is that we create a way for providers to talk among themselves that doesn’t include the patients then we haven’t really created that health care system, engaged the patients in their health care. A clear success criterion is to make sure the patients are engaged.

You mentioned the Blue Button activities, and that’s a key part of what we need to accomplish. There is a challenge that you’re going to have all these portals, and for you to be able to get an integrated view of your health care system, it’s going to be really, really hard, because you have all these different places that you need to go.

I’ll use an analogy from the financial sector. What we don’t want is a whole series of portals into your investments and your bank and things like that. We want something that could eventually look like Mint.com, for example. We could integrate that and be able to take a look at all the things that are there.

There is a risk that we’ll have these multiple portals, but I think it’s probably an intermediate step to a better place. In the Blue Button, we’ve adopted the standard that’s the same content standard, if you will, as what we have for providers. We’ve created a mechanism to allow that kind of exchange to occur. We’re trying to, within Blue Button, expand the kinds of exchange protocols using both email and other ways, so we have the ability to have this integrate with some of the other EHR systems.

I think fundamentally it is really important for patients who see a doctor who uses one particular EHR that their data doesn’t get locked into that EHR and can’t go with them. If you were to leave Kaiser and move to a different provider that used a different EHR system, I think that we, as patients, have the right to get that information in computable ways so that we don’t have a bunch of scanned images going forward that doesn’t allow your new doctor to take advantage of clinical decisions, support, medication reconciliation, or some of the other things that might be possible.

You highlight an important point, one that I think we are working diligently to create ways that both the consumer and the provider, that information can be merged together. I think the Blue Button activities and the work of the Direct protocol is a first step in that. We still have more work that needs to be done. I think at the end of the day what will drive this is going to be patients who see the value of this, who demand that from their providers or from their health care systems.

And in fact there starts to be business drivers that make it advantageous to the organizations to share the information to include the patient in their health care and make sure that if you have multiple Web portals and the data isn’t getting integrated in a way that you can perceive it, my guess is that same integration probably isn’t happening at the provider side either.

InfoWorld: Let me ask you a related question around a security model with the patient information. I’ll use Kaiser as an example, since I know it very well. If I go to a Kaiser facility, they give me paper with all this medical information on it. If I want to take that from their patient portal and put it onto my computer, I can’t. That strikes me as odd. I realize that electronic information is much more easily routable, so it’s unlikely someone’s going to come and steal my paper records in my filing cabinet in the home, while it would be much easier if they had access to the portals and could take that data, that they might do nefarious things with it at scale. It’s easier to do it at scale electronically.

But it seems like an inhibitor for patients to aggregate their own stuff. You can’t even email, for example, your doctor and get an email back. You have to log into their system. If you happen to have your phone with you and not your computer, you don’t have your password, it doesn’t work the same way, blah, blah, blah. I wonder if that’s also something intermediate or whether there is something fundamentally different about electronic communications that’s going to keep the access tighter than it is on paper.

Fridsma: Well, I think there is greater concern around electronic data because obviously you could go down to a paper-based medical records room, put on a white coat, walk in there, and pull a chart to take a look at it. But it would be hard for you to take all the records in that room, put them in the back of your trunk and take off and peruse through that or sell the information or the like. They might notice that they are gone. If they didn’t, that would be an institution you wouldn’t want to go to.

InfoWorld: Yeah. But electronically, when you steal it, you still leave it there. You don’t actually take it, you copy it.

Fridsma: Right. Privacy and security are important aspects. We certainly believe that’s an important aspect of our responsibility, to make sure that patients and the people that are entrusted with the care of that information, treat it seriously, and provide proper safeguards to that information. So I think part of that is to have some of these other things in place.

But if you think about what’s happening in social media — it’s not exact example, but I think it’s important just as a data point — if you have a Facebook account, you’ve probably gone to Twitter or you’ve been on a Web page or something like that where it says, “We’d like to authenticate you.” You could just authenticate with your Facebook ID and password. You could authenticate with your Gmail two-factor authentication or the like. One of the things that we’re seeing that’s happening in social media and out there on the Internet is you’re starting to see people developing infrastructure that allows you to authenticate in one environment and use the credentials from that authentication in another environment.

The White House a couple of years ago produced a white paper report called NSTIC, the National Strategy for Trusted Identities in Cyberspace. What NSTIC is trying to do is to develop an ecosystem of identity management, if you will. If you go to a bank and you take out a loan for a house, they credential you there and give you an ID or a password or a certificate or whatever it is, something electronic that allows you to access their website and things like that, that process by which they authenticated that it was really you, you’re the one responsible for this loan, and they know you are who you say you are. They may be able to issue you a credential that could be then used in other such situations. You might be able to use this to go and do not just online banking, but other things. You could manage email, or you could do something with the government, or you could whatever.

I think there is a lot of desire to create an ecosystem that allows you to get credentials that then would allow you to authenticate and use that credential in different places. In the health care space, you could imagine that you’re in your doctor’s office. The doctor knows it’s you because he’s seen you for the last couple of years. There’s a credential that gets issued as part of that office that might be able to be used, say, in a hospital that’s affiliated or with a consultant that the doctor refers you to that allows you to tie together all that information and not have you go to all these different websites and authenticate.

You start to see more seamless integration. I think that’s a vision that the White House in the NSTIC report put forward, not just in health care but more broadly. I think what we’re seeing is right now we have some initial forays into making sure we have things private and secure and we’re moving incrementally to expand the level of sophistication or the level of ease of use. But we’re trying to do that in a very cautious way so that we maintain that privacy and security. We want people to really understand that to get information to flow. As Farzad [Mostashari, the national coordinator for health care information technology at the ONC] likes to say, information moves at the speed of trust. You’ve got to be able to trust how the information is being managed and that becomes an important part of the overall strategy.

How to keep sensitive information separate but accessible in a federated system

InfoWorld: Let me switch speaking of trust to an issue I’ve heard from several people on the health care provider side. One thing that really drives them nuts is how to handle the rules around AOD [Alcohol and Other Drugs], because there are stricter rules about information there, so even in the unified system, AOD stands apart. The primary physician may not know what is being prescribed, for example, by a psychiatrist or that a person is being treated for some sort of drug addiction, and there can be consequences of the isolation of information. I realize this is rooted in 1970s rules around privacy, when there was a lot of abuse of these records by insurance companies and employers and others, so legislators created these rules to basically wall it off. But in integrated care, walling it off is an issue. I’m curious if you’re seeing this or if this is just a handful of people I happen to know who are frustrated by it. If this is an issue, how might it be addressed?

Fridsma: You’re absolutely right. There are a lot of folks who are concerned that they follow the rules and regulations around protecting these particular kinds of diagnoses and behavioral health issues, issues that have to do with drug dependency and things like that. As a result, they would much rather not share data at all than risk breaching or sharing information in a way that would be not in compliance with the what the rules and regulations are.

This is something that we identified early on as a significant challenge, and we’ve been working very closely with SAMHSA [the Substance Abuse and Mental Health Administration] and primarily through Joy Pritts, our chief privacy and security officer, to develop technical specifications that help implement or support the policies that are out there around these behavioral health issues.

One of the things that we did is, over the course of the last year and a half or so, develop a project called Data Segmentation. It’s data segmentation for privacy. It’s a standard in the interoperability framework, one of the initiatives that we have that helps support the community to reach consensus around standards.

Coming out of that initiative, we developed technical specifications that allow you to take the medical record and segment those chunks that would be protected diagnoses or protected information that allows you to say, “Here’s the whole medical record. Here’s the chunk that I’m going to share with you as a primary care doctor. But I don’t want you to share it with anybody else.” That information gets carried with the electronic information so it carries with it the disclosure rules and things like that, so you can make sure that you can segment the data, that which you want to share and that which you don’t want to share, and that which you’re going to share but you don’t want that person to forward it on to anyone else.

That early work is now being piloted. There are, I think, three or four pilots that are currently ongoing. There’s a standard that’s going through the standards balloting process right now, and we have some commercial enterprises that have adopted that standard, that demonstrated at HIMSS this past spring.

I think fundamentally it’s really important, as you expressed, that behavioral health providers feel confident that they can share information and not have it disclosed in ways that would not be under the rules and regulations that that information is held. By providing that technical infrastructure that would enable that to occur, we hope to be able to engage behavioral health providers and others, because clearly there are patient safety and other issues that need to be addressed if that information is withheld or is not shared or is inadvertently shared.

InfoWorld: One health system I talked to, what it’s done is basically put in the records that the person is being treated, no details as to what, and indicate, “You need to call us if you’re treating this person, because there’s something else going on that we can’t put in the record.” It basically put in a flag. That way at least you know there’s something going on, as opposed to not knowing, because if you don’t reveal that there is something going on, a person may make assumptions and just go blindly, not knowing there is an issue to even worry about. That’s how one organization does it. Another one I’ve talked to basically says, “If it involves any medications, we have the psychiatrist, if they’re being treated by a psychiatrist, review the medications from the primary physician.” They sort of flip it the other way, where they put the responsibility on the person who has the most access, which the doctors didn’t like at all. But they didn’t know how else to deal with it. Those are two models I’ve come across.

Fridsma: One of the things that’s important, at least from my perspective in the work that we do, is when it comes to the standards and the technical specifications that we work on, I don’t want the technology to be a barrier to the policies that people want to apply or to implement. Regardless of how to handle that issue, we want to make sure that people don’t say, “Well, there’s no technology to do this, so therefore we aren’t going to share at all.” We want to be able to support the various use cases and make sure that we’ve got the right way to do this. So that’s part of our responsibility, is to make sure that we’ve got the technical capabilities that allow the policies to be properly implemented.

Why incremental efforts are a better approach than a top-down specification

InfoWorld: I suppose one subtext there is that if the policies were created for a different time and space, and don’t fit the more integrated care model of today, maybe the policies need to be revisited, which of course is outside of your domain. But that may be a requirement.

Fridsma: No, but you’re absolutely right. We talk about the interaction between the policy and technology pieces. Within ONC, we have both of those responsibilities. So, on the one hand we want to make sure that the technical infrastructure can support the policies that are out there. But we also have to recognize that sometimes a particular policy in a different world would have been easy to implement, but in the current world is really convoluted, and that maybe we need to go back and revisit that and say, “If there’s a small refinement to our policy, we can actually simplify the technologic implementation of that in a really substantive way.”

There is this interplay between the policy and the technology that’s so critical. It’s one of the reasons why, at least within ONC, we have both the HIT Policy Committee and the HIT Standards Committee, and they keep each other informed. Because the policy folks might say, “We would like to do X,” the standards folks will say, “Well, you can do X, but it’s going to be really complicated. If you wanted to just tweak this a little bit this would be easier.” Then we feed that back and we can come to the right angle of repose, if you will, between policy and technology.

InfoWorld: It’s funny, this sounds like the so-called agile development process where the stakeholders all are talking to each other throughout the development, because things do affect each other. If you specify, then dump it over to somebody to implement, those interactions aren’t always apparent and they can lead to overly complicated approaches, approaches that don’t work. Right?

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.

Part of what we’re trying to do is build in the ability to move from one way of doing things to a different way of doing things. If you build one big system and one-size-fits-all, you have to do rip-and-replace, you have to start over.

Remember AOL? It was the easy way to get on the Internet but you could have everything but the Internet. Because it was interfaced and canned, a closed garden. We’re really trying to get to the point of “Let’s not build AOL for health care. Let’s build those fundamental building blocks that allow things that we could not have even imagined now to be able to be enabled.”

We need to build in that process the ability to incrementally update and change. That’s why I think this notion of agile and Lean and the ability to migrate, if you will, from Version 1 to Version 2 is such an important part. If you have building blocks and get one of them wrong, you can swap it out and put in another one. Or if there’s a new way of doing things that comes along, you can insert it into your portfolio and it’s not going to necessarily disrupt the rest. That’s an important part of our strategy and frankly, it’s an approach that is different from what many other countries have approached in terms of their strategies for getting to interoperable health care systems.

InfoWorld: Your AOL recollection made me laugh because I was around this business back then, and a lot of organizations said, “Oh, we’re going to go on AOL because it’s a pre-fab environment basically that works. People love it. It works. It’s pre-fab.” But you’re right. You could do only what it allowed you to do, and it didn’t evolve with people’s needs and uses and desires, and it fell away. But I think a lot of people in health care would love the almost-easy answer of an AOL-like approach. It wasn’t easy to build AOL — it was a lot of work — but the notion that you can build it and be done with it I think is attractive in the short term to people. “Build the health system. We’re integrated, now done, move on.” But that’s not realistic, and the Internet shows us why that’s not realistic.

Fridsma: Exactly. We realize that there will be people who will build AOL-like solutions in this space. Our job is to make sure that patients’ health information doesn’t get locked into those systems if they need to move or migrate to systems that are more modular and have additional functionality.

InfoWorld: That applies to the providers too, if they end up building AOL and realize, “Oops, we didn’t want to do that after all, and do something else.” They have to be able to move, not just the patient.

Fridsma: That’s why we have this stack. We have the stack of vocabulary and content and exchange standards. We just made an announcement around a new initiative we’re working on that we’re calling our Data Access Framework, which is how can we make sure that EHRs and the data within them has the ability to move with patients if they move. Because once you have that functionality in, you can start layering on things like authentication frameworks that allow you to do that remotely, or information models that allow you to ask questions in consistent ways that allow you to leverage that functionality for public health and the like.

We see that as an important part of maintaining both innovation and modularity and driving toward that world in which if you bought an AOL solution, at least you should be able to get your data out. If you decide that you want to create a highly refined way of doing things by connecting a bunch of building blocks together, that’s where we’d like to be. APIs and the ability to connect the pieces are what we will be exploring with the HIT Standard Committee as we think about how to build out this portfolio of standards.

There are some things that we’re not going to get quite right. And that’s OK. Because we’ve tried to create these building blocks and this portfolio of standards in a way that should be resilient. But it’s going to be hard for a while.

I think everybody is really struggling to do the right thing. I recognize the impatience. I recognize the struggle that people are going to go through. Our job is to try to do our very best to help support them as we go through this, to learn where the problems are and to try to quickly incorporate those changes to make things better as we go to Version 2 and Version 3. Our job is to provide the platform for others to succeed in this space.

This article, “The savvy tech strategy behind Obamacare,” was originally published at InfoWorld.com. Read more of Galen Gruman’s Smart User blog. For the latest business technology news, follow InfoWorld.com on Twitter.