What a build includes

Booking through what you already use

Yes, you can add online booking to your website without changing the tool your team already uses. A Monograph site links to your booking system or to the patient tool your EMR is already connected to, embeds it inside your page where the vendor supports that, or routes a request into it, so patients book in a few taps and your staff keep one calendar. The systems, the methods and their status are in the table below.

Whatever you run now, the site links to it or embeds it. Nobody at the practice learns a second system, and there is no second calendar to reconcile at the end of the day. The work is in the path to the booking: the button is where a patient looks for it, the service pages say what can be booked and what cannot, and the steps between arriving and booking are as few as the tool allows.

If you are not running anything yet, we will look at what your profession and province use, and connect the one you choose.

The four ways a site connects

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.

1. Link or buttonThe 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 embedThe 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 connectorYour 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 requestA 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.

Systems, methods and status

Researched examples, checked against each vendor's current public documentation. Naming a product here does not mean the vendor endorses Monograph or that a connection has been built for a client. What a vendor allows depends on the product, the edition, the enabled modules and your contract with them, so each route is confirmed for your practice at proposal.

Status as of 1 October 2026. A system not listed here can usually be linked or embedded; ask and we will confirm before you buy. Product names belong to their vendors and appear here to describe compatibility, not endorsement.

What integration does not mean

• No form on a site we deliver asks for personal health information, and the message field asks patients not to include it. Forms collect contact details and a short message; refill, transfer, intake and booking requests are routed into your own system or a Canadian hosted intake tool, never by plain email.
• Monograph does not hold your appointment data, your patient records or your prescriptions. What a patient can do inside the booking or request step is set by your system, not by the website.
• A click on a booking button is counted by the website as a click, in your own first party analytics. A completed booking is counted only where the vendor permits it; some booking tools, Cortico among them, do not run third party scripts inside the booking flow, so the website never claims to know what happened after the click.
• A website does not replace your clinical record, your province's prescribing infrastructure or your insurer's adjudication. Claims tools such as TELUS Health eClaims and CDAnet are used by your staff inside your practice software; the site only explains your billing policy.
• Nothing is described as connected until it has been scoped for your system and version and tested with non patient data. Vendor fees for portals, interfaces or add on modules are yours and are listed in the proposal.

What you get

• Your booking tool linked or embedded, whichever it supports
• One calendar for your staff, with no second system to keep in step
• Booking paths on the pages patients actually land on, not only the home page
• Clear wording on what can be booked online and what needs a phone call
• Booking tested on a phone before launch

What it does not do

• We do not replace your booking tool and we do not hold your appointment data.
• What a patient can do in the booking step is set by that tool, not by the website.
• If the tool has no embed or link that works on a phone, we will tell you before you buy.

Where it sits. Listed under Essential as booking or contact integration. See the three build tiers.

Related: Medical clinic websites, Physiotherapy websites.