John Maher: Hi. I'm John Maher. I'm here with Mike Lucey, president of Community Hospital Advisors. Mike is formerly of McKesson and was part of the team that reintroduced Paragon to the market in the early 2000s. Then he started Community Hospital Advisors, which is a consulting firm dedicated to helping hospitals effectively install Paragon. Today, we're talking about converting your hospital system to McKesson's Paragon product. Welcome, Mike.
Mike Lucey: Hi, John. Nice to see you.
John: Thanks. Mike, what is it that makes the conversion aspect of a McKesson Paragon Project such a big deal?
Mike: It is a big deal. It's kind of like building a new kitchen not having any food in it. You're going to build the whole kitchen, but you eventually have to bring in all the reason that it exists.
That's the data. It's near and dear to my heart. When I started CHA, I ended up adopting the conversion piece of this puzzle, and I don't know if that was a good idea. I thank God there's other guys that are in there doing it with me and for me now.
Conversion is the big daddy of going from, into. I'm going to go from this system over here, and in this system I have all the work that I have done over all these years. I have all the patients that I have worked with over all these years. I need all that, now, in my new system. That actually explains, by the way, the two big buckets.
There's two big buckets of data. There's what in the Paragon world is called common reference masters. Often in Meditech it's called dictionaries, but it's all the stuff that makes up the system part of your data. Things like my charge master, my item master, my caregivers. These are all the things that make up my system that now I'm going to work with to care for these patients.
The other big bucket of data is, then, the patients, often called the patient index, or your visit files, and those things. You look at those two big buckets of data, and actually you have, in many ways, you've just bookended your project. You can't build anything in Paragon until you have your common reference masters into the system.
The challenge, though, is that over those 12, 15 years, you have a relationship with that data. The data, itself, has been informed and created out of how you use it, and by the way, how you work over the years has been informed and shaped by that data.
What we have to do is break that relationship. We have to break the relationship with the past to say, "All right. Now I want to look at this data very objectively. What is it that, first, I absolutely need from my old system to make Paragon work?"
Then I go, "What do I want from my old system? What is good, good data that I want from my old system to make Paragon work?" In that, you're also recognizing that there's a lot of stuff in there that I don't need. There's a lot of stuff in there that I don't want.
Then the final question is, "Now that I've decided what I need and what I want, how do I actually want it to behave in Paragon?" I will take something like in the STAR world -- STAR is an older HIS system from McKesson, currently out there, currently working and functioning -- but a lot of folks in STAR are going to move into Paragon. They have a structure where, I look at a patient, and I see the patient type, and I see the patient service, and then I see the location.
That little dynamic of how I see that patient in Paragon is different. There's no such thing as location in the same form, and I have a new level called the patient category. OK. How do I take this data from over here and then shape it to work right over there? That has to happen at the beginning of the project.
Once you make those decisions, we end up employing a couple of devices that we've developed over the years, a software device and a big ole honking spreadsheet, that allows us to populate Paragon very directly, in a way that's going to work effectively in the future.
John: Right. You have these two big buckets of data, these reference masters and the patients' data. Why don't we take the first one? How do you get the reference masters data into Paragon?
Mike: The first step is getting it out. [laughs] To get it in, I have to get it out of the old system, and that take a few forms, and we work with your current vendor. Usually, if it's a McKesson-McKesson, like a STAR series to McKesson, we'll work with that group to get the data out in the form that you want it to...Well, you just get it out. Get it out so I can look at it.
We then put this moment in place, which is the review moment, where you bring in the right bodies -- the folks from patient finance and from clinical and from general ledger, and all them from HIM -- you get them in the room at the same time and say, "Let's look at these different chunks of data. How do we want to shape it in the future?"
One is pretty clear to understand is something like caregivers. These are all the physicians we work with for the last 20 years. A certain percentage of them don't work here anymore. A certain percent are dead.
Do I want to bring all those thousands of physicians that are no longer relevant into my new system? Your registration person would say, "Please don't." Because they know that they're going to have to choose from this drop down of all those physicians and sift through all those Smiths and Kims to find the right one to associate. If we only have the caregivers, we only have the physicians that are relevant that makes their new system work far more effectively. We'll do that everything.
Race codes have gone throughout in how many iterations over the last several years. I don't want the old race codes, I want the new race codes that CMS really wants me to have. We shape them, and then we have import file. CHA import files that we didn't create format, and that flows directly into paragon. Then we can check off that box and sign that form, and we're ready to start building.
John: What about patient data? Is that a similar thing, or is that very different?
Mike: It's a whole different world. What we employ and what we have created over the years is an iterative way of bringing in MPI. In other words, we're going to bring in the patient data. We're going to work in a very focused way leading up to the big moment of integrated test.
Kick back about three or four months before then, we're going to start working with these patient index files. We're talking about files that will be hundreds of thousands of patients. It's a millions and millions and millions of visits. They're just big, ugly, nasty files. They are filled with data that you...Go back to our first piece of the puzzle there. What do I need? What do I want? How do I want it to work?
I now have made adjustments to all my service code so that they work effectively in the future. I got to go back and cross walk all these visits to effectively view and effectively appear in my new system. All of that is possible. All of that is very doable, but it has to be done over a long period of time. It does require that people review it and focus on it. We're able to do two things very...There is two very important pieces to this.
I want it to work effectively, but I also am driving down risk for that big event at the end of the Go-Live event. I want to get all these work done ahead of time, so I have a big old clean set of files that I can import on that Go-Live Weekend. I'm not going to wait through the process of doing it all starting Friday night at 12:00. That's the iterative part of our process.
If we've done it very effectively, I think that when I first did the MPI, did that patient load in an iterative fashion, I actually got to sleep on Friday night. I got to go home. It's rare on Go-Live Weekend that you get a lot of sleep. It's like, "Holy mackerel, it's all done. I go back, I can take a nap. We come back in."
We're focused on then being in a position to turn the system on, do a soft Go-Live on the evening of Saturday instead of waiting to pull everything together at the last minute on Monday morning. All those are focused on driving down the risk of that big event.
John: What happens between that period where you're starting to pull that data over? Then before you do that, like as you said, the soft Go-Live is there. Do the people at the hospital have to input the data into the...Are they inputting it into the new system at that point, starting Friday night?
Mike: Sure. There are actually a variety of things going on. First, you reflect that. We've taken 95 percent, so there's 10 years of data. We will take nine years and nine months of data, and we will put them in these pristine files, and we will test them. We will error check them, and they actually will have been used at your integrated test. You will have seen these patients. You will have seen how these patients present.
We scramble certain things so that we can be protective of patient data, but it is the actual body of data that you're pulling from your old system. You never have to extract that data again.
On that go-live event, we're now working with just the three months, or even sometimes I've worked with just 30 days' of data, between our last iterative poll and what happens on Friday night. What we do is, our partners at McKesson will do the extract, create the files. We have some automated processes, some automated software that formats it, cleans it, and delivers it back to McKesson, the whole body of data, quite frankly.
We add it. We add that little chunk to the big chunk, send it back to McKesson. We know the big chunk is clean, but in order to get it into Paragon effectively, McKesson has to run a particular process, and it has to work with all the files as one unit to do it. It delivers all those files. We get our confirmation that they're clean. If there are errors, and there often are, we fix the errors.
We're running a process that takes now in the order of an hour to an hour and a half, that in the past would have taken several hours to accomplish. We're able to, like I said, drive down that risk issue.
Once we have the data in place, we do two concurrent events. Every hospital wants to look at their data. Every hospital wants to sit down, get ten people, and confirm with a spot eyeball check, "This is Mike Lucey in the old system. This is Mike Lucey in the new system. This is Tom Jones in the old system. This is Tom Jones in the new system." We do that about 100 to 200 patients, so that they have a visual confirmation that the system, the import, worked effectively.
At the same time, we have another device that will do it in an automated fashion. We will confirm on five fields that everything that was in the extract file now exists in the import file. We do a pull from Paragon, and we compare those two files one-to-one. Again, that's a place where CIOs very much like to take that report, put it off on the shelf, because it's their little life raft.
John: What is the ultimate goal in regard to converting to McKesson Paragon?
Mike: The ultimate goal is to go into that mid-process and say, "I'm looking at what our data was. I've decided how I want my system to work in the future, and I shape my data to work very effectively in that manner." Where we go into optimize systems that are struggling, it's often because they're struggling with data that isn't shaped to work right in their new system. That's our ultimate objective. Get your data to work toward your new objectives.
John: Mike Lucey, thanks very much for speaking with me today.
Mike: My pleasure.
John: For more information, you can visit the Community Hospital Advisors website at commhospital.com. That's C-O-M-M-hospital.com, or call 888-811-4687.