When a leading pharmaceutical company approached us to conduct an independent technical review of their blockchain-based medicine supply chain platform, we were given access to a complete 10-document MVP specification — architecture, smart contracts, data model, roadmap, security model, legal framework, and risk register. This case study summarises what we found, what we recommended, and how the engagement shaped the platform’s direction before a single line of production code was written.
The Problem: Counterfeit Medicines and a Broken Supply Chain
The pharmaceutical supply chain in the United Kingdom faces four interconnected challenges that this client wanted to solve with blockchain technology.
First, there is a fundamental lack of transparency. When a medicine reaches a pharmacy shelf, regulators and consumers have no reliable way to trace where it originated, who handled it at each stage, or whether it is genuine. Second, counterfeit and substandard drugs enter the supply chain and reach patients — with serious health and safety consequences. Third, regulatory burden falls heavily on government agencies that struggle to oversee production, licensing, and movement of medicines consistently. Fourth, prescription control for controlled substances remains largely manual and easily circumvented.
The client’s proposed solution: a private blockchain platform where government bodies, manufacturers, and pharmacies share a single, tamper-proof ledger of every medicine unit from creation to dispensing.
Our Role: Independent Technical Review
Adexorb Technologies was engaged to conduct an independent review of the full MVP documentation set — not as the development partner, but as an objective technical voice before development commitments were made. This type of pre-development architecture review is one of the most valuable interventions we offer, because fixing a design flaw on paper costs a fraction of what it costs to fix it in production chaincode.
We reviewed 10 source documents including the executive summary, product requirements document, technical architecture specification, smart contract logic, data model, non-functional requirements, timeline and milestones, legal and commercial framework, risk register, and UI/UX wireframes.
The Architecture: Hyperledger Fabric with a Three-Organisation Network
The client chose Hyperledger Fabric as the blockchain platform — a private, permissioned blockchain where only authorised parties operate nodes. This was the right choice for a pharmaceutical supply chain, where the participants are known, regulated entities and public blockchain transparency would create both privacy and competitive exposure problems.
The network architecture comprised three organisations on a single application channel called medical-supply-channel. The Government organisation owned the ordering and endorsing nodes and was responsible for registering drug types and issuing licences. The Manufacturer organisation held endorsing peers and was responsible for creating medicine units and transferring them to pharmacies. The Pharmacy organisation received units from manufacturers and dispensed them to citizens.
The smart contract asset model was clean and well-scoped for an MVP: DrugType (a registered medicine class), License (a manufacturer’s authorisation to produce a specific drug type), and MedicineUnit (an individual unit with a unique UUID, linked to a drug type and a licence). Every ownership transfer — from manufacturer to pharmacy to citizen — was recorded as an append-only history entry on the ledger, making the full chain of custody permanently auditable.
Citizens could verify any medicine unit by scanning a QR code and querying a public verification portal using the UUID. No login required, no PII exposed — just a clean read that returns provenance data.
What We Found: Strengths and Critical Gaps
Our review identified several genuine strengths in the documentation. The Hyperledger Fabric platform choice was correct. The three-organisation channel design mapped cleanly to real-world regulatory roles. The asset model was minimal and well-scoped — a common failure point in blockchain projects is over-engineering the data model at the MVP stage. The TransferOwnership pattern with append-only history was architecturally sound. The public UUID verification endpoint was the right separation of concerns.
However, we identified several critical gaps that needed to be addressed before development began.
Single-orderer risk. The MVP specified a single Raft orderer, which is a single point of failure unacceptable for a regulated pharmaceutical system. We recommended a three-node Raft cluster from day one.
File-based cryptographic material. The architecture relied on file-based keys for the Fabric CA and orderer. For a system handling regulated pharmaceutical data, we recommended HSM-backed keys stored in a cloud vault from the start.
PII on-chain. Citizen identity data and medicine ownership transfers were planned to be stored directly on the ledger. This creates an irreconcilable tension with GDPR and the UK Data Protection Act 2018, since blockchain data is immutable but privacy law requires the right to erasure. We recommended an off-chain PII vault approach — storing only salted hashes on-chain, with the actual personal data in an encrypted database that can be deleted on request.
Missing Private Data Collections. The single-channel design meant all manufacturers could theoretically observe each other’s transfer volumes. We recommended Fabric Private Data Collections (PDC) to enforce data isolation between competing manufacturers.
Underestimated frontend timeline. The roadmap allocated three weeks for frontend development across four distinct UI surfaces — a government dashboard, a manufacturer dashboard, a pharmacy dashboard, and a public verification portal — plus a full REST API, authentication, and role mapping. Our honest assessment was that this would realistically take five to seven weeks.
AI Integration Opportunities We Identified
Beyond the core blockchain architecture, we identified three high-value AI integration opportunities that were absent from the original documentation.
The first was counterfeit pattern detection. By training a model on historical transfer patterns from the ledger, it becomes possible to flag anomalies — sudden velocity changes, geographic outliers, owner sequences that don’t match a normal supply chain pattern. This would give the government regulator dashboard genuine intelligence rather than just raw data.
The second was a citizen verification chatbot. A WhatsApp or SMS bot that accepts a photo of a medicine package, OCRs the UUID, calls the verification API, and replies in plain language in the user’s local language would close a significant UX gap. Most citizens are not going to navigate a web portal to verify a medicine — but they will send a WhatsApp message.
The third was predictive recall scoping. When a drug type needs to be recalled, an AI model could predict the geographic distribution of affected units based on historical transfer patterns, enabling targeted interventions rather than blanket recalls.
Outcome: A Significantly Stronger Platform Before a Line of Code Was Written
Our review resulted in a revised architecture specification, an updated risk register with five additional risks (including UUID enumeration vulnerability, Fabric developer scarcity, and cross-border data residency), a realistic revised timeline, and a security hardening checklist covering HSM keys, off-chain PII, recall and quarantine chaincode functions, and a formal threat model.
The client entered the development phase with a production-grade architecture rather than an MVP-grade one — which matters enormously in a regulated sector where retrofitting security and compliance after deployment is exponentially more expensive than designing for it upfront.
What This Means for Blockchain Projects in Regulated Industries
This engagement illustrates a pattern we see repeatedly. An organisation builds a technically competent MVP specification, but the gap between “works on paper” and “production-safe in a regulated environment” is larger than anticipated. The blockchain platform choice may be correct. The data model may be sound. But the security model, privacy architecture, and deployment realism often need independent scrutiny before development investment is committed.
If your organisation is planning a blockchain implementation — for supply chain, healthcare, financial services, or any regulated domain — an independent architecture review before development starts is one of the highest-return investments you can make. We find the gaps others miss, before they become production incidents.
Contact Adexorb Technologies to discuss your blockchain architecture review or development engagement.
