David Lareau, President and CEO of Medicomp Systems – Interview Series

David Lareau, President and CEO of Medicomp Systems, is a healthcare technology executive and entrepreneur with a career spanning nearly five decades. After beginning his career in computer auditing and management, he founded Dexcom Systems in 1987, helping deploy some of the earliest enterprise communications networks and large-scale LAN environments for organizations including the World Bank, DuPont, and Sinai Hospital. He joined Medicomp Systems in 1995 as Chief Operating Officer and was appointed CEO in 2012, leading the company’s evolution from a pioneering clinical knowledge engine provider into a modern healthcare AI and interoperability company. Under his leadership, Medicomp has expanded its global reach, advanced evidence-based clinical intelligence solutions, and focused on improving clinician productivity, data usability, and patient care through smarter healthcare technology.

Medicomp Systems is a healthcare technology company best known for its clinical intelligence and knowledge-engine technology that transforms complex, fragmented healthcare data into structured, clinically relevant information. Founded around the patented MEDCIN clinical knowledge engine, the company’s flagship Quippe platform helps healthcare organizations improve clinical documentation, interoperability, quality measurement, risk adjustment, and AI-driven decision support. Designed to mirror how clinicians think and work, Medicomp’s solutions are used by hospitals, health systems, EHR vendors, and healthcare organizations worldwide to streamline workflows, reduce administrative burden, and deliver more meaningful patient insights at the point of care. The company has become a recognized leader in combining clinical knowledge graphs, structured data, and AI to support more accurate, efficient, and trusted healthcare decision-making

You’ve spent nearly four decades working across healthcare IT, from early enterprise communication networks and medical billing systems to leading Medicomp Systems for more than 30 years. Looking back at that evolution, what fundamental healthcare data problem do you believe the industry still has not solved?

The healthcare industry still lacks an integrated standard for clinical data. The terminology standards we rely on were each created to solve coding problems within a single domain: ICD-10 for diagnoses, CPT and HCPCS for procedures and tests, LOINC for lab results and other measurements, RxNorm for medications, and SNOMED CT for clinical findings. Each one was built for billing, classification or research. None was built to organize a patient’s care.

Healthcare information systems use these standards to complete specific transactions, most of which are tied to reimbursement, rather than to give providers an integrated view of a patient’s status. Consider a patient with diabetes. That patient’s data is spread across separate tabs in the health information system, with no single “diabetes view” that pulls everything related to the condition together. The coding systems share no common schema, which makes them computationally inefficient, and that inefficiency becomes a far larger problem in a world of clinical AI. AI depends on good data, and our industry does not yet have it.

Picture an Amazon warehouse trying to operate without stock-keeping units (SKUs), relying instead on text descriptions of every item, each description linked to a data structure that changes from one item type to the next. Almost every industry has some version of the SKU. Healthcare does not, and so its data stays fragmented and inconsistent.

You’ve described many modern healthcare repositories as “data swamps” rather than actionable data lakes. What are the biggest architectural mistakes health systems made during the rush to centralize data?

The central mistake was organizing the repository the way the source systems were organized, around domains and transactions rather than around the patient. Most health systems still separate clinical information into discrete domains such as labs, medications, procedures, and diagnoses. Users, and the software they rely on, then have to reach into different files and locations to assemble a picture of the patient, which makes every process slower and more cumbersome.

The deeper issue is that each transaction, whether a bill, a prescription, a test order, or a lab result, is stored as a self-contained item rather than as one part of an integrated view of the patient’s condition. Centralizing that data in one place does not fix the problem. A data lake filled with fragmented, domain-bound records becomes a data swamp because volume alone, without clinical organization, does not yield understanding.

A large percentage of clinically meaningful information still lives inside physician notes, imaging reports, and discharge summaries rather than structured fields. Why has the industry struggled so much to operationalize unstructured clinical data at scale?

This is changing, and quickly. Large language models (LLMs) can now generate text summaries of encounters free of abbreviations and idiosyncratic shorthand, making it far easier for clinical natural language processing (NLP) to extract structured, coded data from that text. In the past, capturing structured data meant asking clinicians to work through checklists or forms, which they found cumbersome and largely unusable.

Today, the sequence works differently. Ambient listening produces a reasonably clean text note, an LLM summarizes that note into a semi-structured form, and NLP then runs on the summary. When the NLP is pointed at a proper clinical data target, one that represents clinical concepts rather than a flat list of codes, it can produce well-structured data from narrative text. Achieving this still takes a combination of technologies working together, and it depends entirely on having that proper clinical data target in place.

You argue that the core challenge is not “data quality” but data fragmentation. Can you explain the difference, and why that distinction matters for AI-driven healthcare systems?

The two are closely linked, yet they describe different problems, and that difference matters a great deal for AI. Data quality is about whether an individual piece of information is accurate, complete, and correctly recorded. Data fragmentation is structural. Fragmentation occurs when clinical information, regardless of its quality, is split across separate domains and coding systems and stored in different formats and locations.

That fragmentation is the current practice because each coding system was designed for a separate transactional use case. The approach was adequate for writing a prescription, generating a bill, or handling other discrete tasks. Overall patient care is a different problem, one that requires information from several domains to be brought together, processed, and displayed as a single, diagnostically connected view of the patient. A record can be full of individually accurate data points and still fail the clinician, because nothing connects those points into that view.

You’ve highlighted three major gaps in most healthcare data lakes: narrative extraction through NLP, clinical knowledge graphs, and reconciliation of conflicting records. Which of those missing capabilities is currently causing the greatest downstream impact on patient care?

Two of the three are closely connected: the reconciliation of conflicting records, and the fact that a clinical knowledge graph is only as good as the data it operates on. Of the three, reconciliation is currently doing the most downstream damage, because it sits upstream of everything else.

A great deal of what lives in a patient’s chart was entered by copying and pasting from earlier encounters or by consolidating information from multiple providers. Moving that information between systems with Fast Healthcare Interoperability Resources (FHIR) makes it easier to send and receive, yet it does nothing to improve the underlying quality. Run AI or a clinical knowledge graph on that information and the results will most likely carry the same inconsistencies forward.

Consider a patient with diabetes who is evaluated for retinopathy or cataracts. That evaluation does not mean the patient has diabetic cataracts, since the cataracts may be age-related cataracts unrelated to the diabetes. An LLM may miss that distinction, and the false association then enters the patient record and stays there as it moves from system to system. A knowledge graph given poor data will return poor results.

Standards such as SNOMED CT, LOINC, RxNorm, FHIR, and C-CDA are often discussed as interoperability solutions. In practice, why do many organizations still struggle to turn standards compliance into clinically useful systems?

Many systems and organizations carry poorly coded data because their user interfaces make it easiest to pick the first item presented. Those interfaces are built to move the code along for billing as quickly as possible, rather than to supply the clinical context that would let the user record the condition accurately.

ICD-10, for example, includes a code for “hereditary motor and sensory neuropathy,” a category that does not distinguish Charcot-Marie-Tooth disease from Roussy-Lévy syndrome, even though both fall within it. If a user interface surfaces that category first and makes the specific condition harder to select, the user will most likely choose the category. The category may be enough to have a claim paid, yet it is far less clinically useful than the specific condition. All of the transactional coding terminologies share some version of this problem.

Recording the most specific condition, therefore, falls to the system and UI designers, and over time, it slides down their list of priorities. As long as the transactions keep flowing and the claims are paid, the incentive to design for clinical specificity fades.

Medicomp has spent years building clinically connected terminology and relevance engines around systems like MEDCIN. How important is a clinical knowledge graph for making healthcare AI trustworthy and context-aware?

A clinical knowledge graph is essential because it makes data usable at the moment a clinician or reviewer actually needs it. The test is straightforward. When a patient has a specific condition that is being managed, can the user see everything related to that condition right away, or must they sort through the entire record, tab by tab, to reconstruct the clinical context? A clinical knowledge graph built on clean clinical data can surface that context in an instant. Without one, finding the same information takes far too long.

This is why, every time I visit my mega-hospital, I am asked to complete a four-page, six-screen medical history form with the same information I provided the month before. Finding anything in current health information systems is simply too hard. Medicomp has spent more than 45 years building MEDCIN and its clinical knowledge graph to close exactly that gap, so that AI operating on top of clean, connected data can be both trustworthy and aware of a patient’s clinical context.

Many healthcare organizations are now deploying generative AI copilots and ambient documentation systems. What risks emerge when those AI systems are trained or operated on fragmented, poorly contextualized clinical data?

Hallucination and the miscategorization of information are two of the most common risks, and both become more likely when the underlying data is fragmented and poorly contextualized.

A personal example: my father died of liver cancer at 78, yet on a recent visit, I was asked how long I had been in remission. The ambient documentation system had recorded a personal history of liver cancer in my own chart. A colleague ran into something similar. He had chronic obstructive pulmonary disease (COPD) entered in his record because his provider, using ambient documentation, had ordered a chest X-ray to rule it out. When he later applied for life insurance, he was denied, and the reason given was the COPD diagnosis that the earlier X-ray order had inadvertently generated.

The context failures can be stranger still. In one recent case, a male patient who mentioned eating eggs for breakfast was reclassified as female, presumably because the system associated the word “eggs” with female biology. Each of these errors is easy to laugh at in isolation. Once they are written into a chart and exchanged across systems, they stop being funny.

There is growing excitement around national interoperability progress, with hundreds of millions of records now being exchanged annually. What still needs to happen before clinicians can genuinely trust that exchanged data is complete, accurate, and clinically relevant at the point of care?

Two things must happen. First, the providers who sign off on encounters, which are increasingly generated by ambient listening tools with LLM summarization, need quick, easy-to-use guardrails available before they sign, at the point just before that data enters the patient record. Once incorrect information lands in the chart, every downstream use of it inherits the timeworn “garbage in, garbage out” problem, and correcting it after the fact is difficult.

Second, even when the data is accurate, a clinician must be able to find what they need without slogging through everything else in the chart. Exchanging hundreds of millions of records does little good if the receiving clinician cannot locate the relevant information or trust that it reflects the patient’s true clinical picture. Validation at the point of care and easy retrieval are what make exchanged data something a clinician can actually rely on.

Looking ahead five years, what does an “activated” healthcare data environment look like when AI, interoperability standards, clinical context, and physician workflows are finally aligned in a meaningful way?

Alignment will depend on every party having access to a reliable clinical data foundation, one designed to manage each patient effectively and, collectively, to make genuine population health management a reality. Given that foundation, alignment starts with the individual patient.

Before each encounter, one AI agent assembles all available data for that patient from health information networks, exchanges, payers, and enterprises, while another removes duplicates and organizes the remaining data. Through an app, a kiosk, or a conversational agent, the patient then verifies current diagnoses, medications, recent lab results, and any new issues, correcting any errors along the way. A draft of those changes goes to a clinician for review.

At the encounter, virtual or physical, the clinician reviews that information with the patient and turns to the conditions needing attention. An agent surfaces diagnostically relevant context for each existing condition or new complaint, and ambient listening captures the conversation. A second agent summarizes it for the clinician to review, correct, and approve.

From there, agents handle the downstream work: securing any required authorizations, sending prescriptions to the pharmacy, submitting claims, scheduling follow-up care, and packaging information for approved parties. Throughout, background agents assess clinical risk and prompt for quality, risk-adjustment, and regulatory documentation. The whole model rests on clean, reliable data at every step, with clinicians kept in the loop, producing information that supports both individual patient care and effective population health management.

Thank you for the great interview, readers who wish to learn more should visit Medicomp Systems.