Drupal and medical practice
Practice sites on Drupal, and the install that may not be available
Two things decide this pair and neither of them is the tag. The first is whether the practice actually administers its own Drupal site, because a large share of practice websites are built and hosted by a supplier on a shared platform where the practice manager has an editor account and nothing more. The second is that the material patients want is usually a file rather than a page.
Why this pairing is its own job
The Drupal install guide covers the tag, and the medical practice guide covers what the assistant has to know. What follows is the part that belongs to neither.
- Every route that works on Drupal needs more than an editor account. A module has to be deployed, an asset injection module has to be installed, or a theme has to be one you maintain. A practice manager on a supplier managed site has none of those, and the honest first step is a request rather than an install.
- The block route, which is the one a practice manager would find first, is the one that fails silently. The text format drops the script element on render and the editor often removes it on save, so it reads as an install that did not work rather than a route that never could.
- Practice material lives as attachments. The fee list for private forms, the registration leaflet, the practice booklet: files hanging off a node and linked from a page, so a crawl following the link is reading a document rather than the page you had in mind.
- Most practice sites hand the actual transaction to somebody else. Appointments, online consultations and prescription ordering sit on a supplier's system at another address, frequently framed inside your page, and the widget can neither appear inside it nor read anything in it.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the Drupal guide. Everything below is about where it goes on a medical practice site specifically.
Establish what you actually control before choosing a route
Sign in and look for the modules screen and the appearance screen. If they are absent, or present and read only, the site is administered by somebody else and this is a request to them with the tag and the reason attached rather than a job you can do this afternoon.
That request goes better when it is specific: one script element at the end of the page, no server component, nothing installed into Drupal itself, and one address to permit. Suppliers refuse vague requests and approve narrow ones.
If the answer is no, that is a real answer rather than a setback. A practice site on a locked platform has no route to a floating launcher, and the next question is whether the site is worth moving at the next review rather than whether there is a workaround.
Where the tag must not be
Whichever route you use, the tag lands in the page shell every front end page shares. That is what you want on the surgery information pages and it is not what you want beside an embedded appointment or consultation system.
Those systems are a frame pointing at another address. Nothing you install reaches inside it and the assistant cannot read what is in it, but it will be sitting next to it, and a patient part way through describing a symptom into a clinical form has an open chat box on the same screen.
Where a page exists only to carry that frame, keep the tag off it. On the template route that is a condition on the path; on the asset injection route it is the path conditions that module already gives you.
Test the way a patient arrives
Anonymous visitors are served from a different cache than you are, so confirm in a private window after a cache rebuild. That is true of any Drupal change and doubly worth doing here, because your entire audience is anonymous.
The practice specific part is which pages you check. Registration, opening hours, the branch page and the out of hours page carry the traffic, and on a practice site those are frequently rendered by different templates than the home page somebody tested on.
Where the answerable material lives
| Registration and how appointments work here | Ordinary nodes, crawlable as published, and the two highest volume calls at any practice with a moving population nearby. Worth checking they describe the process you run now rather than the one before the last change. |
|---|---|
| The fee list for non clinical forms | Almost always an attachment on a node rather than page text. Upload the file as material in its own right, because a crawl that follows the link is reading a document and a patient asking the price should get the current one. |
| Opening hours, branches and access | Frequently rendered from fields through a view, which produces a clean table and very little context. Make sure the page states which branch and which days in its visible text, because a table row on its own answers nothing once it is retrieved alone. |
| Anything inside the appointment or consultation system | Unreachable. It is another organisation's application at another address, the assistant cannot read it or act in it, and every question about a booking made there is a handover to the practice. |
The first thing to get right
Put the install question to the supplier in writing, and while you wait, upload the fee list and the registration leaflet as material.
The material is the part you control regardless of the answer and it is the part that takes longest to get right. If the supplier agrees you are ready the same week. If the supplier declines you have lost an afternoon and gained a written list of what patients ask that nothing on the site answers, which is the argument you will need at the next website review.
The failure that belongs to this combination
A launcher sitting beside the online consultation form
The clinical risk on a practice site is not a wrong answer about opening hours. It is a patient with a symptom choosing the wrong box. The consultation form is designed to collect that safely and is triaged by the practice, and it looks like a form. The chat panel is friendlier, replies immediately, and is right there on the same screen.
The assistant refuses symptom questions and names the emergency route, which is correct and is not the same thing as the patient having used the form. Time passes between the refusal and the patient starting again, and on a practice site that delay is the exact thing you were trying not to introduce.
Keep the tag off the pages carrying the consultation and appointment frames. On every other page it is doing what a practice wants, which is taking the registration, prescription and opening hours questions off the phone.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a medical practice visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Our website is run by a supplier. Is there anything we can do ourselves?
- Not for the install. Every working route on Drupal needs a permission an editor account does not have, and the one you can reach, a custom block, has the script filtered out on render. What you can do without waiting is assemble the material, so that the day permission arrives the setup is an afternoon rather than a project.
- Can it book an appointment?
- No. It cannot reach the appointment system, cannot see availability and cannot act on anybody's behalf. It explains how booking works at this practice and points at the route, and where somebody needs a person it takes a name, an email and a message for the practice to pick up.
- Why did my custom block do nothing?
- The text format applied to that block filtered the script element out on render, and the editor may have removed it on save before that. Nothing reports either loss, which is why it reads as a failed install. Use a module, an asset injection module, or a theme template you maintain.
Keep reading
- Installing on DrupalText formats strip script tags from blocks. Use a small custom module, an asset injection module, or html.html.twig, then rebuild the cache.
- Everything for a medical practiceAdministrative questions a practice can safely automate, the symptom questions it must never touch, and how to word the refusal.
- One university, forty sites, and the question of whose assistant this isEach department runs its own site, material and allowlist entry. Course requirements sit in fields and tabs that a plain crawl never assembles.
- A surgery site on WordPress, and the page the widget must not be onWho actually does the install when a supplier owns the site, keeping the launcher off the consultation form, and branch sites that need their own entry.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.