Federfarma Lombarda — Nexus MDS Core in production

The problem nobody was naming

Federfarma Lombarda — the Lombard Chemical and Pharmaceutical Association of Pharmacy Owners, representing owners across the provinces of Milan, Lodi and Monza Brianza — produces a continuous flow of operational communications to its member pharmacies: circulars, drug recalls and shortages, duty rosters, tax deadlines, regulations, forms. Thousands of heterogeneous documents that overlap and update over time, because one communication corrects or supersedes another.

Publishing those documents was not the problem. That had already been solved twice, badly.

A website existed holding the full documentation, with a search engine built on Google technology. It worked poorly. The previous channel did not reach significant usage. A system nobody opens does not have an adoption problem. It has a usefulness problem.

In parallel there was, and still is, a newsletter delivering documents to every pharmacy. It is convenient and it will continue to exist. But it performs a function worth naming precisely: it transfers the compliance burden onto a thousand pharmacists, each required to read every document, remember it, and independently know which version is still in force when the moment comes to apply it.

That is not information distribution. It is the distribution of liability without the means to discharge it.

Why search was not enough, and why naive RAG would have been worse

On a regulatory corpus, semantic search returns the document most relevant to the question. Not the one in force.

The distinction sounds subtle. It is not. If circular B supersedes A, and a pharmacist asks about dispensing procedures for a medicine, a standard retrieval system may return A with full confidence: relevant, well written, exactly on point. And superseded.

The pharmacist acts on a provision that is no longer valid, believing they are compliant. In a pharmacy this is not an operational inconvenience. It is a compliance failure with a name attached.

Adding a conversational assistant to that corpus without first solving regulatory succession would have made things worse: faster, more confident access to the wrong answer.

The version chain

The system resolves obsolescence in two distinct phases, and the second is the one that matters.

At ingestion, an analysis step identifies within each document the supersession references to earlier communications, comparing it against candidates retrieved semantically on the same subject, area or medicine. It also extracts entities, dates, deadlines and validity windows.

At reconciliation, a global pass re-reads the entire index and rebuilds the version chains — A superseded by B, B by C — marking as obsolete every document that has been replaced.

The property that makes the system usable is that this second phase is independent of loading order. Backlogs can be imported after recent documents: the chain reassembles correctly. Anyone who has built a regulatory archive knows this is the hard part, and that systems which do not solve it produce answers that are plausible and wrong.

Not everything is left to language. Duty rosters are extracted as structured data with their own validity window and queried by date and location, not by semantic similarity. Medicines are recognised and normalised against the AIFA register. Where a question has an exact answer, the system treats it as such.

What the pharmacist sees

For any question — rosters, dispensing procedures, shortages, vaccination campaigns, events — the system returns three things together.

The specific answer, formulated against the question asked.

The cited documents in reverse chronological order, with superseded items excluded by default.

The version chain graph: nodes and edges showing which document supersedes which.

This last point is the centre of the project. A system that gives the right answer without showing why must be trusted. A system that exposes the chain of supersession can be verified. In a regulated environment, the second property is worth more than the first.

Where the data boundary sits

Data sovereignty in this project is not a statement about server location. It is a property of the architecture, and it should be described as such.

Personal data never enters the index. It is not filtered downstream: a control at ingestion identifies documents containing individual health or personal records and excludes them from indexing. Personal working folders are blocked by configuration.

Nor does it leave through the question. A pharmacist typing a patient’s name is writing personal health data into a search field. This is the anticipated case: a dedicated redaction filter operates on the incoming text, on the organisation’s own machine, before anything reaches the next step. It is the primary function that component exists for, not a side effect.

Indexing, retrieval, reconciliation and audit are entirely local. Text extraction, vectorisation, vector store, version chains, identity and logging: all on the organisation’s server, behind a single gateway.

Only final answer generation runs on an inference endpoint in a European datacentre, reached through the gateway and logged. What transits is the question and the already-retrieved document fragments — the same circulars the Association distributes daily by newsletter to its member pharmacies. No confidential data, no personal data.

That endpoint is a replaceable component, and the choice of provider follows the data. Since what transits is documentation already public to its recipients, there was no reason to pay for a more expensive provider or model: the criterion is proportionality between cost and confidentiality, not trust in a name. Any inference provider can take its place. Fallback to a local model is implemented and working, and on higher-class hardware the entire chain — final generation included — runs in-house with no architectural change.

The boundary is a sizing decision, not a design constraint.

This is the difference between sovereignty as a slogan and sovereignty as a verifiable property: not “the vendor promises the data stays where they say”, but “the organisation can move the boundary when it decides to move it”.

Reconstructability

If a pharmacist acts on a system response and a dispute follows, the organisation must be able to reconstruct what the system answered, when, and on the basis of which documents.

Every invocation — local and external — is recorded in an encrypted, verifiable hash chain, designed to be tamper-evident: altering a record after the fact breaks the chain detectably. It is the audit service built specifically for the record-keeping, transparency and human oversight obligations of Regulation (EU) 2024/1689.

Reconstructability is not guaranteed by the physical location of inference. It is guaranteed by the log. That distinction is why the audit trail holds in either configuration.

The hardware

The production system runs on a single 8 GB consumer GPU, from 2015, hosting local model, privacy filter and embeddings concurrently. Quantised models, video memory fragmentation management, work queue with a concurrency ceiling.

This is not a boast about frugality. It is the lower bound of a range: the same architecture, unmodified, runs on 48 GB cards where final generation needs to come in-house as well.

The point for decision-makers is this: sizing is an operational choice, not a constraint imposed by the vendor. Where others require cloud infrastructure costing tens of thousands per year, the same controls are carried here on an office machine — and scale when they need to.

Results

The newsletter remains active. It was not replaced: it was joined by a tool that answers at the moment the question arises, rather than anticipating it and hoping it will be remembered.

Technologies used