HIStalk Interviews Andy Aroditis, CEO, NextGate

Andy Aroditis is president and CEO of NextGate Solutions of Pasadena, CA.

Give me some brief background about yourself and about the company.

I started in healthcare about 20 years ago. I worked for a large institution out here on the West Coast called UniHealth. I started off as a programmer and then I became a programming manager. I worked for a company that had an integration engine. I stayed there for quite a few years. That’s when I had my first exposure to EMPIs and patient registries.

The company that I worked for was STC, Software Technologies Corporation. Then we changed our name to SeeBeyond. We got acquired by Sun Microsystems and that’s when I left.

I set up NextGate with two other partners about seven years ago. The first couple of years, we focused on doing integration and doing upgrades of EMPIs. We stayed within the same space, because that’s our comfort zone and that’s where we stayed.

Gradually as things became available to us, either through open source or through creating our own intellectual property, we set up as a product company. We set up NextGate, which is a parody if you know the names — the engine that we put out quite a few years ago under STC used to be called DataGate and then it became eGate, so we thought it would be funny if we called ourselves NextGate.

Those early integration engine companies got acquired multiple times by large and impressive organizations. What do you think those big organizations saw in those technologies that made them want to be become part of it?

To a certain respect, they bought the customer base. The company that we worked for before, SeeBeyond, had a very large customer base. According to our ex-CEO, we had about 70% of the market. Maybe we had 60% of the market. So we had a lot of the customer base and therefore it made it easier for them to get in there.

If I can just go off on a tangent just for a couple of seconds, it also made it easier for us working for that company to generate new products. That’s how we generated the first EMPI back in the early ‘90s. We went back into our own customer base, and our own customer base guided us through the maze. That’s what makes the product successful, I suspect.

Who are your main competitors?

Obviously the main competitor is Initiate, which got acquired by IBM, which makes it even bigger for us.

When you look at what’s changed since those early days of the ‘90s when everybody was working on these different ways of integrating systems, what are some of the newer challenges and what are some of the solutions for patient identification?

If you remember in the early days, doing integration — and that’s where we spent most of our lives, doing integration –we were lucky to find systems that actually pushed out HL7 messages. The ones that didn’t didn’t really concern themselves too much with patient identification. When I was first asked to set up an EMPI or a master patient index outside the realm of the existing systems, it was unique in a sense because it hadn’t been done before, but looking at it from the integration perspective, it was really necessary.

A lot of the systems pushing out these transactions, HL7 or not, were not exactly accurate enough. They needed some kind of accuracy, because if you remember back in the early days, we all preached the same thing — buy best-of-breed, best-of-breed, best-of-breed and we will bring in an integration engine and integrate this.

But the integration engine wasn’t sufficient, because now you had Andy Aroditis and you had Andrew Aroditis. Trying to figure out how to match those two people wasn’t that easy, meaning matching the order going out from maybe an HIS system to receiving the results back. That’s how we first came up with the first EMPI system, in order to do that, believe it or not.

That’s really almost a simple problem comparatively because people were using the engine just for their own patients. They had multiple systems, but a fixed body of patients. Now with all the emphasis on population health, anybody could be your patient.

Absolutely, and try to deal with patient discovery now over multiple institutions. They used to compete in the past, and now they’re asked to play nicely with each other. 

The biggest thing that we rely upon as an EMPI service is how well the data is captured. A lot of the inaccuracies that you see in terms of the patients and actually maybe even introducing them to or exposing them to treatments that they don’t need is because each system has its own unique way of capturing the data if you can’t figure out how to merge all that and get to the accuracy that you’re looking for. I think that’s the biggest problem that we had in the old days. Imagine now that you didn’t wait 10 or 15 or 20 systems. Imagine how much worse it is today.

I would think it’s also a challenge because at least when it was just a hospital keeping their own records, they could make rules to say, “Here’s when we use a middle initial” or “Here’s how we spell things out instead of abbreviating.” But now that they’re being asked to share data with physician practices that may have a completely different set of data validation rules on the front end, it’s going to be tougher to say, “I’ve got 20 medical practices out there and I need to match those up with my inpatient records.”

You’re absolutely correct. The biggest issue now is if you go to a physician office, depending on how big the physician office is, it’s highly like that they would know you personally. They might have a little bit more accurate data or they have your home phone number because they’ve known you in the neighborhood.

Whereas now if you walk into a hospital, there are two huge scenarios. If you present yourself and you’re on a gurney unconscious and they’re trying to figure out who you are, the way they register you within a system varies from institution to institution. For example, you can go in as John Doe or **Unknown, and then at some point in time when they’ve gone through your pockets and discovered who you are, they will attach a name to you. By then it might be too late because they’ve already done six or seven tests, or they need to do six or seven tests. Imagine if you do that 10 times because now there’s 10 institutions that are trying to participate within the same HIE. Imagine how much worse it is.

Patients can never figure out why it’s so hard when they say, “I gave you my new address, why don’t you have it?” But if you’ve got different points of presence all using different systems, how do you figure out who’s got the most current copy of the address or the phone number?

That’s usually one of the biggest challenges that we have when we implement an EMPI. There’s a couple of phrases that we coined way, way back at the beginning where you installed an EMPI or a registry of some sort — passive mode or active mode.

If you install it in a passive mode, you do the clearing as an afterthought. That’s when you get yourself into a whole lot of trouble. Think of what is happening with NHIN Connect and the engines that they’re coming up with. They’re trying to do the patient discovery up front, and that’s what the active integration is all about. 

For example, if you are within Siemens and you’re looking for a patient, instead of just looking at that, you’re actually looking at an EMPI which is an external to your system. You have better accuracy, because obviously the matching algorithms are more sophisticated in the software that we have. We also introduce fuzzy logic to play into it. When we present a set of patients or a set of names back to you, we can actually rank them and even color them or do something that will attract you and get your attention so you can pick the right person.

Obviously you can never let people click and say, “I’m going to register a new patient” because they can create havoc. But at the same time, if you make it so easy for them not to generate a new patient, they won’t, and they will pick one from the list that you present to them. That makes it easier and more difficult at the same time, depending on how many patients you have to deal with.

I would think the cleansing after the fact is unacceptable now, where you’re trying to take on financial risk and you need to know what tests and treatments have already been done. Or whether this a readmission, where the patient is being seen by multiple facilities. Is that something that can even be tolerated by practices or hospitals going forward?

It’s still tolerated because that’s the foundation of everything, whether you do it as an afterthought or you do it as the point of entry within the healthcare organization. 

Think of it like plumbing. In all cases, you have to have it in place, even though you’re only doing it as an afterthought. Because remember, even if you’re doing an active integration where I hand over the patient’s demographics to the registration system, they still have the luxury of actually messing it up. What I mean by that is they can turn around and say, “Hey, even though your name is Andy Aroditis, now I decided that I’m going to change your address, I’m going to change your phone number, I want to change your cell phone number.”

When it arrives back at the EMPI, because all these records have to be looked at through the passive integration and the plumbing, we can still go through the same identification and say hey, we have certain overlays. For example, I handed you over Andy Aroditis and now you’ve changed everything including the gender and you’re sending that record back to me. You’re creating a situation where you’re putting the patient’s health at risk because now you’ve changed them totally. Or, you’re using the same medical record number, which is totally inaccurate and you shouldn’t be. Which again it puts the patient’s health at risk.

How does the whole idea of patient identification fit into the Nationwide Health Information Network?

The way that it works, at least from my vantage point, is that the moment that you walk in, they can issue what they call a patient discovery, and they can actually broadcast that. There’s been a couple of schools of thought as to how they do that and how they improve the accuracy. Because as you can imagine, if they broadcast it to maybe 50 or 60 different institutions at the same time, imagine all that traffic getting onto whatever network, trying to get all those responses back. There are different ways to do this. 

For example, if I show up in an institution on the East Coast, it’s highly likely that I’m an East Coaster. Obviously there’s people that do travel from the West Coast to the East Coast, so therefore they would search maybe the local one, so they do a patient discovery to the local participants before they begin to launch those patient discovery queries across the states, going from East Coast to West Coast. There’s some logic that goes into this before you can actually do it in a nice way, or do it in a way that it would serve your purposes.

Do you think that there’s enough sophistication within that process that it will be reliable? That if one facility updates a patient’s allergies, let’s say, that everybody else will accept and use that information?

There is, but also the warning is, what if I capture the data somewhat differently? Penicillin allergy to me means ABC whereas to you it means FEG. The data capturing and how you apply those quotes to specific cases even though we do have the ICD-9 and the ICD-10 to make life easier. I’m not quite sure if you can get down to that level in order to improve the accuracy, with people capturing it the same way.

You work with provider registries. Describe what those are used for.

The question that we were asked over and over again with a lot of these HIEs is that the we want to deliver results to a specific provider on a specific day or even on a specific time of that day. In order to discover where the provider provides — no pun intended — the service for that specific day, we need to have some central location to do that. In order for us to know which provider to deliver the results, we need to have the relationship between the patient and the actual provider or the PCP or the person that will receive it, because obviously we can’t just broadcast it to every single provider that is out there.

That was the premise of, how do we identify people, and at the same time, how do I identify the caregivers to those people? We set up the provider registry. The provider registry has the same kind of confusion that a patient registry would have where people are described differently, but it’s more of a deterministic nature. The reason for a provider registry is in order for us to provide a reasonable answer in terms of somebody asking us where do we deliver the results for Dr. Andy, where would he be on Wednesday between 9:00 and 11:00, and what is his fax number? 

That’s the reason why we created a provider registry. In addition to that we also have the relationship that says that, “PCP Dr. Tim is Andy’s PCP and I can deliver results because some other external system tells me that I can and I know where to find Dr. Tim.”

You mentioned that Initiate is a significant competitor. What capabilities differentiate your product from theirs or others?

In terms of functionality — if I can be modest enough, I’m also biased — we have every piece of functionality that they have and then some. The reason that I’m saying that, though, is because a lot of the NextGate employees that are currently working on the product and the delivery of it have been in the EMPI space well before even NextGate came on the scene, meaning we started our work for the company in—and I don’t know how long you’ve been in healthcare – but we used to use an algorithm by a company called Alta, which was up in Northern California. People would deliver tapes, and then the company would deliver reports in terms of the potential duplicates.

It was two guys who wrote a bunch of Pascal routines that would go through tapes and would identify the potential duplicates in those tapes. They would return paper reports back to the medical records department so the medical records department could merge the charts. I happened to discover them quite a long time ago because of my work that I did for UniHealth back in my early days — we used them at the hospital. We managed to get that algorithm and get it embedded within the first EMPI that we developed. All that processing that used to happen in batch, we could actually do it in real time. That’s how our system stood up. We do all the processing in real time and we deliver the accuracy in real time.

Any concluding thoughts?

We started with the EMPI, and we started with the provider registry and the provider directory. All these components and all these registries and the way that they play with each other — we see that as the healthcare data integration platform where you can integrate a lot of disparate systems as the engines used to do in the past, but now we can actually integrate your data from the outside looking in, as opposed to from the inside looking out.

What I mean by that is the whole design and the whole structure of our EMPI is designed to stand alone and be a feeder system from all the HIS systems that are out there, whether it’s a MedSeries4 or an Epic or a Cerner or what have you. Whereas a lot of the Epics and the Cerners and the Siemens, their EMPI is just central to their own operations, and therefore it’s really difficult for them to have that exposed to the outside world. 

That’s the space that we’re in. We think that with the HIS industry growing, we will grow with them.