Clinical Recalls

Clinical recalls are the backbone of proactive patient care. Whether it's a cervical screening due at three years, an annual diabetic review, or a childhood immunisation schedule, recalls are how practices ensure patients don't fall through the cracks. A missed recall isn't just an administrative inconvenience - it's a clinical safety issue.

So when evaluating practice management software, the recall system should be one of the first things you examine. And this is where the difference between Jump EHR and Semble becomes stark.

Semble's Approach: There Isn't One

Semble does not have a clinical recall system. This isn't a matter of interpretation or a feature buried in a menu somewhere - it's a gap that Semble's own users have publicly confirmed. One reviewer on Software Advice noted that "there are some features which are not yet available, such as an effective recall system," while praising the platform's general usability and support.

Semble offers two workarounds that practices sometimes use in place of a recall system, but neither comes close to filling the gap.

The first is manual task creation. A clinician or administrator can create a task for a future date - "call Mrs Jones about her smear" - and assign it to a team member. This is essentially a to-do list. It requires someone to remember to create the task in the first place, provides no clinical protocol logic, and offers no way to track whether the patient actually attended. There's no concept of fulfilment, no escalation if the patient doesn't respond, and no population-level visibility of who's overdue.

The second workaround is post-appointment messaging. Semble can send an SMS or email to a patient after an appointment, with a configurable delay of hours or days. This is useful for post-procedure instructions or satisfaction surveys, but it's fundamentally reactive - it only fires after a patient has already attended. It cannot identify patients who haven't attended, which is the entire point of a recall system.

Neither workaround can define clinical protocols, automatically enrol patients based on their conditions, track recall fulfilment against specific appointment or consultation types, or provide a practice-wide view of overdue patients. In short, Semble has no mechanism for proactive, protocol-driven patient outreach.

Jump's Approach: A Purpose-Built Recall Engine

Jump EHR includes a dedicated clinical recall system designed from the ground up for primary care. It's not a bolt-on or a repurposed task manager - it's a first-class recall engine with its own data model, automation layer, and management interface.

The system operates across four tightly integrated layers: recall rules (the clinical protocols), recall enrolments (which patients are on which protocols), recall occurrences (individual scheduled recall instances), and recall triggers fired (the record of each outreach trigger executed). Each layer has full audit logging, and the entire system is driven by a domain event architecture that supports both time-based and event-based automation. Outreach itself - the actual SMS and email delivery - is handled by the workflow and communications layer, which the trigger engine invokes.

Recall Rules: Defining Clinical Protocols

Recall rules define the clinical logic for when and how patients should be recalled. Each rule is configured with a recall interval using ISO 8601 duration format - supporting any cadence from daily to yearly - along with a configurable recall window that defines an acceptable date range for fulfilment.

What makes this clinically meaningful is the fulfilment criteria. A recall rule can specify not just that a patient needs "an appointment," but that they need a specific appointment type with specific SNOMED-coded consultation outcomes. A cervical screening recall, for example, can require a screening appointment type coded with the correct clinical procedure - not just any appointment the patient happens to attend.

Rules also define trigger sequences: a series of outreach attempts at configurable intervals. A typical configuration might send an initial message on the day the recall window opens, then follow up at seven days, fourteen days, and thirty days if the patient hasn't responded. Maximum attempt limits prevent excessive contact, and the system respects patient communication preferences including channel opt-outs and quiet hours.

Rules are organisation-scoped and reusable across patients.

Recall Enrolments: Getting Patients onto Protocols

Patients are enrolled into recall rules either manually - by a clinician from the patient's Recalls tab - or in bulk from population cohorts and care gaps. Each enrolment tracks its status (active, deferred, fulfilled, cancelled, or excluded) and its provenance: how and why the patient was enrolled, with full source entity linking for traceability.

Enrolments can be deferred with a captured reason and reactivated later. When a matching appointment or consultation is completed, the recall is automatically marked as fulfilled. Every status change is recorded in a dedicated audit log with before-and-after state snapshots and actor tracking.

Recall Occurrences: The Scheduled Instances

Each active enrolment generates recall occurrences - concrete, dated recall instances with their own lifecycle. An occurrence progresses from pending to scheduled to either completed or lapsed. Each occurrence tracks its due date, its acceptable fulfilment window, the number of outreach attempts made, and what ultimately satisfied the recall (if anything).

The system's lapse handler automatically marks occurrences as lapsed when they exceed their window end date without fulfilment. This is a critical safety feature: it provides a clear, auditable signal of patients who have fallen through the net, rather than leaving overdue recalls sitting indefinitely in a pending state.

Automated Outreach and the Trigger Engine

The recall trigger runner is a scheduled job that processes pending and scheduled occurrences, calculates trigger times based on each rule's configured offsets, and fires outreach at each interval. Every trigger fires exactly once (guaranteed by idempotency records), and every outreach attempt is recorded with channel, template, status, and provider message ID.

Outreach is multi-channel - email and SMS via Firetext integration - with each channel respecting patient-level communication preferences. Templates support merge fields for patient and recall data. Staff can also manually fire triggers from the interface for ad-hoc outreach.

Population Health: Finding the Patients Who Need Recalls

A recall system is only as good as your ability to identify who needs to be on it. This is where Jump's population health layer becomes essential.

Clinical Cohorts

Jump includes a cohort definition system for identifying patient populations based on clinical criteria. Cohorts are defined by versioned SQL queries that filter patients by SNOMED-coded diagnoses, clinical findings, lab results, and demographics. The system ships with pre-built cohorts for common conditions - diabetes, hypertension, asthma - and new cohorts can be added at the platform level, ensuring clinical governance over population definitions while making them available to all practices.

Disease Registers

Built on top of cohorts, patient registries provide population-level management with automatic membership tracking, real-time member counts, configurable refresh frequencies, and a full membership audit trail.

Care Gaps

The care gap system identifies where patients are missing recommended care. Each care gap links to a patient cohort, specifies a recommended action (recall, review, or no action), and shows the matching patient count alongside existing recall enrolment counts. Staff can set up recalls directly from a care gap, with a preview mode showing affected patients before applying.

Bulk Enrolment

The bulk enrolment system enables staff to enrol all patients from a cohort into a recall rule in a single action. Preview mode shows affected patients before committing. The system identifies already-enrolled versus newly eligible patients, creates audit entries for every enrolment, and tags each enrolment with its source cohort or care gap for provenance tracking.

None of this is possible in Semble, which has no cohort definitions, no disease registers, no care gap identification, and no mechanism for bulk recall enrolment.

Workflow Automation

Jump's visual workflow automation system integrates directly with recalls. Workflows are node-based flows with event triggers (including recall.trigger, recall.lapsed, appointment.completed, and lab_result.received), action nodes (send SMS, send email, create task, update recall, wait, branch, filter), and full execution tracking.

This means a single recall trigger can orchestrate a complex care pathway: send an SMS, wait seven days, check if the patient booked, create a task for the reception team if they haven't, send a follow-up email, and escalate to the clinician if there's still no response after fourteen days.

Semble has no workflow automation system. Its only automated communication is the post-appointment message, which fires on a fixed delay after a completed appointment.

Immunisation Tracking and Care Programmes

Jump tracks immunisation records with status codes (up to date, due, overdue, not enrolled), decline reasons coded in SNOMED, and full administration details. These status codes display as colour-coded badges in the clinical summary, giving clinicians immediate visibility of a patient's immunisation status.

Beyond individual recalls, Jump supports structured care programmes for chronic disease management - programme enrolment with status tracking, condition-specific dashboards with insights (such as weight trajectory analysis or overdue follow-up detection), and recall linkage so that programmes can generate and track recalls as part of the care pathway.

Semble offers neither immunisation tracking nor structured care programmes.

Compliance and Audit Trails

Clinical recalls carry significant regulatory and medico-legal implications. If a patient's screening is missed because no recall was sent, the practice needs to be able to demonstrate what happened and why.

Jump provides audit logging across six tables covering every aspect of the recall lifecycle: enrolment status changes (recall_enrolment_audit_log), trigger firing (recall_triggers_fired), workflow execution (flow_action_logs), registry membership changes (register_membership_audit_log), cohort version activations (cohort_audit_log), and a system-wide domain event stream (domain_events) that captures all recall-related events alongside other clinical events. Every action is timestamped, attributed to an actor, and includes before-and-after state snapshots where applicable.

Semble, having no recall system, has no recall audit trail.

The Comparison at a Glance

The gap here isn't a matter of one system doing recalls slightly better than the other. Semble has no recall system at all. Jump has a full enterprise-grade recall engine with protocol-based rules, multi-step automated outreach, auto-fulfilment, lapse detection, population health cohorts, care gap identification, workflow automation, immunisation tracking, structured care programmes, and comprehensive audit logging.

• Clinical recall rules - Jump: Protocol-based with ISO 8601 intervals, SNOMED-coded fulfilment criteria, trigger sequences. Semble: Not available.
• Patient recall enrolments - Jump: Status tracking (active/deferred/fulfilled/cancelled/excluded), provenance, bulk enrol. Semble: Not available.
• Recall occurrences - Jump: Dated instances with lifecycle (pending/scheduled/completed/lapsed). Semble: Not available.
• Automated multi-step outreach - Jump: Configurable trigger sequences with SMS and email. Semble: Not available.
• Auto-fulfilment - Jump: Recall automatically marked fulfilled when matching appointment/consultation completed. Semble: Not available.
• Lapse detection - Jump: Automatic lapse marking with auditable overdue patient visibility. Semble: Not available.
• Population health cohorts - Jump: Versioned SQL-defined cohorts by SNOMED criteria. Semble: Not available.
• Disease registers - Jump: Automatic membership tracking with real-time counts. Semble: Not available.
• Care gap identification - Jump: Missing-care detection linked to cohorts and recalls. Semble: Not available.
• Bulk recall enrolment - Jump: Enrol entire cohorts with preview and provenance. Semble: Not available.
• Workflow automation for recalls - Jump: Visual node-based flows with recall event triggers. Semble: Not available.
• Immunisation tracking - Jump: Status codes, decline reasons, colour-coded badges. Semble: Not available.
• Structured care programmes - Jump: Programme enrolment, condition dashboards, recall linkage. Semble: Not available.
• Recall audit trail - Jump: Six dedicated audit tables with actor attribution and state snapshots. Semble: Not available.
• Manual task workaround - Jump: Not needed (dedicated recall system). Semble: To-do list approach, no protocol logic.
• Post-appointment messaging - Jump: Available (plus full recall system). Semble: Available (only automated outreach option).

For any practice that takes proactive patient care seriously - particularly those managing chronic disease registers, screening programmes, or immunisation schedules - this is likely the single most significant differentiator between the two platforms.

Who Should Care About This?

If your practice is small, sees patients episodically, and doesn't manage ongoing conditions, you might get by without a recall system. But the moment you're responsible for a diabetes register, a cervical screening programme, childhood immunisations, or any form of chronic disease monitoring, the absence of a recall system becomes a clinical governance gap - not just a missing feature.

Practices switching from NHS systems like EMIS or SystmOne, where recall management is deeply embedded in clinical workflows, will find Semble's absence of recalls particularly jarring. Jump was designed with these workflows in mind.

Methodology

This comparison was compiled in February 2026 using Semble's public help centre documentation (help.semble.io), product pages (semble.io), verified user reviews from Capterra, GetApp, and Software Advice, and direct inspection of Jump EHR's codebase and product functionality. Where a feature is described as "not documented" for either platform, it means we could not find public evidence of the feature - it may exist but not be publicly visible. We encourage readers to verify specific capabilities during a product demonstration.