Why "our website and PMR don't talk" is the most expensive sentence in online pharmacy
The cost of a disconnected website is paid three times, and most owners only count the first. Operationally: every order arrives as unstructured information, an email, a PDF, a dashboard entry, that a human must read, interpret and re-key into the dispensing system, which is slow at ten orders a week and impossible at a hundred, and every transcription is an error opportunity your accuracy check then has to catch. Commercially: the ceiling on the business is set by admin capacity rather than demand, which is why disconnected operations plateau exactly when marketing starts working. And in compliance terms, the disconnection is a records failure wearing operational clothes: the GPhC's inspection findings concentrate on consultation records that cannot evidence decisions and audit trails that fragment across inboxes, which is precisely what a re-keyed workflow produces by design, the plumbing wall our analysis of why pharmacy websites fail named as the third place sites die.
The frustrating part is that the gap is nobody's fault and everybody's problem. Web developers build websites and assume the pharmacy system is someone else's domain; PMR suppliers build dispensing systems and assume the website is decoration; and the owner in the middle hears the word integration from both and reasonably assumes it means the same thing to each. It does not, which is why the next section exists.
Embeds, APIs and webhooks, translated
Three words carry almost all the weight in these conversations, and each is simpler than the people using it make it sound. An embed is a piece of another system living inside your web page: the clinical assessment a patient completes on your site, rendered by the PMR inside your page rather than on a separate site the patient gets redirected to. The patient never leaves your domain, and the answers land as structured data in the clinical system rather than as a form submission in an inbox. When Dataforge PMR questionnaires run on a pharmacy's Shopify or custom site, that is an embed doing its job.
An API, an application programming interface, is a doorway one system opens so another can pass things through in an agreed format. Your website uses the PMR's API to create an order, look up a service's availability or fetch an order's status, and the crucial property is structure: an order arriving through an API is data the PMR understands natively, patient, service, assessment, payment, not a message a human must translate. When a supplier says "we have an API", the buyer's follow-up is always "for which operations, and where is the documentation", because an API that only reads data cannot create your orders.
A webhook is the reverse of a lookup: instead of your website repeatedly asking the PMR "anything changed?", the PMR taps your website on the shoulder the moment something happens. Prescriber approved the case: webhook fires, your site updates the patient's account. Order dispatched with a tracking number: webhook fires, the confirmation email sends itself. Webhooks are what make status flow feel instant, and their absence is why some "integrated" sites show patients information that is hours stale.
What a properly integrated order journey looks like
Judge any integration by walking one order through it, because the journey either holds as a single chain of structured data or it does not. The reference version, which is the journey our order screening article documents inside Dataforge PMR: the patient enters through a condition or service page and completes the clinical assessment embedded in your site, with live identity verification at the moment of submission; payment is taken in the same flow; the order lands in the PMR as a complete, structured case, assessment answers, verification result, payment state, ready for prescriber review with no human assembly; the prescriber's decision, approve, request more information or reject, flows back to the patient through the website automatically; dispensing runs in the PMR with labels generated from the prescription record; and dispatch through the Royal Mail Click and Drop integration returns the tracking number to the order, closing the loop the patient can see.
Notice what that journey never contains: an email carrying clinical information, a spreadsheet, a re-keying step, or a moment where the website and the PMR disagree about an order's state. Notice also what it produces as a by-product: the complete audit trail, verification to doorstep, on one record, which is the exact artefact a GPhC inspector samples and the standard this series keeps returning to. Integration is not a technical nicety bolted onto compliance; done properly, it is how the compliance evidence gets generated without anyone writing it.
The impostors: things that get called integration but aren't
Four arrangements routinely wear the word integration in sales conversations, and an owner should be able to name each on sight. Email notification: the website sends an email when an order arrives, and a human does everything else; this is a doorbell, not an integration. The export-import shuffle: orders download from the website as a CSV file and upload into the PMR, usually daily, usually by the same overworked person; this is batch re-keying with better posture, and it fails the moment volume or urgency arrives. The shared dashboard: staff log into the website's admin panel to read orders and act on them in the PMR alongside; two systems, two screens, one human bridge, and the audit trail lives in neither. The redirect: the "integrated" assessment that actually sends patients to the supplier's own domain and back, leaking conversion at both hops and putting your patient journey on someone else's pages.
None of these is immoral, and a brand-new pharmacy doing five orders a week can survive on any of them for a while. The dishonesty is only in the label: each is a manual workflow with software decoration, the labour cost scales with every order, and the clinical record fragments exactly as the regulator's findings describe.
Show me an order created on the website appearing in the PMR as structured data, and a status change in the PMR appearing on the website, live, without anyone typing. That single request in a supplier meeting exposes all four impostors.
The questions to ask your PMR supplier and your web developer
The gap survives because each supplier answers only its half; the fix is asking both sides questions that meet in the middle, in writing, before contracts.
| Question | Ask whom | A good answer | Red flag |
|---|---|---|---|
| Does an order arrive in the PMR as structured data, including the assessment? | PMR supplier | Yes, via the API or native platform integration, demonstrated live | "Orders come through as notifications" |
| Which platforms do you integrate with today, not on the roadmap? | PMR supplier | Named platforms, Shopify, WooCommerce, custom via API, with live customer examples | Roadmap answers without dates, per our PMR buyer's guide |
| Does status flow back to the website automatically? | Both | Webhooks or equivalent push, with the events listed: approved, rejected, dispatched, tracking | "Patients can email us for updates" |
| Where is the API documentation, and can my developer see it before we sign? | PMR supplier | Public or shared documentation a developer can evaluate | Documentation only after contract |
| Who owns the integration when it breaks at 5pm Friday? | Both, together | A named owner and a support route agreed between the parties in writing | Each supplier pointing at the other |
| What does the integration cost, initially and per change? | Both | Itemised: build, any per-order or monthly fees, change costs | "Integration available" with no numbers |
| What patient data passes through the website layer, and where is it stored? | Web developer | Minimal data client-side, nothing clinical in analytics or URLs, storage in the PMR | Assessment answers sitting in the website database "for convenience" |
| Can we test the whole journey before launch? | Both | A staging environment and a scripted end-to-end test with dummy patients | Testing in production on real patients |
The security layer, in owner's terms
Patient data crossing between systems is still patient data, and the owner's checklist is short enough to memorise. Everything moves encrypted, which in practice means the developer confirms all connections run over HTTPS with no exceptions. Every doorway is locked: API access uses proper authentication with credentials stored securely, never pasted into page code where anyone viewing source can read them. Data lives in the right place: the clinical record belongs in the PMR, the website holds the minimum needed to serve the patient, and, per our UK GDPR guide's sharpest warning, nothing health-related ever leaks into analytics tools, advertising pixels or page URLs on its way through. And the paperwork matches the plumbing: your web developer and platform are processors handling patient data on your behalf, so processor contracts sit in the same supplier file as the DCB0129 answers, and the integration itself gets a line in the risk assessment your distance services governance already requires.
None of this needs the owner to become technical. Each item is a yes-or-no question a supplier either answers crisply or does not, and the pattern of this whole series holds: fluency under basic assurance questioning is the best free sample of a supplier you will ever get.
Where integration is heading: FHIR and the open API expectation
Two directions of travel are worth an owner's attention, because they change what "good" looks like over a contract's life. The first is standardisation: NHS interoperability is consolidating on FHIR, the modern standard for exchanging health information, and sector commentary in early 2026 was already framing the shift from legacy formats as a significant challenge for incumbent systems that under-invested in modern architecture. You do not need to know what FHIR stands for; you need to know that a supplier building on modern, standards-aligned foundations will connect to whatever comes next more cheaply than one translating from a legacy core.
The second is cultural: newer entrants increasingly advertise an open API ethos, the position that the pharmacy's data should be reachable by whatever tools the pharmacy chooses, and that stance is becoming a buyer expectation rather than a differentiator. It connects directly to the portability argument from our consolidation analysis: in a market where your supplier's owner can change mid-contract, an open, documented API is not just an integration feature, it is your exit route and your insurance, because data you can reach programmatically is data you can take with you. Hold every supplier, including us, to that expectation.
Scoping your own project
The honest sequence for an owner starting from a disconnected position has five steps and no heroics. First, map the current journey on one page: where an order is born, every hand that touches it and every system it enters, because the re-keying steps you find are the project's business case. Second, decide the destination journey using this article's reference version, trimmed to your services. Third, put the question table to both suppliers and let the answers pick the architecture, embed plus API plus webhooks where both sides are capable, or a platform with the integration native where that is simpler, which is the route Shopify pharmacies running Dataforge PMR take. Fourth, insist on the staged test: dummy patients through the whole chain, including a rejection, a refund and a failed delivery, before any real patient touches it. Fifth, launch narrow, one service end to end, then widen, the same discipline every build guide in this series has preached.
"The integration is not a line item on the website quote or the PMR contract; it is the product."
Budget honestly for the truth this article opened with: the £2,000 saved by skipping the integration is repaid monthly in staff hours and annually in inspection risk for as long as the pharmacy trades.
Key takeaways
- A disconnected website costs three times: re-keyed labour on every order, a growth ceiling set by admin capacity and fragmented records that fail the inspection standard.
- Embeds put the PMR's assessments inside your pages, APIs let systems pass structured data through agreed doorways and webhooks push status changes instantly the other way.
- The reference journey runs assessment and verification on your site, lands structured cases in the PMR, flows prescriber decisions back automatically and closes with tracking on the record, generating the audit trail as a by-product.
- Email notifications, CSV shuffles, shared dashboards and redirects are manual workflows wearing the word integration, exposed by one live end-to-end demonstration.
- Ask both suppliers the eight questions in writing, and make them agree between themselves who owns the interface when it breaks.
- Clinical data belongs in the PMR, moves encrypted, never touches analytics or URLs, and the developer handling it needs a processor contract in your supplier file.
- Standards-aligned, open-API suppliers cost less to connect and leave, which makes the open API question part of your exit planning, not just your build.
FAQs
Both sides of the gap.
We sit on both sides of this gap deliberately: Our publisher builds pharmacy websites on Shopify and Next.js, and Dataforge PMR is built to connect to any of them, natively on Shopify, via integration for WooCommerce and custom builds, so the reference journey in this article is the one our clients actually run. If your website and PMR don't talk, book a 30-minute conversation and bring your current order journey; we will map the gap with you whichever systems you keep.
Book a demo