Net-apoteket
Healthcare
Designing the compliance architecture for a European online pharmacy
“Every regulated event in the pharmacy flows through one boundary we own. When the regulator can inspect you tomorrow, that is the difference between hoping you are compliant and knowing where the evidence lives.”
CLIENT
Net-apoteket
INDUSTRY
Healthcare
HEADQUARTERS
Denmark
USE CASES
Compliance Boundary Middleware
National eID Age Verification
AI Support Triage with Pharmacist Routing
Wholesale Catalogue Synchronisation
5
Regulated integrations live behind one compliance boundary
100%
Of regulated events captured in one append-only audit trail
Company facts
Organisation scale
Danish online pharmacy running over-the-counter retail on Shopware 6; catalogue of approx. 15,000 products synchronised from the wholesale supplier
Operating environment
Regulated OTC retail under the Danish Medicines Agency; national eID age verification mandated on restricted dispensing groups; GDPR Article 9 exposure on pharmacy purchase data
Primary challenge
A storefront platform cannot carry regulatory obligations; compliance needed an architectural home, and the build needed to be biddable, before anything could be built
An introduction to Net-apoteket
Net-apoteket is a Danish online pharmacy built on Shopware 6. Selling over-the-counter medicine online in Denmark is a regulated activity with real teeth: age verification on restricted dispensing groups, enforcement of the Danish dispensing rules at the point of sale, and an audit trail that stands up to inspection by the Danish Medicines Agency. Most e-commerce builds treat compliance as a checklist to clear before launch. A pharmacy cannot. Here, compliance is the load-bearing wall.
The team behind Net-apoteket came to the build as pharmacy operators, not as a webshop with a licence bolted on. Going online is not a channel decision, it is a licence decision: the online counter answers to the same regulator, the same dispensing rules and the same inspection regime as any physical counter, from its first order. That requirement shaped everything that follows.
The engagement ran from regulation to live pharmacy: the compliance architecture, the technical specification that turned it into a buildable plan, and delivery by our engineering team in gated phases, discovery first, implementation after. The pharmacy now runs on that boundary.
ARGUS Operational Audit
AItillery analysed the regulatory obligations attaching to Danish online OTC retail, mapped the five external integrations the platform requires (wholesale product feed, payments, national eID age verification, shipping, and customer support), and defined the boundary between what a storefront may own and what a regulated core must own.
The audit surfaced two distinct problems: regulation with no architectural home in a standard e-commerce stack, and a build that could not be delivered honestly without its unknowns named first. ARGUS ranked the interventions by regulatory risk and sequenced them so the architecture was fixed before the build began. The two challenges below represent that sequence.
Challenge One: Regulation with no home in the stack
The Problem
Age verification is a legal requirement on restricted dispensing groups, and a storefront platform cannot be the system of record for a regulatory verification step. If the theme changes, a plugin updates or the platform is replaced, the evidence base must survive untouched.
Danish dispensing rules classify every product into dispensing groups with different rules for sale. Enforcing that logic in theme code couples regulatory behaviour to the most frequently changed layer of the stack, which is precisely where it will eventually break.
The Danish Medicines Agency inspects. Standard e-commerce logging is operational logging, not audit evidence. An inspection-ready trail must be append-only, complete across every regulated event, and retained on a documented schedule, none of which a storefront provides natively. And the commercial exposure is binary: an online pharmacy that cannot evidence compliance is not fined into compliance, it is taken offline, and for an e-commerce business every day offline is the entire revenue line.
Pharmacy purchase data carries GDPR Article 9 exposure under recent European case law, where enforcement scales with global turnover rather than being capped at a fixed fee. Any support tooling, AI-assisted or human, that touches customer questions about medicine needs a structural answer to where health data may and may not flow.
The Solution
AItillery designed the architecture around a custom middleware layer as the regulatory boundary. The middleware does not just integrate the five external systems. It adjudicates. Four components define the design:
Compliance Boundary Middleware: six responsibilities held exclusively inside the boundary: age verification orchestration through the national digital identity system, dispensing group gating driven by each product's release code, an append-only audit trail designed for five-year retention, the integration adapters for all five external systems, regulatory routing, and reconciliation against source-of-truth systems because webhooks fail in the real world.
National eID Age Verification: full-page verification through Denmark's official digital identity infrastructure, with the middleware validating the result and recording the verified outcome as audit evidence, keeping the storefront out of the regulatory loop entirely.
AI Support Triage with Pharmacist Routing: customer support built on a three-tier model where AI handles product and order questions, and the middleware's regulatory routing detects clinical intent and hands those conversations to a pharmacist. Compliance by routing: the system inspects intent without storing health data, which is the structural answer to Article 9.
Storefront as commodity: Shopware owns catalogue, checkout interface and customer accounts, and at the regulatory boundary it queries the middleware and acts on the response. Nothing regulated lives in theme code.
The Result
Age verification, dispensing-group gating and the append-only audit trail run in production, and the Danish Medicines Agency's inspection surface is one system with one owner, not logic scattered across a theme, a plugin set and a support tool. The storefront is replaceable without regulatory consequence: a new theme, a new framework, even a full re-platforming away from Shopware would leave the audit evidence base untouched. And the design was strong enough to hand to our engineering team as a fixed architectural given rather than a topic for debate.
“The middleware is the pharmacy. The webshop is just the counter.”
Challenge Two: Delivering a regulated build without drift
The Problem
An architecture is not a buildable object. Without a specification, delivery estimates become guesswork dressed as planning, and every unknown surfaces mid-build, where correcting course costs the most.
Regulatory grounding had to be verifiable before anything was built. A build resting on a misread executive order, wrong webhook events or an invented data model surfaces as expensive confusion mid-build, at exactly the point where a regulated launch cannot absorb it.
A pharmacy build cannot absorb normal software-project drift. Every week of slip is a week of regulated inventory, staffing and launch commitments moving with it.
The Solution
AItillery wrote the build down completely, then our engineering team delivered it in gated phases:
Technical specification: a 23-page specification covering all five integrations, the middleware's responsibilities, and the order flow end to end. Every regulatory citation, webhook event name and data reference fact-checked against primary sources before the build began.
Gated delivery: a fixed two-week discovery phase closing the named unknowns first, followed by phased implementation of the five integrations behind the boundary, each proven against realistic order flows before the next was brought live.
Governance held throughout: production data walled off until a data processing agreement was in place, the middleware's intellectual property sitting with the pharmacy from day one, and every regulated design decision documented so the build itself carries an audit trail.
The Result
Five regulated integrations run live behind the compliance boundary. A catalogue of approximately 15,000 products synchronises from the wholesale supplier, age verification runs on every restricted purchase, and the append-only audit trail captures every regulated event. The pharmacy went from gated discovery to live operation in months, and every regulated commitment made in the specification held through to production.
“We shipped a regulated pharmacy in months. Not because we hurried, but because nothing had to be decided twice.”
Next phase
The boundary was designed past the launch scope. Two expansions are already laid into the architecture and the build, technically and regulatorily:
Full prescription solution: the identity layer already verifies customers at the strength prescription dispensing requires, the product data model carries prescription flags from day one, the dispensing- group gating extends to prescription groups without structural change, and the append-only audit trail is the evidence base a prescription operation must stand on. Connecting the national prescription infrastructure is an integration on the existing boundary, not a rebuild.
AI healthcare concierge: the compliance-by-routing pattern is the regulatory foundation an advanced healthcare concierge needs. The middleware already inspects intent without storing health data and routes clinical questions to a pharmacist; a full concierge extends that triage with deeper, personalised guidance while the boundary keeps GDPR Article 9 exposure structural, not aspirational.
Neither expansion requires new compliance architecture. Both run on the boundary that is already live.
