SemDB is a semantic database developed by Intelligence Factory to address the limitations of existing retrieval and generation systems when working with legacy, fragmented, or semantically complex data. Built as part of our core technology stack in Orlando, Florida, SemDB is designed for environments where trust, auditability, and system integration are essential—especially in regulated industries like healthcare. Unlike vector-only or generative systems that suffer from hallucinations, semantic ambiguity, and limited reasoning capability, SemDB uses structured ontologies, hybrid embeddings, and local integration to create a data layer that can be queried deterministically and acted upon directly.
One of our clients faced a high-stakes regulatory audit with little time and even less structure. Their call center had logged over 10,000 recorded phone calls—completely unorganized and entirely unlabeled. There were no tags, no metadata, and no linkage to downstream records. The only fallback plan involved listening to each call individually, deducing the caller's identity from the audio, and manually verifying whether their issue had been resolved. This process, if followed, would have consumed weeks of staff time across multiple departments and left them with unverifiable edge cases. The client asked us for help.
I was approached by a software vendor in the aviation industry who wanted to explore integrating AI into their platform. The motivation was straightforward: enable natural language interaction with their data. The challenge, however, was anything but simple.
Their core data lives inside a multi-terabyte Oracle database comprising over 900 tables and thousands of columns, many with cryptic, unintelligible names—things like MT05_TRK_LNK, ORD_HDR_FLG_X, or INV_RSRC_IDX. Even if we could make semantic sense of the schema, there's no way to cram more than a few hundred kilobytes of structure into an LLM’s context window. And of course, sending sensitive industrial data across the internet to OpenAI or Anthropic was a nonstarter for both security and regulatory reasons.
I built this project because ChatGPT was becoming a problem. Not because it’s useless—quite the opposite—it’s too good at confidently saying things that sound correct. In the world of specialty billing, especially for Medicare and insurer-specific rules, that can mean confidently filing incorrect claims. I started seeing this more and more with our billing partner, Medek Provider Network. Billers would argue about the right way to handle something, and it turned out they were quoting competing versions of ChatGPT like two LLMs debating through human proxies.
This isn’t the future we want. At Intelligence Factory, our billing automation system (FairPath) needs one source of truth. That’s why I built an internal knowledge base—grounded, curated, and semantically indexed—to serve as the backbone for how our systems understand medical billing.
AI agents are increasingly used in real-time customer service conversations, but as adoption increases, so do the risks of low-quality output: hallucinated facts, misinterpreted inputs, and unresolved objectives. These aren’t abstract concerns—they erode trust, create confusion, and often result in unmet customer needs.
This project was designed to solve exactly that: we built a real-time hallucination detection and correction pipeline for AI Voice Agents inside Feeding Frenzy CRM. The system runs on Buffaly, our in-house implementation of OGAR (Ontology-Guided Augmented Retrieval), and operates at runtime to monitor AI behavior, catch mistakes, and redirect the conversation.
Most high school math students have come across the Traveling Salesman Problem. It’s a classic way to illustrate how complexity explodes factorially when you try to optimize a route between cities. Now imagine a similar problem—but with a moving graph, unpredictable demand, and golfers who get ornery if they don’t get their drinks in time.
Welcome to the Traveling Beer Girl Problem.
During the height of the COVID-19 pandemic, SafePass began as a secure mobile application for storing encrypted vaccination documentation on the blockchain. But when news broke of a pending federal vaccination mandate for companies with over 100 employees, the problem space changed overnight. Employers across the country were about to become responsible for tracking not only the vaccination status of their workforce, but also weekly testing, exemption requests, and live proctoring of tests—all while maintaining HIPAA compliance and data security at scale.
So we built it.
Our client, one of the largest RPM providers in the country, came to us with a very specific problem: they were responsible for communicating with thousands of patients across the country, and they needed to do it safely, accurately, and at scale. Ensuring patient satisfaction was their top priority, but so was maintaining HIPAA compliance. They needed help managing everything from daily patient reminders to structured data collection—and they needed to eliminate the risk of hallucination, privacy violations, and inconsistency in communication.
I built Nurse Amy to solve exactly that.
In Remote Patient Monitoring (RPM), Chronic Care Management (CCM), and Remote Therapeutic Monitoring (RTM), clinician time is the most valuable—and the most constrained—resource. We built this project to answer a simple but frustrating question that nearly every clinical team faces: once you’ve handled the critical issues, how do you spend your remaining time in a way that is efficient, compliant, and financially sustainable?
Let me be absolutely clear: this project does not prioritize based on revenue at the expense of patient care. Critical alerts, symptoms, and emergencies are handled first by a separate triage algorithm built for safety, not billing. That’s always the priority. But after those have been handled, we’re left with a queue of lower-urgency patients—all deserving of care, but all competing for limited time.
So the question becomes: which of these patients should I call today? Who gets time? Who gets a reminder? And how do I ensure we’re not wasting effort while still providing meaningful care?
Eligibility checking—the process of determining whether a patient’s insurance will cover a particular medical program or procedure and what their out-of-pocket cost will be—remains one of the most frustrating, expensive, and opaque aspects of modern healthcare. This is especially painful for small and mid-sized practices, who lack the financial resources and IT staff of large health systems, but are expected to compete on the same playing field. Multiple clients have come to me asking the same thing: how can we perform eligibility checks at scale, accurately, and without spending a fortune on per-transaction APIs? I built a solution that delivers exactly that.
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.