CleverTech nam dit platform over en moderniseerde het in plaats — geen big-bang-herbouw, maar een gefaseerde stabilisatie- en integratieaanpak op de bestaande codebase. Het werk liep langs vier sporen.
We vervingen de pipe-gescheiden tekststring door een genormaliseerde plan_slots-structuur: terugkerende sloten met dag- en weekmaskers (1-, 2- of 4-weekse cycli), een ankerdatum en geldigheidsperiodes per slot. Alle actieve plannen werden in een eenmalige, idempotente, dry-run-gevalideerde migratie omgezet (184 plannen → 954 slots), met een byte-voor-byte round-trip-controle als vangnet.
Daarop bouwden we een vooruit-genererende boekingsmotor: cyclus-bewust, DST-veilig (herschreven nadat een zomertijd-bug de week-index kon laten omklappen) en idempotent per slot/datum/tijd. Een preview-eerst genereer-paneel toont eerst wat er geschreven gaat worden voordat er iets gebeurt; alle bijwerkingen (facturatie, betaalverzoek, e-mails) staan standaard uit, zodat het "vooraf factureren"-model dat de klant bewust wilde behouden intact blijft. Een nachtelijke cron verlengt de planning rollend ("auto-extend"), met gap-detectie en herstel.
“
Ontwerpdoel van dit spoor: de handmatige boekingsinvoer terugbrengen van circa drie dagen per week naar circa een dag. Dit is het gestelde doel van het project — geen na de oplevering gemeten resultaat.
In plaats van de back-office in een keer te vervangen, introduceerden we een moderne admin-schil pagina voor pagina naast de bestaande pagina's, met dezelfde bedrijfslogica eronder. 18 gemoderniseerde admin-pagina's draaien nu op een gedeelde shell en een eigen design-systeem, met veiligheidsguards op gevoelige acties.
Op een voorheen ongeteste codebase voegden we een volwaardige testsuite toe (circa 165 testbestanden: 127 PHP-tests, een dependency-vrije JS-runner en 23 Playwright end-to-end browsertests), plus een CI/CD-pijplijn met Docker-images, migratie-gates, health checks en rollback. We voerden een gestructureerde bug-jacht uit over zes oppervlakken: alle 21 gevonden defecten kregen een eigen regressietest; na drie fix-rondes resteerden 0 kritieke en 0 hoge bevindingen. Sentry-foutmonitoring en een cron-health-dashboard maakten het systeem voor het eerst echt waarneembaar.
Toen zich een echte productieverstoring voordeed, hebben we die volledig verholpen en gedocumenteerd: een ontbrekende time-out op een externe boekhoud-API kon de hele PHP-pool dichtzetten (load liep op tot 112). We voegden time-outs toe, plaatsten een samengestelde database-index die de mobiele API van een filesort naar circa 150 ms / HTTP 200 bracht, fixten vijf langlopende correctheidsbugs in de mobiele API, en schaalden de infrastructuur op — een verstoring van uren werd een rustige steady-state.
We abstraheerden de boekhoudkoppeling achter een provider-laag en voegden Xero toe naast de bestaande Sage-integratie, met idempotente factuuraanmaak en tweerichtings-statussync.
Het vlaggenschip is de Nourish-koppeling: een uitgaande sync waarbij het admin-systeem de bron van waarheid is en gegevens automatisch naar Nourish stromen in plaats van dubbel ingevoerd te worden. Omdat Nourish geen test- of sandbox-omgeving heeft, bouwden we een fixture-gedreven mock-API op basis van geanonimiseerde, productie-vormige data, met CI-gates die controleren dat er geen PII, secrets of live-hosts in fixtures of code lekken.
De koppeling kreeg een entity-matcher die clienten en verzorgers paart op naam, geboortedatum en postcode, met handmatige beoordeling voor onzekere gevallen. Een data-kwaliteitsprobleem blokkeerde aanvankelijk vrijwel alle matches: clienten-geboortedata waren grotendeels leeg (62,7% NULL, 28,6% 0000-00-00) en verzorgers-geboortedata vrijwel volledig (97,8% NULL) of in UK-formaat dat de matcher afwees. We schreven daarom een reconciliatie-aanpak die identiteiten afleidt uit het werkelijk geleverde zorgpatroon (dezelfde client en verzorger op dezelfde datum en tijd, met een fuzzy tijdsmarge) en zo de ontbrekende geboortedata omzeilt. Daarmee ging de matching van vrijwel 0% naar 100% clienten, 100% verzorgers en circa 96% van de afspraken van actieve clienten.
Twee details laten zien dat dit zorg-domeinkennis vergt, geen kale code:
- Live-in zorg uitgesloten van de sync. In het admin-systeem staat live-in zorg als een financiele 1-uurs-placeholder (puur voor facturatie); Nourish kent diezelfde zorg als de echte 16-uurs-dienst. Het klakkeloos doorzetten van de placeholder zou het echte zorgschema in Nourish overschrijven en CQC-compliance-records breken. We filteren live-in-boekingen daarom expliciet uit de sync.
- Drie lagen duplicaat-preventie. Een terugval-controle op de reeds-gekoppelde afspraak-UUID voorkomt dat circa 4.800 al gereconcilieerde boekingen opnieuw als duplicaat worden aangemaakt; een pijplijn-filter houdt reeds gekoppelde boekingen uit de wachtrij; en een fuzzy tijdsvergelijking (plus/min 30 minuten) vangt bijna-duplicaten af.
De Nourish-koppeling is gebouwd, uitgerold naar dev en productie, en in dry-run gevalideerd — bewust nog niet live-schrijvend. Dat is een opzettelijke kwaliteitskeuze, geen onaf werk: voordat er ook maar een record naar een echt zorgdossier wordt geschreven, zijn er een kill-switch, een dubbele-goedkeuringsgate (gescheiden zakelijke en technische goedkeurder, zelf-goedkeuring geblokkeerd), een afgekapte pilot-allowlist, een dry-run-grootboek en een hash-geketende, manipulatie-bestendige audit-log actief. De expliciet te vermijden faalmodus is een "verkeerde-patient"-incident; daarom is elke productie-mutatie gegated. De koppeling gaat live zodra de organisatie de laatste operationele beslissingen heeft bevestigd.
