Working in healthcare and technology for over a decade and a half, one thing I’ve noticed is that innovation is slowed and often nixed because we look at how an incremental achievement fits into the current mega-sized health I.T. environment.
I’ve experienced numerous times where operations, clinical or administrative personnel bring up problems that they are encountering that could easily be solved by technology, and when those problems are assessed by the IT department, most often they are acknowledged and solutions are even considered.
But it’s during the consideration process where the solutioning breaks down. This is due to the uber static situation health IT is in. For example, I recently was given the opportunity to manage a very large alternative payment initiative facilitated by CMS and the State of Texas. For years, this initiative was project oriented, and payments were made for design work and infrastructure development. Now, however, the initiative’s remuneration model has changed to outcomes-based care for patients with chronic diseases. Having people trained to conduct A1C tests or 3-part foot exams for diabetic patients wasn’t enough anymore, we actually needed to improve performance on these measures.
The obvious operational solution was to identify our patients who have chronic diseases, and ensure that when they come in for appointments, we do the necessary tests and exams to achieve the measure. We’d also need to identify our patients with diabetes, and if they do not have an appointment scheduled, we would need to try and get them to come in for a check-up, and conduct the important tests.
With all this, and with limited staff, we knew we needed a system to help us proactively manage these requirements. My team has been responsible for reporting for many years, and we knew there was a way to identify our patients through a series of queries in our EMR; theoretically we knew it was possible. So I proceeded to spend some time with our EMR leadership and ask them how we could tap into the system and build workflows to allow our practices the ability to be made aware of required activities.
The answer: Good News! We are working with our EMR vendor, and we are looking into a new product that they will be providing to help us case manage our patients, and flag when certain tests, exams, or services are required based on patients’ with chronic diseases. Needless to say I was stoked, until I got the answer to my final question: “When will this be available?”
The answer to my last question was, “2020?”
Well, in my experience, that’s not bad for a big 3 EMR -- but my issue was that I was responsible for a lot of money in 2018 and 2019 in this alternative payment model.
Innovation foundation already in place
Before I go any further, I do want to acknowledge that I was in a very fortunate situation, in the sense that my employer and predecessor had set us up well by being forward-looking strategic thinkers. We have a great team of developers and project managers that have enabled us to create the systems I am about to talk about.
Considering the value of the initiative I am managing, waiting 2-years for a system, and hoping that organically through communications, education, and auditing we’d meet our objectives was not gonna cut it. And, buying a bolt-on case management system, and getting set up was both out-of-budget and would take too long. So, we had to come up with a solution.
After several meetings with the developers, project managers, and subject matter experts, we decided to build our own application, that would allow case managers to see patients who are on the schedule, and who are diagnosed with a chronic disease, and who need one or more of the tests, exams, or services required by CMS/Texas.
Here is how it worked:
First, we needed access to the data. Since our department has been a reporting area for years, we already had SQL-level access to EMR data, through a ‘Clinical Data Warehouse’ So, that was good! Over the years of the initiative, the team and their EMR partners had developed queries for reporting on patients who had chronic disease diagnoses, and they had developed ad hoc capabilities for reporting the HEDIS requirements we were looking for. All we needed to do then was turn those queries on earlier, to be proactive.
Next, we needed a delivery medium. Believe it or not, even in 2018 in healthcare, Microsoft Excel is still often thought of as an acceptable delivery vehicle for a ‘work queue’. No, we wanted to create a real application, with performance measurement, auditability, and reporting capabilities, and we wanted something easy to access and maintain.
Design and Development
Once we identified our toolset -- an open source UX/UI template, we needed to address our design and development process. In my many experiences over the years, I have learned to be cautious of two things:
- Competing with the EMR, and
- Creating a tool that is too purpose-built
Competing with EMRs is tough, it’s like a local, organic farmer trying to collaborate with Albertson’s. Not to say it’s impossible, just not the easiest thing to do. We needed to work with the EMR, but creating a competitive solution, for something in their pipeline would not have been smart. So, we decided to keep our application simple, and also recognize things we could not accomplish, such as bi-directional communications. More simply: we knew we would not be able to post data back into the EMR systematically.
Knowing our limitations, and knowing that our users would still need to work in the EMR, we were able to build workflows that were simple to follow, meaningful, but not redundant. We always asked, “will the user have to do this in the EMR, and if so, do we have to have them do it in our app, too?” This mindset has allowed us to build applications that the users actually enjoy using, and do not find terribly intrusive to their daily work.
The second concern we dealt with was ensuring our design process would be open-ended enough to potentially solve other problems, too. Leveraging our industry knowledge from SME’s we asked what other types of problems could our application potentially solve? We didn’t obviously get an exhaustive list, but we did identify several, and we are now incorporating four other alternative payment models into the application we’ve built.
So, what have we done?
This is what we’ve accomplished, so far.
What you see above is a work queue of (fake) patients who are scheduled to come in for an appointment, who have a chronic disease, and who are “at risk” for certain HEDIS health indicators.
All of this information is from the EMR, and we are just re-organizing it, to focus on case management concerns. It provides a case manager with the important information, to conduct their work, to ensure that patients are given quality care, in accordance to our alternative payment model.
This, is the patient profile:
What you see in this screen are action items. Such as the ability to assign a patient to me, so I can work with them, even after the appointment, to keep them engaged with their health.
You can also see the option on the ‘At Risk Quality Indicators’, to allow me to create a checklist, and give that to the nurse and/or doctor, to let them know in advance of the appointment what patient Sam needs.
Lessons learned
This all took us about 6-months to build, to get us to the version we’re at now. Since this application has been in production, we have had 5 case managers, in two departments, facilitate thousands of patients’ care with their provider.
Without this tool, we would have either needed to hire 15 or more case managers, or, we would have just crossed our fingers and hope that we are successful.
Here is the moral of the story: With the right mind-set, and the willingness to try something different, even in health IT you can achieve great success without millions in investment, and without having to wait years for features to come out of the “pipeline.”
If in 2020, our EMR comes out with a solution that kills our app, guess what, no harm done. This has been a nominal sunk-cost, and our ROI expectation is exponential, based on the value of the alternative payment models we’re already working on, and the several we’re going to incorporate over the next few weeks.
Corey Shank is Director of Strategic Initiatives at the Texas Tech University Health Sciences Center, in Lubbock Texas.
