In the medical field, there's no shortage of ontologies. You've got HL7 and FHIR for healthcare data exchange. You've got SNOMED for clinical terminology, LOINC for lab results, and RxNorm for prescriptions. There are ontologies for body parts, billing codes, procedures, and chronic conditions. And of course, there's ICD-10—arguably more data than schema—which is used to label just about everything.
But in practice? None of that helps if you can’t get two EHRs to agree on what a diagnosis looks like.
I built an integration layer designed to normalize data across nearly three dozen EHR and EMR systems—from industry giants like Epic and eClinicalWorks to one-off installations coded by a doctor’s nephew (not joking). The goal wasn’t just to extract or push data, but to translate everything into a unified ontology that powers our entire eligibility, billing, and reporting stack.
If you’re doing anything in RPM, RTM, or CCM, you need to answer simple questions:
That’s easy if you live inside a single system. But if you're supporting 30+ EMRs across a national client base, the problem explodes. One EMR stores chronic conditions in a table. Another stores them as freeform notes. Another doesn't track them at all.
Most teams throw bodies at the problem: train a specialist on each system, and let them learn how to navigate it. You build tribal knowledge for eClinicalWorks, Epic, Athena, Kareo, Practice Fusion, and on and on.
The other solution people gravitate toward is RPA—robotic process automation. And sure, there are companies spending millions building fragile bots that click through UI screens. That might work for the largest systems. But it doesn't scale. Not to the long tail of small clinics using unknown tools. Not to the average doctor trying to compete in a system tilted against them.
So I took a different approach.
Instead of teaching dozens of EMRs how to talk to each other, I taught each one how to speak a common language.
The architecture works like this:
This lets us train our logic once. Fix a mapping once. And everything downstream—every calculation, every rule, every report—works without touching the original EMR again.
Some people draw hard lines between the two. Personally, I treat a schema as a more precise subtype of an ontology. Ontologies describe entities and relationships; schemas add type constraints and memory layouts. But most medical ontologies, like ICD-10, are more data than schema. They define relationships and meanings—and they’re exactly what you need when you’re trying to normalize data across dozens of messy systems.
With our ontology layer in place:
We get economy of scale. A fix for one doctor in one EMR becomes a fix for every other doctor using that same system. And our downstream tools don’t care where the data came from—because by the time they see it, it’s already normalized.
The data we work with comes in every form imaginable—CSV, Excel, APIs, PDFs, ERA/EOBs, clinical notes, even scanned documents. When we encounter a new system, we feed it through a custom AI that analyzes the structure and performs an initial mapping to our internal ontology. This mapping isn’t one-size-fits-all: it’s designed to stitch data together from multiple sources. Demographics might come from one file, insurance from another, and chronic conditions from a third.
A human-in-the-loop reviews the AI’s initial mapping, validates it, and suggests improvements. These refinements are remembered—so future imports benefit from both machine deduction and accumulated human knowledge. Every new report, every edge case, every system we touch makes the AI smarter. Over time, it adapts to handle more EMRs with less effort.
The ontology itself is powered by Buffaly, and we use SemDB to handle unstructured or text-heavy inputs—ensuring the entire pipeline stays deterministic, auditable, and aligned to our semantic framework.
Eligibility checks. Billing workflows. Custom reports. All of them now run off the same ontology, regardless of where the data came from. We stopped writing custom code for each EMR. We started building reusable mappings. And now we can support the long tail of healthcare—the small practices, the rural providers, the independent clinicians—without sacrificing functionality or control.
Most of the market is optimizing for scale by chasing Epic. We’re optimizing for access by supporting everyone else.
This is how we make that possible.
