What is the absolute best way for a domain expert (health or care practitioner) to collaborate with a digital team (software designers and developers) to realise your goals and create a digital tool that has a chance of seeing the light of day?
This is a question we set ourselves at #PDDigital16 after hearing a salutary tale of a practitioner’s nightmare experience whereby a brilliant idea descended into a heap of trouble and a resulted in a failed project. Everything that could go wrong did go wrong and it was a tricky experience for everyone involved.
But it doesn’t have to be like that!
A group of health and care practitioners and digital experts put our heads together to work out how to collaborate well to get the best results. The 20 tips we came up with are as important for software developers as they are for domain experts. They might make the difference between a wildly successful project and one that maybe isn’t so great.
So here goes…
1. Involve end users from the outset (always and always and always) remembering that end users are not just patients (citizens) but often other health and care practitioners and administrators
2. Invest in lots of discovery (early stage research) so you can really understand the problem you are trying to address, the outcomes you want to achieve, and the experience you want to create
3. Check if your idea already exists (review the market) and avoid reinventing the wheel
4. Commission a process rather than a product – this means a collaborative relationship rather than an exhaustive specification – that way you can make the most of each other’s skills and expertise
5. Experiment with existing technologies to test out your ideas before you invest in any coding – if it doesn’t work out as you planned then you haven’t wasted lots of time and resources
6. Think carefully about intellectual property and put in place a proper agreement before you start – are you clear who owns the code?
7. Create pauses and break points at key points in the project so you can stop if it isn’t working out
8. Consider the whole life costs of the digital tool you are developing from the outset (such as hosting, technical support, updates and further developments) and not just the first stage development costs – how will you sustain your product over time?
9. Have weekly (daily if you can) meetings to check in with each other – spending time together will build trust and a collaborative approach – use sharing tools (like Slack) to aid collaboration inbetween meetings
10. Check out the evidence before you start and build in evaluation from the outset – how will you know you have achieved the experience and the outcomes you hoped for?
11. Be aware that agile (iterative) approaches that are common in software development can be problematic in a healthcare context where there are often fixed budgets and timescales – work out how you will manage this tension between you
12. Test | iterate | get stuff out | iterate again – your digital tool doesn’t have to be perfect before it sees the light of day – start small and prioritise
13. Agree to produce non-technical documentation so you have information about what your digital tool does in clear easy to understand language that you can explain to others
14. Take time to familiarise yourselves with the skill sets in your respective teams – whether it be different domain expert roles through to different roles in software development
15. Put in place a ‘product owner’ who can hold the vision of what the digital tool will achieve and manage the relationship between the domain experts and the software development team
16. Identify early on if your digital tool needs to interoperate with other systems so you can design this in from the beginning (and in a health context be aware of the challenges of interoperating with systems such as electronic patient records)
17. Be aware of information governance and privacy at the outset of your project. You’ll need to involve your information governance lead and undertake a privacy impact assessment in the NHS
18. Build a minimum viable product – a digital tool that does fewer things well. Avoid trying to squeeze everything into your digital tool – you’re in danger of ending up with a complicated project that never ends
19. Don’t assume you can’t do harm with your digital tool. Bring in someone to help you do a clinical safety assessment – identifying and mitigating risks as you develop it – that way it will be fit for purpose in a health or care context
20. Enjoy the adventure and good luck!
This isn’t an exhaustive list (we didn’t even touch on procurement…) but hopefully is a useful set of pointers for anyone considering a digital health and/or care project. Is there anything in this list you’d change or add to? If so, please get in touch and let me know.
Thank you to everyone who participated in the conversation – it was a proper team effort. If you’d like to read the #PDDigital16 report, you can do so here.