Have you ever sat down with your grandparents, or other "more seasoned" folk, and talked about the the good old days? If so, chances are they've mentioned how everybody today is "in such a hurry." And it's true. We are in a hurry. We're resource challenged without enough time to achieve the results that our stakeholders desire - if not demand.
As we all rush to figure out population health and value-based care, IT departments can easily get into the trap of just "working down the list of requests." At least we're getting things done, right?
But the question is, "Are we getting the right things done?"
Holly Landowski, one of Nordic's strategic advisors, recently sat down with John Pollard, part of the Nordic marketing team, to talk about how she prefers a more "old-school" approach to processing population health requests. Holly's methodology calls for a little more understanding, a little more time spent upfront, and some quick wins along the way. Give the podcast below a listen to see whether Holly's approach may help you more effectively process the population health requests hitting your IT department.
You can play or download the episode below. Also, you'll find the full transcript below.
Did the conversation inspire any questions? Contact us and let's talk.
Show Notes
- [00:00] Intros
- [04:47] Defining Success: A happy customer
- [06:15] Assisting IS with population health requests
- [06:47] A breakdown of lean methodology
- [08:25] Changing the description of your business need
- [11:40] The importance of communication
- [14:25] What is the "discovery document"?
- [16:48] What is the "design document"?
- [17:20] The validation process
- [18:27] What does ongoing work need to account for?
- [19:11] Prioritizing requests
- [20:20] Building credibility and trust
- [22:03] Guiding principles
- [24:27] Closing remarks
Transcript
John: Welcome. My name is John Pollard. I am a part of the marketing team at Nordic, and I'm joined today by Holly Landowski. Holly, why don't you tell us a little bit about yourself?
Holly: So, I guess, quick highlights: Before I started my career in healthcare IT, which was in 1998 as an Epic employee, I was in public accounting. I'm an accountant by degree and background, which I think there are a lot of things that will never go away because of that. Very detail-oriented. After being at Epic, I served in a lot of local positions for healthcare organizations in the Dallas/Ft. Worth area, as well as southern California. Prior to joining the consulting world, I was the executive director over all of our Epic applications at my place of employment in California.
John: A pretty broad set of experiences. I think that qualifies you for this discussion today.
Holly: I would say very broad, kind of everything under the sun, I feel like at times.
John: We're going to try to wrap our heads around this world of population health and where everybody is heading and this move to value-based care. Your current client ... well, tell us a little bit about the stage. Set the stage for us, like how were they set up? What precipitated you in this role?
Holly: My current role would probably be best classified as an IS engagement manager for all things population health. While there are elements of Epic and Epic's Healthy Planet tools and other pieces of Epic as well that really kind of support the entire pop health workflow, I'm also working with a number of other applications in the industry, so big analytics vendors, provider roster management systems, and so on, and so forth. I think the customer really found themselves in a position where the strategy, the need to sort of move things forward, was happening more quickly than the current IS employees had the bandwidth to manage.
They definitely needed somebody that could really step in and think at the big picture and strategic level and lead a team of people through a project, beginning to end, and it seems like it quite frankly never ends. It keeps growing because the customer keeps entering into more and more agreements, so we start, we stop, we start, we stop, then we keep going. I think they really needed that person who could see the big picture and lead a team of operational people through technical requirements and implementation when they didn't quite yet know what they needed.
They couldn't describe the requirements. They didn't know. They weren't there yet. They needed solutions faster than they could think through the new operational processes. I think my background, my tenure in the industry, just sort of the jack-of-all-trades, has worked in a lot of different positions. I've done the gamut from being a builder to being an executive director, learned new things along the way.
I think I ended up being a good fit to really step in and manage the relationship with the customer, so speak at more of a strategic or an executive or a high-level process, but really partner with the analysts and the build team who needed a whole different approach and strategy, and I would just say methodology to sort of take these projects through their life cycle.
John: Let's talk about that briefly, though. Before we get to that, when you came on, did they give you a clear definition of what success would look like, would they say, "Hey, Holly, if you can do these things, we'll know we're successful," or was it maybe more like a typical project?
Holly: I think probably typical, other than success was a happy customer. I think historically, with a number of the projects I've worked on for all the years, be it something small or something big, I think a lot of my relationship with the customer and my approach and my style, and how I develop trust, and how we can move forward, I think that ultimately makes me successful. It may never be the perfect system solution, but it's the best system solution to offer for what the need is at that time. I think they felt confident, that just kind of given my experience, my track record, even my interpersonal skills, that I was the right fit at this point in time.
John: Sure. Let me see if I can wrap my head around this. You come in there, and you're helping the IS team better react and respond to, or maybe even proactively respond to these requests, these population health requests. Is that a good summary of it?
Holly: Yeah, I agree. I think it was the combination, so there was a list, right? Every organization has the list that had no structure, no organization to it, nothing behind it other than sort of all these requests that were in a thousand different places, that had now been combined into one spot. There was putting some structure and some processes. Quite frankly, it was like 5Sing it, to use lean terminology, you know, 5Sing the list.
John: For those that don't understand lean, do you want to break down those real quick?
Holly: It's funny because at one of my places of employment, as a leader, we had to go through a series of lean classes. I think what's interesting to me is there was nothing – I wouldn't say – new. There's always nuggets, and there's always things you can learn, but it was nothing earth-shattering. To me, it's how Holly thinks, how I process.
John: Sure.
Holly: Of course that's how I would go about structuring and organizing and bringing, I guess, sanity to the insanity that's happening.
John: Is sanity one of the S’s?
Holly: No.
John: No, it's not.
Holly: Sanity is not one of the S’s. It was interesting to be in classes with people where this whole concept of kind of lean thinking and really simplifying and eliminating the waste and making sure you're going from beginning to end in the most efficient way possible. It was like earth-shattering to a lot of the people, but we really did kind of the 5S’s, which I'm probably going to forget one at this point. It's you sweep, you sort...
We basically took a list of 500-some-odd items, categorized them, tried to kind of break them down. These are duplicates. Make sure things are alike. Then we went through a whole effort, so two full days, like 16 hours, at-the-elbow work with the end users to come back out with some priority behind that.
John: Sure.
Holly: I think the team I was working with, that was a very new approach to try to digest on behalf of what the customer was asking, but organize it in a better way, where we could take what they wanted, but kind of back to the proactive point, also insert, "Well, you've said you want A, but if we kind of digest it down, we think what you're really saying is this, and this is going to be the right solution." I think the other thing we try to do is really change the method that people were asking for from a requirement standpoint.
Don't say, "I want X in the application." Describe your business need. Then take what this business or the operation or the clinical – whatever word you want put in there – need is, and say, "Oh, well, if you want that, the best way to do that in the system is A. If you don't like A, B and C may work, but A is really the best." I think it was an entire, kind of, mindset change that started with this giant list and trying to organize and pare it down to go forward.
John: You're talking about changing the mindset of how your analysts approach solving the customer problems, in this case.
Holly: I think so.
John: Yeah.
Holly: I think, in turn, it's a way to change the dynamic with the customer and have them really kind of understand, "We're here to serve your need. You be the experts in the workflow, and your process, and your operations. Describe them to us, so then we can use our expertise and our knowledge with technology and give you the best solution possible." Versus, I think, sometimes when people and builders work as like ... I kind of use the term "a list builder."
John: Right.
Holly: Give me your list, and I'll go build it. There's no dialogue. There's no interpretation. There's no, "What are you trying to do with the list?"
John: There's no "why?" to it. Yeah.
Holly: "Where is the list? Why?"
John: You're saying that this is what the scenario was before you got there, was it was they would take a list and sort of just start working through the list.
Holly: I think take the list, and also, maybe there was a little bit of not feeling comfortable that they had the ability or the authority to push back at the customer. If the customer asked for, we'll just say, a best practice alert in the system, "Well, I want a best practice alert to do X," but the best practice alert wasn't the right solution, I think the team, as it was structured and as they had been operating, to no fault of their own, didn't feel like they could say to an executive director in operations, "Hey, that's really not the best approach."
John: Right.
Holly: So, I think it was a little bit of asking the why, but really developing the right relationship, so the customer could trust IS, that we were trying to bring the best solution forward, but that any system has its limitations.
John: Sure.
Holly: I always tell people ... so when I meet a customer for the first time, as in the customer on the business side or the clinical side, I basically say, "Here's the deal. I'm going to do the best I can possibly do for you throughout this implementation, but we have to have good communication, so you need to tell me, you know, what your need is. What's your request?"
John: Right.
Holly: "But I'm going to ask you a lot of questions, too, and we have to go back and forth. There are going to be times you are going to ask me for something in the system, and we'll do it. Fine. Great. No problem."
John: Right.
Holly: "There are also going to be times that you're going to ask me to do something in the system, and I am going to say, 'Nope, can't do it.' I either can't do it because the system won't," and obviously, you explain it to them.
John: Right. You mean you don't just say, "Nope, sorry."?
Holly: But they trust you.
John: Yeah.
Holly: Maybe sometimes I do, but 90 percent of the time, 99 percent of the time, explain it. There are some times where the explanation is, this system could do that, but for the integrity of the enterprise or the entire system, maybe not just how it works with Epic, but how Epic talks to the other applications or how somebody on an ambulatory side wants something, but that will negatively impact the inpatient side, sometimes you just have to say, "No." I guess I tend to think of it as relationship building. I call it my little piggy bank of love.
We have to build the thing, where sometimes we do it. We'll do some of the quick wins or the little things that may not be the best way in our mind, but it builds that rapport, so at the time, you have to say, "No, we can't do it," again, with a reason –
John: You've got a little bit –
Holly: They have trust, and they know I'm not saying no because I just don't want to do it, or I don't understand. They can believe in us as an IS team, and they trust that we're trying to do the right thing. Again, it all goes back to the communication and making sure we really understand what they're trying to accomplish and not just taking it at the surface with a list or a functional request.
John: Right.
Holly: On that giant spreadsheet, for example, there were things that basically said, "I want an alert to do this." Well, as we went through the 5S session with them, we broke it down or expanded it to really try to get at what they truly wanted.
John: Now, we've talked about that a little bit beforehand, and you said that you had been using a discovery document. Is that something that helps provide some structure to this process of getting their feedback and understanding all their needs and getting to the why?
Holly: It does. Yeah, so I think part of just with my expertise and forming new teams over all the years and managing people, this was a new team. That is one thing the customer did in demand to the growing strategy, was created an entire new team subset in IS to deal with population health. This team, including the manager, needed a little bit of structure.
John: Sure.
Holly: Trying to teach this group how do you prepare for a session with the users and putting together a discovery document ... yes, we have a template, but it's nothing formal. It's nothing extreme. It just really is a way to have the analysts prepare for and think in advance of the session with the end users. We can say, "Okay, again, you need to get admission notifications for all your patients who are participating in one of the Accountable Care Organization contracts when they present at the hospital. Okay, well, that seems simple enough, but there's probably five, six, seven, eight ways that you can do that in the system."
John: Right.
Holly: Having the analyst sit down and actually write their questions out seems silly, but I'm probably a little bit old-school, and I would actually probably truly write them out, where a lot of people will type them out.
John: This is before they get together with them.
Holly: This is before they even get out.
John: They're thinking through, "Okay, what are the different scenarios? How could I possibly-
Holly: Yeah.
John: -approach this?"
Holly: Then that way, even though you're putting the time, I would say, on the front end ... this is not a fast process, necessarily. You're investing your time on the front end, but what you then avoid is you're in a session, if you've done it the old way, where you're just like, "Okay, I'm going to go get my list," and then they tell you something, and you're like, "Oh, I hadn't really thought through that workflow. Oh, let me get back to you, because I'm not prepared." It's being one step ahead of what we think the end user is going to ask us, based on having a just general working knowledge of the request, so we're ready to go.
Then you get their agreement. Everybody is on the same page. Then we move to a design document. "Okay, I've asked you all my questions. You've given me your answers. Now let me show you what I think is best in the system. So your request is this. Your need is that. These are your options." Then we have a design document.
John: Discussion. Oh, okay, document.
Holly: A document as well.
John: Yeah, right.
Holly: A design or an architecture document, if it needs to be a little bit more technical in nature. Then I don't quite stop there in my process. I kind of go through that old-school validation, where you then go show them again. "Okay, so I've heard your requests. I've asked you some more questions. This is what I think we need to do. Does all this sound good? But now let's spend some time with you looking at it. Did I get it right? What is missing here?"
And, you know, again, it doesn't always work perfectly, but because we've invested that time up front, once it's live, 90-some odd percent of the time, they're satisfied because you really went through a very diligent process to make sure you understood the need, you were meeting the need, you got the sign off, and then now we can take it live.
John: Yeah, they're involved at least three or four times as the process is going. They've had their chance to give their input, so when it comes, it's no surprise. They're getting what they asked for, essentially.
Holly: Yeah.
John: They should feel that, good, that that's the best solution to the given problem.
Holly: Yeah, and I think the best solution at that time. I think that's the other thing you have to account for, is this work is never really done. Your ongoing work has to account for the, "This is as good as I can make it today, and now I need to make it better tomorrow." I think the challenge with population health is sometimes the strategy or the operations is moving faster than the technology is to support it. If you don't have a good tracking mechanism, and again, you haven't kind of dotted your i's and crossed your t's throughout the process, you'll never know what it was you need to come back to as the systems enhance themselves and there's optimizations available.
John: So, as you have all these requests, how do you decide which ones are the most deserving? I mean, do you apply some sort of rigor to ... you obviously are always going to have more than you can possibly do in a given day or a month.
Holly: I'd say there's a balance. The client does have an organizational structure in place that helps to assign priority to requests. I think certainly, we have to go through all of those mechanisms to make sure generally speaking, this body of work should be worked on.
John: Right.
Holly: I think where it becomes challenging with population health is they really do want everything worked on. The other thing I see sometimes is that the level of leaders who participate in those approval bodies are a bit removed from the day-to-day operations.
John: She's making these hand signs, which are way up in the sky right now, which you can't see on the other end of this podcast.
Holly: Maybe a bit removed from just sort of the day-to-day operations, so there needs to be a little bit of balancing there. I think you have to apply some, that if I just take the time to do this, be it a quick win, or something that I know that's going to help them, even though maybe they haven't asked for it, but it's standard functionality in the system, we ought to provide it to it. It's really kind of balancing the, "This is the list of formally approved things," but then these are the things I, as an expert, or the team as an expert, just knows we ought to really activate to make their workflow better.
I think it's making sure that you find time to work those little items in, and I think that takes me right back to my little piggy bank of love example. Sometimes the big picture things take months, and months, and months to implement, whereas I guess implementing a real time notification process ... again, when patients that they are financially at risk for enter one of our own facilities, they were faxing face sheets. Well, there's functionality in Epic. There's admission notifications. There's census logs. There's all these things that ... nobody should have to ask me for that.
I should just offer that to them as a part of a solution to make things better. I think we've really, with this customer group, we've gained a lot of rapport, again, because while we're doing the things they're asking for, we're also showing them how they can use the system better today to make some immediate efficiencies in the workflow, if that makes sense.
John: Exactly. Building your credibility, building trust, as you say. Yeah, that's excellent. So, if we were trying to summarize or maybe ... this was a great conversation, but if you wanted to sort of wrap this into this piece of advice for people that might be on the same sort of journey, going down the same path, they've got an operational team that's making requests, population health related, do you have any sort of guiding principles that you might offer for that audience?
Holly: I think it's really invest the time up front. Even though everybody wants it done yesterday, if you don't step back and put the right structure in place, it certainly wasn't ready yesterday, and if it's ready tomorrow, it's not going to be right, and it's not going to meet the needs at the end of the day. I think it's, especially as a consultant, probably, feeling comfortable to sometimes the pressure that's coming with the deadlines, or "We need this turned around in a week."
It's really having them understand and trust the process that you're trying to implement, even though it seems like maybe the process is taking a little bit longer, and "Why isn't it live? Why can't we have it?", that ultimately, if you do it the right way up front, you're not redoing it after the fact. We are doing a little bit of redoing after the fact right now at my current client, because I think the upfront implementation wasn't done with the right methodology.
It wasn't thought through, and it was kind of back to the, "Let's just build the list. Let's just do exactly what's asked." Now, A, the system has improved, and there are new optimizations and all those other types of things, but a lot of what we're doing could have been done two years ago.
John: Right.
Holly: I think it was a different approach to the process.
John: That's probably the case for many of our listeners, too, who have had years of reacting to lists and doing what needed to be done, often very quickly, and so worth the time to give it a second look, especially as we move into this new land of population health, value-based care. Well, Holly, that was a very insightful look at the things that you are doing to put structure in place, to be proactive in meeting operational needs. It sounds like this client is certainly benefited a lot by your experience and this very strategic and thoughtful approach. I think this is something that many of our clients can benefit from. Thank you very much for this time.
Holly: You're welcome.