Brailer's Farewell
In a one-on-one interview, Healthcare Informatics Editor-in-Chief Charlene Marietti recently chatted with David Brailer, M.D., PhD., the nation's first coordinator for health information technology, who recently announced his resignation. In the following interview, he provides advice on how providers can develop an IT strategy that will align with national initiatives.
Based on the foundation work you have begun, what key elements should healthcare executives consider in planning their HIT strategies?
There are three key elements. First, how are they going to get the basic clinical enterprises to pull more information from electronic health records, medication administration, etc.? I know they're well along on that, it's the basic.
Second, they need to look seriously at their interoperability strategy. How are they going to connect to other providers, labs, pharmacies, health plans? Whether they have a RHIO (regional health information organization) or not, or participate in another project, I think it's very clear the direction we're moving. It's not enough to have an information strategy that makes them a standalone island or that makes hurdles to information flowing. They need to take that into account so they're not surprised with lots of cost, changing infrastructure or surprises.
Third, they need to begin thinking about supporting the information needs of their consumers and patients. What are they going to do for portalizing their information? What are they going to do for supporting personal health records? For giving information to consumers about how well they're doing with their procedures — their clinical and quality performance on hospitals and doctors? This is something that's coming center stage now, and this is no longer a time they can put their heads in the sand and hope that it passes over. It's here to stay.
One risk factor they have to think about as they make these decisions is, we're in the process of getting agreement on what all the key information standards are, and they want to obviously pay attention to that. It's a process that will take a while because the U.S. is in such really bad shape given our standards activities. We're trying to make them, if you would, as 'de facto' as possible, meaning driven by the real life of what people do rather than something that experts proclaim from on high.
Will the continuity of care record (CCR) standard form part of your approach?
The government is not the chooser of standards. I know that in the past, when the CDC or FDA or some other agency needed a standard, they just went off and kind of cooked it up. We have partnerships with the private sector to work collaboratively, and that means we have to follow that discipline. We're not going to pick.
Vendors don't pick. Part of the problem we've had in the past, when the standards have been worked on by vendors, everyone said, 'This is all so technically complicated that we need the technical experts at the vendors to deal with it.' We've tried to be very clear about this: There are lots of technical issues, but this is also about making business judgments — about what business problems are important and require standards to be present and making sure that standards are not just technically sophisticated, but practicable.
We will vest our healthcare IT standards panel to deal with the question of the CCR like all other standards. The issue is this: The CCR is a fine standard, but it's completely overlapping with at least five other standards from HL7 and IEEE. What we want to have is not pick a bunch of best-of-breeds that are 'one-off' standards; we want to have the standard that we're going to use be harmonized and be mapped together.
It's a process that will take a while because the U.S. is in such really bad shape given our standards activities.
This (selection of standards) is going to be won ultimately by saying, 'What problem are we going to solve?' and 'What standard are we going to use?' The American Health Information Community has given everyone a set of five key business problems, but it will be up to the Healthcare Information Technology Standards Panel (HITSP) and the others to choose which standards they're going to drive from.
HITSP is a panel created in the American National Standards Institute that we have contracted with to develop the harmonization process across all the different standards organizations in the U.S. What we've said to the standards organizations is that HITSP is not one of you — it's an overarching project to bring you all together. You can all do your own pieces, but in the end there's one set of standards for the U.S. — one and only one — and HITSP will decide.
We're going to start channeling our funding to standards organizations and our support for them as a condition of them being in good standing with HITSP to make sure they are able to actually all work together. We're going to track this problem. In the end, the important thing is it will be people like your readers — doctors, hospitals, and leaders who work for real delivery systems and understand the real problems — and not the government and not the vendors.
Do you have a timeline for when you expect delivery of these standards?
It's an iterative process. For years, people tried to develop standards based on data. Now we're trying to develop standards based on business problems. A business problem might be, my patient shows up in the ER and I know nothing about them and we need standards for that. There's not going to be a beginning, middle and end to this. It will be an ongoing process.
To be specific: For the five breakthrough areas we've identified, we expect to have standards articulated by September or October. Then we're going to queue up some new ones. The question that we don't know the answer to is how many standards can HITSP handle in a given year? Is it four? eight? 12? We don't know. We're hoping it's between eight and 12. I think it will take five years for us to work through the 50 or 60 key business problems that the U.S. faces to really have the extent of standards defined.
For years, people tried to develop standards based on data. Now we're trying to develop standards based on business problems.
(But the work is) never over. As soon as a standard's gone, a year later, (standards developers) are going to go back because of new issues that come up. This is exactly why you put it out of government. Look, for example, at HIPAA standards. There are known defects in those HIPAA standards and the standards in the private sector have been updated a couple of times. But the regulations are still built around the standards that existed three years before the (rule) was passed. It's just really hard to reconcile the really deliberate and purposeful process of regulation with the organic and technically innovative way in which standards come about. We're trying to fit the process to the problem instead of using a one-size-fits-all tool.
How do providers and payers play a role in overcoming what you have said are your two biggest worries, that is, the adoption gap and interoperability?
On the adoption gap, providers and payers have a responsibility. We're going to promulgate the final rule for the Stark exception anti-kickback that will allow the donations of IT to doctors at hospitals. I really hope hospitals will see this as an opportunity a long time in the making. We're trying to establish a precedent in that exception not only to allow IT, but to make it one of the cleanest and most easily accessible — yet not abusable — exceptions we've ever produced.
And two, providers and payers have got to think about how to support regional or other initiatives that allow them to level the playing field to make sure everyone can come along and get these technologies, particularly payers who get a lot of the economic benefit for getting HIT put in place.
As for interoperability, the first thing they have to do is make sure they buy based on certified EHRs. We have the ambulatory certification out, but within a year, we'll have the in-patient (version). By buying against certification, they're sending a huge message to the market that they're really serious about interoperability.
Second, we want them to support their regional projects. These are really pushing toward putting basic infrastructure in place and, more importantly, the governance. That's a key thing they have to do.
And finally, they need to be developing a business plan for what they're going to do as these standards come out of HITSP. I'm sure that the products the provider has will not always be in compliance with those standards, and we don't want them to wait years and languish until everyone comes into compliance — yet we're not going to mandate. I'm hopeful that they'll take a look at how they're going to develop a fast track to get these standards into their products — by requiring their vendors to modify them or putting into their contract that the vendor will stay current with HITSP standards whenever possible or other things so they can really be leaders in interoperability.
We're trying to establish a precedent in that exception not only to allow IT, but to make it one of the cleanest and most easily accessible — yet not abusable — exceptions we've ever produced.
