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.