SCL Health - Is There a Doctor in the House? - Inspire 2017

From practitioners to procedures and insurance, healthcare organizations have many systems, most with complex data. SCL Health is using the power of Alteryx to join and analyze patient data, payment data, insurance data, and more, from many sources — a data lake in Hadoop, Excel spreadsheets, and SQL databases. Join to learn how self-service data blending is helping SCL Health to address multiple use cases including:

  • Analyzing and reporting on patient outcomes to track doctor-to-patient attribution over time
  • How payment models have drastically changed, moving from a fee-for-service model to a value-based payments, where care outcomes and patient satisfaction now determine how much a hospital gets paid for procedures
  • Building a current-state and historical doctor master index that is automatically dashboarded, to track operating room set-up customized to each doctor


Video Transcription


Speaker:
Okay, I think we're ready to get started. Welcome to the session, "Is There A Doctor In The House?" Joining me today are two analytic architects from SCL Health, Cynthia Tamayo and Brenda Fosmire. What they're going to talk about today is how they're able to take multiple types of data, from patient data, payment data, insurance data, from multiple sources, whether it's in a data lake, SQL databases, Excel, join those together to track doctor to patient episodes. With that, I'm going to turn it over to you guys.

Brenda Fosmire:
Okay, great. Can you hear me? Good, okay. I'm Brenda Fosmire, and I have a background, I started in economics and banking, and then I got interested in software and got trained as a software engineer, and then since then I've been in healthcare data, and I'm a certified health data analyst. At first I want to ask to help[ us, raise your hand if you work with healthcare data, if you're familiar...

Cyndi Tamayo:
Oh wow.

Brenda Fosmire:
The audience, buddies. Okay great, that helped us very much. Also let us know, have you been using Alteryx more than a year, or are you new? More than a year? All right. Okay good, we'll try to get into some details. First let me let Cindy introduce herself.

Cyndi Tamayo:
Hi, I'm Cindy Tamayo. I'm fairy new to the healthcare industry. My prior background had to do with a couple of startup, small software companies, so I've had major roles as it relates to product development, sales, training, reporting. Back in the old days they said reporting, now it's analytics, so moving on into analytics. One thing I've found in dealing with healthcare data hat I've never had to deal with before is that it's very complicated data. There's lots of it, and you also have to worry about a lot of the protected data, the HIPAA stuff. For me that was kind of eye-opening, because I've never really had to be concerned about it as to who can see the data and who can't see the data. With that, I'm going to go ahead and take it back.

Brenda Fosmire:
The way this is going to go down is, I'm going to tell you our more complicated use case, and I'll do that, and then at the end Cindy's going to present one of her solutions she gained from our process of working with provider data.

Cyndi Tamayo:
You guys didn't realize you're really getting two for one today.

Brenda Fosmire:
Yeah, we're two for one. All right, next slide. First of all, SCL Health. I really enjoy working for SCL Health. I'm really dedicated to them. My husband has worked for them as a provider, he's a physician, he's worked for them for like 26 years. My son works for them, my niece works for them. Anyway, I'm pro SCL Health. It's an organization that is multi-state over Colorado, Montana, and Kansas. It is faith-based, originally a Catholic-based organization, and nonprofit. We're getting there, $2.5 billion net revenues, and we're very charity-oriented.

As a nonprofit we give every year, every year it's over $200 million, away, in care. 11 hospitals. About eight of those are large hospitals, and they may have a few smaller hospital environments as well. Of course our span of clinics, what did I put there, 210? We have a lot more than 210. It's probably closer to 300 clinics right now. Then, we do a spectrum of care. We do some mental health, we do hospice care, so it's a large mid-west organization housed out of Denver. 18,000 employees.

The SCL stands for the Sisters of Charity of Leavenworth. Way back in the 1860s the nuns came across the prairie, they stopped in Kansas and started hospitals, and then they stopped in Denver and started hospitals, and that's our roots. What is it, two thirds of people who were born in Colorado were born in one of our hospitals, so we're very planted there. All right, that's SCL.

One last thing I should say is, we get the Most Wired Award very often. Three of our hospitals are very new and very technology based. Both Cindy and I work for departments that have innovation in the title, and we're really working towards pushing healthcare to the next level. Now Cindy's going to tell you a little bit about our data organization.

Cyndi Tamayo:
We're a fairy new department, so approximately 18 months ago they hired our director for our analytics development, that the company decided that we need to get out of the report writing mode and move into the data analytics, just where healthcare information was going. The way we are structured right now, we have 11 employees. The last group were our solution analysts that were just hired ... Or, not hired I shouldn't say. We transitioned over onto the team. They were considered Crystal Report writers, and so we inherited them. We're trying to redefine their roles to be more solution analysts. How can we solve the problem? What's the analytical need that people are asking, and how do we address it? Transitioning to kind of what we saw in some of the keynotes to get more into the realm of analytics.

I'm going to have a hard time, because I'm going to walk down there, but as you can see I did a wonderful thing where I walked the strip and pulled my knee. The green center is kind of our central hub of where we are sitting, our team is sitting. Ideally what we want to be able to do is partner with our business units. We're trying to establish, who are some key people, and as we found out in the last two keynotes, the citizen data scientist is like, that's perfect. That's how I can label this now. But all the little bubbles around it would be our key data scientists, or citizen data scientists, that will be in our business areas, so that they will be the focus for those areas, because they know the data best. It's still going to have a dotted line back to our team so that we can be more, what do I say, be more cohesive, and be able to share knowledge and workflows and standardizations and all those type of things. We are not quite there yet. We only have, I would say, right now about two different business units where we feel that we have true technical ability to classify them as a citizen data scientist.

Brenda Fosmire:
In fact Cindy and I were kind of thinking next year we can come and talk about the culture change for us, because we went from zero Tableau users to about 200 tableau users, and we didn't even have Alteryx a year ago, and we think by the end of the year the plan is to have 60 Alteryx users. We're going to build that community too.

All right, let's get onto the topic of provider data. Fundamental healthcare processes are very dependent on knowing who the doctor is, who the provider is, and being able to link that. I'm referencing here this report. "The healthcare industry spends at least $2.1 billion annually working with provider databases." This report by the CAQH is a really good report that I found, it's a white paper that goes into good detail on, what are the issues with provider data, and why are we having these problems. Since so many of you guys are healthcare, it's not just our hospital's problem, we all share this problem.

Let me just, for those of you who need an explanation, there's a few places where we're breaking the system. We know in the last few years that we've lost millions of dollars because we couldn't link a doctor or somebody to the right claim, or some other process. Let's say that you're a patient, and some friend told you about a great doctor, so you go to the internet and you're going to look that doctor up. You should find them, but you might not, or you might find them, or they're at the clinic they were at three years ago, saying they still work at that clinic. Or you can't link into it and get right to an appointment. This is something, our electronic medical record is Epic, and we're really working, and we've really made progress in getting that. We have the MyChart going well and so forth, but the final linkage of where that doctor currently practices, who's employed providers, who's not employed providers, has really been a struggle.

Then another type of break point for this is, let's say you call, you're going to make an appointment with a new doctor, and you wisely check with that doctor. Do you take my Cigna insurance? The person at the front desk says, "Oh yeah, we take that one." You go, you have this appointment. Well then, when the process of the billing comes along, come to find out, subplan BC Cigna 123, they don't take that one. That was because in Cigna's provider database the attestation broke. They didn't flow down. The doctor went through the application to attest to that insurance, but somewhere either in your systems database or in Cigna's database, one subplan contract didn't get this doctor's NPI number in that record. So, money lost. Either the patient ends up not getting this covered and having an out of pocket expense, or the provider or the healthcare system doesn't get paid.

Then another example might be a hospital stay, and so there's the admitting physician, there's the attending physician. Two residents saw you, three consultants saw you, then there was a reference to a referring doctor, and then there was a discharging physician, all in the medical record. Now, how are we going to say the primary... This is provider attribution because you're mostly healthcare. How are you going to go make that algorithm and make all that linkage correct, to say that the doctor that saw you the most, who wrote the most notes in your record, got the quality score, got the outcome attributed to that? This is a breakage for us as well.

Then there's health information exchange. This is the government program where we've been incentivized to make connections. You're out of town and you have an appointment outside of your normal network, and then you go back to your doctor in town, they should be able to pull up and pull that information in. We had this working like 80% of the time, but then some doctor's address in the electronic health exchange is incorrect, or is out of date, or somebody moved and it didn't happen, and they can't pull up your record. We lose points with CMS with that for meaningful use type data, plus it's just something we ought to be able to do. Keep this more up to date.

Then maybe the last thing to mention would be quality scores. How are we going to attribute this outcome to this facility, to the seven doctors who were in this case and so forth? Quality scores are another very complex piece of this.

Add to all of those types of breakage scenarios the new paradigm where it used to be fee for service, and now it's value-based payments. Used to be the doctor did seven things for you, there were seven charges, the bill went out, and you got paid. No more, and as all of you, we're preparing to move into this new paradigm of value-based outcomes, but it's not just the outcome of our care site. It's that care site by that provider. We're held responsible for the provider's quality scores, and there's kind of a tension in that relationship between the provider saying, "Those aren't my seven patients that you told me I didn't do a good job on." It could well be that our provider data error is causing that problem, or some other little subtlety about how it's attributed.

Then add on to that the bundled payments model. Let's say one of our facility does 60 to 80 knee jobs every month. Say you want to have a new knee, and your Medicare is your insurance. You will have a few pre-operative visits, then you'll have your stay in the hospital, and you will have a great surgical experience, be out in three days, then you're discharged with some rehab appointments and then some followup case management appointments. In the bundle payments model the facility really doesn't even get paid six to nine months later, when we can bundle together six to nine months ago's knee procedures, quality score them, make sure we've met the base metric, and then get paid. This becomes a really data-driven need to be able to track, and also to say, on seven knees we lost what, two percent of the payment, a couple thousand dollars or so, just because the case manager couldn't find the patient's phone number and the doctor didn't do a followup call. Everything else in that environment was great. Little types of disconnects like that can end up being a real loss in our quality.

Then we have to talk about the definitions of a provider. In my world, I usually think that you're a provider if your profession requires some type of credentialing or licensure, or you're somebody who, quality scores are part of your assessment. These people are not our employees, often they're not our employees, and in that way I always think, if they bill for their services independently, then they're a non-employed provider. These providers also work in many different environments. They might work in three of our hospitals and two of the cross-town hospitals who are not our facilities. Then how do you attribute quality scores and things to that cross-city type of access?

Now bring in the allied health professionals. A provider used to be a doctor, and now it's a surgical tech, a diabetes educator, a nurse practitioner, a pharmacist, so forth. This definition, and all keeping up with who's license is up to date, who's in good standing with the state DEA, it becomes a really critical process for just knowing where all these entities are.

Then there's the fact that a provider is often not a person. It also can be a facility. This becomes a complication or a confusion for many providers. All right, next slide.

We do have the National Plan and Provider Enumeration System, and all doctors, all providers, of a certain class are required to have an NPI number. But there are real problems with the NPI. I love this study I came across where NPPES itself did an assessment of their records, and found that 48% of the NPI records are inaccurate. As you know, it could be that when they applied for the number they thought they were applying for a personal NPI, but they got attributed as a facility NPI, or the doctor got their NPI post medical school but that was 20 years ago, and the address is still that cranky apartment they lived in in med school. There's no incentive in the system for the providers to keep this data up to date.

I have talked to a couple care sites, or facilities, who at re-credentialing, are bold enough to ask the provider to go and update these records, but most of us have a culture at the hospitals where we don't want to in any way ask the doctor to do more than they want to, to keep these type of data driven things clean. Either we just don't have it correct, or we will actually go and correct it sometimes for them.

At the very bottom of this slide, in 2013 the OIG really did an in-depth study about, one of the top management challenges for health and human services is provider data, so it's a big problem.

Now I'm going to bring it down to our facility and our system. In the center there, with the electronic medical record, just imagine that those three databases are greater than 200, maybe even over 300 different systems, that are directly involved in the patient care experience. In all the ways, each one of those products have a different way that they assign a doctor at provider key. Some of them use social security numbers of the provider, some want the NPI but that could be wrong, so they apply their own internal key.

That's crazy enough, but then the blue systems out around here are very important. The credentialing database, credentialing and privileging database, I'm sure some of you use Cactus, this is the credentialing of providers, keeping up with their licensures and review and so forth, is very complex, and I don't think there is a great, perfect credentialing database out there, but managing that is critical to the whole connectivity across these systems.

Then below that the insurance and payers and plans, and you can add to that. The accounting systems and even the cash management systems, where we need to track income by certain employed providers and so forth. Those do not share the same unique keys that the credentialing databases do.

Then in the upper right there, the HIE system is something, we invest a lot of time in this database, and trying to interface to the national clearing houses for these things, and getting data back and forth and saying, "Hey, did you know you haven't cleaned up these doctors in five months and these are all out of date," and communicating. It's not as interchange-y as it should be, it's much more human driven.

Then really important is the quality scores. With the Leapfrog or some of the other public-facing, the customer, the patient, should be able to log in and look up a provider or a facility and see a score, but if we can't even locate them to that we can't do that. It's a real loss for the consumers to not be able to see transparency about who's the best person to go see for what you need to have services for.

Here's the approach we took. I started this about nine months ago, and we call it the Provider Master Index. I could not have even gotten as far as we have without Alteryx. The project started, I got Alteryx, and I immediately said, "I can do this." What we're doing is, we're using Alteryx to hit all of these other key ancillary systems and make an index of all the different provider keys across all the systems.

The purple up there, the wide Provider Master Index, is really two or three different files. One of them I call just the provider master, and what that is, is I have a flat file that basically gives you key information about that provider, like their name, da-da-da, and then where their practices are from the different systems. It says, in Cactus it says their primary practice is Main Street, but in our Epic system their primary practice is Yarrow Street, something totally different. I capture all that so I can show it to the people in the different work areas so they can start to clean this up, but I'm trying to make a flat file that then we can put in Tableau and some other things to make a dashboard of, which doctors are where. This runs through Alteryx' server every day, and I output it in many different formats.

The next piece of this is what I call the index piece of it, and that is where I'm just logging changes. This provider had a change in practice, they had a change in, are they employed with us. Some doctors might be employed with us for a while, they're still credentialed at our care sites, but they decided to go join a private practice. I need to log this because I need to change their quality score metrics as they move in and out of our system. For the index piece I'm just tracking changes, so it's your basic log, with here's the date the change happened. Even that is fairly complex, because which system is my system of truth? Is it only when the change got into Cactus, or do I log it the day it got into Epic or some other system there? I'm just tracking them all, basically. I end up with two really large files.

There's one other piece that we're doing with this, which, again, this is not 100% done, but I am loving where it's going. We're calling this continuous quality improvement reporting. For certain key fields, which seem to get out of sync, because for some reason our interfaces overwrite something, someone goes into Cactus, changed something about a provider, and then some Epic file comes in and overwrites it. It's like, okay, we lost the chain. This kind of seems to loop around. To help clean this and help to expose where our interface is broken, we've made a lot of improvement but it's not quite as tight as we want, we're starting to make reports that, for key targets where we think things are getting out of sync, we're running a report, and then it's emailing itself to the key players of where those changes could've occurred. From that we've started having every other week meetings to talk about, why did something get out of sync, and what is the source of this problem? Because sometimes it's a process error, and sometimes it's an interface error or something that's going on in Epic.

Continuous quality improvement reports to focus on areas, and we are going to just keep those running. Maybe instead of daily they'll go down to weekly, and it's going to say, "The practice name in this system doesn't match this system." It's going to output just the mismatches and send it just to the people who need to fix it. That's now automated. It's beautiful to be able to do that in Alteryx, where once we get it figured out what are the key, you've got to be able to get everybody to decide what they want to focus on to clean up first because there's so many choices, building those reports is a simple process.

One of the other things that has been really important for us about the ability to do this is all the different data types, or system, or databases, that we're interfacing to, is a breeze, which would not have... This is basically the part that would not have been easy to do without Alteryx. We have our Oracle connection, we have direct SQL Server connections, a lot of just files where people are running reports and dropping files, and I have Alteryx just automatically just picking those up. Then we also do have a data lake, or a Hadoop data structure, and I really think that wasn't being useful, abut is really starting to mature now, and we're learning how to hit that group connecting directly tooth data lake with Alteryx.

We basically just dumped a compete copy of Cactus every night into that, because that allowed us to do some more sophisticated analysis of what was going on with our provider in credentialing data. Just the spectrum of data types all in one workflow, it's actually four workflows, but in such automated system, to make all those connections and join all this together, I just don't know how I would've done this before we had Alteryx.

Then, so in the middle there, we do tons of data cleaning. I should've made the formula tool there enormous, because there is so much data cleaning that has to go on. The different formats of the social security numbers, you have to take the dashes out for some, even just to get things to join is quite a bit of work.

Then, once you've done that work, you can output it in many different forms. There are so many different areas of the hospital system that needs to be able to look up a provider. We're outputting automatically, just dropping them in different directories. Some people still need a spreadsheet. A lot, we're really moving towards just outputting .tde files and letting the tableau users just connect to that, and then when they publish it's a live connection. It's been really efficient to use that Alteryx to Tableau type connection.

We've got the Alteryx gallery, and just in the last few weeks we've really started to have some different departments that can pick that up. As our Alteryx designer software users expands, this will be a place where they can just go and pick up provider data to do what they need to do.

I mentioned the Hadoop and the other outputs as well. All right, well every Alteryx presentation must have this picture, right? Ta-da! I'm going to go into some of the details here. Next slide.

One of the things, I wanted to build a flat file, and so I'm starting with relational data and normalized data in Cactus. We have, as many as one third of our providers are privileged at more than one of our care sites. In this workflow I'm using the summary tool and then rejoining and doing a concatenation to pull what would have been in three different tables into one field. If you'll look...

Cyndi Tamayo:
There's not a pointer.

Brenda Fosmire:
I need a laser pointer.

Cyndi Tamayo:
Do you want me to run over there?

Brenda Fosmire:
Yeah. Be a Vanna for me.

This little snippet is what my output is from this process that I'm doing in Alteryx. In the top row of the snippet it says EGS, SJH, and then it says Active, Active. What I did here was, EGS is our Example Good Samaritan hospital, and SJH is our St. Joe's Hospital. This tells me, on this one-row provider flat file, I can tell you where that provider is credentialed today, and I just concatenated it together. This tells me that the doctor who would belong to that first row is credentialed at our Good Samaritan Hospital and our St. Joe's Hospital, and at those hospitals they're active. There's just different variations of this based on our different hospital.

This helped me to compress this data down and make it much more usable. Within Tableau you want to go bust that back out, you can. This gave me on record where I got a lot of information that was a normalized process, that workflow there, and joining and flipping it with the summary tool is sweet.

Then, speaking of cleanup data, and you guys will like this one. In this first filter it says I'm trying to get to just what we call the mid-level providers. I'm using the filter tool to say, "If provider's type is APRN, da-da-da." Then the next one, would you believe that even though we have a test environment and a dev environment and all these types of things, that our primary EMR holds test data? I don't want that to end up in my provider master index, so if the NPI is 19999 or greater, because there are as yet no NPIs greater than starting with a two as a digit, I'm filtering those out. At least the test people, when they built bogus providers into our Epic system, they were smart enough to do that. We filter those out, and then taking out the doctors who just don't have an NPI in the system and so forth, and then in this last filter you'll see an example of this enormous contained statement I wrote. I love this one because we have test doctors of names like Dr. Duck Test, Dr. 1871, Dr. Midlevel, and so forth. This was a way that I was really able to clean up a lot of junk out of our data.

Next one. In the Epic system, in some of the user defined fields, in one field, using new line characters, there were 12 different data pts. Being able to use Alteryx, over here to the right I've shown you a snippet of what was written, but each one of those pointing-sideways carets was a variable that we wanted to capture that had been encased inside the new line for that record. It's a user-defined field, so forth. By writing this massive formula statement, and then just copying, pasting it, I think it's 13 times, it's 12 times, we were able to take what was really embedded data and flatten that out, and we made a new column for each one of these fields.

We have Kaiser Permanente as one of our major partners. Are they Kaiser? Yes, no? I've now got a field for that. What is their old Meditech pneumonic? I now have that. What is their Cactus ID? I was now able to bust that into its own column and so forth. What's their LabCorp and their Quest, so forth. This makes a really rich reference that way. For my downstream users to keep the data cleaner, they can now read this flat file very easily and say, "How many doctors are missing a LabCorp ID?" And there it is. Again, this big flat file, the Provider Master Index, has many, many uses. Go ahead.

I'm sure you're going to have questions about that, and we are getting lots of... This hasn't quite finalized yet. One of the last things we've really decided is that having an Alteryx type skilled person who is full time dedicated to our provider data is our next goal. Because I'm doing eight other things and doing this on the sly and figuring this out, and as they've started to see the value of this, the management ha just decided... I wrote up the job description, and it was like 30 things I thought this person could do full-time to really keep our provider data very clean and typed. We'll be hiring that person in the near future. Sounds like a great job. It sounds good. Then, we get daily requests for this data, and now that the word has gotten out, I just now have a feed. Because it's very, very popular data.

The last thing we wanted to do, one of the outcomes of having gotten this data more joined in this format is the project that Cindy was able to do, so she'll take over from here.

Cyndi Tamayo:
Just to reiterate of what Brenda just did on this, this is just going to gain us so much insight to our provider. The other thing we're trying to do is, how can we leverage it, and be able to give this to the rest of the company? This is another one that we're trying to put on the gallery. Let's put it on the gallery so people just can pick it up, so they don't even have to request anything from us, it's there, it's available, and they can use it whenever they need to.

Just curiosity, how many of you guys kind of are experiencing this type of issue and complication? Some of you guys can totally relate to this.

Brenda Fosmire:
Yeah.

Cyndi Tamayo:
My use case is slightly different. I came across a scenario with somebody that, I found out they were doing something manual, and I am so there to help you, because if we can automate it and streamline things, let's do it. Because I know I don't want to do anything manual if I don't have to. I don't expect others to do it. The minute I saw that it was taking this person about four to eight hours, weekly, every Monday, to pull all this data together, to stick it in an Excel spreadsheet, some pieces of it or a lot of pieces of it manually putting it in an Excel spreadsheet, to get some insight on what they're doing, I went, "Oh, no, no, no. I will help you. I will do whatever I can to get this somewhat automated." Because that to me is just way too much work.

As a result of this, what I did, I took two approaches. There's a long-term fix and there's a short term fix, and since we're kind of a new department, to do a long-term fix, it's going to take a little bit more investment and a little bit more time to really look at it holistically. I looked at what was being done with this current process, and how can I just take that process right now, streamline it to make it an automated process? I would never have been able to do that without Alteryx.

To go through my example, anybody familiar with OR procedure cards? Preference cards, sometimes called? This is the scenario that I came across. Basically when you're going into, and let's take Brenda's example of the knee replacement, prior to you going into the surgery, the doctor, at some point in the system, has set up what is called the procedure card, preference card. When they go in to do that surgery, they have already identified what instruments they're going to use for that surgery. Then prior to you going in for that surgery, there is what is a surgical tray that is presented in the OR so that they have all the equipment they need right then right there to be able to perform that surgery.

As a result of that it's going to be a little more accurate. Let's hope that when you go in for surgery they're doing exactly the correct knee and not leaving any instruments in your leg at all, but also saving huge costs. Because you know when you have a tray, or even when you go into the hospital, even if you're not using something that's there, you're getting charged for it. How can we reduce some of the costs back to our patients, as well as back to the company? What they were trying to do is look at, overall, what kind of waste do we do when we go in and do the surgery? Because sometimes there's instruments left on the tray that are never used, and that's cost.

I'm going to go through the comparison. Here's kind of what we were doing before Alteryx, and here's how Alteryx had helped us. As I mentioned before, it was a manual process, it was a little bit automated because we are using Crystal Reports, so we were actually having two Crystal Reports that were running, and we started to go down the path of using Webi Reports, if anybody's familiar with those, but we kind of transitioned and realized Tableau is a better solution. But they're still sitting there. That data that is coming out of those four processes... Two of them actually, the Crystal Reports, were actually doing subreports, so if anybody is familiar with that, subreports aren't that much fun. Out of those four different reports, they were already summarizing the data, so I didn't want to go back and try to recreate that because to me that's the bigger picture going back and reengineering it. I just looked at those reports and made sure they were in a nice format output. I took those reports, I let Alteryx read all the data that's coming out of those reports, blend the data, and be able to create two workflows that we're going to feed into Tableau.

The other thing, because of the volume of data, Crystal Report... Crystal is fine, but when you schedule the reports in BOE, sometimes when that data gets so big you get some weird things going on with the files, and sometimes the files just start putting garbage at the end of it. They had to split these reports up for each one of our facilities. At the time we had eight acute facilities that this is running for, so that's eight reports per Crystal Report that is scheduled.

That's a lot of them for them to sit there and go through. The other thing that they ended up doing when they brought it into, they were using Excel to put all this data together, when they brought it into Excel they were actually creating a tab for each one of those facilities. Now you can see the volume of manual work that was like, "No, we don't want you to have to do that.

Then lastly they were trying to do a sort of trending, so they were, like I said, doing this every Monday so that they could get a reflection of what the last week was, because there was no date stamp in there, so they had to look at what this looked like at a point in time. Again, it was all summarized, so there's no drill-down capability. Ideally what I want to do then is, at some point those two BOE Crystal Reports and the Webi reports will totally go away, and we'll make sure Alteryx connects directly to our database, and therefore be a little bit more efficient.

There's an example of the spreadsheet that they maintained. As you can see, they were actually manually entering the date for the week that these ran. All the facilities across the tabs on the bottom were in separate tabs, and then they were manually... In the Crystal Reports, because they were outputted as a CSV, they could cut and paste some of those numbers in there, but I don't know, it's a tradeoff, cut and paste versus just manually keying it in. I don't know. Then the other one, because of the way they designed the Webi reports, they really had to manually enter in all that data.

Then along came Alteryx. As I mentioned before, we were able to create two workflows to pull all that data together. One of the tools, it's kind of a boring workflow from the standpoint of tools you're using, but for efficiency's sake it was awesome. One of the tools I like that I didn't know about was the dynamic input tool. I was having all these reports right to directory, so I could just pick up everything in that directory and be able to merge it and blend the data level together. As a result, we created a TDE file. The way our organization is, we are trying to pass off the Tableau visualization to our business units. We want to empower them because they know the data, they know what visualization they are.

Now that team can actually pull in that TDE and create their own visualization, so you can see such a difference between a spreadsheet where you're looking at numbers, versus a visualization, where now they can compare facilities. They can compare other things. Whatever fields we bring in, they could really drill down, and eventually when we go back and rework it, we can drill down to the lowest level of data that's coming in.

Where are we going from this? Lots of places, with Alteryx. We are trying to look at, how can we build out really robust curated datasets so that we could deploy those to the gallery, or to TDE fils, whatever the need is, so that we can empower the business to be able to go out and do their own data analytics. I was so excited, we know that the Alteryx reports are coming, we saw a little bit of the demo, I think it was at a user group a few months ago, so I started getting excited. When she had healthcare data in that demo it was like, "Yay," because that's exactly what we want to do. I know, even though you try to go away from some of the flat reporting, there is still a need for it, so I think with the Alteryx reports we're going to try to really transition our Crystal over into using Alteryx all the time. Then of course we're going to try, as I showed you in the slides earlier, we're going to try to get those citizen... What did I call them?

Brenda Fosmire:
Data ...

Cyndi Tamayo:
Data scientists, sorry. Try to get those citizen data scientists out deployed in the business area, get that group growing, and then be able to start taking it to the next step, which is doing predictive analytics, which is so important in the healthcare industry. On the clinical side...

Brenda Fosmire:
Yeah, on predictive analytics, now that Alteryx has given us just a whole new view on how we can use our data, and now that we have the Hadoop data structure, in the next year our goal is to start doing some prediction of sepsis patients, and we're going to use some prediction for readmissions. Those are going to be our first two use cases, and we've been reading up on what other healthcare organizations are doing around that, and we're going to start with Alteryx. We've also looked at the date robot product. We've had them come in, and we're going to talk to them again, because I really like the multi-model approach that they're doing for that.

Part of this is just that Alteryx has transformed us. I like to say that we went from drums to wireless, and we skipped the telephone poles, because we now join data and do things we've just not been abl to do before. I think we have enough time for [inaudible 00:42:10].

Cyndi Tamayo:
Lastly, don't forget, they threw this slide in as a last-minute, but just make sure you go out there and fill out the survey. Now we're ready for any questions.

Crowd question:
Hi. Thank you for the explanation and sharing the example. I represent Express Scripts, so this is very familiar. My question is, and then I think you just hit on it at the end where you said we went from drums to wireless in between, our organization is somewhere in the telephone, and we are moving towards wireless in the same metaphor. What do you say you gained by not having to make the same steps using SQL? Because technically you could do the same thing by SQL coding, and having in-stage tables, and then moving it to a warehouse, which we do today.

Brenda Fosmire:
That's a really excellent question. We certainly do have a community of certain key users who are very SQL strong, and that's their comfort level, and as we've moved towards Alteryx we've had a few people not want Alteryx. For those people we're letting them just basically embed their SQL into Alteryx, and then trying to show them that many of the pluses or benefits of Alteryx aren't just the query, but it's the many things you do before the query, the query itself, after the query, how you deliver the data, and that's how we're pulling those people in.

We're also nothing differences in speed, and we've kind of done a few tests, and we're going to be doing more about, which is faster: just paste some really complex SQL into one input tool and pull it in, or make multiple joins and let Alteryx do some of that loading in a different way? We're seeing differences, I don't think we have our favorite answer yet on which is faster, but this is another thing we're letting people talk about as we move towards getting them to embrace the Alteryx model.

Cyndi Tamayo:
my answer to that is, right now we're still so new, we've got data sitting in a Clarity, which is Epics database. We're moving some of that data into, we've developed another SQL database to do self-service analytics, so in case those people don't want to use Alteryx they do have another option, although we're trying to push them to use Alteryx.

Some of the examples would be like, Epic supplies these Crystal Reports, and they're actually starting to go through putting SQL in the Crystal Reports, so what I like to do is, I like to strip that out and then just throw it into an Alteryx workflow. All that logic has already been tested by them, it's already validated by them, so I can throw it in, but now what I can do, instead of throwing it into SQL Developer and looking at it, I can really analyze my data. I can look at it... If I need to bring something in like, Brenda's created this great provider data so now it's like, how can we keep pulling in that provider? Because that's the provider we want, and that's what's sitting in the database. You could start merging that kind of stuff.

We're still trying to get our arms around it. We know the direction we want to go, we're just not there fast enough. We've got this great Hadoop data lake. We don't have any of our clinical data from our enterprise system going in there yet. Ideally we would like to do that, but we're still swimming.

Crowd question:
Hey there. I think I'm actually one of the few people in the room who isn't in the healthcare industry, so forgive my ignorance on this, but I do know you guys are very heavily regulated, especially when it comes to data privacy. Have you guys run into any issues with changing things, and how that's all coded and accounted for?

Brenda Fosmire:
Right. There's two sides to that: The data access from our analysts our Alteryx users. One of the things that I'm actually really liking about Alteryx is, it has this Alias manager for database connectivity, and so basically if you're one of our Alteryx users, you're in that group of privileged people who have a true business reason to be accesing clinical data. The Alias manager is a good compliment for that, we can kind of track who's been given access to what databases, and so that's good.

Then on the output side is where we're probably most exposed, so when we expose patient data through a tableau data extract, we then publish that data source through Tableau Server as a published data source, and then our Tableau users, because Tableau monitors who logs in and picks up that data, gives us that audit trail that our previous reporting system gave us no audit trail on where these reports are going. As even when you build a Tableau dashboard, it lots who viewed it and how long they viewed it. We are capturing all that data, and plan to build some management reports around that.

Cyndi Tamayo:
We do run into, and like I said, we're new, we're still trying to work through this, but when it comes to that data layer it's, this person, this group, we can let them drill down. They can see that protected data. This group, not so much. How do we want to turn off those fields, how do we want to... We're still trying to get our arms round that, because that is so key.

You guys are all leaving because you heard that party going on over there, aren't you?

Brenda Fosmire:
Sorry. It is time, actually.

Crowd question:
It seems like you guys are more in your own department. I'm in marketing. Do you guys have your own in-house data warehouse, or how do you do that? Because it seems like you have multiple different sources, which we do too.

Cyndi Tamayo:
Let me answer that, because I am working with marketing right now. Are you familiar with MyChart, when you go out there and do your own scheduling? They're taking on that project of, how can we reach out and get new patients based on what we're getting in from MyChart? In that scenario I'm actually building Alteryx workflow that's going against our reporting database to be able to give them that information so they can build out the dashboard, so they can make those decisions as, how do we target our patients, how do we market to our patients. It just depends on where that data sits, what's the best way to get it. If there was something that was more real time that they needed, we would have to build some extracts to come out of Epic, and then have Alteryx pick up those extracts, because that's more real-time.

Brenda Fosmire:
We're growing partnerships with many other departments, and we're the center of excellent, but we really want to empower them, so marketing doesn't have Alteryx, but based on Cindy's work, the next level is for them to have Alteryx.

Speaker:
All right, let's do one more question here.

Crowd question:
It sounds like you've done a lot with Alteryx, probably in a very short period of time. Do you have upper level support? Because I know that that's one of the real keys. And have you gotten any resistance from people that just don't want Alteryx in your business?

Cyndi Tamayo:
I will have to say, for the most part no, because the fact that we can use Alteryx to get that data out there faster, and people are just loving it... We did have some resistance in another area where we had a dotted line to our quality measure area for our clinics. She was so comfortable with SQL stored procedures, she had her own SQL database and had gone down that path, so we were trying to, how do we figure out how to work with her to transition her to move to the Alteryx so that we could support it? The way we took care of that is, she left the company. We inherited the work, so now we can turn around and go back and figure out how we're going to do the workflow.

Brenda Fosmire:
At the e-suite level we wish that... Do they support us? I don't really think they know what Alteryx is. I think they know that they didn't have data and now they have data, and the data is revealing problems. Now we're telling them that we need more Alteryx users to help us answer what these problems are. At the first go-around they actually called us a little skunkworks for our own three works because management didn't really know what we were doing, but then when we had things to show, that's become aware. That's the goal now, to bring us up to 60 Alteryx users. We've got kind of a plan, and we're telling the e-suite about that.

Cyndi Tamayo:
It goes back to Crystal Report, Tableau. Crystal Report, Tableau. But in order to do Tableau, we have to have Alteryx there. Now they're starting to get that.

Brenda Fosmire:
Yeah.

Cyndi Tamayo:
That was the easy piece. The hard piece is the analytics around it. They're so used to doing, "Hey, I want this report, I want this report, I want this report." So when I go back to saying we want to build out robust curated datasets, we're going to build this dataset to answer this need, this need, this need, and this need. Now you're not coming back to us to go these one-offs. You go get that data. It's here, you build it out yourself. That's the shift that we're trying to deal with a little better, is think outside the box. We're dealing with analytics, not just reports.

Brenda Fosmire:
Reports. Yeah.

Speaker:
Okay, thank you very much.

Brenda Fosmire:
Thank you.

Cyndi Tamayo:
Thank you.

^Top

ERLEBEN SIE
DIE WELT VON ALTERYX
SELBST.

Los Gehts