The Silicon Practice disruption affects more than the page where a patient finds a practice’s opening hours. NHS notices identify website hosting, the FootFall online-consultation service and a chatbot as separate affected functions. Restoring a website therefore does not, by itself, establish that an online request can reach the practice. West and North London ICB notice
For practice teams, the useful starting point is to separate those functions from the clinical record and from alternative contact routes. The local NHS notices examined on 29 October describe different parts of that picture; none is a complete national outage audit.
A website, a request channel and a clinical system are different layers
West and North London ICB says Silicon Practice, trading as Schappit Ltd, has entered administration. Its 28 October webpage names the three affected services and tells FootFall practices to explain the loss of online consultation requests and provide alternative ways to contact them.
That is a statement about access to particular services. It does not establish that every system used by an affected practice has failed, that every previous request was lost, or that a replacement website includes a replacement consultation tool.
Bath and North East Somerset, Swindon and Wiltshire ICB makes the distinction explicit in its notice for affected practices in BSW and Dorset: it says patient records and clinical systems are unaffected and practices remain open. That assurance belongs to the local circumstances described in that notice; it is not an independently verified statement about every practice using the supplier. BSW’s local notice
The distinction also helps explain why a functioning alternative service can coexist with a broken practice website. The relevant question is which connection each service depends on, rather than whether the practice is simply “online” or “offline”.
The continuity task includes the domain and the integrations
The WNL ICB’s one-page letter asks affected practices to identify an alternative provider and establish likely transition timescales. It also names less visible dependencies: copies of essential content, account and supplier information, domain ownership and renewal, accessibility requirements, integrations, retained information and patient communications. Continuity letter, page 1 (PDF)
These are different workstreams. Recovering the text of a website does not establish control of its domain. Taking control of a domain does not reconnect an online-consultation service. Publishing a temporary contact page does not confirm the status of requests submitted through an earlier form.
The letter says the ICB does not have confirmation of how long services will remain available, while the accompanying webpage describes inaccessible functions. Those are differently scoped operational messages, not a restoration timetable. The retained uncertainty matters when interpreting an announcement or planning a transition.
For broader supplier assessment, our social-care software questions distinguish documented capabilities from the arrangements a local service still needs to establish.
Advice about existing requests must remain local
NHS Essex ICB’s north east Essex notice says information from recently submitted online consultation requests will have been shared directly with the practice and asks patients to wait for a response rather than call at that stage. It separately sets out alternative contact arrangements and lists affected practices. Essex’s request and access guidance
It would be misleading to turn that local assurance into a guarantee that any request submitted anywhere through the supplier was received. Equally, an unavailable website is not evidence that an earlier request disappeared. The relevant practice or NHS body’s current notice is needed to resolve that question.
The same caution applies to replacing a channel. A telephone number, temporary page or app link can give patients another route, but its actual function and local availability need to be clear. Our NHS App messaging explainer addresses a related distinction: access to an interface, delivery of a message and a response are separate events.