Interview by iHub friend and blogger, Ryan Allen, Practice Coordinator at Brigham and Women's Faulkner Hospital. *
Recently, I had a chance to talk with a few members of the ICD-Nav team, winners of the Brigham Innovation Hub prize at our annual Hackathon last November. Jayson Marwaha and Elbert Heng, medical students at Brown University in Rhode Island, with the help of two Brigham residents, Omar Badri MD and Arvind Ravi MD, believe that coding patient visits has become far too time-consuming for clinicians. Furthermore, ICD-10 billing codes, which just went live in October 2015, have made the process more complex than ever, so they put their heads together and came up with the idea for ICD-Nav, an intuitive search tool that would help providers find the diagnoses codes they’re looking for much faster.
"Provider billing is certainly not the flashiest area for innovation, so what exactly compelled your team to tackle it at the Hackathon?"
Jayson Marwaha: I think the global problem we were trying to tackle was that it’s really hard for physicians to do what’s right, in terms of keeping their patients’ medical records up-to-date. For example, something we mentioned in our pitch was that obesity is not coded for 94 percent of the time, yet the prevalence rate of the disease is about 36 percent in the United States, but it’s only documented 2 percent of the time on those patients’ medical record. That opens up a big window for clinical shortcomings.
Elbert Heng: That’s why we really liked this problem, because it has a lot of potential impact for practices and hospitals, both clinically and financially. If something’s not being properly documented, then who’s to say if the right care is being provided? Hospitals spend a lot of money to provide the right care to patients, and they don’t get reimbursed at the level they deserve.
Arvind Ravi: From the physician standpoint, billing continues to be one of the most dreaded parts of the patient encounter, and with the growing volume of care, it’s easy to see why billing accuracy can fall by the wayside. Solutions like ICD-Nav are part of an emerging class of technologies that wed advances in big data science and analytics to the traditionally low-tech doctor’s visit in order to provide optimal care for the sickest patients.
"ICD-10 billing has been live for only a few months. Can you tell me a bit about the effect it’s had on providers within that short time frame to necessitate an IT solution like ICD-Nav?"
JM: I think the experience we had that started this off happened about one month before ICD-10 was rolled out in October. A lot of our attendings got this gigantic, 2,000-page book dropped off at all of their front desks. Medicare had sent it and was just like, “Yeah, you guys have one month to familiarize yourselves with ICD-10, so here’s a book that will tell you everything you need to know. Good luck!” So the first day that it [ICD-10] came online, no one knew what to do. That’s sort of when we realized everyone was frustrated by it.
Omar Badri: The adoption of ICD-10 has slowed down work flow in our clinics. Given the unfamiliarity with the new billing codes, suboptimal search functions, and increased complexity of ICD-10 it can now take up to several minutes to find all of the proper codes, and that’s time that could be spent seeing patients or charting. Although things have improved as providers have become familiar with the codes, there is a large opportunity to provide decision support to ensure quick, efficient, and thorough billing.
"This seems like such a simple solution to a complex problem. Has a tool like this been piloted anywhere before for ICD-9 or 10? If so, how was it received by healthcare providers?"
JM: Even with ICD-9, a lot of physicians and practices experienced many of the same issues that they are experiencing with ICD-10. They said it was hard to navigate. But their solution to that over time was to memorize their favorite codes, but they were more like “check-all” codes—codes like diabetes, with no specifications to indicate whether or not it was with or without complications. And with ICD-10, it’s much harder to pick out these codes, so whatever problems there were in ICD-9, they’re kind of exacerbated by the more complicated codes in ICD-10. The tools back then were good enough. The problem is that all the tools that were used to navigate ICD-9 are now being used to navigate ICD-10, which is inherently not the right fix.
EH: There are native search tools out there right now, as well as some third-party services like IMO [Intelligent Medical Objects], but I think the general consensus we’ve heard on the wards and from many physicians that use these kinds of resources is that they don’t really enjoy having to use them, and it’s still difficult.
AR: Every clinician who has used Amazon or Netflix sees the surprising limitations of even the most sophisticated billing tools in use today. In fact, many practices still resort to a printed list of the most common diagnoses billed in clinic – regardless of the provider or patient – with a final check box for “other.” If Amazon recommended the same purchases to every customer, you can imagine it wouldn’t actually be helping many people.
"What was the biggest challenge your team had to overcome in finalizing its pitch?"
JM: I had an awesome time at the Hackathon. It was definitely one of the cooler events I’ve been a part of. Elbert and I did a quick pitch of the problem on the very first day and started milling around, started talking to different people who were interested. We just happened to land on a really nice balance of expertise. You had Elbert and myself who were really familiar with the problem, but you also had Omar and Arvind. They both had a ton of firsthand experience with ICD-10. Omar gave us a lot of really good case examples of instances where dermatologists have to, in one visit, code for seven different things but often forget one or two of the seven. In these instances, the computer isn’t acting as any kind of a safety net to make sure that they capture everything.
EH: The problem with something like ICD-10, as a data set was really fun and interesting for the developers to work with because it’s so large and complex. There’s a lot we can do with it, and a lot we still plan to do.
"One of the most common EMR-related complaints that I hear from physicians is that there are “too many clicks” needed to do what you want to do in the chart. How do you plan on avoiding this pitfall with ICD-Nav?"
JM: I think two things guided our front-end approach. The first one was simplicity, and under the umbrella of simplicity comes something like click volume. The other guiding principle for us was taking a predictive approach, as opposed to a rules-based approach. In terms of click volume, we want to make every data point that the physician uses in the EMR an opportunity for us to respond to that data point. Anytime they start typing in what they’re looking for, we’re able to provide them with not only the code they’re looking for, but other codes that are commonly coded alongside those codes. It will intuitively pop up without them having to add any additional effort.
EH: We’d like our software to be able to learn over time and adapt and evolve, as opposed to just having coders write in more and more rules. Medicine changes, too, and our software should be able to learn and evolve with that. Our approach is to try and develop a software that makes it easy for physicians to do what they know how to do, rather than have software that attempts to do the work for them or replace them. Physicians are well-trained at their jobs for a reason, and the software should be there to help them.
"How do you plan on engaging primary care practices to pilot your application?"
JM: We’ve taken incremental steps in product development, making sure that that progress is guided by feedback from potential end-users. So we’ve been talking to a lot of practices and physicians who we imagine will end up being the end-users about the kinds of features they want to see and the style of integration into their workflows.
"For those who pilot the application, how soon do you expect them to realize results (i.e. more time spent with patient, less time spent billing, fewer rejections, accurate documentation)? Or do you believe that this solution is so simple that it stands to make an immediate impact?"
JM: We are designing the product with immediate impact in mind and want to make it as intuitive a user interface as Google, which practically has no learning curve. We know that there are a lot of add-ons out there for EHRs. We’re weary of the pitfalls of many of them, which most often tends to be the learning curve. Our intention is to make it as simple as possible, so that an immediate impact can be realized. A physician should be able to click on our tool, get almost nothing but a search bar, type in what they want to see, and immediately have all the codes on the page for them that they need to use. We want the data to inform what the minimum and most important stuff that needs to be displayed to the physician on the screen should be.
EH: Our tool should allow clinicians to spend more time tracking their patients and less time thinking about how to document things that they already know clinically. And over time, the impact that we’d like to see from practices and hospitals on a larger level is that due to the more accurate documentation, their clinical practices improve and financial reimbursement is improved. I think it’s important to know here that a lot of feedback we get are concerns about up-coding, and I think that’s because practices aren’t getting reimbursed for the things that they do provide. A lot of money is lost that way. That’s not to say that we want to encourage documentation that shouldn’t be there. The idea is, instead, to suggest things that the doctor may have missed and did, in fact, treat for.
"What kind of a role did the Epic and Microsoft Azure developers play in giving your team a better understanding of what it takes to integrate something like ICD-Nav into the EMR? Did they add value based upon their industry experience?"
JM: Of all the sponsors, we really got a lot of value out of the Epic people, talking to them about the nitty gritty of how to use their sandbox and how to build a tool that can be seamlessly integrated. Essentially, our ultimate goal is to replace the search button. In terms of figuring out how hard or how easy it is to do that, it was really helpful to have the Epic people there. We also got a lot of value out of having the mentors that the iHub brought in, too. There was one from Podimetrics and a few others kind of just milling around with the people from the iHub. They were all people who have built other devices or apps that are really successful right now. We talked with them about validating our business model and making sure that the space we’re entering is not already oversaturated with competitors. Or even if it isn’t, we wanted to understand the barriers to entry, how big other players are, or how complex it is. Getting these types of questions answered was important for us and how we move forward with the tool.