Botcraft: at-home diagnostic testing with verified results.
A digital point-of-care platform built with Python, Django REST Framework and React, supporting at-home diagnostic testing. Patients book and attend a virtual visit, complete a test at home, and receive verified results in their own portal — a clinical pathway assembled from steps that normally require a physical location.
The challenge.
- A diagnostic result is only useful if it can be trusted, and moving testing out of a controlled clinical setting puts that trust at risk.
- The pathway spans scheduling, a supervised virtual visit, the test itself and result delivery — each a separate concern, but a break at any point invalidates the whole episode.
- Results are among the most sensitive data a system can hold, and they are delivered to patients rather than only to clinicians, so clarity matters as much as security.
- Patients are often unwell or anxious when they use it, which sets a much higher bar for the interface than a general consumer product would face.
Our approach.
- Modelled the testing episode in Django REST Framework as a single entity spanning booking, visit, sample and result, so verification is a property of the whole pathway rather than of the final step alone.
- Kept the chain of custody explicit in the data model — who was present, when each step occurred, which sample produced which result — because that record is what makes a remote result defensible.
- Built the patient portal in React with results presented plainly, avoiding the pattern of delivering a raw clinical value to someone with no context for interpreting it.
- Designed access control around the episode so a clinician sees what their involvement justifies and no more, rather than granting broad access to patient records.
- Treated the virtual visit as part of the clinical record rather than as a separate communication tool, since supervision is what distinguishes this from an unsupervised home test.
The outcome.
- The full pathway from booking to verified result runs as one recorded episode.
- Chain of custody is captured as data, which is what allows a remote result to be relied on.
- Patients receive results in a form they can act on rather than a bare value.
- Access to clinical data is scoped to involvement rather than granted broadly.
Related healthcare & life sciences work.
HealthcareFitmesh: workout, diet & social fitness.
One app replaces three for serious users.
React Native · Django · Django REST Framework · PostgreSQL
HealthcareWellthread: shared health records, plans and progress.
A web app for health & wellness, built with Google Cloud Functions. Records, plans and progress stay consistent between the user and whoever supports their care, in a product simple enough for daily use.
Google Cloud Functions
HealthcareSwiftcart: Health platform.
A web app for health & wellness, built with Flask and Python. Records, plans and progress stay consistent between the user and whoever supports their care, in a product simple enough for daily use.
Flask · Python
Where AI fits in healthcare & life sciences.
Drafting letters and summaries for clinicians to approve, patient assistants that know when to hand over, and retrieval over guidance documents, built with UK GDPR and clinical safety in mind.
Explore AI development“Dragonfly has been working with the team at Enigmatix Global for several years now on building out our web-based platform and APIs. One of their strengths is quickly building out a multi-disciplinary team to work on the development and delivery of features with different technical requirements. Their support has allowed us to accelerate our development work without building an internal team. They have also worked seamlessly with other third parties both during the acquisition of Dragonfly and development of our mobile app. Enigmatix Global has been instrumental in bringing our ideas to life and providing guidance to help us make the best technical decisions. I would recommend getting in touch with them if you're looking for support.”
Questions about this build.
Still wondering something? Ask an engineer
Model the episode, not the screens. Booking, virtual visit, sample and result belong to one entity, because the credibility of the result depends on the integrity of the whole sequence rather than the final step. Systems that model these as separate features end up unable to answer the question that matters most: whether this specific result came from a properly supervised process.
By making chain of custody explicit in the data model — supervision, timing, and the link between a specific sample and a specific result all recorded as first-class data rather than inferred from timestamps. Remote testing is not less trustworthy than in-clinic testing by nature, but it is only as trustworthy as the record it produces, so that record is the engineering priority.
Access scoped to clinical involvement rather than to role, so being a clinician does not by itself grant sight of a given patient's results. Add encryption in transit and at rest, audit logging on every access to a result, and retention rules aligned to the applicable health-data regime. The design principle is that broad access is the risk, and narrowing it is cheaper than monitoring it.
Plain, contextualised and honest about uncertainty. Delivering a raw clinical value to someone with no framework for interpreting it produces either false reassurance or unnecessary alarm, both of which generate clinical contact that the product was meant to reduce. Presenting the result with what it means and what to do next is a clinical design decision as much as an interface one.
Let's build from here.
Thirty minutes with an engineer who builds. No sales, no drip campaign. If we're the wrong fit we'll tell you and point you somewhere better.