I was recently asked to put together an overview of how I would approach product design for DTx.

For those of you not in the know, or unsure what I mean by DTx, it’s short for ‘Digital Therapeutics’, and they are software solutions that have evidence-based therapeutic capabilities. Like digital therapy or digital medicine, digital therapeutics have a measurable impact on health outcomes. DTx can also be ‘prescribed’ by medical professionals, which is another big difference.

Digital therapeutics achieve their impact through digital interventions, which typically induce or facilitate specific patient behavior. Examples include increasing medication adherence, enacting self-care instructions, or guiding towards a healthier lifestyle. What I like about DTx as a concept, is that they’re incredibly difficult to achieve, and unlike digital well-being apps that litter the app-stores now, DTx has to follow very strict ISO and CE standards in order to get signed off in much the same way that a pharmaceutical medication would before it’s ready for public consumption.

This not only creates a layer of governance across the product, but it also ensures that teams need to be very mindful designing, building and deploying only the very highest quality functionality.

Find a Map

I’m going to walk you briefly through this little flow diagram, and we’ll whizz in and out of the main components in turn, so you can see how you might want to think about the strategic design of DTx.

People who know me well, know that I have a bit of a love / hate relationship with the ‘pen portrait’ persona. They bother me slightly because of the way they homogenise us into groups, when as we know so well now, everybody is unique and a vessel for their own quirks, thoughts, ways of behaving and modalities.

But, I would still advocating that you start all DTx product work with a detailed analysis and breakdown of the audience (a persona!). In most cases this is probably going to be; The Patient(s), The Clinician(s), any other protagonists such as the Pharmacy or say, the Technician analysing biomarkers on their dashboards.

Getting the audience definition right gives you the foundations to create a series of Experience Maps.

I’m not going to go into huge detail on what an experience map is, or how to do it properly, that’s a whole article on it’s own. I will say it’s a skill though, so swat up on it, or get UX people who understand the method. However, the value of a good set of experience maps is unquestionable as a way of guiding the design, and vision. I mean, they’re literally ‘maps’.

The questions I would use in primary and secondary research to find the friction for the personas, and guide the output of the experience maps are:

• What processes are redundant now / in the future?
• Where are you slow?
• What pathways and endpoints are confusing?
• What’s not automated that could be RPA?
• Where are we inflexible?
• What’s not in the DTx that should be?
• What should include digital or remote access?
• What should be touch-less using Ai / Data?
• Where would human pathfinding make a difference?
• What can we Buy, Build or Borrow?
• Data Matrix: Support > Service > Predictive > Perceptual (see my book)

Ultimately you use the Experience Map to determine your KPIs and OKRs. Which will be hugely important in determining how you approach the design and build of any product, but is even more imperative for this kind of product because DTx can literally have life or death consequences.

I don’t really have a preferred prioritisation technique to decide where to start. But I do often lean into the KANO model because it’s simple. Again, I’m not going to go into the details of the KANO approach, that’s another article, but loosely speaking you’re classifying the feature suggestions that fall out of the map into;

• Must-Be (will not ‘wow’, but must be there i.e Clinical)
• Attractive (make people happy, but not essential)
• One-Dimensional (happy when there, unhappy when not)
• Indifferent (No audience impact, but makes dev easier)
• Reverse (Features that make an audience unhappy, but have to be there; e.g. 2-factor authentication)

Clinician-First-Design

Now we get to some of the really interesting parts of the process — You can’t do DTx unless it’s clinically led, validated, and approved. So you might as well just run a clinician-first process, rather than focus your design work on the patient. DTx is essentially a B2B2C product mentality. That is to say you want the clinicians to define and design the pathways and endpoints. This is almost (in my view) the most significant difference between a well-being app, and one that’s being built with DTx in mind. When they’re designed by qualified clinicians, with Designers and Product experts, they’re already aiming to be ‘clinical’. When they’ve been created by clever, but unqualified designers or developers to fix a problem, and help with peoples health, they’re not clinical per se.

A clincian-first, iterative design process is a lot of fun. It’s rigorous, it’s detail focused, and it’s almost entirely focused on what the structure of captured data will look like, and how that data will be used to prove the efficacy of the product or drug later on down the line. There is no lean-cowboy approach to DTx, it’s unethical — the order of the day here is rigour, methodical, and balancing innovative design with clinical precision.

Set your teams up in Pods or Squads. That is to say, a small team of cross-discipline team members focused on one little-big-thing each. A clinician, a designer, an engineer, and probably a copy-writer.

This all leads into what will be the most fascinating of iterative processes — learn, measure, tweak and repeat.

With DTx, when you release the first few versions of your product, key features, SoMD etc for testing, you’re looking for the efficacy markers. Does it work? Can a controlled clinical trial show us that the tool improves the outcomes of a patient? Does the product have usability flaws? Do any tweaks I make deviate off a predetermined change control plan?

A PCCP is hugely important in DTx because from the outset you’ve planned your product on paper, with clinicians who will be advising on what works and what doesn’t. A “predetermined change control plan” helps to anticipate potential future software updates and a total product lifecycle regulatory approach that aims to facilitate the review of rapid product performance improvements and subsequent deployment, without compromising patient safeguards.

By making iterative usability updates you may inadvertently change the thing(s) that got the product signed off and approved as clinical-grade in the first place. So get your PCCP plan tight. Very very tight.

You’ll also need to use an explainable Ai approach, allowing timely identification and mitigation of any risks associated with machine learning algorithms. If you can’t do this, at this stage, you won’t get approval for clinical use.

The Innovation Opportunity

I’m going to give you some of my own vision for free now, simply because the more of us that try it, the closer we’ll get to what I believe is game-changing health innovation for all — Digital Phenotyping.

DTx tools, if built correctly as platforms and not apps, have an opportunity to start digital phenotyping using data collected from the apps and smart devices to build a rich, personalised digital pictures of behaviour, create new audience types, track markers of say, depression and anxiety, and develop new ways to diagnose illness, choose effective treatments and potentially detect relapse before it occurs.

When you’re planning your DTx project that has to be the central vision IMHO. You start with a set of humble personas, but by launch you are basically phenotyping, grouping, re-classifying and learning on a scale that is more appropriate to our rich human communities. I’d love to discuss this idea with like minded people — feel free to ping me for Podcast conversations, or just debates about the ethics and implications.

At the bottom of that last chart above there’s a green dot. It represents this idea with with rich, functioning digitial phenotyping we can really start to send nudges and alerts that are truly precision for each type of patient, clinician, or care-giver. Changing human behaviour is exceedingly difficult, especially for behaviours that arise from years of thinking and acting in relatively rigid, routinised ways — Digital Phenotyping allows us to also create a totally personalised ‘nudge’ engine for different digitised data-sets.

Here’s an example of how looking at all the data-points, passive and active, can be used in DTx for more details digital segmentation, personalisation, and ultimately phenotyping.

Validating the DTx

I’ve mentioned this above. The big difference between a DTx and a stanard, well-crafted well-being app is validation.

My rule: Start with clinicians, and build WITH clinicians. Let the clinicians design the clinical protocol that will be given to the product team for feature or innovation creation.

Work with the Pod (UX, Designers or Third Parties etc) to create something engaging, safe and efficacious in line with regulations such as 2017/745/CE.

Once the new piece of functionality is created, then you go through a 3-stage study;

• Acceptability: Give it back to clinicians before you give it to patients to make sure they are absolutely happy this is something that can be delivered to patients. Not effective at this stage, just purely; “Is it safe?”
• Feasibility: Can this technology be delivered in into the clinical setting or peoples lives. This also starts to determine if the product / feature can be effective.
• Effectiveness phase: Does it work? Live trial (e.g www.curebase.com) across a control group(s) that only apply standard lifestyle changes depending on, for example, the NICE guidelines (A). And an intervention group using the DTx app with lifestyle changes proposed using nudges and content (B).

Implementation Considerations

I’ve given you a broad set of guidance about how I would structure and approach a DTx product build. But what other considerations are there before you take on a regulated design product?

Firstly, it only works if you get the Pod collaboration working successfully. Chemistry is key — Cross globe and the correct expertise. Getting the right collaboration methodology is critical to success. Finding the right consumer voices is also critical. In something like DTx it’s more important to get the RIGHT people working, than trying to sweat a D&I policy for PR reasons. Get people who are qualified, expert, have experience in the particular health challenge, and make sure they respect the views and expertise of their Pod Peers.

Secondly, all DTx product designs (internal or external) must comply with quality system requirements for Medical Devices e.g ISO 13485, and with software life-cycle management requirements e.g IEC 62304. They just have too — it won’t get signed off if you don’t. Full-stop. It’s not DTx if it’s been signed off by a company like Orcha, but doesn’t fulfil the CE marks and ISO standards, in my view.

Make sure you have good;

• FMEA — failure mode and effects analysis (specifically, inputs defined as per ISO14971 and IEC/TR 80002–1) and;
• FTA — fault tree analysis for Q&A so that every little error is traceable.

I advocate a Web 3.0 / Low and No Code approach to the product build. Ultimately what you want to get right is the platform, so building everything as a suite of APIs is recommended.

Stubborn on the vision, flexible on the details.

Everything that you buy, build, or borrow to build your DTx should use your own predetermined platform of APIs, either externally focused, or internally focused; DTx as a platform, not tactical tools.

That gives you the opportunity to be flexible on the innovation whilst retaining a central data-set that is fixed, owned and allows you to lake-data from multiple sources for precision primary, and psychiatry objectives, including patient stratification, clinical trial optimisation, personalisation, and identification of novel compounds, regardless of the interaction point.

It also allows a much more rapid rate of innovation in the product space.

Summary

So that’s my little guide to approaching DTx products. It’s not exhaustive obviously, and there is so much more to write about DTx. It is however, a really exciting space to work in.

You might for example want to decide if you’re DTx is Standalone, or ‘Around-The-Pill’.

‘Prescription’ or ‘standalone’ digital therapeutics are those designed to work independently of regular pharmaceuticals and are usually designed to prevent or treat health conditions. Should a patient be diagnosed with prediabetes, for instance, an effective standalone DTx can successfully enact lifestyle changes that can prevent the condition from progressing to type 2 diabetes. Drawing on lingo from the world of pharmaceuticals, prescription DTx are also referred to as ‘monotherapy digital therapeutics’.

‘Around-the-pill’ digital therapeutics have evidence for delivering their impact in combination with another treatment, typically a drug. They deliver their results in ways such as by helping patients taking the right dose at the right time or better managing symptoms and side effects of their disease or treatment.

I find the later a really fascinating area, especially for measuring new types of Pain Relief such as Medical Cannabis, or the efficacy of psychedelic drug compounds like MDNA for PTSD, or Psilocybin for treating Depression and Treatment-Resistant Anxiety etc.

If anything I’ve laid out above is interesting, and you’d like to discuss things with me further, please feel free to get in touch via LinkedIn.