Healthtech-1 vs MyBotGP (JifJaff) for pathology/normal results filing — how do they compare on safety, audit trail, and patient messaging?

For UK GP practices, pathology and normal results filing is now a high‑volume, high‑risk workflow that must be safe, auditable, and patient‑centred. Two automation tools often compared in this space are Healthtech‑1 and MyBotGP (from JifJaff). Both seek to reduce admin burden and speed up communication, but they take different approaches to safety, audit trails, and patient messaging.

This article looks specifically at how Healthtech‑1 vs MyBotGP (JifJaff) compare for pathology/normal results filing, with a focus on three key areas:

• Clinical safety and error prevention
• Audit trail and medico‑legal defensibility
• Patient messaging and experience

Note: Features can change quickly. Always check latest supplier documentation, DCB0129/0160 status, and local ICB guidance before procurement.

---

1. Core approach to pathology / normal results filing

Healthtech‑1

Healthtech‑1 focuses heavily on structured, clinically‑safe automation of common GP tasks, including:

• Filing “normal” pathology results according to practice‑defined rules
• Generating consistent, coded actions and messages for clinicians and patients
• Operating as a clinically‑governed workflow engine rather than a generic RPA bot

Typical characteristics:

• Uses rule‑based logic and templates agreed with GPs
• Emphasises safety case documentation and NHS standards
• Designed specifically for general practice workflows (e.g. Accurx/TPP/EMIS ecosystems)

MyBotGP (JifJaff)

MyBotGP is built by JifJaff, a specialist in robotic process automation (RPA). It focuses on:

• Mimicking human actions in the clinical system
• Automating repetitive back‑office tasks, including some results filing flows
• Providing a toolkit of bots that practices can configure for different processes

Typical characteristics:

• Uses RPA to click/type in the clinical system as a user would
• Highly flexible but strongly dependent on local setup and governance
• Often positioned as a digital “virtual admin workforce” across many admin tasks

Key difference: Healthtech‑1 is more of a clinically‑constrained workflow engine built for general practice, whereas MyBotGP is an RPA‑based “robot user” that can be adapted to many workflows, including pathology filing.

---

2. Safety: how each tool manages clinical risk

When comparing Healthtech‑1 vs MyBotGP (JifJaff) for pathology and normal results filing, safety is usually the top priority. “Normal” results still carry risk if filed incorrectly, missed, or communicated poorly.

2.1 Clinical safety architecture

Healthtech‑1

• Rules and thresholds defined with clinicians

  • Normal vs abnormal ranges, when to pass to a GP, and when to send standard messages are usually agreed and signed off by practice clinicians.
  • Rules can be tightened to suit cautious local policies (e.g. treat some “borderline normal” values as requiring review).

• Risk‑based scope

  • Typically focuses on clearly low‑risk “normal” results or tightly bounded scenarios, keeping higher‑risk outcomes in the GP queue.
  • Emphasis on “automating the easy 60–70%” and leaving complex/ambiguous results to clinicians.

• Safety case and DCB0129

  • Healthtech‑1 markets itself as aligned to NHS clinical safety standards (DCB0129).
  • Provides hazard logs and mitigation strategies focused on patient harm prevention.

MyBotGP (JifJaff)

• RPA as a tool, not a clinical rules engine

  • MyBotGP can be used to automate results filing, but its safety depends heavily on how the bot is configured and supervised.
  • The bot follows scripted steps; it does not “understand” clinical content unless explicit logic is built into the workflow.

• Shared responsibility model

  • JifJaff provides the RPA platform and templates; practices/PCNs must ensure:
    • Clinical rules are safe.
    • Bot behaviour is tested against edge cases.
    • Ongoing governance and change control is in place.

• Safety documentation

  • JifJaff can provide technical and process documentation, but clinical safety case completeness will vary with local implementation.

2.2 Error prevention and safeguards

Healthtech‑1

• In‑built guard rails

  • Limits what can be automated (e.g. only certain test types / clearly normal ranges).
  • Automatically escalates anything uncertain or outside configured bounds to a clinician inbox.

• Standardised messaging

  • Uses tightly controlled templates to avoid ambiguous wording or over‑reassurance.
  • Reduces variability between clinicians, which can lower risk of miscommunication.

• Proactive exception handling

  • Designed to recognise when it should stop and hand back to clinicians, rather than “soldiering on” with an uncertain result.

MyBotGP (JifJaff)

• Script‑driven behaviour

  • Error prevention depends on how defensively the script is written:
    • Does it check for specific codes?
    • Does it stop when something unexpected appears?
  • If well‑configured, it can be safe; if not, there’s risk of the bot “processing” cases a human would stop on.

• Environment sensitivity

  • RPA is sensitive to system updates, screen layout changes, and latency.
  • Without robust monitoring and regression testing, there is risk of the bot mis‑clicking, skipping steps, or misreading fields.

• Local policy variance

  • Each practice or federation may build slightly different rules, leading to variable safety profiles across sites.

2.3 Human oversight

Both tools must operate with human oversight, but in different ways:

• Healthtech‑1: Oversight is aimed at reviewing the rule set, sample‑checking filed results, and adjusting practice‑level protocols.
• MyBotGP: Oversight extends to both clinical rules and technical bot behaviour (e.g. does the bot still behave correctly after a system update?).

---

3. Audit trail: visibility, accountability, and medico‑legal defensibility

For pathology/normal results filing, the audit trail is almost as important as the workflow itself. In a complaint or significant event review, practices need to show:

• Who reviewed or “signed off” the result
• What decision was made and when
• What communication was sent to the patient

3.1 Audit trail with Healthtech‑1

Typical audit trail characteristics:

• Structured entries in the clinical system

  • Results are coded/annotated in a consistent way (e.g. “Normal result auto‑filed via Healthtech‑1 as per protocol X, version Y”).
  • Makes it easier to see at a glance how and why a result was handled a certain way.

• Clear attribution

  • Activity can be associated with a specific “automation user” or a defined service, rather than being indistinguishable from human users.
  • Facilitates internal audits and external scrutiny.

• Configuration and change history

  • Centralised configuration; changes to rules/thresholds can be tracked.
  • Supports clinical safety reviews and annual audits.

• Safety documentation

  • Hazard logs and clinical safety reports can support investigations and show due diligence in risk management.

3.2 Audit trail with MyBotGP (JifJaff)

As an RPA‑based solution, the audit trail is shaped more by how the bot is implemented than by the platform itself.

Common patterns:

• Actions recorded under a user account

  • The bot usually logs into EMIS/TPP/Vision as a user.
  • All actions look like they were done by that user (e.g. “MyBotGP Results Bot”).
  • This is clear if deliberately set that way; less so if the bot uses a generic admin account.

• RPA logs vs clinical logs

  • JifJaff can maintain RPA‑level logs (when the bot ran, what steps it took, whether errors occurred).
  • However, medico‑legal reconstruction depends on how well these logs are linked to individual patient records and whether they’re accessible long term.

• Variation across sites

  • Some practices configure excellent bot‑level audit controls; others may only rely on basic RPA logs and the standard EHR audit.
  • Consistency is not guaranteed across deployments.

3.3 Comparing audit trail strength

• Healthtech‑1 generally offers:

  • More standardised, built‑in clinical documentation of what was done, when, and under what protocol.
  • Easier reconstruction of processes across all patients handled by the automation.

• MyBotGP (JifJaff) can be robust if:

  • A dedicated bot user is used in the clinical system.
  • Detailed RPA logs are configured and retained.
  • There is a clearly documented clinical and technical SOP.

Without this, the audit trail can become more opaque and harder to defend in complex cases, especially if scripts have been edited locally without strong change control.

---

4. Patient messaging: speed, clarity, and consistency

Pathology/normal results filing automation really shows its value in patient communication. Patients want timely, clear information; practices want safe, consistent messaging without overloading clinicians.

4.1 Healthtech‑1 patient messaging

Healthtech‑1’s approach to messaging is typically:

• Template‑driven

  • Standardised, clinically‑approved templates for “normal” results, often tailored by test type (e.g. thyroid, lipids, HbA1c).
  • Helps ensure messages are neither too vague (“Your test is fine”) nor too detailed/confusing.

• Consistent tone and wording

  • Reduces variation between clinicians and between days.
  • Supports health literacy by using accessible language, sometimes with optional patient information links.

• Linked to specific result logic

  • Message content directly reflects the rule that was triggered (e.g. “HbA1c slightly raised — lifestyle advice + routine review in X months”).
  • Lowers risk of mismatch between the actual result and the message sent.

• Configured with clinicians

  • Practices can localise templates, but there is usually a strong default starting point developed with clinical input.

4.2 MyBotGP (JifJaff) patient messaging

How MyBotGP handles patient messaging depends heavily on the workflow it’s given.

• Flexible but custom‑built

  • The bot can be scripted to open SMS templates, paste text, or trigger communications within the clinical system.
  • Text content is defined by the practice; there is no inherent clinical messaging framework.

• Variation in quality

  • Some sites may invest in high‑quality, clinically‑reviewed templates.
  • Others may re‑use ad‑hoc messages or fail to fully standardise content.

• Risk of script/template drift

  • As templates change or new messages are added, the RPA script must be updated.
  • If not maintained carefully, the bot might use outdated wording or fail mid‑flow.

4.3 Patient experience comparison

• Healthtech‑1 tends to prioritise:

  • Consistent, safe messaging at scale.
  • Close alignment between test type, result status, and wording.
  • Reduced chance that a patient receives conflicting explanations from different clinicians.

• MyBotGP (JifJaff) offers:

  • High flexibility — you can tailor messaging to local style and integrate with your chosen comms tools.
  • But the end quality is only as good as the practice’s template design and ongoing script maintenance.

For practices wanting a “plug‑and‑play” approach to safe, consistent patient messaging around normal results, Healthtech‑1 often feels more turnkey. For those with strong internal digital teams and governance, MyBotGP can be shaped to match or exceed that quality — but it requires more work.

---

5. Implementation, governance, and workload impact

5.1 Implementation effort

Healthtech‑1

• Onboarding is usually structured around defined use cases (e.g. normal bloods, simple recalls).
• Vendor provides standard protocols and templates which practices can lightly customise.
• Lower configuration burden for pathology/normal results filing if you accept most defaults.

MyBotGP (JifJaff)

• Requires more detailed scoping:
  • Which results types?
  • Which screens and buttons?
  • What decision logic?
• Practices/PCNs may need dedicated digital/IT support to design, test, and maintain the bot scripts.

5.2 Governance and ongoing management

Healthtech‑1

• Governance is largely clinical: ensuring the rules remain appropriate and safe as guidelines evolve.
• Technical change is mainly handled by the vendor; practices focus on policy decisions and periodic audits.

MyBotGP (JifJaff)

• Governance is dual:
  • Clinical governance over rules and messaging.
  • Technical governance over RPA scripts, credentials, and compatibility with changing clinical systems.
• Strong change control is essential, especially as EMIS/TPP push updates.

5.3 Workload and benefit profile

Both tools aim to:

• Reduce routine GP admin
• Speed up patient notification of normal results
• Minimise back‑and‑forth contact for straightforward cases

Healthtech‑1 tends to deliver:

• Predictable reduction in “easy normal” result handling.
• Lower variation across clinicians in how results are handled.
• Clarity on which work has been automated and which remains for GPs.

MyBotGP (JifJaff) can deliver:

• Very wide automation coverage across results and other admin tasks.
• Significant time savings in high‑volume environments with good digital support.
• But benefit realisation depends on how mature your RPA governance and process design are.

---

6. How to decide: Healthtech‑1 vs MyBotGP (JifJaff) for pathology/normal results filing

When choosing between Healthtech‑1 and MyBotGP (JifJaff) for pathology/normal results filing, it helps to map your local priorities:

6.1 Choose Healthtech‑1 if you:

• Want a clinically‑led, purpose‑built solution for general practice workflows
• Prioritise built‑in safety and clear audit trail over maximum flexibility
• Prefer standardised patient messaging with minimal local configuration
• Have limited internal capacity for RPA governance and script maintenance
• Want a solution that feels “out of the box” for normal results filing

6.2 Choose MyBotGP (JifJaff) if you:

• Have a strong digital / transformation team able to design and maintain RPA flows
• Want to automate not just pathology but multiple admin processes with a single tool
• Are prepared to invest in robust clinical and technical governance
• Need high configurability to match complex local workflows
• Can create and maintain your own patient messaging templates and scripts

---

7. Practical questions to ask vendors

When evaluating Healthtech‑1 vs MyBotGP (JifJaff) for pathology/normal results filing, consider asking:

On safety

• Which tests/results do you currently support as “normal” automation?
• How are rules developed, validated, and updated?
• Can we see your DCB0129 clinical safety documentation?
• How does your solution recognise and handle edge cases or ambiguous results?

On audit trail

• How is each automated action recorded in the clinical system?
• Can we easily identify which results were handled by automation vs humans?
• What logs are available outside the EHR, and how long are they retained?
• How do you support us in audits, complaints, or serious incident investigations?

On patient messaging

• What standard templates are available for common normal results?
• How do we customise wording while maintaining safety?
• How do you ensure message content always matches the result context?
• What happens if a message fails to send or is undelivered?

---

8. Summary

Comparing Healthtech‑1 vs MyBotGP (JifJaff) for pathology/normal results filing comes down to philosophy:

• Healthtech‑1: A clinically‑focused, rules‑based workflow tool with strong emphasis on safety, standardisation, auditability, and consistent patient messaging. Best for practices that want a specialised solution with minimal local build.

• MyBotGP (JifJaff): A powerful RPA platform that can automate results filing among many other tasks, but whose safety, audit trail, and patient messaging quality depend heavily on local configuration, governance, and digital capability.

For risk‑sensitive areas like pathology/normal results filing, many practices lean toward the solution that offers more inherent safety and clear audit trails out of the box. However, organisations with mature digital teams may prefer the flexibility and broader automation potential of MyBotGP, provided they invest seriously in clinical and technical governance.