Business Intelligence and Data Analytics with Lancer Seaman
Below is an excerpt of the full interview conducted with Lancer Seaman. Download the PDF now for the full article.
Key Takeaways
1. While the CIO of the Rothman Institute a +40 location leading ortho MSO with +200 orthopedic surgeons and another 200
extenders, the over-arching priority of the IT and Business Intelligence unit was to minimize IT disruption to the physician and maximize their IT experience.
2. IT Practice Acquisition Due Diligence will normally focus on Risk, Capabilities and Cost. The real goal is to assess, from a risk perspective, what we as an organization are getting ourselves into and how to integrate the target practice. How far off are their policies and procedures to ours? It was very important for us to make sure that all of the policies and all of the processes, along with the culture, are similar or at least similar enough to be able to integrate them at some point.
3. While at Rothman, we made the decision to convert every new practice into a single central IT system rather than allow for an ever-larger number of individual practice IT systems and respective EMRs, Call Centers etc. While the up-front work is greater the benefits in terms of systems management and expertise, with everyone in the organization being well trained in the one system, along with the benefits in capturing and analyzing data across the entire organization, were incalculable. The reality is that black-box data integration solutions that sit on top of disparate systems aren’t normally able to get you an efficient and satisfactory solution, and optimal reporting is too important to sacrifice.
4. The hardest integration challenge we faced was in converting prior call centers to our corporate 1800 number as patients were reluctant to make the shift. That necessitated a local call center interim alternative in most cases.
5. The ability to process data quickly and efficiently across our organization has allowed us to focus on the key strategic goals that we wanted to focus on and execute ahead of our competition. We have modified our patient care based on patient outcomes that we track carefully, adjusting if, when and how we use PT post procedure for better results. We have also saved significant costs by optimizing our sites of service based on patient risk stratification that is highly data driven.
6. When developing a data analytics program in your organization you can rely on the same core team but its important to reach out to subject matter experts and work in partnership with them when you design your respective programs as they will be the ultimate end-user, so physicians on physician data analytics, operators/administrators on practice management and so on.
7. The majority of practices and MSOs will continue to struggle to implement a strong data analytics program. There are so many ways to fall short of a high-quality operation and the majority of groups lack the expertise to build a program that makes a highly positive difference, so they chose not to build at all.
The recently launched SCALE Data Analytics/Business Intelligence unit will be focused on helping these groups realize their goals.
Intro To Lancer Seaman
I’ve been a healthcare CIO for a little over 30 years, and about 15 years as head of security at multiple organizations. I originally
went to work for one of my sales clients, Innovative Health Systems, I moved from sales to software development. We sold that company to 3M, and I went to work for a group called Practice Management Partners, which was really an MSO. We managed a little over 60 medical practices across the country. Some very large, 40, 50 locations. Some small, one or two doctors, but all had the same problems. They needed somebody to manage their IT, they needed billing, and they needed assistance in how to run the practice efficiently because they were doctors, and they wanted to focus on the patient. We later sold that organization off to NextGen Healthcare, the EMR vendor. And I was there for about four years and then left to go to work for Rothman Orthopedics. So I left the software development side and then went to the heart of where medicine is practiced, to a medical practice itself. Rothman, when I joined, had about eight locations. We expanded that to 42. We tripled the size of the organization in five years and did a lot of really, really fun things. We built out an entire platform based on the data, pulling data from multiple different sources, and eventually sold that part of the functionality, marketed it, but did some great things as far as optimization of the organization. I left Rothman about eight months ago and have been working with SCALE ever since.
How does the Rothman IT platform differentiate itself from other MSOs?
Physician burnout is one of the key things in the industry right now. It’s one of the things we talk about a lot. How to make things more efficient for the physicians, take less time for them. Our primary goal in the IT department was to ensure we never added time to the physician’s day. When I joined Rothman, Dr. Rothman pulled me in his office and he drilled into me the fact that he sees 40 to 60 patients a day and if we added one minute to any of those encounters, that’s an extra hour that he doesn’t get to spend with his family. Everything that we did, whether it was a new platform, policy or process, was all focused around the physician – how to optimize the systems, to assist them as opposed to requiring more time. That could be implementing software in the call center to automatically answer calls and assist the patients, or from a physician’s perspective, that could be using AI technology in the background to generate reports, pull information and present it to the physician. Everything we did was to optimize the physician’s experience so that they could spend their time with the patient, as opposed to spending time with technology.
How do you approach IT due diligence as part of a new practice acquisition?
My job was to evaluate a target practice’s technology program, including the IT team. We had someone else who was responsible for reviewing the remaining operations – how long they spent from a front desk perspective, how they handle patients, how quickly they could process patients, how many patients per hour, etc.
From a pre-close IT due diligence perspective, I looked at three themes: Risk; Capability; and Cost. Within those three areas, we
looked at people, process, and technology.
From a people perspective, we wanted to see how many people they had in IT. Do they have the right number? Do they have to many? Too few? Do they have the right knowledge? And then from a risk perspective, do they have redundancy of that knowledge? The majority of the practices that we would go into would only have one or two people on the IT team, and there was often very siloed information. The challenge is that any time there’s an acquisition, there is always a risk of people leaving the organization. We wanted to make sure that if those individuals left, there was knowledge within the group to be able to continue to run and operate. The IT people typically know where the skeletons are buried, so our job was to try to get that information and get it quickly.
From a process perspective, it’s do they know where their assets are? Many practices we diligenced would say, “Oh yeah, our old EMR it’s sitting under Suzanne’s desk,” which is never a good thing from a data perspective. Do they know where their assets are? How secure are they? Do they have redundancy built into it? And then, how do they manage them? Are personal devices allowed onto the network? And then, also from a compliance perspective, are they HIPAA compliant from a connectivity perspective? Are they emailing and texting patients directly? How do they protect their data? Do they encrypt it? Do they know where their data is – all of it, whether that’s in the cloud or local?
And then, we would look at business continuity. If something failed, would they be able to continue to run the operations throughout the day. From a disaster recovery, if something happened, malware event or something like that, would they be able to recover? And how long would that take?
Our real goal was to assess, from a risk perspective, what are we as an organization getting ourselves into and how can we best integrate what they have with what we have?
How far off are their policies and procedures to ours? Some practices that we met with, their policies and processes were very, very different from what we did, and they chose to not adopt our policies. Anytime that would occur, we would simply pass on the opportunity with that organization. It was very important for us to make sure that all of the policies and all of the processes were similar, or at least similar enough to be able to integrate them at some point.
How accurate was your forecasting on the difficulties of integration from a timeline, cost, disruption, perspective? How accurate was that forecasting as it related to EMR integration, practice management, billing integration, cloud, data storage integration, call center integration, and other technologies?
Early on, when we had not yet acquired a significant number of practices, there were challenges. The first acquisition was rocky, the second was much better. And by the time we hit the third acquisition, it was incredibly smooth, and we were able to move forward very quickly because we knew what to anticipate. Some of the things that we learned along the way were with regard to making the choice of do we integrate them or do we allow them to stay on their own platforms.
What we found to work the very best and to optimize the practice as quickly as possible was to shift them entirely off their old systems and bring them onto our systems.
From an IT perspective, we were always looking at cost and capability. Anytime you have multiple systems in the environment,
there’s a tremendous amount of cost involved with that. You have to have people that understand those systems, people that can manage those systems, people that know how to operate and work them, maintain the infrastructure underneath of it. We that when we would bring a practice onboard, we would switch them entirely onto our systems. That created a tremendous amount of efficiency – we were able to build our team of subject matter experts that could move in and train everyone on how to move on to our systems. It created efficiencies within the policy and process perspective because everybody would move into the policies and processes that we knew were efficient. And then from an analytics perspective, immediately, all of the data that we relied on from an operational perspective was there, present and ready, so it made things significantly easier.
The biggest challenge we had with our integration strategy was the call center. Rothman operated off a centralized call center, and many of the practices had developed relationships with the patients. The patients were used to calling the practice, getting through quickly, and talking directly with their nurse or whomever. That was a challenge because it became much more difficult to replicate this experience going through the centralized call center. We eventually developed a model where we would have our main call center using our 800 number, and then at least for the first year or two, we would develop a more localized call center just for that practice. There were a lot of reasons for that. Probably the biggest one was phone numbers. And if somebody’s doing an outbound call from a doctor’s office, if they don’t recognize that number, or at least see that it’s a local number to them, they won’t answer the call. We were losing a lot of patients and a lot of interactions, as well as experiencing a lot of inefficiency because the telephone number was a main 800 number as opposed to a localized number. And since the patients weren’t familiar with that, they simply wouldn’t answer the call. By developing those localized call centers, it significantly helped the practice integrate over the first couple of years.
How accurate was your forecasting on the difficulties of integration from a timeline, cost, disruption, perspective? How accurate was that forecasting as it related to EMR integration, practice management, billing integration, cloud, data storage integration, call center integration, and other technologies?
Early on, when we had not yet acquired a significant number of practices, there were challenges. The first acquisition was rocky, the second was much better. And by the time we hit the third acquisition, it was incredibly smooth, and we were able to move forward very quickly because we knew what to anticipate. Some of the things that we learned along the way were with regard to making the choice of do we integrate them or do we allow them to stay on their own platforms.
How do you think about IT business intelligence, the entire spectrum of IT and data in the context of strategic discussions in your organization?
While at Rothman and Practice Management Partners, data pretty much ran the organization. We quickly realized that there were
no systems that would be able to support the analytics needs that we had. At Practice Management Partners, for example, we started off with the policy that all of the practices would remain on their own systems. Again, inefficient from a people perspective, and it just became very difficult to get data. We spent a lot of time building what we called the black box. The black box allowed us to ingest information from the practices – whether that was billing information, patient visit information – and create a package. We had an account manager for each practice that would then meet with the practice on a monthly basis and go over those numbers. The problem with the black box solution was the data was disparate from the different systems, and so it became very difficult for us to manage and determine where the performance remediation needs lay – was it in the system, or in the data or in the actual operations? We decided that it was going to be better to bring everybody onto a centralized platform. We worked with GE Centricity at the time, and we deployed that program to all of the medical practices for free because it saved us so much money on the back end. The key thing a standardized system gave us was consistent data. So regardless which practice the program was deployed to, the data was always the same. The analytics were always the same. And so we were able to go in and really help the practice optimize everything from operations to billing and collections. From my perspective, data is really the key to any medical practice.
Do you have a bias in terms of the sequencing of building data analytics solutions based on department function? From RCM to Finance, to Marketing, down to Patient Care-related data, Population Health analytics, and ultimately, data impacting patient behavior, so patient-facing applications. Where do you start? Where do you finish?
I think that differs from practice to practice. Some practices are more efficient at revenue cycle. Some are more efficient at other things. We began our journey with analytics with regards to physician outcomes. The reason why is because Rothman dealt a lot with trying to change behavior of their physicians and bringing all new physicians up to speed with the quality that we had with the rest of the physicians. A key concern of the physicians, when we decided that we were going to grow, was how do we ensure that the new physicians that come in are really at the same level as what we’re doing? We began the analytics build specifically with this in mind from the physicians’ perspective . We had a great tool that we had helped develop for gathering outcome information. For every patient that came in, before they were seen by a physician, we collected HOOS and KOOS and several other scores. Then, if they were a candidate for surgery, we did it at the time of surgery. And then for example, with a shoulder surgery, the patient would take that same series of questions at three months, six months, a year, and two years. We were able to quickly develop outcomes data and be able to say, for example, what kind of a patient is best for surgery and which patients are most likely to have reoccurring problems. From a physician perspective, the outcomes data allowed us to be able to evaluate which physician costs the least or has the best outcomes in the shortest period of time. Then, how do we take the outliers and train them based on how the physicians who performed strongly were operating? It quickly allowed us to optimize operations from a physician perspective, which then optimized the outcomes for the patients. And, that’s how the company built the reputation that they have of achieving incredible outcomes. I’m personally a patient of Rothman. I had my shoulder replaced, and my shoulder had bothered me for 20 plus years. My shoulder is better than it ever was. In fact, it’s better than the other shoulder. And I got to that point within three months of having my surgery. The only way that came was by being able to watch and see what exercises would work best, how much PT is required, what types of implants are needed and how best to handle the overall care. And here’s a perfect example from a cost perspective. Most orthopedic practices, when you have a shoulder replacement or any kind of a replacement, they’ll put you into physical therapy for whatever the maximum length that your insurance will take care of. I never went to any physical therapy whatsoever. Rothman, through this whole process of being able to evaluate the data, determined that physical therapy was insignificant in driving the overall outcomes. They gave me three exercises to do at home five times a day. I did those, and I’m every bit as good as anybody could be. I have almost one hundred percent utilization of my shoulder. So that’s the kind of decision-making and process improvement that comes from data. From a perspective of prioritization, that type of outcomes data was what was important to Rothman. For a practice that may be struggling from a financial perspective, taking a look at the RCM may be the first step. It’s really individually based on each practice and what their needs are.
Similarly, we determined early on that cost containment was a major focus. And as insurance companies continually came back trying to get us to cut our rates, we had to look for other areas in which to generate income. We were able to work out a shared savings program with our payers, such that if we could prove that we saved the insurance company money, they wouldn’t cut our reimbursement rates. That led us down the path, again from a data perspective, of determining how to maintain the same high level of quality for the patients while simultaneously reducing cost. We started looking again to our analytics platform to analyze where the costs lay with regards to every surgery. What we found is that if we went to a neighboring hospital, a shoulder surgery would cost $40,000. If we performed that same procedure in our own specialty hospital, the cost was $20,000 – same doctor, same nurses, same implants, same everything, simply a difference in cost of location. And that was a huge revelation for us.
What we decided to do was risk stratify all of our patients to determine which patients need to go to the high-cost facility and which patients can we shift over to the low-cost facility. And we did that by creating a number of scores. One was a social risk score, and the other one was a medical risk score. For the social risk score, we would talk to the patient and find out do they have pets at home? Do they have rugs? Do they have their bathroom upstairs? Or is it downstairs? And then from a medical perspective, what co-morbidities do they have? Are they diabetic? Are they overweight? Are they on other medications? And then, through our quality team, we generated a score for every patient. When the physician met with the patient prior to surgery, they had the two scores there, and they could say, “Okay, you’re a candidate to go to our lower cost facility, so we’re going to send you over here.” And that was a huge shift for the organization because the physicians had built relationships with the hospitals, they liked working there. But from a cost perspective, we were able to save millions of dollars per year.
I think the outcome was somewhere in the neighborhood of about 10 to 12 million dollars per year simply by shifting from one location to another.
No other change. Simply by doing that. We were able to then approach the insurance companies and say, “Look, we’ll split these savings with you so lets dig deeper into our value creation opportunities.” And they were more than happy to do that. And that’s the model that Rothman operates on now. Of course, it didn’t make the hospitals very happy because we were pulling patients away from them.
In your experience, did you migrate from one department to the next over time? How much complexity did you face as you went from a partial data-related business to a complete comprehensive data-driven business?
We began, like I said, with the physicians and their outcomes. And from there, after they saw the value of the data in that area, we said “Okay, where else can optimize?” And again, Rothman is a very physician-specific and focused organization. And so rather than go to revenue cycle, because they were financially strong, they had no problems from that perspective, they then shifted to operations.
All of our analytics then began to look at how much time physicians were spending in operating rooms? How efficient are they from a patient perspective when a patient comes in? How efficient are we at getting the patient checked in, into the room and ready to go? And analytics played a huge part there. One of the interesting things that Dr. Vaccaro did, and he actually published a study on this, was that he found that if he could get to the operating room early in the morning, say 5:30 in the morning, his ability to perform surgeries increased significantly. He could perform significantly more surgeries the earlier that he started. The reason for this was that when you’re at a hospital, specifically as the day progresses, they get busier and busier. And so time being pulled on those resources gets more intense, and so they don’t have enough time to focus on getting the rooms prepped, cleaned, and ready for the next patient. We were able to get information from the hospitals, pull that into our analytics systems and then make some significant changes with regards to when our physicians schedule their hospital surgeries.
Again, going back to prioritization, Rothman’s focus was on the physician. So we started with the physician - how do we optimize the physician experience? How do we optimize their time?
Then, we went to the operations team, and then from operations into x-rays and other areas. And actually, RCM was the last bucket that we tackled.
Did you use the same internal team, the same external teams to process and analyze this data? Or did you use different individuals depending on whether you were focused on RCM data solutions or population health, patient outcome solutions?
The team that built the visualizations, built the database, and worked on analyzing the data were the same individuals. We would bring in subject matter experts from each of the functional teams our analytics team partnered with. For example, when we were talking about the physicians and what they needed, we would bring in several physicians, and they would help us as we designed what was being shown. Because in our minds, as data analysts, things that were important to us were not really that important to the physicians. They didn’t care about the way things look. They just wanted the bare numbers and very specific numbers. As we moved into operations, it was important to bring in the subject matter experts. In our case, it was the office managers to determine how to best assist them. How do we bring in patients faster? They told us the milestones of where things needed to be. We built out a whole analytics platform around quality. At that point, we brought in the subject matter expert of our quality director, and she laid out a great plan as far as what they needed to see and how they needed to see it. But the backend team always remained the same.
Why is the medical industry slow to adopt what you’ve described, which to me is incredibly useful, brilliant, and seems almost calm and sensible? If you were Microsoft and develop the operating system, you could then broadly get lots of people to use the system. In other words, how do you scale it?
We recently launched SCALE Data Analytics. Our mission is to help scale this across organizations. But, what seems logical versus what’s deployed in a practical sense across thousands of organizations often reveals a massive gap between A and B. What are the reasons for that? Lack of time, lack of trust, lack of access to expertise and resources, failed experiments that delay successful experiments, in many cases indefinitely. You also face legacies of overspending on IT, underspending on IT, subpar IT implementations that generate ill will because physicians now have added burdens. The complexities of any one of these initiatives – there’s so many ways to get this wrong.
Rothman always went on the premise that they wanted to share the information. Almost on a monthly basis, we would have other large practices come and visit us – everyone from Advent Health to other large hospital groups and hospital systems, other medical practices. Rothman would spend an entire day hosting them and showing them all the secret sauce. We’d show them all of our analytics. We’d talk to them about how we did things, how our operations worked. When I first started there, I asked our CEO, “Why are you willing to give up your secret sauce in all of this?” And he said, “Because they can’t implement it.” And it was true. Over the course of the nine years that I was there, we did probably 50 or 60 different demonstrations to large groups. They would come in and watch our physicians. And then, they would leave and go back and never be able to make the change. And the reason why is they just didn’t have it within their organization to be able to make that happen.
Rothman was organized in a very unique way. We had, for lack of a better term, a VP of the Physicians, and he ran the physician team. We had our administrative staff who was run by our CEO. By keeping those two teams separate and yet highly collaborative, we were able to accomplish a lot of amazing things because the physicians drove the physicians and the administrative staff drove the administrative staff. In most organizations, you don’t have that ability, and so making change is very, very difficult. For us, we could come in one day and say, “Okay.” And this a great example – our marketing lead came in and said, “Based on the research that we’ve done, we can see that if somebody has a four and a half star rating, that they are five times more likely to be chosen than the next comparable person.” And so our goal became to get every physician up to four and a half stars at a minimum. And we tracked that on a monthly basis. We had our director and leadership team meetings, and in that meeting, we had the marketing team update leadership on where they were with the initiative on an individual physician basis. We knew at any point in time which physicians scored low, which physicians scored high. When a patient would come in, we would hand them an iPad, click the button, have them log in to any of the rating sites and have them give the positive ratings. We informed the physicians about it. The physicians then began to drive it within their team organically. Within a period of about eight months, we had the majority of our physicians scoring at least a four and a half stars – I think there were only two that remained as outliers.
How does IT strategy and the topic of IT integration change, if at all, if you’re thinking about larger organizations acquiring other large practices, each with entrenched cultures, histories and established preexisting teams that are sophisticated in and of themselves?
And a sub-question to that - a key to data analytics that you mentioned was systems standardization, can you talk about whether there an option of getting to value add analytics without systems standardization or, from your perspective, is that too high of a hill to climb and it’s unlikely to yield something valuable?
From an IT perspective, anything can be accomplished given enough time and money. The question is, do you want to expend the time and money to achieve that particular goal? When we looked at it, integrating systems, again, every time you add a system to an organization, there’s cost from a licensing perspective, there’s a people cost for managing and maintaining that, and there’s an infrastructure cost to be able to support that, whether it’s cloud-based or whatever, there’s still a cost associated with it. Trying to be as efficient as possible, we had specific targets with regards to overhead. Our target as a business was no more than 32% overhead. So in order to achieve that, being able to just integrate systems really wasn’t that feasible. You can take the data, you can transform it, you can bring it in, we could make it work, but the reality was how much effort did you want to put on that versus do you want to be able to put that effort and those resources into building the business? So it then becomes are you going to scale the business just to run the business? Or are you going to use those resources to build it? And our choice was to build it. That did not come without some challenges, of course. In meeting with the practices, that would require them to change significantly. Mostly from a staffing perspective, many of the practices that we met with had to completely change the way that they handled staff and the number of staff that they had. Each physician no longer had two or three extenders. They had to be able to justify that. MAs were then shared across everybody. From a cultural perspective and from a data perspective, it just became much easier to have everybody on the same physical platform, the same policy and process platform, and the same data. Again, we could have done it differently, but every time we tried to, it was just far more expensive and more work than it was really worth in the long run. As we evaluated a practice, they were able to come in and watch all of our physicians, see how everything happened. Because we’d gone through it before we could show them, “These are all the changes you’re going to have to make. Are you willing to make these changes?” And again, we left deals on the table.
But everybody that came in, six months later, everybody, every single person, every physician, without question said it was the best decision that they’d ever made. They were earning more, working less, everything was much more efficient.
They had more time to spend with their families. And really, from a medical practice, that’s what drives growth, right? If the physician can make more, not have to do any more work and continue to grow, that’s what’s going to drive a practice.
In your experience with these solutions, have you seen a lot of high initial capital commitments or capital commitment requirements? Or have you been able to, with your expertise, start projects on a very small scale in order to maybe demonstrate to yourself on something untried, untested that you can really break-up value creation into increments versus log function or step function increments?
I think one of the challenges that a lot of practices make is they go full force into things and invest a lot of money only to find out that it really didn’t give return on investment. One of the things that I always do with every implementation, regardless how large
or how small, is we do a proof concept. For example, we wanted to be able to have the physicians log into the EMRs quicker. We wanted to deploy the ability to have a card tap in, tap out. We did it with a small group of physicians first – I think there were 15 from the different subspecialties. What we found right off was they would leave their cards at home, and so we’d have to give them temporary cards, which meant we had to have the office manager have spares, which really then did away with the whole benefit of security and everything else. From a cost perspective, rather than spending $350,000 immediately and deploying this throughout the organization, we always do a proof of concept across a broad area. And we found out quickly that didn’t work. We then switched to something that they can’t lose or can’t leave at home – and that
was their thumbprint. So the physicians would simply walk in, use their thumb to touch a button, and then that would automatically log them into the computer. That was much more widely adopted. The physicians thought that it was a much better solution long term because they didn’t have to worry about losing anything or forgetting anything. They didn’t leave it over at the hospital when they had just done surgery, and it improved their ability to log in. From a security perspective, it helped. From a speed in logging in, they were able to just put their thumbprint down, turn right to the patient, again, talking with them while the computer booted up.
