HIStalk Interviews David Lareau, CEO, Medicomp Systems
David Lareau is CEO of Medicomp Systems.
Tell me about yourself and the company.
I have been with Medicomp for a number of years. Our core competence is that we produce a clinical data engine that we call a Clinical Knowledge Graph. We’ve been building it based on expert input since 1978.
We have been through many technology transitions. Now we’re in the world of AI with clinical applications. We feel that we are well positioned in that area since we have very domain-specific knowledge for training small models to do what we need them to do.
Will the customer cost of using AI technology that is sold by big tech firms that have to keep investors happy going to inevitably increase?
We think that the Butcher’s Bill is going to come in for these large models that are expensive to use. People already are starting to say, “We are going to use AI to train for specific workflow issues and specific clinical domain issues.” We believe right now that we are well positioned in that space.
We are having great success in terms of performance and lower cost by using a small model rather than a large model. Our engine, and all the power that’s in it, can be run on CPUs rather than GPUs, inside a vendor’s own security environment without going out there. We can do that because we have a target of 400,000 clinical concepts with hundreds of millions of links for diagnostic relevancy and coding relevancy. To be able to do that with a small model is because we have a clinical target that’s been very well-defined over the last 40-some years.
The vendors that we are working with have seen their costs drop by using a smaller domain-specific model that is trained on our clinical data points that link to our engine. The roadblock to that was the lack of a clear standard for how to communicate between applications using various aspects of AI. The MCP, or Model Context Protocol, developing as a standard has allowed us to expand the number of partners that might be able to take advantage of our unique Clinical Knowledge Graph.
That’s why what’s happening in the industry is an opportunity for us rather than a threat. If I want to know the 250 clinical concepts that might be relevant for somebody with chronic kidney disease, that’s in our engine. The MCP allows us to present a standardized way to request that information from our engine and send it back to the application, whether it’s a language model or somebody else that wants that information. It will be what drives the integration of all these AI agents that people are building.
It was an essential, missing building block for communications between systems that are using AI to do very specific tasks. When Epic, for instance, announces that they’re building hundreds of AI agents, they will be using things like MCP to communicate between various aspects of their system.
Has AI changed your business strategy?
It has. We definitely have had to adapt to it. The conversational AI still captures text. It does a very good job at it. We’re really astonished and pleased at how effective it is at removing the need to enter text into a medical record. But it’s still text.
We have been using AI. We’ve been using language models internally to fine tune our offerings and our tools. We are building a small model, domain-specific, task-specific ways to use our data, extract data from text, and then operate on it to service all the downstream things that you have to do, like quality measures, adequacy of documentation for Medicare’s Hierarchical Condition Categories, that sort of thing. We’ve had to embrace it and figure out how to use it transparently, effectively, and affordably in the clinical domain.
It is an exciting time as the AI tools have matured, the power has matured, and you have everybody in the industry rowing in the same direction. But they need clinically specific tools to get where they need to to make it affordable and useful at the point of care.
We saw it as more of a threat two or three years ago. A threat being anything that causes people to not need to do business with you today is a competitive threat. When the frenzy over AI started a few years ago and really built lately, it really was a competitive threat to us because it made people sit on the sidelines and wait to let AI figure it out. Now people are realizing that generalized predictive pre-trained transformer is not enough for clinically specific work. That’s where we are hooking it into our Quippe Clinical Knowledge Graph to do very specific things for clinicians. People are realizing the proper uses of AI in clinical medicine and the things that it doesn’t do so well.
We are pleased with the way things have developed over the last 12 months, as the rubber is starting to meet the road with AI in medicine.
Startups and big tech companies might be slow to realize that AI and ambient documentation are table stakes that aren’t much of a business moat. Does your phone ring from companies that have the technology but need help understanding how to integrate it into healthcare workflows?
I get four or five inquiries a week. Most people that call when they hear the specificity of what we’re doing say, “We’re not quite to that point yet. We’re just trying to figure out how to compete with all the other people that are in our space.”
We’re starting to see that people are actually putting these applications into use. Those are the more serious inquiries when calling us. They say, “We’ve got the table stakes working, but now we’re having trouble meeting all the downstream requirements because we just have text, we don’t have data.” They need to get there because when the government puts in very specific requirements for things like quality measures. They are looking for specific data points. That’s what’s in our engine.
They say, “The acquisition of documentation is no longer an issue. Now we need to do something with all the downstream processes that are tied to the information in that text.” When they hit that wall, that’s when they’re calling us.
You wrote something about instafraud, the claim by insurers that some providers are using AI to increase billing, and their intention to use AI to stop it.
We’re in initial conversations with some folks in compliance and regulation. One example where it shows up is in Medicare Advantage, which was supposed to reduce the cost of caring for people people in Medicare. It uses risk adjustment codes, Hierarchical Condition Categories, to identify somebody who has a disease that puts them at risk of poorer outcomes, and then to manage those conditions. But to do that, you have to code a diagnosis to get that risk, and then receive more money put in your risk pool each year.
AI was algorithms even before AI became a thing. People were using algorithms to say, “This guy has a high creatinine. He probably has chronic kidney disease, so let’s code that.” If you code it and send it, you get a higher risk score, but the documentation has to support it.
When we published our E&M algorithms when the 1997 guidelines first came out, the most common question we got was, “You guys have all this data that can support a code. Could you use it to tell us the three things we need to do to get a higher level of service to get more money?“ We said that we could, but the government has seen what we’re doing and warned us off and said, “If you do that, we’re going to come after you.” So that feature was disabled. You can’t ask it the minimum you needed to document to get a higher code.
The same thing started to happen about five years ago with risk adjustment. They called it “suspecting.” They wanted to use AI to look at the record and find potential evidence for one of these HCCs that would support a higher code. This would be submitted without necessarily seeing that the documentation supported that the patient actually had that condition.
Suspecting is a valid thing if there is a condition that’s unaddressed and you then address it, but it’s fraud if you look for the possibility that somebody has something and then code that they have it without investigating whether they actually do.
There’s a tug-of-war going on between the payers, the regulators, and the enterprises over the proper handling of patients with chronic conditions in the Medicare Advantage program. The government is starting to pay a lot of attention to that because Medicare Advantage was supposed to cost less per patient than traditional Medicare fee-for-service and that hasn’t turned out to be the case. I think it’s because people are over-coding for risk factors.
How does Epic’s public sharing of its AI roadmap affect innovation?
There are a number of layers to that question. Epic is not the only large vendor that I would call an impediment to innovation just because they’re a dominant in their space. We do quite a bit of business in Asia, and this is not limited to the United States.
Years ago, we had another unnamed vendor in the US, not Epic, whose customers told them, “We really like what this niche vendor is supplying. I want it.“ We had the experience with a different vendor years ago, where they said, “We’re getting a lot of customers that are asking for what you have. We’re probably going to develop that ourselves so we’re not interested, but we are willing to work with you. But since we think of our customers as an asset, you’re going to have to pay us the bulk of your revenue for access to that asset.”
That’s the moment where I realized that dominant vendors, because this vendor was large in the space then, tend to treat their customer as an asset and as turf that they own, not as an obligation to provide a higher level of service. When vendor app store organizations were first set up, the agreement that you had to sign as a niche vendor said, “We need to vet what you have. You need to show it to us. You need to show us your source code so that we can make sure it doesn’t create any vulnerabilities on our system. But if we then decide to do something like that ourselves, you have no recourse to us.” That scares off the niche vendors.
We’ve also had the situation where a large consulting company that specializes in implementations for the large HISs said, “We have a lot of customers asking for what you have. We have a lot of people asking for the kinds of things that you and other companies like yours provide. But we also have $90 million a year in consulting revenue from this vendor for implementation assistance, and they’ve told us that we’re putting that at risk if we start to introduce these niche best-of-breed vendors into their ecosystem.” So it really does stifle innovation in that sense.
Do companies call you wanting to buy Medicomp rather than try to build complex healthcare technology?
Yes, we get that from investors, private equity, and larger vendors. The issue for us is that we do one thing. We focus on it. We don’t do anything else. Being employee owned, basically, allows us to focus on what we do and not get distracted, and we plan to keep doing that.
As people see how you can leverage our Clinical Knowledge Graph for a very specific thing that has a widespread need, we get a lot of activity. I thank people very politely and explain that we see a model of sustaining what we’re doing for quite a while, even into the next generation of the company.
What will be important to the company’s strategy over the next few years?
We need to make certain that we are using these new AI tools to make ourselves more productive while producing our Clinical Knowledge Graph. With the new Model Context Protocol, MCP, stuff that is coming out, we’ve been API based for a long time. We make it easy and transparent to link to our clinically data specific APIs to accomplish specific tasks. Acquiring documentation, no longer a problem. Acting upon it and doing something with it is the next step.
Our strategy over the next three to four months is that some EHR vendors will start showing the intersection between ambient listening coming in as documentation, then link to our engine that will validate, filter, and present that information and accomplish all the specific things that you have to do with the data, such as getting the right billing codes, meeting the quality measures, and verifying adequacy of documentation for HCCs. Linking our stuff and allowing our engine to be accessed through the MCPs to accomplish specific tasks other than just documentation.
We see great potential in that space. We will have the first few implementations of that hitting the market over the next few months with some specialty-specific EHR vendors.
"A valid concern..." Oh please. Everyone picks the software they like and the origin of that software is an afterthought.…