Guide

Can a practice keep its EMR, pharmacy system or booking tool when it replaces its website?

Written by Arash Pourzare, Pharm.D., a practising pharmacist in British Columbia. Reviewed by Behnaz Alijani, Pharm.D. Published . Reviewed . Next review .

Yes. A practice can replace its website and keep every piece of software it runs. The website does not hold the record, the schedule or the billing; it connects to the part of your software that patients touch, and only in the ways the vendor supports. This page explains the two layers, the five routes, what the common Canadian vendors document, and what to confirm before anyone promises a connection.

Most practices run two layers of software. The clinical system holds the record, the schedule and the billing. The patient facing tool is what a patient touches: booking, a refill request, an intake form or a portal. A website connects to the second layer, through whatever the vendor supports, and never replaces the first.

ProfessionClinical or practice system (stays)Patient facing tool (what the website connects to)
PharmacyKroll, Propel Rx, Fillware, WinRxPharmaConnect, MedMe Health, MedEssist
Medical clinicTELUS PS Suite, TELUS Med Access, Accuro EMR, OSCAR ProOcean, Cortico, Pomelo, Medeo
Dental clinicABELDent, ClearDent, Tracker, DentrixThe booking module or patient service the practice system sells as an add on
Physiotherapy clinicJane, Cliniko, ClinicmasterPhysitrack, Wibbi
Naturopathic clinicJane, Practice Better, OptiMantraFullscript

Researched examples, not a list of clients. Each profession's page carries the full table with what a patient does and the website route for each product. Industries.

The five routes

Every connection between a website and practice software is one of these. The first three cover most practices. The fourth is a form Monograph builds. The fifth is rare and is always a separate project.

  1. Link or button.The website sends the patient to the booking page, refill tool, intake form or portal the vendor already hosts. Works with any tool that has a public address, and with the button code some vendors generate. Confirmed at proposal: The address your practice approves for patients, and any rule about new or existing patients.
  2. Vendor supported embed.The vendor's own booking or intake component runs inside your page, so the patient does not leave your site. Only where the vendor documents an embed, and only when it works with a keyboard and on a phone, with a plain link as the fallback. Confirmed at proposal: The vendor's current embed documentation, the module enabled on your account, and a test on a phone.
  3. Existing vendor connector.Your clinical system already connects to a patient tool (an EMR to Ocean, a practice system to an exercise platform). The website links to that tool; the connection between the two systems is the vendor's, not ours. Confirmed at proposal: The exact product, edition and module on each side, what the connector is permitted to do, and your vendor's confirmation.
  4. Routed request.A form Monograph builds sends a refill, transfer, intake or registration request into your own system or a Canadian hosted intake tool, not to a shared inbox and never by plain email. A clinician at your practice still reviews every request. Available in Signature and Platform builds. Confirmed at proposal: The destination your team will work from, who owns it, and where it stores what it receives.
  5. Direct connection.New, authenticated data exchange between the website and your system through the vendor's own interface. Only where the vendor grants access, and always scoped, quoted and tested separately before patients use it. Confirmed at proposal: Vendor access or approval, a suitable contract, the defined data flow, a test environment, and who maintains it.

The word "integration" is used loosely in web agency proposals. Ask which of the five is meant. A link and an embed are part of any competent build and cost nothing beyond the page. A direct connection needs the vendor's access, a contract that permits it, a test environment and someone to maintain it when the vendor changes its interface.

What the common vendors document

These are the conditions the vendors themselves publish, read on 1 October 2026. They change; the current version is checked for your practice at proposal.

Jane

Jane documents booking buttons and links to Jane hosted booking, by practitioner, location or service. It does not offer an open API, and its integration program is a vetted partner route that excludes clinic built or single use integrations and direct calendar posting. A full calendar iframe is not a supported route. Jane also sells its own website builder; the case for a separate site rests on profession specific content, design, migration and clinical review, not on the booking button, which any site can carry.

Ocean

Ocean generates a booking link for each clinic, connected to a supported EMR. Its setup guidance discourages placing that link in an HTML iframe, so on a website Ocean is a link, not an embed. Compatibility is feature by feature and EMR by EMR.

The TELUS EMRs

PS Suite and Med Access route patient booking through a connected tool such as Ocean or Pomelo. The Collaborative Health Record has its own eBooking and the Connect patient app, and TELUS lists an Enterprise API as a separate, subscribed add on. That listing shows a route exists; it does not show that a given clinic's contract includes it or that any agency has access.

Cliniko and Practice Better

Both document an embed: Cliniko provides iframe code and custom booking pages filtered by practitioner, location or appointment type, and Practice Better provides service, package and program links, public booking pages and an embedded booking widget. Cliniko also documents a REST API with private keys, which belongs on a server and never in a page. An embed proves that booking can sit inside your site; it does not prove any clinical write back.

Pharmacy systems

Kroll's patient side is PharmaConnect, TELUS Health's add on for refills, prescription photos and appointments. Propel Rx is McKesson's current system, formed from PharmaClik Rx and Nexxsys; its documentation names web refill channels through banner programs, and it is not offered in Quebec. Fillware pharmacies may have a refill portal or the FillAssist app. WinRx documents booking through its Pharmacy Dashboard package. MedMe recommends a booking link per service; MedEssist documents an embed for existing pharmacy websites. None of these establishes a public API for a generic website form to write into the dispensing system, and a refill request remains a request a pharmacist reviews.

Dental systems

ABELDent, ClearDent, Tracker, Dentrix, Open Dental, Curve Hero, MaxiDent, Paradigm, and Dentitek and Progident in Quebec each sell online booking or a patient service, usually as an add on with plan conditions. Several treat a new patient booking as a request the practice accepts. Claims move through CDAnet and ITRANS inside the certified practice software, by staff, and are not a website feature.

PrescribeIT

PrescribeIT, the e-prescribing service operated by Canada Health Infoway, ended on 29 May 2026. We do not describe it as an integration, and we confirm a clinic's current prescribing workflow with the clinic and its EMR vendor rather than relying on older vendor pages.

What to confirm before anyone promises a connection

A discovery call for a practice website should collect these before a proposal names a route for any tool. If an agency does not ask, it is guessing.

  • The exact product, edition and version, and which modules are enabled. "We use Accuro" is not enough; "Accuro with Engage and Medeo enabled" is.
  • The patient facing addresses your practice approves: the booking link, the portal, the refill tool, the intake form.
  • Who may book: existing patients only, new patients, rostered patients, a specific program. This goes on the page before the button.
  • Whether a booking is confirmed at once or held as a request, so the button and the confirmation can say so.
  • Where an intake form or an uploaded document lands, who owns that account, and where it stores what it receives.
  • Vendor fees for the booking module, the portal or any interface, listed separately from the website's cost.
  • Who supports each part: the website and its links are the agency's; the booking tool and the EMR are the vendor's.

Two rules apply regardless of vendor. A staff login is never a patient destination, and a patient specific address is never placed in a permanent public link.

How Monograph handles it

Every Monograph proposal names the route for each tool the practice runs, using the five routes above, and lists the vendor conditions and fees beside it. Nothing is described as connected until it has been scoped for your system and tested with non patient data. The register of systems, routes and status is public on the integration page, and each profession's page shows the tools that profession may already use. Where a vendor's documentation changes, the register changes with it.

Questions practices ask

Do we have to change our EMR or pharmacy system to get a new website?

No. The website connects to the patient facing side of what you already run: a booking link, a refill tool, an intake form or a portal. The clinical record, the schedule and the billing stay in your system, and your staff keep working where they work now.

What is the difference between a link, an embed and an integration?

A link sends the patient to a page your vendor hosts. An embed shows the vendor's component inside your page, where the vendor documents one. An integration, in the sense most vendors use, is a direct exchange of data between systems through the vendor's interface, which needs the vendor's access and a separately scoped project. Most practice websites need the first two.

Our vendor says it has an API. Does that mean the website can write into our system?

Not by itself. A published API is evidence that a route exists, not that your contract includes it or that a web agency has access. The TELUS Collaborative Health Record's Enterprise API, for example, is a separate subscribed add on; Accuro's API needs an agreement with QHR; Jane has no open API at all. Ask the vendor what your edition includes before anyone quotes for it.

Who pays for the booking module or the patient portal?

You do, to the vendor. Online booking, portals and engagement modules are usually add ons to the clinical system, priced by the vendor. A proposal should list them so the website's cost and the vendor's cost are not confused.

Can the website replace our clinical software?

No, and it should not try. A website is not a clinical record, a prescribing system or an insurer claims channel. Claims tools such as TELUS Health eClaims and CDAnet are used by your staff inside your practice software; the website explains your billing policy and stops there.

Applies to
Pharmacies, medical clinics, dental clinics, physiotherapy clinics, naturopathic clinics and nurse practitioner clinics in Canada
Primary sources
Each vendor's current public documentation, read on 29 September 2026, and Monograph's software register
Source date
29 September 2026
Last reviewed
30 September 2026
Reviewer
Behnaz Alijani, Pharm.D.
What this page does not cover
Choosing an EMR or practice system, migrating clinical data between systems, or the terms of any vendor contract

Start with a call, or a free review of your current site

Send us your website address and the free ten point check scores it in seconds. If yours passes, we will say so.