HIStalk Interviews Charlie Harp

Charlie Harp is CEO of Clinical Architecture.

Tell me about the company.

I started Clinical Architecture about two and a half years ago, with our focus being primarily — I always use the term “plumbers” of healthcare information. What I mean by that is having worked in the industry, both from an end user perspective when I did clinical trials and hospital labs, to when I spent time at Hearst Business Media at First DataBank and Zynx on the content side. I’d worked with a lot of vendors that worked with a lot of organizations and I really thought that by creating a company like Clinical Architecture, we could help be a catalyst to improve the effectiveness of the implementation of content in the healthcare environment.

With Clinical Architecture, we started out doing mostly consulting, where we would work with content vendors and system vendors and end users to really focus on the problems they were having either with content design, integrating of clinical content or terminologies into their environments, or helping to manage some of the unexpected aspects of working with clinical content in a live environment. As we went through that process, we started seeing the same patterns over and over again. What we do as a solution provider is we try to provide what I call “plumbing solutions” to help with those common patterns of disconnection or dysfunction.

Most doctors do not find clinical warnings useful, even overriding most of the allergy warnings. How can that content be better used?

From my perspective — and I’m a simple country programmer, I’m not a clinical person — I’ve just been in this field for a while and I’ve seen a lot of dissatisfaction. I think a lot of it revolves around the fact that when you look at the content we have today and you look at the way that these healthcare systems have evolved, the content, when it was built and the structures that are still in use today, were built for a different audience. A lot of the clinical content that exists today, and a lot of the terminology, started out to support retail pharmacy, at least in the United States.

What happened is those content modules migrated their way into the inpatient and the practicing setting. It was put in front of physicians how a pharmacist, especially a pharmacist in a retail setting, deals with interruptions and deals with alerts. It is extremely different from how a physician does, or a nurse does, because their time constraints are very different. A physician is right there at the point of care trying to make decisions, and so if something isn’t really relevant, it’s not going to be perceived as useful.

I think that is where we are today. There’s another aspect there, too. Just to clarify, I think part of it was the electronic medical record was really not something that people felt was comprehensive. In fact, I remember speaking to a physician once who said that, “You know, Charlie, 40-60% of what I know about the patient is not in the computer — it’s in my head.” I think that’s been true for a long time.

I think that we’re at a point now where these electronic medical record systems are evolving. Whether they’re being driven by some of these incentives coming out of the Administration, or whether they’re being driven by just the need to resolve a lot of these medication problems or medication errors we’re having in healthcare — I don’t know, but I think the industry’s evolving. EMRs are evolving, and so that creates an opportunity for the clinical decision support content to evolve to be much more relevant. I think we’re just at the beginning of that era.

Do you think software vendors were too complacent in just letting the content providers tell them what they had and then just throwing it on the screen and calling it clinical decision support?

I don’t know that I would use the word complacent, but I think you’re right in that the content providers maybe didn’t have the content that the system vendors needed. The system vendor is in a Catch-22 because they develop this next-generation, cutting-edge system that requires a certain complexity and content to drive it and there’s nobody providing that kind of content. They’re on the hook to do it.

I’ve worked for content companies for a long time and it’s a lot of work. Building content and managing terminologies is definitely non-trivial. Clients might not like your content, so they might want to have the option to switch. You’re almost forced into a least common denominator position where you have to accommodate what’s available.

I’ve worked with a lot of content provider folks over the years. They’re all very noble and they’re trying to do the right thing and they work real hard, but when you try to introduce some new content, if there’s no place for it to go because no system is advanced enough to utilize it, that’s a Catch-22 as well. Developing new content is a non-trivial investment, and developing systems that are being driven on new content that doesn’t exist is a non-trivial proposition.

I think between the two, that’s where we’ve been stuck for a little while. I’m hopeful that a lot of the changes that are happening in healthcare today around improving the medical record will be the tipping point that we need to move forward.

I’ve always argued that there’s an attitude built into clinical decision support that says physicians can’t be trusted to determine what they need or find useful. What do you think would happen if individual doctors had the option to either detune the warnings for themselves personally, or to turn them off by saying, “I don’t want to see any more like this”?

I think that there’s nothing wrong with that. Once again, I’m not a clinical person, but I think that a lot of the clinical decision support is local. I think that the objective of a content provider is to provide a framework and a starter set and having the ability for the local population to tune certain things out. I mean, when you look at clinical alerts, there’s certain things that should never be done. Whether or not people should be allowed to turn that off and then woe be unto them if it results in something negative.

I guess that’s the option, but I think that the first thing we need to do in clinical decision support is make alerts that are much more contextually aware, because I think the physicians will be less likely to turn something off if every time they get an alert it was relevant to their patient and to what they’re doing. The other thing I think happens sometimes is you’ll have people that turn alerts off — so they give the physician the ability to just turn of a particular alert — because it’s not relevant to that patient, but it might be relevant to the next patient.

I think a lot of it has to do with our ability to apply alerts in a granular and effective way. If we can get better at that, then the physicians will be less likely to turn it off because every time it fires they say, “Wow, I’m glad I got that alert.” I don’t think that is the reaction you get today.

Do you think the content providers are concerned about their own legal liability, or some FDA interpretation that maybe they’re offering what sounds like a medical device? Do you think their incentive is to just alert for everything because not doing that could get them in more trouble?

I think that whenever you’re dealing in this space, there’s concern about liability. I think for some people, to err on the side of over-alerting in order to protect yourself. I don’t know that I would say that’s necessarily the case, but I think that part of the problem is when people create clinical content, they’re getting the content from somewhere.

For example, if I’m going to the package insert to drive all my clinical decision support, well, the package insert is really something that is designed around liability. So, one could argue that if something’s purely based on the package insert, it’s going to be alerting more often than not. I think the issue though, is I think it really has to do with what sources are available for information.

I remember once I was somewhere and somebody really wanted accurate pediatric dose checking and for neonates and for preemies. The problem, of course, is a lot of the data you get to drive clinical decision support comes from human trials and comes from case studies. Not all populations have case studies, and so sometimes it’s hard to come by really good information. So then you start leaning more on expert opinion, and sometimes people are concerned about how their advice is being carried forward into the point of care setting. But just in general, I don’t know that I would speak for how the content providers are positioning themselves in their content.

Given that whole emphasis on some grading of the studies and weighting of the evidence and the severity and all that, do you think there are opportunities for individual providers to create their own content based on local experience? In other words, I go to a doctor and say, “Here are some things we might do. Tell me what would be important to you in your practice.” Or is there any new use of content that isn’t the same old stuff? Is anybody doing anything creative with it?

I think what’s going to happen is … I mean, even when I was in my last job at First DataBank, we were seeing a lot of people who would use our content as a starting point, but they would also have you build and localize it. We actually built tools around localizing, and I think a lot of the system vendors and content vendors are moving to accommodate that.

I think it has to do with the fact that if you’re at a large teaching institution, you might have some additional rules in clinical decision support that you want to use to augment what’s coming from your vendor. You might also want to be able to turn off some of the things that are coming from your vendor because you just don’t agree with it. I think localization is something that’s going to start to happen.

But the other thing I think that’s going to start to happen is, as we improve the plumbing and we lower some of the barriers that the terminology creates, I think it creates an opportunity for other folks with new content to put that content out there; whether they’re a university or whether they’re a particular collaborative group. To put together content and make it available to people.

We’re not there, I don’t think, today. But I think that’s something that could happen in the future. I do believe that clinical decision support is local. In fact, when you look at the ARRA Meaningful Use, I like the introduction of the five rules because it almost says, “You really should be thinking about local and what kind of local things you need to look for.”

There was that point, maybe ten years ago, when Eclipsys bought the BICS rules from Brigham and Women’s. That never seemed to go anyplace and neither did the idea that there’s some open standard where individual providers can exchange Arden Syntax or whatever they’ve written their rules in. Is that ever going to catch on, that people will use rules that were created elsewhere? Or share rules via some sort of exchange process?

I’d like to see it happen, but I’m not sure it’s going to happen in the public domain. The only reason I say that is, building content … healthcare is constantly changing and building content is not easy. I really think the public sharing of information without some way to fund it and some dollars to help cover the costs of the content’s development, whereas I think it’s a great idea and I would like to see it happen, I just don’t know if it’s financially feasible. What happens is you create content and that content has a half-life and you need to be updating the content, and you need to maintain the content.

The other problem is if there’s some kind of sharing environment that’s driven by Sponsor A or Vendor A, Vendor B, if they’re a competitor, is not going to want to promote that and be compatible with that because it’s their competitors offering a standard. In fact, with Clinical Architecture, one of our goals was to be a neutral plumber to maybe help bring about a time when people can have general plumbing for sharing clinical decision support content without having to worry about their competitors and whether or not their competitor is behind it or not.

You mentioned the Meaningful Use proposed criteria. Do you think those proposed criteria and the reimbursement guidelines say enough about clinical decision support, and also the specific taxonomies and the architectures that they’re suggesting that is needed to go forward with it?

I think that they started us down a path where just saying that Meaningful Use means that the computer needs to do some of the heavy lifting, is really the way I read the direction of Meaningful Use. I think that there are things that computers and software are really good at when it comes to minutiae and tracking details and correlating data, as long as it has meaningful information with which to do it. I think that moving in that direction is good.

There are a lot of different definitions for what clinical decision support is. So I’ll be kind of narrow and say, “computerized rule checking around patient context to provide advice and alerts about something going on with a patient.” I think that there’s still a ways to go to evolve clinical decision support to be meaningful, because I think if we just perpetuate what we have today, you’ll still have people who get frustrated and turn it off.

I think when it comes to terminologies — I think that we’re a ways off from getting to the point where we don’t have multiple terminologies out there. Part of that is because of just the rate of change in healthcare is slow, and a lot of it has to do with the criticality of these systems. You can’t just unplug one and plug another one in, as I’m sure you well know. When you introduce something new, it takes time.

A lot of these third party terminologies are pretty ingrained; whether they’re a local terminology that someone builds, or whether they’re one they bought — they’re pretty ingrained. So, getting them out, if that ever happens, will take a while. The standard terminologies that are promoted in ARRA, whereas I think they’re a good start, need to evolve to really meet the demands of what we’re going to be asking them to do, as well.

Are we’re relying too much on content that was designed for billing, like ICD-9 and CPT codes, and trying to make it into something it never was intended to be?

Oh, I think so. I think that when you look at the general codes that are used most in healthcare today, the CPT, the ICD-9, and in the drug world, the NDC code — those were all really built around transactions and billing. But that’s kind of our roots. That’s where the US healthcare system came from is transactions and billing. What we’re trying to do is evolve into systems that are based upon a clinical framework.

If you look at other countries where they didn’t come from there, it’s very interesting to see how those systems have evolved because they look different than the systems we’re used to here in the states because they don’t have those aspects. Whenever you try to take data from the states and introduce it into those other countries they go, “Well, why does it look like this?” It’s because of where we came from.

I think that the danger is when we create new terminologies that are designed to be clinical terminologies, we need to evaluate the characteristics of those terminologies. I’ll give you an example, and I think I have a blog entry on this.

ICD-9 has a bunch of concatenated terms in it and they’re conditions or problems that are put together in a particular order because it facilitates billing activity. Well, when you look in SNOMED, we’ve started introducing those same types of concatenated terms. The problem is the concatenated term is very difficult to leverage when you’re doing clinical decision support because you’ve created a term with multiple meanings. Any time you have a term with multiple meanings; it results in things getting a little fuzzy.

It almost looks like, in some of these cases, the SNOMED CT codes — and I don’t know this for a fact — but it looks like they’ve shadowed ICD-9 to a certain degree. If SNOMED is going to be our clinical terminology, we shouldn’t be doing that. We should be saying, “Well, we want to treat this differently.” But it’s difficult because you can’t be precognitive and know everything that’s going to happen. There are a lot of unintended consequences when you create a terminology, but I do think that a lot of the problems we have stem from where we’ve come from with these terminologies.

You would think that the one giant test bed that’s out there that could maybe take a different direction would be the VA, since they don’t worry so much about billing and they’ve got clinical systems that are mature. Are they doing any work that would be innovative that might find its way into the average hospital?

They may be. I haven’t done a ton of work with the VA in these last couple of years, so I don’t know that I could give you a meaningful answer in that respect. If they’re not encumbered by some of the issues that a lot of these other systems are.

I actually think a place where things would be interesting is some of these newer systems, especially some of these Web-based systems that don’t come from a background of being charge capture systems. That’s one place to look. I think looking at the systems that are coming from other places, just to see what patterns they’re using to capture and deal with clinical information, I think, would be interesting.

Is metadata and semantic interoperability the next hurdle?

I’ve spent a lot of time in the last year working on interoperability, and I think that there’s a lot we can do with interoperability to get us to a next evolutionary step. I think, ultimately, if you have systems that are using whatever code they’re using locally and are loosely coupling to a standard for data exchange, interoperability becomes a lot easier.

For example, if I’m using content vendor code A or my own local codes, but in that dictionary in my system I also have the RXCUI. When I go to exchange data, if RXCUIs are comprehensive from RxNorm, then I can exchange data meaningfully. I think that between those points, in our utopian future and today, I think that there are some roles for metadata in understanding and correlating terms.

I think that the UMLS Metathesaurus and RxNorm are a good start, but a lot of people go to them thinking they’re the ultimate key to fixing the problem, but they’re really not, at least, not yet. It’s one of the reasons why we built our SYMEDICAL product. We were working with a bunch of clients and seeing the same pattern over and over again where they’re trying to exchange data.

There are really two problems today. One is to map from one terminology to another is an extremely manual and time consuming process. Because of that, the second problem occurs; which is if there’s something you don’t want to do because it’s long and painful, you put it off. So a lot of people will build a map and it’ll cover a certain percentage of the things they’re trying to exchange, and then two years later the map is severely out of date because code sets are constantly changing. Much more so than people think they do.

One of the reasons we built the product we built was to let the computer do some of the heavy lifting. It really leverages metadata and contextual parsing to do that, and it actually does a fairly good job. I think that when it comes to interoperability, having tools out there in the public domain like UMLS Metathesaurus and RxNorm help. Having tools that help domain experts at institutions, or vendors and facilitates the mapping process also helps. Then staying on top of it and not letting things go for a year before you get it updated again, especially now that we’re leveraging the electronic medical record and really pushing it more and more.

Who is your customer, and has their interest changed with the emphasis on clinical systems and Meaningful Use?

Our customer — like I said, we’re kind of a across the field. We work with content vendors, we work with system vendors, and we work with end users. But when it comes to the changes I’ve seen in the last year because of the HITECH initiative, I think that a lot of it has to do with it drives or prioritizes certain things to the top. There are a lot of things we should do as a healthcare industry. There are things that we should do, and then there are the things that someone’s willing to potentially pay us to do. What I think has happened is number one; raised more awareness, and it has given people an incentive to accelerate the process, which I think is good.

For example, we also help people implement content and get decision support up and running. In the last year, we’ve seen a lot of people who previously didn’t do decision support, didn’t have structured terminologies, are now really feeling the pressure to do so — which is good, because before everything was free text, and if people wanted to do checking, they really couldn’t, at least not in a computer-assisted way.

I also think when it comes to interoperability; there are people who probably don’t want to deal with interoperability. This forces the issue, which is also good. We’ve still got to sift through and decide about standards and formats and all those things, but putting the notion of interoperability forward is good because ultimately, for me, it drives Clinical Architecture. It’s one of our primary goals, which is about making healthcare more effective and improving patient safety. With interoperability the way it is today, there’s a lot of manual reentry, there’s a lot of free text information, there’s a lot of potential clerical error and human error.

Whereas, if you can increase the fidelity with which systems communicate with each other, and those codes are being exchanged more accurately, you increase the efficiency of the people that are actually trying to manage the movement of data. You increase the accuracy of the data that’s in the patient record. Therefore, when you do clinical decision support, or when you’re looking at things about the patient, you’re actually going to have a better picture of what’s going on. No clinical decision support will help you if you don’t have any coded data that can drive it.

Any final thoughts?

There’s a lot of people that build really good systems, and there’s a lot of people that build a lot of really great content. What I try to do with my contacts in the industry is to push them a little bit and say, “You know, I think we could do better.” I think there are things we can do, and it’s not easy.

Another quick sidebar is I think that one of the things that people aren’t really ready for, which I’m not sure they are, is if we ratchet up the electronic medical record, there’s a lot of housekeeping. In the past, and electronic medical record for a lot of systems, was probably an episodic transitional thing where the patient comes in, they leave, and you might pitch the electronic record until they come back the next time and they fill out the form again. But once you start persisting that and you’re relying on it over time, there’s a lot of housekeeping that goes along with that. There’s a lot of cleanup because the codes are always changing behind the scenes. Information’s always changing, rules are always changing.

I think the next big thing that’s going to happen to the industry is once they really start persisting and dealing with the reality of the medical record that’s coded and structured, they’re going to have to deal with “how do I make sure that it’s accurate as time goes by” I think that’s going to take a village. That’s where interoperability comes in, because ultimately, your electronic medical record is not just your doctor’s office, not just your pharmacy, not just the hospital. It’s the meaningful combination of all those things put together. It’ll be interesting.