Home » Interviews » Currently Reading:

HIStalk Interviews Tim Burdick, MD, CMIO, OCHIN

October 13, 2014 Interviews 7 Comments

Tim Burdick, MD, MS is CMIO of OCHIN of Portland, OR.

image

Tell me about yourself and OCHIN.

I’m a family physician, increasing the amount of my time over the past eight years in healthcare informatics. Currently I’m one day a week in clinic at a rural health clinic as a family physician and four days a week as chief medical informatics officer at OCHIN. OCHIN runs a hosted Epic EHR for 350 clinics. Eighty-four healthcare organizations contract to use our EHR.

 

Epic gets criticism that its product is a walled garden and it’s not interoperable. What’s your opinion?

I think the interoperability frustrations cross all EHR vendors at this time. I don’t see that Epic is any better or any worse than others.

We’ve had good luck building interfaces and interoperability with other systems, with regional HIEs in and out. We have projects going with the VA, with Social Security Administration, and several HIEs. We do a million CCDA transactions with other Epic shops around the country.

Epic’s increasingly been good about opening their APIs. I’m not sure it’s fair to single out Epic. Certainly with the lack of any kind of national standard on interoperability, there hasn’t been a big push to make it happen.

 

Will the government every lay down a standard that everybody has to follow?

I think it is changing. Clearly Karen DeSalvo has over and over again said that she’s going to push the interoperability issue, so I see that coming. I think there have been other pressing issues for the HIT community that we needed to address before we could tackle interoperability.

The time has come for us to do it. It just hasn’t happened yet because we just weren’t there yet.

 

You’ve mentioned the challenge of state-specific interoperability requirements, such as California’s mental health reporting and its requirement that providers review lab results before putting them on the patient portal. Will the states standardize?

I’m not sure I see the states working together to do that. What’s happening, for example, in the case of the California legislation preventing organizations from releasing lab results to patients, as of October 1, federal law allows the laboratory companies to release results directly to patients. As a result of the federal law, state laws like the one in California are now superseded, so that’s no longer an issue for us in California.

It’s going to have to be strong federal lead on this that pulls the states into a common compliance rather than states coming together on things.

 

Do you have a solution to address the difficulty of connecting to state registries such as those for immunizations?

Again, it’s going to come down to standards. If we have a standard that says, these are the core data elements for an immunization registry. These are the requirements that you need to be able to do to pass that information from the EHR to the registry, from the registry back into an EHR, or from the registry to a patient portal. That will bring everybody along so that we’re not having to individually create 22 different interfaces and standards.

 

You operate in 22 states, but it could be a 50-state problem.

We could potentially have that problem. OCHIN is expanding. Certainly there are plenty of other large healthcare organizations that are in multiple states and having to deal with this issue as well.

If you look at Meaningful Use requirements around interoperability, if for Meaningful Use Stage 2 and Stage 3, we have to have every single eligible provider using some sort of registry list, immunization registry, or special disease registry, and we have to do one-offs in every single state, that’s not scalable, as I said in the testimony.

If we can build one interface, either to a federal registry or at least build it at the state level or the regional level or the county level, but know that those interfaces are all going to look the same and have a same standard set of data elements and same transactional messaging processes, then we can scale it up as a healthcare system.

 

You’ve said that some of those registries are run by drug or medical equipment vendors and charge fees as a for-profit company would. Can you tell me more about what you’ve seen?

ONC keeps a list of all the different registries — who runs the registry, what the quality registry is, whether it’s a diabetes registry or heart failure registry, and the costs associated with sending the data to those registries.

There is not good transparency around how the data are going to be used. If you’re sharing the data with that registry, can the owners of that registry then use that information? Some of it Is PHI. Can they use it for their own research purposes, their own marketing purposes, are they associated with a pharmaceutical or device company?

Some of those are fairly expensive. If you’re a larger organization, it’s going to cost you a huge amount of money to connect to one of those registries, and yet at the same time, there’s a federal mandate that we do connect to registries like those. Though we get some money back in Meaningful Use dollars, the cost of connecting to those registries on a monthly subscription basis is enormous, and frankly prohibitive.

The third piece is that healthcare organizations are hooking up to those registries and sending data just as a check box so that organizations can say, we’re sending data to a registry so we can collect our MU dollars. But the value that those registries provide back to the eligible providers is questionable.

As with most of the Meaningful Use stuff, I believe firmly that the intentions for Meaningful Use are good and that it’s pushed the healthcare industry along in the right direction, but we need to get away from doing it for check boxes to doing it to drive clinical improvement.

That means that we need to value back from those registries to the providers. It needs to be integrated back into the EHR rather than just saying here’s a website where you can go log on to a third-party app where there’s registry data about your patient population that are no way tied back to clinical care in a clinical operations.

 

I got two types of reader comments when I mentioned that some of the public HIEs are charging full participation prices to providers who just need to submit to public health registries. Some said they need a viable business model and a provider is either in all the way or out, while others said public health requirements shouldn’t force an organization to join as a full participant for that reason alone. What do you think?

I see both sides of that. Clearly if you’re a business and you’re going to stand up some sort of data warehouse and provide some quality metric reporting around that, that’s a difficult technology. OCHIN’s been working on it for several years. It comes at a very real cost to employ the developers and to do that work. I’m fine with organizations charging for that.

The difficulty comes when there’s a federal mandate to do this. As I said earlier, the financial incentives to do it don’t cover the cost of subscribing for these services. The transparency is that if I’m going to be paying hundreds of thousands of dollars to hook my Eligible Providers up to some registry, I need to know very, very clearly who’s collecting that money, what the money’s going to, and what kind of data use is going to happen with that information. I don’t think we have that level of transparency.

I’m not opposed to organizations collecting fees to cover their costs and even making a profit off of that. But we need to know who they are, what they’re doing with the data, and what their intentions are.

In addition, I think it would be great if the CDC, NIH, Institutes of Medicine, some of the other federal organizations could host some federal registries rather than doing it at the state level. Again, coming back to this idea of Eligible Providers in 22-plus states for OCHIN, if I can’t find a federal registry, then I’ve got to start reaching out to state registries.

The other example here would communicable disease surveillance, infectious disease surveillance registries. Those are largely at the state level. It’s just not practical for me to reach out with interfaces to 22 states. But if I can submit diabetes information, heart failure data, infectious disease surveillance data to a federal agency on a federal program at a cost that is subsidized by the federal organizations – ONC, CDC, etc. – then I can scale it up and there is less of an issue of questions about potential profiteering and lack of transparency.

It’s in the interest of organizations like CDC to start developing those federal registries and being able to collect the data and use those for national healthcare initiatives. I see it as a win-win.

 

Is Meaningful Use Stage 2 causing other unintended consequences that aren’t in a patient’s best interest?

That’s difficult. Yes, there are definitely unintended consequences and negative impacts. I’m firmly committed to the long-term benefits of Meaningful Use. With the significant earthquake changes that things like Meaningful Use bring along, there’s going to be the unintended consequences that we need to work through. But I don’t think that in any way negates the vision of Meaningful Use and HIT improvement processes.

 

Is it a short-term problem that patients are confused by having to log in to several patient portals, one for each provider, to look at their own data?

I think it’s a medium-term issue. There is a growing market for vendor-agnostic PHRs. HealthVault, Apple getting back into it, Google getting back into it. There are other third-party companies getting into this. Some of those were represented at the ONC patient engagement meetings a couple weeks ago.

I think there’s going to be a competitive market for that type of work. That’s going to drive it pretty quickly. Karen DeSalvo has mentioned at several meetings that I’ve attended that ONC is interested in supporting that process in some fashion or another. I see this issue being a two- to four-year growing pain problem that will have some solutions in the foreseeable future.

 

What do you think the business model or overall goal should be for public HIEs, or what we would have called a RHIOs in the old days, beyond just letting providers look at information on the screen?

The idea of having either a pass-through model or a data repository where the data are going to be held for a period of time while keeping the data in some sort of separate system … I think that model has not proven value and doesn’t have any long-term financial viability to it, as witnessed by innumerable failures of RHIOs in the past.

From a Triple Aim perspective, what we really need is for the data about a patient to get pushed through to a provider at the point of care within their EHR — whether it’s in an office visit or a care coordinator working on patient population issues — so that if that patient has had a hemoglobin A1C done by an endocrinologist a week ago at a different healthcare facility, the data are actionable in real time within the EHR.
The patient’s data need to move seamlessly across platforms. Care Everywhere works well and there are other things like that, but it still requires me to go out and look for that information and it still doesn’t move easily back and forth, even between EHR systems that are using the same vendor.

We need to get away from that model that a patient’s data exists in different instances separately and move to a place where the patient’s data coexists simultaneously and in real time in any instance of their care. That’s going to allow us to make it actionable to drive clinical decision support, panel management, and population health. That’s going to get us to Triple Aim.

The other thing it allows is on the patient-facing side of things for the patient to be able to see their information in a collated fashion and not in a siloed fashion so that they understand their healthcare picture not from the perspective of, “This is my cardiologist’s view of me. This is my pulmonologist’s view of me. This is my PCP’s view of me,” but, “This is the healthcare system’s view of me as an individual patient.”

 

Will the CommonWell initiative will make an appreciable difference in interoperability?

I think that’s to be determined.

 

Do you think Direct messaging will have a significant role or has it missed its opportunity?

Certainly some folks would say that it missed its opportunity, that the concept is so fundamentally flawed that it can never be executed on a large scale.

I don’t think anybody has shown that Direct is not viable, but I don’t think anybody has shown that Direct will work at a large scale, either. The issue of sharing directories and trust bundles across organizations that don’t have close working relationships with each other is unproven at this point.

At OCHIN, we are building out our Direct address directories. We are starting to share those with outside organizations. The uptake is slow on it. Just the mechanics of how to move the data back and forth, integrating that into clinic workflows on the clinic side, as well as how to set up those address within the EHR.

It’s still an early process technically. We’re facing things like that some organizations that we work with want every provider to have their own Direct address. If they set it up that way, then does an inbound message come through directly to that provider’s in-basket? If so, does the provider know what to do with that information and does that information get processed the right way in clinic?

Some organizations want to take the approach where the organization’s going to get a Direct address and the individual providers won’t. Then it will come in and some staff person will process those messages and move them around.

Even just simple questions like which process are we going to through with that organization address or an individual Eligible Provider address. We don’t even know how we’re going to handle that. Until we try those different things for a month or a year, I don’t think we’re going to know for sure what’s going to work in clinics.

 

If you were king of interoperability for a day, what would you do?

What I would really like to see right away is for the healthcare industry — healthcare providers, payers, federal government — get together a summit of thought leaders and define 30 clinical data elements that are needed to improve Triple Aim, things like hemoglobin A1C levels and left ventricular ejection fraction. Agree that these are just the basic elements that we need to start with in order to improve our Triple Aim outcomes.

Define those at a national level and figure out for those finite number of elements, how is every single EHR vendor going to really easily make that data flow out? How are we going to really easily make that data move in? What role does the federal government have in helping consolidate a national pass-through model that will at least make those common data elements available seamlessly across organizations.

 

Do you have any final thoughts?

The big issue here is patient matching. It really is going to come down to our ability to match our patients. Until we tackle a patient matching issue, we can come up with standards all day, but if the patient match rate is 20, 30, 40 percent, then we’re not going to get there.

I doubt there’s a political willpower to bring back to the table a conversation about a national healthcare ID. If we’re not going to do that at a federal level, then healthcare organizations and patient advocacy groups need to tackle this issue on a non-legislated fashion.

One of the things that I mentioned in my testimony would be developing a grassroots organization that allows patients to have an interoperability member card. It’s going to have on there the patient’s name the way they want it spelled consistently, down to capitalization and hyphenation. It’s going to have a date of birth, and in the case of patients who were born outside of the United States, we can’t continue to just randomly assign January 1 to tens of thousands of patients whose birthday isn’t documented.

If we use a phone number for patient matching, even if the patient’s no longer using that phone number for communicating with the clinic, we can at least continue to have them use that same phone number for patient matching.

It becomes a proxy for a standard ID, but that patient’s going to carry that card with them year after year. Those elements aren’t going to change. They can voluntarily take that card to registration at a hospital, lab, radiology facility, outpatient clinic, or the ER. The data for that patient are going to get populated in registry systems at every healthcare organization that that patient touches. That’s going to allow us to do patient matching at a much, much higher percentage.



HIStalk Featured Sponsors

     

Currently there are "7 comments" on this Article:

  1. Good piece…
    “The big issue here is patient matching”
    Amen, Amen, Amen! After some forty years in health care I could not agree more. Everything else is incidental. Struggled with this problem some 30 years ago, still the same problem.

    If DeSalvo and the feds really wanted to solve the interop problem the first thing they need to do is come up with a mechanism for a unique patient identifier. But we all know that will never happen in this ‘privacy’ environment. So since the feds will not (cannot) deal with it they beat up on the providers/insurers telling them solve the problem or we will legislate!

    Well…maybe we should all sit back do nothing and let them legislate a unique identifier. Dare them to do it. Think they can accomplish that??
    Could cost them re-election, so not in my grand children’s lifetime! And around and around we go again…

  2. Great article. I’ve always loved the idea of an interoperability member card. In a perfect world this would be the drivers license/ID card, it already has most of that important PHI and with new chip technology it would be extremely easy to tie in the rest. But I could never see this being mandated, something about government control or privacy protection.

  3. We completely agree that solving the current patient matching problem is critical if we are to succeed with healthcare interoperability. In response to the federal paralysis on this issue we have created a private industry solution that includes a unique healthcare identifier that conforms to an ASTM standard (E1714). It has many desirable properties – available to all, inexpensive to deploy, scalable, strong return on investment, HIPAA compliant, compatible with and works very closely with existing EMPI systems, and available today.

    We believe that any approach that addresses the patient matching problem but ignores patient privacy issues will fail. Our approach empowers patients to simply and proactively manage the privacy of their clinical information using the same mechanisms that ensure that they are accurately identified. I hope that your discussion helps convince healthcare organizations to get serious about solving the patient matching and allied patient privacy issues in the very near future.

    Barry Hieb, M.D.
    Chief Scientist, Global Patient Identifiers, Inc.







Text Ads


RECENT COMMENTS

  1. I think Disingenuous is confused (or simply not aware of how it has been architected). How control of Epic is…

  2. It seems that every innovation in the past 50 years has claimed that it would save money and lives. There…

  3. Well, this is predicting the future, and my crystal ball is cloudy and cracked. But my basic thesis about Meditech?…

  4. RE Judy Faulkner's foundation wishes: Different area, but read up on the Barnes Foundation to see how things work out…

  5. Meditech certainly benefited from Cerner and Allscripts stumbles and before that the failures of ECW and Athena’s inpatient expansions. I…

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

 

 

RSS Webinars

  • An error has occurred, which probably means the feed is down. Try again later.