Healthcare technology
Software for the pharmacy data layer.
N2 Pharmacy Analytics builds analytics software for hospitals and health systems — pharmacy operations, 340B program integrity and claims reconciliation. We work with the layer underneath the reports: the part nobody presents in a board meeting, and the part everything else depends on.
The problem
When a pharmacy number is wrong, the cause is almost always further down.
A health system runs several products that all ingest the same pharmacy data to do overlapping jobs. Each one handles it a little differently. None of them agree, and no one can say which is right.
The disagreements are rarely dramatic. An eleven-digit NDC normalized inconsistently. A package basis applied at the wrong unit of measure. Two systems that never agreed on a join key, so accumulation that should have happened quietly never did. None of it surfaces as an error. It surfaces as a savings figure nobody can trace back to a record, months later, in a meeting.
Much of that is settled before the data reaches any of them. The extract request goes to IS with a field list and no explanation of what it is for. They find the value sitting in twenty-seven tables, with no way to know which one is meant, why it lives in so many places, or how the copies differ. They choose one, reasonably, and nobody downstream ever learns which. Billing units go out as the quantity for every drug because that is the column the report offers — right often enough to pass review, and wrong where it matters most, insulin among them.
Doing it properly means understanding every operational step from the drug wholesaler to the patient to the bill, and the documentation behind each one, before a single field is chosen. That is step one, and most organizations never get to it. The good information they do have tends to be there by chance. None of which is incompetence — nobody in a health system is employed to know what a third party's ingestion logic assumes, and the vendor rarely explains it.
The tooling to go and check that layer does not exist. That is what we are building.
The other half
The answer exists. It is split between people who do not talk.
The same gap sits in front of the purchase. What a drug actually costs the organization, once everything bearing on that number has been accounted for, is rarely something anyone can produce on request. Buyers are working from a screen that shows a price. It is seldom the price the organization ends up paying, and there is usually nobody to ask.
The halves of that answer sit in different departments. Pharmacy knows what was purchased, stocked and dispensed. Revenue cycle knows what was billed and what came back. The two often do not talk — and when they want to, neither is sure what the other needs, or who to send it to.
The shape of it
Every product in this market is somebody's source of truth. None of them answers to any of the others.
That is not bad faith on anyone's part. Each of them set out to be the last tool a pharmacy leader would need — the one place you could go and be done with the question. And each of them is only part of what a health system actually runs: past the systems everyone names are the ones nobody wrote down.
Every system in this space was built to be the one ring — each the single source of truth, each ruling a different version of the same data.
The result is a landscape of rings, none of which rule anything.
We are not building another ring. We are about gathering the right data at the right time from the right source, and helping you make the right decisions for the health of your patients and your organization.
We are not interested in giving you another sophisticated, elegant or expensive way to be wrong. We are interested in being your partner, working with you to understand the problems at hand and then actually partnering with you to solve them.
Why this is still unsolved
Every product we added solved one thing and handed back three.
This is our own experience, not a survey of the market. A product would solve part of a problem and hand back three we did not have before — another export to reconcile, another place for two numbers to disagree, another system whose assumptions nobody had written down. The original problem got partly better. Everything around it got worse.
We think the cause is language. The people who understand the pharmacy and the people who build the system are usually not the same people, and rarely fluent in each other's work. A wrong assumption survives that gap and reaches production, where someone meets it at seven in the morning with a purchase to release.
A tool that solves one problem and creates three is not a net gain. We found the three ourselves, later.
And when something went wrong, the answer was a ticket. We spent a great deal of time explaining our own program to someone who had never run one, trying to establish whether a number was wrong or merely surprising.
We have had these problems
Not studied them. One of us was the pharmacy director accountable for the program when the numbers did not tie, and has been through HRSA audits from inside the covered entity. The other works as a 340B analyst and has used the products in this market first hand. That is the whole company.
We work alongside you
Hand in hand with your team, on your records — solving the problem you came with, and the ones you had not found yet, without handing you a new set you did not need.
What we are building
Two things, both aimed at the same layer
Claims and 340B analytics
A platform for reconciliation and program integrity work across pharmacy dispensing, medical claims and wholesaler purchasing data — with findings that trace back to the underlying records rather than asserting a total.
An analysis workbench
Tooling for the pharmacy and 340B analysts doing this work by hand today: interrogating source data, explaining exceptions, and turning a repeatable investigation into something that can be run again.
Both sit alongside what a health system already runs, rather than in place of it. Nothing has to be switched off, replaced or migrated. We bring in and organize data of our own, and do the work outside the systems already in place — so that a number can be checked against something that had no hand in producing it.
Both are in development. Neither has been released, and we are not yet taking customers.
How we use AI
Deterministic where it counts.
Core claims processing, reconciliation, eligibility and compliance logic is ordinary deterministic software. It does not guess, and it produces the same answer twice.
Artificial intelligence sits above that, over results the software has already produced — explaining why something was flagged, summarizing what changed, pointing an analyst at what deserves attention next, and drafting text a person then reviews.
- No final clinical decisions. The model does not decide clinical questions or determine regulatory compliance.
- No autonomous consequential actions. Transmitting a claim, changing a record or sending a customer communication requires deterministic application controls, explicit human approval, or both.
- Human review before anything ships. Generated code, analysis and outputs are reviewed by our people before they go into production software or to a customer.
More on how we handle data is on the security page.
Who we are
Two founders, and both of us speak pharmacy and system.
N2 Pharmacy Analytics LLC is a Texas limited liability company, self-funded, founded in 2026. It has two principals.
The problems above are not market research. They are the ones our pharmacist founder kept running into as a hospital pharmacy director responsible for 340B, and the ones our technical founder meets as a 340B analyst. After looking for the tooling to solve them, we concluded it had to be built.