Case study 05
Connected Pharmacy Operations Platform
Pharmacy operations rarely fail because the information does not exist. The harder problem is that sales, inventory, purchasing, compliance and management activity tend to sit in separate workflows, separate reports and separate responsibilities. IMTISUITE was designed around a different premise: connect those operational domains into one platform, while giving each user the workflows that belong to their role.
Product StrategyHealthcare OperationsWorkflow ArchitecturePlatform Design
The problem IMTISUITE addresses is not a missing feature. It is that the decisions a pharmacy makes every day depend on each other, and the tools that support them usually do not.
What sells changes what should be held. What is held changes what should be bought. What is bought changes supplier position and cost. Each of those is well understood on its own; the dependency between them is where the judgement actually sits, and it is the part no single tool tends to hold.
Teams can usually get to the information eventually. Getting to it means moving between places, reconciling what each one says, and forming the connected picture in their heads rather than reading it.
Compliance activity and commercial activity operate on the same stock, the same suppliers and the same business, yet they are commonly supported by unrelated systems — as though controlled medicines and margin belonged to different operations.
A pharmacist, a distribution operator, a manager and a regulatory user need different views and different actions. Giving all of them the same screen serves none of them well.
Adding an isolated report to an already fragmented estate produces one more thing to reconcile. What management needs is connected visibility, not additional output.
Healthcare workflows carry obligations about who did what, to which stock, and on what authority. That has to be part of how the system is structured rather than something added on later.
Growth from a single pharmacy to several branches, or to several organisations, is not more of the same work. A structure built for one implementation has to be rebuilt for every new one.
The case for connecting these domains is not elegance. It is that every one of them is already making decisions with incomplete sight of the others.
Connecting a platform does not mean showing every user everything. It means the information is related — and the access is not.
Sales, stock, purchasing and workflow information should connect rather than each be interpreted in isolation and reconciled afterwards by whoever happens to be looking.
Inventory, purchasing, pricing, suppliers and customers all contribute to commercial performance. Seen separately, each looks defensible while the combined position drifts.
Compliance and regulatory activity need clear ownership and traceability — which means being structured into the platform rather than tracked beside it.
Different users need appropriate access to different operational responsibilities. Access design is part of the product, not an administrative afterthought.
A product architecture should support expansion without the system being rebuilt separately for every site it reaches.
I defined the product direction from the operational problems outward: analysing pharmacy workflows, identifying the shared data and decision points, structuring the platform around role-specific responsibilities, designing the product experience, and progressively building and validating the implementation.
The product direction, the architecture and the implementation are mine. This is not a case study about a team.
Set the product direction — what IMTISUITE is for, which operational problems it exists to address, and, just as importantly, what it is not trying to be.
Worked through how pharmacy and distribution operations actually run day to day, from years inside them, rather than from a specification of how they are supposed to run.
Identified the information and decision points the domains genuinely share, and separated them from the ones that only look shared — which is what determines where a platform can be connected and where it must not be.
Designed the platform architecture and the role contexts: what each portal is responsible for, what it can see, and how the workflows behind them relate.
Decided what to build first and what to leave — a product of this scope fails by attempting everything at once far more often than by attempting too little.
Built the implementation: the working product components and the workflows behind them, rather than a specification for somebody else to build.
Tested the product against real operational scenarios and against how the work is genuinely done, and changed the design where the two disagreed.
Refined the product through implementation — workflow, terminology, access design and structure all moved as building revealed what the earlier thinking had missed.
IMTISUITE is organised as three operating contexts over one connected platform. They are not three products that happen to share a name.
IMTISUITE — one connected platform
Run daily pharmacy operations with connected control across sales, inventory, purchasing, compliance and clinical workflows.
Manage distribution with connected visibility across inventory, purchasing, suppliers, pricing, customers and commercial operations.
Support governance, compliance and regulatory oversight across connected pharmacy operations.
The portals are entry points into different responsibilities, not separate systems. What differs between them is the work each is accountable for — not whether the underlying operation is the same one.
Connected data and workflows, plus role-appropriate access, is what makes operational control usable.
A platform that connects everything and then shows everyone all of it has not solved the fragmentation problem — it has relocated it into a single screen.
A pharmacist, a distribution operator, a manager and a regulatory user may all work on activity that touches the same stock. That does not mean they should hold the same responsibilities or see the same surface.
Each context is defined by what that role is accountable for. It follows that the workflows, not just the navigation, differ between them.
What a role can see and do shapes how the product is used and how much of it can be trusted. It is designed alongside the workflows rather than configured afterwards.
Because the domains are connected underneath, narrowing a role’s view does not cut it off from the consequences of other people’s work — it just stops that work being that person’s to do.
The architecture follows the dependencies rather than the org chart. These are the relationships the product is built to hold.
Core operating loop
Connected outward to
Who buys, on what terms, at what price.
Obligations attaching to stock and medicine activity.
Governance, compliance and regulatory oversight.
The connected picture across all of it.
A sales pattern changes what inventory should be holding.
An inventory position changes what purchasing should be buying.
Purchasing changes supplier activity, terms and cost.
Stock and medicine activity can carry compliance implications.
Management needs sight of the relationships, not just the parts.
This is not an attempt to list every module. It is the set of dependencies that made a connected platform the right answer rather than a suite of separate tools.
The three operating contexts are not three products that share a name. They are one platform, entered through the responsibility a person holds.
A user does not choose a portal from a menu of products. The operating context follows from who they are, which is the access model made visible at the first screen.
Pharmacy, distributor operations and regulatory are presented together because they belong to one platform — the distinction between them is responsibility, not installation.
That is the sentence on the front of this site, and IMTISUITE is the largest thing it has had to survive.
I do not start with technology. I start with the operational problem.
What actually goes wrong, in the operation, on a normal day.
How the work moves, including the exceptions.
Who is accountable for what, and where judgement sits.
What the domains genuinely have in common.
The architecture that follows from all of the above.
Build it, so the thinking meets reality.
Check it against the operation; change what was wrong.
A product built the other way round — technology first, operation fitted to it afterwards — produces software that is defensible in a demonstration and awkward on a Tuesday morning.
A pharmacy screen and a pharmacy platform are different commitments. The second one has to hold up when there is more than one of everything — and most of what taught me that came from building it rather than from planning it.
The architecture separates the organisation and site a user is operating within from the workflow logic itself, so the same workflow does not have to be rewritten per location. Designing for more than one site changed decisions in the foundations, which is precisely why it could not be deferred: retrofitting it would have meant unpicking them.
Access sits in the platform rather than in each feature, so a new workflow inherits the access model instead of inventing one. That turned out to be an architectural question rather than an administrative one — better answered once in the structure than repeatedly in every feature that came after.
Capabilities the domains have in common are structured to be shared, which is what stops a connected platform quietly becoming several parallel ones held together by a common login.
The product direction includes operations enabling the modules relevant to them rather than receiving the entire surface by default.
This describes architecture and product direction. Where a capability is designed for but not yet built, it is described as designed for — not as a feature in production.
The product did not arrive fully formed, and the parts that moved most were rarely the parts that looked hardest at the start.
Understand Build Test Learn Refine
Several screens were redesigned not because they looked wrong but because building them exposed a step in the operation that the earlier map had smoothed over.
Where the product’s language drifted from the language the operation actually uses, people hesitated. Naming things as the work names them removed friction that no layout change would have.
The same underlying activity had to behave recognisably in different portals — a constraint on the platform rather than a preference within each one.
The most useful corrections came from running real operational scenarios through the product rather than from reviewing it as a design.
IMTISUITE turned a set of related pharmacy operating problems into a coherent product architecture: one environment connecting operational, commercial and governance workflows while preserving role-specific responsibilities.
Connected operations — related workflows are designed as parts of one operating environment rather than as separate tools that have to be reconciled.
Role clarity — users enter through the context appropriate to their responsibilities, and the access model is part of the architecture.
Domain-led product design — the architecture reflects pharmacy operating realities rather than generic software categories.
Scalable structure — the platform is being designed beyond a single isolated workflow or site.
Working implementation — the product moved past concept into implemented components and tested workflows.
Stated precisely: this is implemented product with tested workflows and a continuing development path. No market adoption, customer numbers, revenue, productivity figure, regulatory certification or completed production rollout is claimed here.
This was not primarily a software-interface problem. It was an operating-model problem.
The product challenge was to understand which pharmacy activities belong together, which responsibilities must remain distinct, and how the information between them should connect — and then to translate that operating model into a usable platform.
Nothing here began as a decision to build software. It began in years of running pharmacy operations and meeting the same problems in different places: stock and purchasing judged apart from each other, compliance obligations tracked beside the work rather than inside it, and management visibility assembled after the fact. A recurring problem is a product question; a one-off is not. That distinction is what this platform came out of.
Everything else in this portfolio is a piece of that question answered at smaller scale: a commercial framework, an analysis, a controlled workflow. IMTISUITE is the same reasoning applied to the shape of an operation as a whole.
IMTISUITE reflects the same principle that guides my broader work: technology should support better business decisions and stronger operations, not exist for its own sake.
Operator Analyst Designer Builder
Domain expertise decided what the platform had to understand. Analysis decided what the domains genuinely share. Product judgement decided what to connect and what to keep apart. Building it decided whether any of that survived contact with the operation.
This case study describes a product and its architecture. No customer, organisation, operational record, credential, internal identifier or unreleased commercial information appears. The platform entry is an implemented product view with account details removed; the architecture, domain and method visuals are editorial diagrams of the product structure rather than depictions of software.
Contact
If you're shaping a product around how an operation really runs — rather than fitting the operation to the software — describe the problem. I'll tell you how I'd approach it.