Katlyn Graham:  Hello. I'm Katlyn Graham, here with Andy Cole, the director of financial implementations at Community Hospital Advisors. Welcome, Andy.

Andy Cole:  Thank you. Glad to be here.

Katlyn:  Thanks for joining this podcast. This podcast is called "Stop the Press: Paragon Breaks Your Paper Habit." This is talking about when hospitals convert to Paragon. What is one of the hardest things people give up when they move to Paragon, Andy?

Andy:  I think what usually happens is...Paragon is a hospital information system that replaces, in many times, 20 to 30‑year‑old computer systems. Those systems relied on physical paper reports being printed daily, weekly, to certain folks and people working for those reports.

Paragon replaces all of that. They make those old paper reports obsolete by, actually, storing the data in the system and displaying the data real time to whoever needs it.

It's really one of the situations, where the users in the hospital that are using Paragon are so used to having stacks and stacks of reports. Once that goes away, it's almost like their security blanket goes away. They think they don't know how to do their job anymore because they don't have that old report.

Our job is to show them that, "You don't need that report anymore. Just because it's printing on your printer every day, it doesn't mean that you needed that report to do your job. The data's still there." This is the new way to do it and to show them it's not that scary.

Those old paper reports are usually the hardest thing for a lot of folks to give up, within a Paragon install.

Katlyn:  I would think so. That's a huge cultural change. As you've said earlier, breaking that paper habit with the reports, who especially usually has trouble with the report issue in hospitals?

Andy:  What I call report anxiety...The typical users, or the areas in the hospitals that have those troubles are physicians, nurses, and patient accounting directors and finance departments.

Those are your typical trouble spots. Oddly enough those are the departments that can make or break a Paragon implementation. It's really important to have a good offense with those folks early on in the install process. You've got to pay some special attention to those showing them that it's easy to run reports out of Paragon.

They are just as robust if not more then their older ports. There's usually not a good reason to print out that report. Once a report is printed, the data on that report is obsolete. That's how it was at the time of printing, not necessarily right now.

Getting on board early, having that reporting conversation upfront in the install is the key to keeping those trouble spots on board.

Katlyn:  I would think using it, the nurse is used to holding her clipboard or whatever and has to switch over. Doing it and losing the paper would help. What do you find is usually the turning point with report anxiety?

Andy:  To get over that anxiety, time and repetition is all you can do to get there. The earlier we get in front of those groups and show them where the reports are and once they start testing the system way before going live.

If they wait until after go live to look at reports it's way too late. That anxiety is not going to go away. It's probably going to get worse.

If they start testing, printing their reports or viewing those reports online, that will slowly go away. Slowly we see their evolvement from "You know what, why did I print that report from the old system?" or "You know, I don't need that report anymore."

That's the light bulb that goes off. If that can happen earlier on in the process with those trouble spots that'll spread throughout the hospital, and make everybody a lot happier. To make the go live a lot smoother and save those trees and save those printers from printing off totally unnecessary reports.

Katlyn:  Thank you so much for explaining that, Andy. It sounds like you're helping reduce report anxiety in hospitals all over.

Andy:  Great, thank you.

Katlyn Graham:  Hello. I'm Katlyn Graham, here with Mark Kandilakis, Technical Consultant for Community Hospital Advisors. Welcome, Mark.

Mark Kandilakis:  Hello!

Katlyn:  Hello. Thanks for joining us today for this podcast!

Mark:  You're welcome. It's good to be here.

Katlyn:  We're excited to tap your expertise on Paragon, the health information system. Today, we're discussing the benefits of a hospital choosing a Microsoft‑based health information system, such as Paragon.

Mark, you're very familiar with this. Could you explain for others, who might not be quite as familiar, what you mean by a Microsoft‑based system?

Mark:  Sure. Essentially, a health information system such as Paragon that uses a platform of Microsoft software such Microsoft SQL Server, or Microsoft Window Server.

Essentially, these are the underlying platforms or technologies that this particular HIS system is built on.

Katlyn:  Paragon?

Mark:  Correct.

Katlyn:  That makes it simple. What are some of the best reasons for a hospital to choose Paragon?

Mark:  Great question. I believe that one of the most important aspects is cost. A lot of hospitals already have an enterprise agreement with Microsoft.

They own the licensing for the database platform, SQL Server as well as Windows and whatnot. That takes a lot of the initial cost out of implementing an HIS system. Another benefit would be ease of views as far staging and configuring the hardware and software since a lot of these IT departments already have those systems in place. They already have expertise in dealing with them. That takes away a lot of the barrier as far as implementing and staging is concerned.

I think also supportability, going forward, you have skill sets in place in your IT department to actually come out and deal with troubleshooting and issues that may arise without having to involve the vendor. It also frees you from the handcuffs of the vendor. You're not exclusively tied to, in this case, for Paragon McKesson to assist with support. You can take a lot of that, own a soft at their plate, and you can support and troubleshoot on your own.

Katlyn:  Because it's a Microsoft‑based system?

Mark:  Correct, yeah. In regards to already having experts in your staff and the wealth of information that is currently on the Internet in different knowledge bases or whatnot.

Lastly, it allows for easier add‑ons or customizations to your HIS system, in this case, Paragon from third‑party vendors. They're able to more easily create or give you the ability to use third‑party tools or applications without, once again, having to involve the vendor.

Katlyn:  OK, it allows you to really specialize and individualize what you're doing. That's interesting how you say a lot of your in‑house IT people will have training and be familiar with this. That's interesting.

I've heard from some other people who say, it's a big culture change for doctors and nurses to take this on. But that's another side of it, the IT side, so that's good to hear from...now, once the hospital goes live with Paragon, what are some of the benefits after Paragon is live.

Mark:  I think I mentioned supportability and that is a very important one. Once again, you have the resources in‑house. There's familiarity already with the products, it's just a lot easier to maintain and support moving forward.

That takes a lot of the anxiety away from IT departments where they're not as dependent or reliant on the vendor. And also, recordability. Because it's built on a Microsoft sequel‑server, it's easy to use off‑the‑shelf recording tools to write your own customized reports. This is a great benefit to a lot of hospitals.

Katlyn:  OK, they can get their reports. And what was the other long‑term benefit that you just mentioned.

Mark:  Supportability.

Katlyn:  Supporting, OK. That all sounds great. Are there any negatives to a Microsoft‑based system?

Mark:  I think the biggest negative in my opinion would be stability.

By going to a Microsoft platform where you're now dependent on SQL Server or Windows, it opens the opportunity for there to be issues with those underlying platforms or systems that aren't specifically centered around the actual HIS application.

In that regard, I think that some of the proprietary systems, the closed systems, are a little bit more stable. But I think as time goes on that goes away. That would be in my opinion one of the negatives.

Katlyn:  As time goes on, the positives way outweigh the negatives, it sounds like.

Mark:  I agree.

Katlyn:  Thank you so much for explaining that, Mark.

Mark:  Oh, you're welcome.

Katlyn Graham:  Hello, I'm Katlyn Graham here with Andy Cole, the Director of Financial Implementations at Community Hospital Advisors. Welcome, Andy.

Andy Cole:  Thank you.

Katlyn:  Thanks for joining us, today.

Andy:  You're welcome.

Katlyn:  We're discussing, Paragon, your system that you bring to hospitals and with that you bring "A Brand New Culture."

That is the title of this podcast. We're going to be digging into the culture of Paragon. Andy, in your opinion, what is the largest challenge a hospital faces when they migrate to this new system? Actually, maybe we should start off just explaining what Paragon is for those, who may be unfamiliar. What is Paragon, Andy?

Andy:  Paragon is a complete financial and clinical information system that hospitals purchase and install.

These systems will usually take around 14 to 16 months to be installed. The project is that long and touches that many areas. It is a complete hospital information system.

Katlyn:  And there is a lot of information at a hospital. This process of implementing Paragon takes more than a year...

Andy:  That's right.

Katlyn:  ...to get everyone on board.

Andy:  To answer your question about what's the largest challenge during that year, in my opinion, it is the actual cultural shift that the employees who will end up using the system go through. There are so many new processes.

Folks are very scared when they see a new system coming in. They're afraid of losing their job. They're afraid of not knowing how to do something. They're unsure of how this is all going to play out. Guiding these employees who have those fears and getting them to realize it's not the end of the world, in my opinion, is the most challenging part of the project.

It's not how to get the system to work properly or to train them which button to click or which software to use. It's moving to that cultural shift.

Katlyn:  I see. And it is a huge cultural change. I would imagine, could you give an example of how a billing, or administration person in a hospital, how one workflow might change with this system?

Andy:  A good example is, charging, how a hospital charges for its services. A lot of times, hospitals have been putting off tough decisions for years.

They realize, "We're losing charges on this system. We're not capturing all the things that we incur during an MRI," for example. Implementing Paragon will actually bring all those departments together. The Radiology Department, and the Billing Department, and Administration, and Finance.

It brings them all together is a room and says, "OK, Let's figure out what our costs are. How can we bill for this appropriately? How are we going to get reimbursed for this appropriately, as well as deliver the care that we need to deliver?

Normally, those four departments that I mentioned have never seen each other before. They may have never spoken to each other before. Bringing in Paragon actually gets them in front of each other to define their workflow better, tie up any loose gaps, close the circles, and make sure their charges aren't flying out the door. It's the point where the software brings people together.

Katlyn:  I would think that more communication between Billing and the more clinical side could not only improve workflows, but also, patient care if everyone is on the same page and know what's going on. It is quite a process to undertake. You know how hospitals do this successfully.

Andy, what are the keys to a successful Paragon implementation?

Andy:  In my eyes, there's four definitive keys. I call them the four ships. Ownership, comradeship, partnership, and leadership.

Ownership meaning that the hospital will, in their minds, own the software. They have a say in how it's going to be rolled out. They have a say in how folks are going to use it, and how they are going to be trained on it.

It's different than some software they've used before where they just take what the vendor gives them and that's just life. Paragon is such that where it allows them to be involved in that design, that rollout, that workflow discussion. They need to get into that process early, and that's one of the things that we help them with.

Understanding, you can design this. You can be a huge part of it's success. Owning the software and realizing ownership is important. Comradeship. What I mean by this is bringing historically adversarial departments in the hospital together. Much like that Radiology and Billing example I gave earlier.

Typically, those departments butted heads a lot of times. They were unaware of what the other one did day‑to‑day. Designing Paragon, they have to come together, because each part of their system will affect the other. Another key is partnership. What I mean by this is the hospital, actually, becoming partner with Paragon. They need to not have a chip on their shoulder. If something doesn't work, not be mad with the vendor.

They need to realize that they can drive change within the vendor. Being an enemy with each other will not get you anywhere. They need to become partners. Lastly, leadership. Leadership at the hospital is huge. The executive team, the administration team. They need to be involved in the implementation.

They need to be part of the design meetings, part of the rah‑rah meetings to inject enthusiasm in the project. Without that, the end users who end up building it and using it just feel like it's something that was imposed upon them. If there's leadership presence, they don't feel that way.

Katlyn:  I like that concept of the four ships. Ownership, comradeship, partnership, and leadership. You're saying that a hospital needs to make sure they have all four ships there.

It doesn't work without them. I'm sure you've seen examples where not all four of these ships are there. After you go through this implementation, Andy, what does a hospital look like after they've successfully brought on Paragon?

Andy:  It usually takes a few months after the dust settles, after they go live.

A successfully implemented Paragon hospital will look totally different from the hospital before they installed Paragon. You'll have multidisciplinary meetings throughout the week, again, where clinical and financial teams will come together and review workflows.

There's just a breath of fresh air almost throughout the hospital where a lot of bad habits are broken. Silos between departments are broken down. Folks have this attitude of not accepting how things are. They'll say, "OK. I know this process is not optimal. What can we do to fix it?"

They've had this mind shift from, "Oh, this is how it works. This is just our lives now" to "All right, I don't like the way this works. Let's do something about it and fix it." It really changes their mindset and really changes their lives to give them that strength and to empower them to make the system their own.

Katlyn:  And to become more proactive about how the hospital operates.

Andy:  Exactly. And to know that they have a big hand in it. They know that what they do on a day‑to‑day basis can make or break the hospital. It's a good feeling for them once they get it and once the system is stable.

Katlyn:  I hope you go back and visit once they get to that point.

[laughter]

Katlyn:  You've helped their hand through the tough part. To see the result, that this has worked out for them.

Andy:  It does. It makes it all worthwhile.

Katlyn:  Definitely. Thank you so much for explaining all this, Andy.

Andy:  You're very welcome. Thank you.

John Maher:  Hi, I’m John Maher and I’m here today with Janice MacDonald, Vice President of Community Hospital Advisors which is a consulting firm dedicated to helping hospitals effectively install Paragon. Janice is a physical therapist by training and she became a community hospital chief information officer before coming to work for CHA. And today, we’re talking about effective use of McKesson Accelerated Services. Welcome, Janice.

What is McKesson Accelerated Services?

Janice MacDonald:  Hey John, how are you today?

John Maher: Good, thanks. So Janice, what is McKesson Accelerated Services?

Janice MacDonald:  Accelerated Services is staff augmentation to complete Paragon application build. There are other things that Accelerated Services can come in and provide additional staff for you but one of the key things in a paragon project is McKesson can offer to give you skilled people who can come in and help build the Paragon applications for you.

Benefits and Challenges of Accelerated Services

John Maher:  Okay. So what would make a hospital feel like they needed to use Accelerated Services?

Janice MacDonald:  Paragon requires a lot of building. There are tables that need to be put together. There are screens and layouts that clinicians and business folks will use to gather and document information and over the course of the whole project, that can be hundreds and hundreds of hours’ worth of work. And sometimes, that work is extremely repetitive.

To take your very, very busy hospital staff, your business office people, your clinicians who aren’t giving up their day jobs for the Paragon project - they’ve still got other work that they’re trying to do and very, very valuable clinical staff at the bedside - to remove them from care, from their day-to-day jobs to have them doing all these build work… I think you can see that it would be very appealing to say, 'Look, we can kind of give you a service that can come in and do some of this keyboard work for you.'

John Maher:  Right. 'You don’t have to worry about this. You guys are busy, let’s just take care of it you.'

Janice MacDonald:  Right. 'We’ll take care of this for you,' and so it’s very appealing and it is… hospital resources are tough to come by, skilled, experienced people, and taking them on the Paragon project. It can be a real challenge.

John Maher:  Right. So then, what can go wrong with the hospital using Accelerated Services?

Janice MacDonald:  Yes. And now, this is a very fine line because it is a wonderful service and it sounds great, and you think, 'Why would I not take advantage of this?' It’s just there are risks and downsides to it. There’s a very, very appropriate use of Accelerated Services but things can go wrong. How it works when hospital uses Accelerated Services is that someone in the hospital still has to define what needs to be built. There are decisions and design work that has to be done somewhere.

John Maher:  Okay.

Janice MacDonald:  If the people that are doing that decision making and design work don’t understand the ins and outs of how the application works, they tend to do layouts on paper and hand them off and then somebody will build what’s given to them, but it doesn’t always work. Translation from paper to the electronic world, it’s just it's never a straightforward thing.

So, it’s that decision in design work that someone has to do before you hand off to someone and say, 'Okay, here’s exactly what we want. Now go ahead and build it and get it done.' There’s just this gap, there’s this risk right there in that hand off.

And so, what we really recommend or what we’ve seen is that if you don’t take some of your resources in hospital, you don’t pull your nurses, you don’t take people off staff and you take a very small group of people and have them make the decisions and hand things off to Accelerated Services to be built, the people who end up using the application are not happy. It doesn’t work the way they thought. There are actually mistakes that can get made, there’s just a lot of risk that gets created in that hand off if there hasn’t been a group of hospital resources that did some really, really good ground work testing, vetting out of how this is going to work before handing things off to be built.

John Maher:  Can you give me one or two specific examples of problems that might come up?

Janice MacDonald:  Yes. I’ve actually got some good examples that we saw at a hospital and built -- I’ll be a little bit simple with some of these but, but I think I can give you two good examples. If you think, for example, about patient information that needs to be documented in four different areas of the hospital. For example, I’m a nurse and I need to document a patient’s blood pressure, pulse and temperature. I’m oversimplifying a bit, but I’m going to document their blood pressure, their pulse, and their temperature.

So I’m going to do those things on a medical surgical floor, in an ICU, in a pre-op area and in the Emergency Department. If the build for those screens was sort of put together separately - which often happens, we had the ED folks look at their screens and what do you need? And we had the med search people look at their screens and what do you need? We had OR and so on - Well, everybody gets blood pressure and temperature and pulse recorded. But for example, on the med surg floor, first I do blood pressure, then I do pulse, then I do temperature. Then, I go over ICU, well, first I do temperature, then I do pulse, and then I do blood pressure, and then I go to the ED, and it’s blood pressure first, and you just start to mix up the order and the layout of things.

John Maher:  Right. So there’s no consistency between the departments.

Janice MacDonald:  Right. And if you’re a nurse that floats from one department to another, which is very, very common, the screen that you got used to suddenly looks different and it slows you down and confuses you and it, it’s kind of a simple example but if you lose that consistency, it just really, really throws people off and can cause people problems down the line.

Another example - and that’s almost a little bit more of a risk and again we’ve seen this too. Sometimes, when a nurse is documenting, they’re going to answer a question and a simple example I’m going to put, “Does the patient have their wristbands on? Yes or No.” and that’s a yes or no answer. Either the patient has their wristband on but they don’t have their wristband on.

John Maher:  Right, it can’t be both.

Janice MacDonald:  Can be both. So the way that should be built is that you’re only allowed to choose one answer that’s called a radio button and that data type is something that’s locked in. Just the way Paragon works, once you build it and publish it, it’s locked in. And if you want to change that data type, you have to rebuild it.

So if you wanted a radio button type, a yes or no answer or only one choice from this list, first is some other thing where I’m documenting skin condition and it can be warm and pink and the whole selection from a list of check boxes, I can have three or four or, or no answers. Those are very different types.

And what we’ve seen is mistakes get made because the people that where building the layout didn’t really understand the difference between having to designate whether this was a radio button or a check box. They didn’t know what that meant, they weren’t experienced with it. They handed off to Accelerated Services. And when things get done, and built, and published, that comes back with the wrong data type. So something that I should be able to make only one choice, I can check both answers, something that I should be able to check three or four, I can only check one. And that’s very frustrating because that actually then needs to be rebuilt.

John Maher:  I was going to say, can’t that just be fixed easily after the fact or is that something that takes a long time to fix?

Janice MacDonald:  These are some of the of the quirks of the Paragon application - things that you would think might be a simple fix actually means that you have to go back and sort of redo that whole box of data. You have to obsolete the old one, recreate it over again and change the data type. It’s just certain elements get locked in. And it’s just kind of one of the quirks of the Paragon build.

That might sound kind of minor but if it happens in 20 or 30 places, and these people have to go back and you have to kind of keep making these changes and it’s just -- Now, you’ve created more work on the backend fixing things that really could have been caught upfront if we had a team from the hospital that really understood what they were handing off to be built.

John Maher:  Right. So isn’t this something that the hospital might expect from Accelerated Services that they would come in and catch these kinds of things from the beginning? Or is it literally that the hospital makes some decisions about what they think they need, hands it off to Accelerated Services, and then, Accelerated Services is just building the system the way that the hospitals said to, and not really questioning anything.

Janice MacDonald:  Yes, absolutely. I think, ideally, the hospital would really want the Accelerated Services folks to be able to catch all this stuff, and to be able to send it back to them and say, 'Hey, did you want this type or this type?' And sometimes, that happens but when you really put this picture together, what happens is, the build gets handed off to the Accelerated Services people in pieces. They’re seeing one piece of a jigsaw puzzle. So they often don’t ever see the picture of how it’s all put together because they’re just building their piece.

John Maher:  Like the example that you said where a different department has a screen -- the four different departments in the hospital, maybe, have a different screen that maybe being built by a different person from the Accelerated Services team, and then, they’re not really talking to each other or coming up with a coordinated effort.

Janice MacDonald:  Right. The four different departments could be built by four different people who aren’t seeing how that flows all together. The Accelerated Services people aren’t the ones doing all the testing and you said everything, so although it would be great if they could catch everything, it’s not always a really fair expectation just because of the nature of the work and the way it’s being segmented off and handed to them.

So sometimes, that happens but again, we see sometimes you think simple things just go wrong because the hand off creates a risk and if the people who are going to use it just haven’t tested it and vetted it, it's just going to create a great opportunity for inconsistencies and errors and lack of flow, and again, then at the end of the project, now your Accelerated Services people believe they’ve done their job because they built what you gave them to build. Now you’re suddenly stuck with all these fixes and things that really --

It’s frustrating because there are potentially really easy things that could have been resolved in a good, solid upfront design phase with people… As I said, there’s really no -- there’s no substitute for the experience you gain from building it yourself. Not just one person but a small team of clerical people understanding how the build affects the use.

And you can only get that from actually building, and then, taking what you built and using it to walk through a patient’s situation that’s when you suddenly go, 'Oh, Aha! I’m missing this. So, I put this in the wrong order,' or 'I never assess that first, I always do this,' or there should be choices. And when you miss that upfront, which again, with this package Accelerated Services will do your build for you.

Well, they can do your build for you but they can’t make your decisions for you. They can’t layout your screens for you. And they really are a large group of resources, and no one of those resources is responsible for you or a big picture. You as the hospital are responsible for putting all those puzzle pieces together.

Solutions to Accelerated Services Challenges

John Maher:  Okay. So we’re getting at the solution here. So how does this all come together and how do we get the hospital to work correctly with Accelerated Services in order to make this all come together properly?

Janice MacDonald:  And yes, that’s where the CHA group -- We really have seen great value to hospitals from Accelerated Services but that value can just be magnified by -- You just have to bite the bullet a little bit and pull some of your hospital resources; your nurses, the people that are going to be your end users.

There’s no substitute for, I think what we’ve called in other podcasts, “super users” - those people from your hospital that are going to take the time to learn how this thing works, how it interconnects, how it all goes together. That they take the time upfront, do the groundwork, actually learn how to build. And it can be as a small group. In a 300-bed hospital, that can be group of six or eight nurses. We’re not talking 20, 30, 40 nurses but we’re also talking more than one, we’re talking more than the IT analyst, but a small core group representing all your departments, understanding how to do the build and putting it together, and testing it at a certain level.

And then, once they’ve decided, 'All right, we’re now happy with this. We vetted it, we’ve run it past some of our end users, we vetted it, we’ve worked with it, and we can guide that,' then it’s a perfect time to then hand off that vetted build to Accelerated Services. And you can even give them instructions about how they can, in sense, communicate back, who they should communicate back to if they have questions, and encouraging questions from the Accelerated Services folks, and working with their team coordinators.

So again, there are some real positives to it but if you don’t have that upfront knowledge, you will create gaps and issues in the build. And then, there’s one other thing that I wanted to make sure I mentioned. Once Accelerated Services is gone and your project is over and it’s six months down the line, there’s going to be new regulations that come out. There’s going to be new data that needs to be collected. There’s going to be some new clinical effort that requires that we keep building. It’s not a static process. It's not 'build it and you’re done.'

John Maher:  Right.

Janice MacDonald:  It is an on-going, changing, living thing - this software that you’re going to work with now. And so, if you don’t have some depth of knowledge of how to continue to build it and shape it and work with it, you’re going to kind of be stuck with how do you make the changes that you need to make in a timely and effective way to continue to grow and expand the use of the application, if all of your knowledge of how to build kind of went away with Accelerated Services.

John Maher:  Right, because you just sort of -- you made an initial decision about here is what we need, you handed it off to Accelerated Services, but you didn’t have a team from the hospital that was directly involved in building this. Then, when it comes time to make some changes and build some new pages out or whatever resources that you need to add to the Paragon System, then you don’t have a team left in the hospital who knows how to do that.

Janice MacDonald:  Right, and so you're either stuck with maybe one person who knows how to do it who’s overloaded with trying to handle more than they can, or now you have to pay somebody to come in and train your people again how to build it.

And in a sense, you’ve already paid for that resource as part of the project. Like I said, I think it’s a sort of the big myth is Accelerated Services can do this all for you. They can’t do it all for you. They can be a great, great resource to help do the repetitive tasks and some of that hundreds of hours of over and over but there’s just no substitute for your core team of clinical super users who really fully understand the build that underlies the use, and all the decisions that went into why it is the way it is.

CHA coordinates, guides, and helps the hospital teams

John Maher:  And so, tell me again how CHA gets involved in this process. It sounds like you’re coming in and you’re helping to coordinate that core team from the hospital so that you’re guiding them in the right direction, helping them make these decisions, is that right?

Janice MacDonald:  Yes, exactly, John. We come in and we can help them really understand what the decisions are. Because we know how to build the application, we can often do quick mock ups when they’re stuck with a decision point of 'I can do it this way' or 'I can do it this way?' Well, we can show them what those alternatives would look like. We can --

John Maher:  'We’ll show you both a ways and you can test it out and try it, decide which way you like best.'

Janice MacDonald:  Yes. 'Let’s play it out and see which way is going to work for you,' because there really are alternatives about how you want to lay this out on which choices you want to make. So we can do work with them, so that they understand the decision points.

We also help people know how to test. How do you go in and actually test and understand all the connections between the Paragon modules because in order to test, 'Does this check box in my nursing documentation trigger the order that goes over to tell the social worker that I want a consult.'

And those are some of the things. And again, Accelerated Services can’t do the testing of the connections but your build is what triggers all those sort of interconnections between the applications and that’s, again, something that we found, for places that relied very heavily on Accelerated Services, they weren't really good at understanding, 'Well, how do I test that everything works and that all my bits and pieces talk to each other?' because they just had never played it through before. So it’s part of the vetting process. It's ‘what are the decision points’? We can help guide those decision points, show people examples, play those decision points through so they really understand the implications of their decision, and then, help them test in sort of mocked up patient care situations to really make sure that they vetted it through.

And then, that’s again - I keep coming back to the word vetting but that’s what we’re doing. We’re vetting their build. Then, when they’re confident, we can then help make sure, that also, that the things that they’ve handed off to Accelerated Services, we help them develop the rules and these rules sound really simple but things like, 'Do I want my font in all capitals or mixed case? Or 'What’s going to be the order of my screens?'

And although that sounds really simple, when those rules don’t get laid out, you get this really confusing -- inconsistent mix of things and it just really hurts your training, and your consistency, and your ability for nurses to float across all departments, and use the application that way.

John Maher:  Right. All right, well, thanks for speaking with me today, Janice.

Jasmine:  Thanks very much John, my pleasure.

John Maher:  And 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.

[music]

Katlyn Graham:  Hello, I'm Katlyn Graham. I'm here with Mike Lucey, President of Community Hospital Advisors. Mike formerly worked with McKesson. He was part of the team that reintroduced Paragon to the market in the early 2000s.

Then, he created Community Hospital Advisors, a consulting firm dedicated to helping hospitals effectively install Paragon. Welcome, Mike, thanks for joining us today.

Mike Lucey:  My pleasure, how are you, Katlyn?

Katlyn:  I'm great, thanks. Today, we're discussing managing the vendor in a McKesson Paragon project. One of the things I've heard you say before is, "Managing the vendor." What does that mean?

Mike:  We'll go right to the hard question first I guess. This is a question that can get me in trouble if I'm not too careful with my good friends at McKesson, but "managing the vendor" really goes down to the essential relationship that needs to exist between the hospital and McKesson, that is the most important relationship.

The relationship with us at CHA is important, but the reality is you're going to be living with McKesson for a long time after you put this product in, and it has to be a relationship of equals, of strength, of shared accountability.

When I say "managing the relationship" in the project process, it's very important to understand what the roles are that need to be played so that you can gauge whether everyone is playing their role effectively.

That's what I'd say, managing McKesson really comes down to understanding what should I expect from them so then I know if I'm getting what I should expect, does that make sense?

Katlyn:  Yes, I think so. Doesn't McKesson build this system?

Mike:  No, [laughs] that's really where it starts. In fact, there's a lot of confusion around that. When I was selling products for McKesson, you understand the relationship changes very dramatically the moment that contract is signed.

In selling Paragon, in some respect in selling any software product, you want to diminish the pain the customer goes through to put it in, you want to diminish that part of the struggle, if you will, to get that signature on the page.

Once the contract is signed, it's very important that the effort now that needs to take place is clearly understood, and that those roles again are very well defined.

The analogy that I would make is, "When you sign that contract, think in terms of moving." You're moving from one house to another house, all that you're buying from McKesson is the truck.

You're buying the truck, that's going to get you from one place to another, but you're not buying the driver, you are the driver. What you get from McKesson when you sign that contract is, "They will train you on how to drive the truck, they will train you on how to build this software, how to build this bridge from your old house to your new house."

My analogy is getting a little mixed up there, but what they will not do is, as I say, drive the truck because they don't know where you live and they don't know where you're going, quite frankly from your old house.

They don't know what you want to bring with you and they don't know where you're going to put it in your old house. Back to your project, they don't know what your current operation priorities are, they don't know how you're flexible, and how open you are to changing them in your new environment.

You have to make all those decisions. The essential part though, the piece that McKesson does deliver, is teaching you how to "Drive the truck."

You're not going to drive it, but they're going to teach you how to drive it, they're going to teach you how to build this software so you can build it to your standards.

Now, once you understand that, you don't expect them to drive the truck. Once you understand that, you don't expect McKesson to make decisions for you, that's really the critical piece is what should I expect them to decide for me, what do I have to decide for myself as I go down this process.

When I get back, then I can understand, I will hold McKesson accountable to deliver very good training on how to build, but I won't hold them accountable for the decisions that I make. Does that make sense?

Katlyn:  That does. They're providing the vehicle, it sounds like, to get you to this new technology. What is the vehicle, is it software or...?

Mike:  There's three things that you'll get from them. You'll get software, in fact over the period of your project, that software is going to change to a certain degree so they will be updating it for you and they'll be telling you about those changes, you get the software.

Secondly, you get this build training. You're going to get a series of people who're going to come into your hospital and teach you how to build physician documentation, order management, registration, they will teach you how to build it.

The third thing you're going to get is this technical support. They will be setting up your databases for you, they'll be setting up your environments, they'll be updating them, they'll be helping enable your conversion process so you have this technical team over here, you have the build training team that's going to come in, and then you have the software in those software updates.

Those are the three things that you're paying for from McKesson. Now, on the hospital's side of it, I learn how to build and I have to do the build, that really is that series of decisions that I pointed out.

You have to make all these decisions about, "How do I want my orders to work? How do I want my screens to look? How do I want my registration process to flow?"

All that stuff has to be done internally, based on what your priorities are.

Katlyn:  It's very individualized, it sounds like, on the hospital, very specific to how they operate.

Mike:  It is, in fact when we do multiple hospital sites, it gets down to if you have a medium, small, and a large hospital, each of those hospitals will have different workflows that have to be considered.

There, you have an executive team that's deciding what do we want to standardize, what are we going to allow each hospital to make more individual, that decision processes is the big challenge.

Katlyn:  What role does CHA play? What does CHA do?

Mike:  It really goes back to those decisions. Since we've worked with a couple of dozen different hospitals, in any one time, we'll be working with 13 or 14 different hospitals, either during implementation, supporting past implementations, or doing upgrades.

We have a very broad and deep view of what hospitals are faced with and are challenged with, we have the ability to say, "OK, you're looking at these decisions, these are your alternatives."

The struggle with decision‑making is the alternatives, is saying "OK, how many alternatives do I have? How do I prioritize them so that I can then make an informed decision?"

Too few alternatives, which we see very often. Remember, you have a series of build advisers who are coming in from Paragon, coming in from McKesson, they have a very limited view of the world.

They have their application in the hospitals they've worked with. They may only show the limited amount of alternatives for using that application that they've seen, that can be very frustrating because if my workflows don't fit in that limited view, then I'm stuck.

Then, there's the other one. I may really think at my hospital that I need to do a certain workflow, I have to do it this way, "It's better to have a third‑party," someone from, for instance, CHA sitting there and saying, "I understand you'd like to do it that old way. The product cannot do it."

We have today very often is we can sit down and say, "The product was built this way because the regulations require this kind of workflow," It's not really McKesson's fault that, for instance, medication reconciliation works this very specific way, it's the regulation requires it.

That's easier to hear from an objective third‑party than hear it from the vendor where you're thinking, "Maybe you're just telling me that because your system doesn't work right." We can sort those alternatives out.

Again, I look at my alternatives, I prioritize them, I make a decision, and I move on. Projects get crushed with delayed decisions, it just kills them, drives people crazy.

Katlyn:  You have that overall view, that overall expertise, and can really provide feedback to people. I'm sure that you appreciate that. It sounds critical with what they're going through.

Mike:  If you make bad decisions, you're going to get a bad result. There's two things that we see pretty chronically with failed or damaged projects.

The first is "I put the wrong driver in the seat." A hospital says, "OK, I'm going to buy this software for you, I'm going to buy this truck from you, drive me to my new house."

They drive you to your new house, it's the wrong place, you don't like it, you've got no one to blame. They didn't know where they were going and they didn't know where they were coming from, that's the first area where we see our problem is accountability.

I've given McKesson the wrong role in this project. The other one is if I have bad decision‑making so that all decisions are delayed, well, then don't be surprised if your dates keep moving.

Probably, the worst one though is if I had bad decision‑making so that I have now built my system incorrectly because I did not see all the alternatives, I did not prioritize them correctly, and I did not pick the good one.

You never get the best, it's a thing in one of the speeches I make. Do not fall into the trap thinking you're going to build the best system in the history of the world. Build a good system, and then make it better through use. We will get folks focused on those decisions, get the decisions made, and keep on track.

Katlyn:  Sounds like hospitals should give you a call. For more information, you can visit the Community Hospital Advisors' website at commhospital.com, that's "comm" with two Ms or you can call (888) 811‑4687.

Thank you so much, Mike, for joining us today.

Mike:  My pleasure.

[music]

[music]

Katlyn Graham:  Hello, I'm Katlyn Graham. I'm here with Mike Lucey, the President of Community Hospital Advisors.

Mike formally worked with McKesson. He was part of the team that reintroduced Paragon to the market in the early 2000s. Then he created Community Hospital Advisors, a consulting firm dedicated to helping hospitals effectively install Paragon.

Welcome, Mike.

Mike Lucey:  Hi, Katlyn.

Katlyn:  Thanks for joining us today.

Mike:  My pleasure.

Katlyn:  I appreciate it. We're discussing these new standards McKesson Paragon require for Meaningful Use 3. What is Meaningful Use 3, Mike?

Mike:  Meaningful Use is the vein of many, many CIOs in hospital executives these days. It's a set of standards that a hospital has to meet in the use of new electronic tools, electronic medical records. It's not just that you're putting in a system, but a government has come up with a set of...It's like checklist of minimal standards that you need to meet for using these products. That has reporting requirements. It has care requirements. It has patient access requirements.

It's been a struggle because as the standards have been delivered, they've also changed. There are three sets of standards. You use one, then two, then three. The Meaningful Use 3 standards are still a bit influx. Hospital executives, CIOs in particular, are trying to figure out, "Where do I need to be from a product‑set standpoint in order to meet these standards?"

One of those challenges is in the McKesson environment, there is a good set of products out there today. Their star is one set of applications and then the horizon set of applications that many people have invested in over the years. The question is hanging out there. Can I keep my current product and then meet these new standards? It can keep folks up at night and give them a lot of headaches.

Katlyn:  Do you need Paragon or McKesson Paragon to meet the Meaningful Use 3 standards?

Make:  No. In a qualified way, the answer is no. You do not need to buy Paragon to meet what we expect to be the Meaningful Use 3 standard. Looking about what those standards are today, no, you don't need it. You can get there with today's product. That's a general statement.

The sad reality is then you say, "OK. Generally, that's true, but what about for me? What about for my particular hospital?" The interesting thing that's happened with these stars‑slash‑horizon hospitals over the years is that everybody has a very different mix of products.

In many cases, it's not just McKesson products. I'll have McKesson products and I'll have McKesson products from the different business units. I'll have Relay products. I'll have Pathway's products. I have Horizon. I've got Star. I've got this sorter lab or I have some other things that are augmenting my environment. This whole ball of wax can whole thing get Meaningful Use 3. That is an individual question, and you have to go through individually to see if I can get to the standards with this set that have.

Generally, though, I'd still say, "Yeah, you probably can. If you've been able to get through other Meaningful Thresholds with your current set, you can get to Meaningful Use 3 with your current set."

Probably not with your current versions, though. That's the other that comes in there is, "I have all these products. They're working pretty good. Got me Meaningful Use 1, maybe get me to Meaningful Use 2. What does it take to get me to Meaningful Use 3?" That's where you have to start down with a calculator and pencil and figure out the dollars.

There are very big upgrade costs associated with a lot of these applications. One of the services we provide is an analysis of that current state and that current set of applications. We generally find the, "Yup, they can all get you to Meaningful Use 3, but then you go and do the other math."

If I'm at version ‑‑ just to pick a number ‑‑ but I'm at version 11, it's OK. To get to Meaningful Use 3, you're going to get to version 15, and version 15 requires these kinds of technology changes, these kinds of upgrades, this kind of new training. If you do that for one application, it has a cost associated with it.

Now, you take that cost and you do it the 2nd the 3rd, the 12th, and the 14th. Suddenly, you're in this place of, "Wow, I'm doing enough work that I could put the whole damn thing in again and start over." That's where you start saying, "It's time to look at Paragon."

Eventually they're going to have to make the move. Eventually these products, whether it's three years, five years, seven years, are going to go away. You're going to move to, if you're staying with McKesson, McKesson's newer platform, which is going to be Paragon. It's just a matter of whether I'm going to do it today or I'm going to do it in three years or I'm going to do it in five or seven years.

Katlyn:  When you stick with Star or Horizon, you're putting off the inevitable or...

Mike:  Yes. You could be putting off the inevitable, but we have recommended hospitals do that. We've gone into some sites, and you see they're very current. They might have built things out in a very effective way. In some respects you're saying, "All right. We're going to hang on here because our upgrade costs are very manageable."

In most, and I'm qualifying that, but I do think right now it's most other environments. When you start doing the math, it starts looking from a dollar perspective, "I could be better off to make the change earlier rather than later" because we do have this other." There's a third calculation here.

Calculation one is, "How much does it cost me to upgrade?" Calculation two is, "How much does it cost me to put in Paragon?" Calculation three is, "How much does it cost me if I don't get to Meaningful Use 3?" Now that's an interesting calculation because that also is very, very individual. I find that most hospitals don't do that math.

It's an important piece of the equation because if the penalty is not horrifying, then you should really take a look at your timing. Our struggle with the government is that the timing has been changing pretty regularly. Every time we think we know what the calendar is, well, the calendar can change.

Most recently we saw this with the ICD‑10 change, which moved a whole year one weekend, which was good news for some people and frustrating for others who were really all ready to go.

Katlyn:  It sounds like that someone might choose Paragon when these upgrades to their old software just gets really expensive, and they want to be able to do more? Is that why someone chooses?

Mike:  Exactly. The mix that comes in is many hospitals had been delaying upgrades for a series of years with the expectation of making a move. That is not a bad decision. Some folks would start to question it because they start thinking, "Man, I should have done it a while ago. The direction we were thinking we were going has now changed. Now it's going to be Paragon."

Nobody likes to have that kind of shift. "I had a direction that I was heading. Now that direction is gone. Paragon is the alternative that's out there. Am I being forced to go to Paragon?" The answer is no.

I have not found a hospital that could not make the move to Meaningful Use 3 with augmenting their current set. It's just a matter of looking at the detail of how much pain is involved in that upgrade, how much cost is involved in that upgrade, and then doing a very objective unemotional view of, "OK, if I go to Paragon, which is the best way?"

I would say when we get to the even, it's X million to go upgrade, and it's Y million to go Paragon and they're relatively even, maybe this sounds self‑serving, but we generally would say earlier is better than later because eventually you're going to make that change.

The more time you have to adopt a new technology, optimize that new technology, and make it a part of your culture the better off you're going to be. You'd hate to be up against the gun saying, "I have to meet a standard by January 1st or July 1st or I'm in trouble." That puts a lot of pressure on a project, and you'd prefer not to be there.

Katlyn:  When are these standards required for hospitals? You said it keeps changing.

Mike:  It keeps changing. I'd be in huge trouble if I...

[laughter]

Mike:  ...I told you.

Katlyn:  Oh, OK.

Mike:  If I put a date, but we've mapped it out for folks. It's individual there, too, because depending on when they made Meaningful Use 1, when they made Meaningful Use 2, now they're looking at Meaningful Use 3. We would put that date, though, clearly into the analysis and it becomes a huge part of the equation.

As I said, the other part is not just when do we need to be there, but what are the ramifications for losing? Because, very interestingly, when we do that math, maybe it's not as bad as you thought it would be and it has a lot of different elements to it, but I think that it's the further part of the equation, it's the further part of the conversation that many folks don't get to. But it's all part of the analysis. Once you sit down and look at it, you'll look at your alternatives, and you make a decision.

To answer the question that originally started it, no. If you have a set of products now and you've gotten to Meaningful Use 1, you've gotten to Meaningful Use 2, you can probably get to Meaningful Use 3. It's just a matter of whether or not it's the best cost decision.

Katlyn:  OK. Thank you, Mike, so much for explaining this. If you would like more information, visit the Community Hospital Advisor's website at commhospital.com, that's comm with two Ms. Or you can call (888) 811‑4687.

Thank you, Mike.

Mike:  Thank you.

[music]

John Maher:  Hi. I'm John Maher, and 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.

Welcome, Mike.

Mike Lucey:  Hi, John. Nice to be here.

John:  Mike, what is different about a McKesson Paragon project, as opposed to other IT projects that hospitals do?

Mike:  That's a significant challenge for me when I'm talking to CIOs, who, quite frankly, run project factories right now. They say, "What's the big deal? It's a different application..."

John:  They do this all the time.

Mike:  Exactly. The way I explain it is to say, "Take a look at your projects for the last, maybe, eight to 12 years. Take the majority of those projects, bundle them up into one big batch, then reintroduce them all on one weekend at one time."

That gives you an idea of what it's like to introduce Paragon. When you do that, then they sit back, "Wait a minute. Let me figure out how many applications that is, how much time they put into them as one very big dynamic, because that's a lot of people, that's a lot of work hours."

The other issue there is that doing it all at the same time. In the past, I did all of these projects in a series. When they interacted with other applications, I said, "We have to make sure that we get those connections correct." Now, I'm doing it all at once. I have to do all these applications at the same time and monitor those interactions, radiology to lab to pharmacy to nursing to orders. All these things have to be built concurrently and all those interactions monitored and effectively managed.

The other piece of it is really the crusher. Someone sits back and says, "OK, I'm going to deliver all these projects all at the same time. All of the people that are impacted by them, all those technicians and those registrars and those nurses and then the real big one, the big hitter, all of those doctors are all going to be impacted but all at the same time, all on the same weekend. That really gives you a much better understanding of how significant the project is.

The unique characteristic about Paragon is not necessarily the amount of software that gets flopped into place. It's the amount of people that are impacted by the software. That's the real crusher.

John:  Like you said, it's everybody who works at that hospital, all of the nurses, all of the doctors. It's hard to roll it out over a long period of time. You just have to pull the switch and then all of a sudden, everybody's on this new system.

Mike:  Exactly. You know, it's a positive and a negative. The beauty of Paragon is that it's one set of applications that all work effectively together. Microsoft technology, and it's current technology, you deliver it all at the same time, in a single database. All those pieces of the puzzle...Back in the day when I sold the product, these were, "Oh, this is terrific. You're going to be able to have this one big database that's all going to work together."

Well, the other side of that is, it all has to go in together. It all has to go on together. It all has to be Friday night, shut off all those old systems, and Monday morning, all those doctors and nurses are going to show up. All at the same time, they're going to say, "What was that log in? How do I get to that order? What does the patient look like?" All the things that they've been trained on, but now they're actually using it.

At the same time, little Johnny is throwing up in the corner and Marge needs her meds, and things have to get done. It becomes a very exciting moment. When we create that picture, then it's much more effective that we can back up the whole trade. It's like, "So, if we're going to do this on this weekend, back up 18 months. This is the time frame you've got to prepare for it and to put it together." That's why conversions become important.

John:  Mm‑hmm.

Mike:  That's why the build becomes important. That's why the structure of your project team becomes important. That really becomes another piece of it that is revealed. When we have that conversation, then I can move very quickly into the other big piece. It's unique because it's this big puzzle coming together at the same time. What that means is you have to embrace it much, much more effectively. I think a lot of CIOs, a lot of people, when they see something big, they back away from it. "I need help. I need somebody to help me with this."

John:  Mm‑hmm.

Mike:  That's true, but we really have to step forward. You have to own that project much more, and understand that McKesson has a role to play in your project. Outside consulting, somebody like me, we have a role to play. But you really have to own it, you have to own that project.

John:  Right. You're talking about ownership. What does that look like?

Mike:  Well, what ownership looks like is, build it. Don't go and hire CHA and get a bunch of cheeks in seats that are going to sit there at keyboards and clickety clickety click. Build all your screens and build all your workflow because the more that we do, the more you cede responsibility, and the more you lose the ability to understand and train folks on it.

Then the other side of it, recognize that McKesson is going to come in here with this pile of software. They have some quite effective people that are going to come in to teach you about that software, but they're all individuals. I have an individual that's going to come in to teach about registrations, an individual that's going to come in to teach about orders, an individual that's going to teach about clinical care station.

Those individuals know their product, their application to a certain depth, but they're very hesitant to cross the boundaries of their area to talk about the whole unified view.

Ownership means owning the unified view, owning how all these pieces of the puzzle are going to work together. Because once you start doing that, you start to recognize that my current state, my current system, it does a lot of things quite well. I want to keep those things.

John:  Right.

As I learn more and more about Paragon, I start to recognize that my current system also does some things flawed, or they were workarounds. The system didn't do A, so we did B, C, and D to get around that problem.

Now, I want to take what's good and leave behind what's bad. Only an owner can do that. You're not going to have the moving company come into your house and say, "I'm going to take the mirror, but I'm going to leave that couch."

John:  I have lived with it. You know what you like. You don't want you don't like. You're the only who can make those decisions of, "You know what, you can throw that mirror out. I never used that or liked that one anyway."

Mike:  That mirror stinks.

John:  "You've got to keep my couch. That's the most important thing to me."

Mike:  Exactly, exactly. When we're looking at it from a system point of view, I can see that the fact that we have this off‑site clinic, we need to keep this other process in place even though maybe other Paragon hospitals don't do that. We need to find a way to fix that.

I also recognize that since I have this Star System that worked with Horizon over here and had a Cerner Lab over there, now I have the unified environment, I don't have to do some of that workaround nonsense that we built to accommodate our problem with another break.

I know I have the unified system. That, sometimes, can be difficult for folks, because we work really, really, really hard on those workarounds. We start to own those workarounds and want to bring them into our new system.

Ownership means being able to make those hard decisions, what stays behind and what moves forward.

John:  Does a hospital have to have somebody dedicated to working with you to help make those decisions? Do they have to put somebody full time on, "You're going to deal with this change over to McKesson Paragon."?

Mike:  Absolutely critical. One of the first things that generally ask us is, "We want you guys to be our project manager." That's a real bad idea. It's a great idea if I...For billable hours it will be terrific for us to be the project manager, but the project manager has got to live in your environment, in your hospital.

Here's what you get from someone like me. You should be able to get all those things that you're not going to need later. The other thing you need to get from us is quickly the ability to develop all those skills that you will need later along the lines of project management.

Any hospitals have their project management officer, but what you want is that central person that will be the project manager. You don't send them into this blind. We've done 14 or so implementations. We've done the last five or six of them a lot better than we've done the first five or six of them. Part of it is we learned that having an in‑house project manager was critical.

Secondly, give them the tools to manage the project very, very well, the structure to manage it. We've got big old monster spreadsheets and we use Pi Matrix to actually put structure around the program, so for document management, task management, resources, schedules, all that needs to be in one web‑based place.

Get those things from us. Get some training from us, initially, to get the project started on the right path, but our job is supposed to be advising, to cross those barriers between applications. Then the other critical part, you're the owner, and you're being delivered. You're buying a new house, but you're not buying a new dog, you're not buying a new family, you're not buying a new garage, and you're not buying a new car.

You have all the other things that are coming with you. All these other ancillary products, these applications that are working outside the McKesson walls, you have to incorporate them into your process. You have to incorporate them into your new system, or, quite candidly, evaluate them, evaluate whether or not they're going to, again, make the move with you.

That's another piece that you get from that third part, the objective you to say, "OK. Here are all your alternatives. Here are all your McKesson alternatives for your decisions. Here are all your current systems, and then here are those things that are maybe outside that you should consider."

That's the proper role, the chair that we sit in. We get that project manager up and going, and then we help with the decision making down the line. Then, at the end, you're going to have two colossal events. You have this integrated test, which is a pretend go‑live, and then you have your big go‑live.

We go back to the 12 years of projects that you've rolled up, packaged, and that you shut them all off on Friday, and then you're going live on Monday. That event is your highest‑risk event.

John:  This has been 18 months or so leading up to this go‑live day?

Mike:  Sure. It's 18 months of staging, building, then you start getting into your testing. There's the integrated test event, that scenario where we have a very strict policy. We use what's called patient testing. We don't use scenario testing. Scenario testing is a nice way that...

When I was back at McKesson, we liked the scenario testing, because it tests in a very controlled way whether or not the software is working the way it's supposed to work. I've got this software. It should be working this way. I have delivered as designed, so I create a scenario to test that all the pieces of that software are going to work effectively.

That's great. The problem is that Johnny, who came in, he's not going to work necessarily based on my scenario, so we use patient testing. We will take, for instance, on this integrated test week, 100 patients. They will fulfill the scenarios that McKesson provides, but we want to take 100 patients that are going to go in their squirrelly different ways through our system, so that we make sure that those exceptions are going to be at least addressed.

You can't always build to exceptions, but you can address them and understand them, because those exceptions are going to be there on Monday of that go‑live week, so we do all the squirrelly stuff as much as we can at integrated test, again, to drive down the risk that takes place on this big event at go‑live.

John:  Right. Go‑live sounds like a pretty momentous occasion after you have done all of this work, testing, and preparation. What's involved in that weekend of go‑live?

Mike:  What's involved is you go live with something because you've killed something else. It's an accurate phrase, because there's no going back. There's no turning around. On Friday night of go‑live week, that bundle of projects that you delivered over 12 years, they're all getting shut off, and there's no turning them back on.

On Monday morning of go‑live weekend, all those doctors, nurses, registrars, and technicians are coming in and sitting down at their desks at the same time, saying, "What's that login again? Oh yeah, I remember," and they start down their path. Our objective is to put in place a process that goes about seven weeks before go‑live to mitigate all the risks that are associated with go‑live with your conversions, with your training.

How you roll out these sequence of applications, all very, very detailed and practiced, so that your team is fully able ‑‑ again, going back to ownership ‑‑ your team is fully able to manage all those consequential problems as they arise. At the same time, you'll have a whole set of folks from McKesson that will be on site starting Sunday to Monday on, because that first week is quite challenging.

You'll have a whole set from someone like us. We're usually coming the week before and are there through the weekend and into the following week. But, after you get to Friday, you should be handling it on your own. That's when that second and third week, if you're still relying heavily on either McKesson or your consultant, then something is not quite right.

John:  Right. After go‑live, when McKesson Paragon is now installed at the hospital, and, like you said, you've had a week or so where you've ironed out some bugs or just gotten everybody up to speed, is your involvement with the hospital then done?

Mike:  Pretty much. Pretty much. Like I said, if you're two, three months down the road and you're still paying me at the same rate you were before go‑live, then someone really botched something up. We do stay involved with our clients, where we have a great set of hospitals that we work with, but they will bring us in as they run into new ventures, new issues that they want to get our involvement, significant upgrades, meaningful use to some regulatory issues, or if they have an organizational change that's taking place.

Then we'll get in and we'll get involved, but the bottom line here is, going all the way back to the beginning, the less you depend on McKesson, the less you depend on outside consulting, the much more effective your system is going to be, and your program is going to be going forward.

John:  Right. Well, Mike Lucey, thanks very much for speaking with me today.

Mike:  My pleasure.

John:  For more information, you visit the Community Hospital Advisors website at commhospital.com, or call 888‑811‑4687.

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.