Mafalda Carvalho
A digital tool earns its place in care when the work around it is understood.
A new digital documentation system can look successful before anybody has tested the difficult part of the job. Staff have accounts. Training is complete. The dashboard shows regular use. Then a record needs correcting during a busy shift, and nobody is certain whether the correction belongs in the new system, the old one or both.
This is an illustrative scenario, not a report of a project I have delivered. It exposes a question that adoption figures alone cannot answer: has the technology made the task workable for the people responsible for it?
My perspective comes from managing adult social care services in the UK. I begin with listening and trying to understand the person doing the work. For healthcare technology, that means treating frontline knowledge as part of the assessment before launch, rather than collecting staff reactions after the main decisions are fixed.
Start with a task, not a product
For digital health product and implementation teams, frontline input needs an explicit place in release decisions. Turn an observed difficulty into a testable requirement: which user, which task, which exception and what would count as a workable response? An issue should have a decision owner, rather than remaining a comment from a workshop. This is a proposed management approach, not a validated clinical assessment.
Choose one task that the proposed tool should improve: recording an observation, responding to a patient message or preparing information for a handover. Follow it from the first input to the person who must act.
Ask the people involved to show where they wait, repeat information or seek clarification. A demonstration organised around an ideal user journey may miss an interruption, an absent colleague or an incomplete record. Those exceptions deserve a place in testing.
A receptionist may identify an access problem that a clinician does not encounter. A night worker may rely on support arrangements that are invisible during office hours. Patient and carer perspectives also matter where the technology changes how they communicate or receive information. Participation should reflect the task and the people affected, including those who find the proposed route difficult to use.
Give observations a route into decisions
Inviting staff to a workshop is a beginning. The useful question is what happens to the issue they raise.
Suppose testing shows that the new interface saves time for one team but requires another to check an additional queue. The project should record the problem, identify who can decide whether that extra work is justified, and explain the decision to both teams. “We listened” is too vague to tell them what will change.
Implementation research offers a way to examine such contextual questions. Damschroder and colleagues’ updated Consolidated Framework for Implementation Research considers determinants associated with the innovation, settings, individuals and implementation process [1]. It can help structure an investigation of barriers and enablers. It is not evidence that a particular digital product improves patient outcomes.
A small pilot can use a proportionate issue log: the task affected, the problem observed, its possible consequence, the decision owner and the response. Keep personal information out unless it is necessary and handled through the appropriate organisational arrangements. Urgent clinical, safeguarding or information-security concerns must follow the relevant established route.
Test the exception and the handover
Before wider use, rehearse an ordinary exception with synthetic information. What if a record is incomplete? What if two systems disagree? What happens when access fails?
The exercise should make responsibilities visible. Who can correct the information? Who decides whether work can continue? Who provides help outside the project team’s normal hours? The answers need to be usable by staff, rather than remaining in a project document they cannot readily find.
Training should include practice on the tasks each role actually performs. Attendance shows that someone was present; it does not establish that they can handle a difficult situation. Where practice reveals a gap, the response may involve changing the interface, instructions, staffing or support. More training is not automatically the right remedy.
Agree what would justify continuing
Define the question a pilot must answer before collecting a large set of measures. If the aim is to reduce duplicate recording, examine where duplication remains and whether work has moved elsewhere. If the aim concerns response times, consider the quality and appropriateness of the response alongside its speed.
NICE’s Evidence Standards Framework describes evidence expectations for digital health technologies [2]. The evidence appropriate to a tool depends on its function and intended use. A local workflow exercise does not replace the assessment of clinical effectiveness, safety or applicable regulatory requirements.
Leaders should therefore distinguish three questions: is the product supported by appropriate evidence; can this service use it responsibly; and is it delivering the intended result here? Progress on one question should not be treated as a complete answer to the others.
Make the response visible
At the end of a pilot, return to the people who contributed. Explain which issues were resolved, which remain open and why the organisation will continue, adapt or pause. A decision to delay can be responsible when an important uncertainty remains.
Frontline involvement should also be proportionate. Asking exhausted staff for repeated feedback without time to contribute or evidence of a response adds another burden. Use existing opportunities where practical, protect time for essential testing and make the decision route clear.
Before the next launch, ask one colleague to demonstrate the task and one exception without the project team supplying the answers. Watch where the work stops. That moment may tell you more about readiness than another positive presentation.
References
[1] Damschroder LJ, Reardon CM, Widerquist MAO, Lowery J. The updated Consolidated Framework for Implementation Research based on user feedback. Implementation Science. 2022;17:75. https://doi.org/10.1186/s13012-022-01245-0
[2] National Institute for Health and Care Excellence. Evidence standards framework for digital health technologies. ECD7. https://www.nice.org.uk/corporate/ecd7
Illustrations
Figure 1. A proposed pre-pilot workflow review. This is an illustrative management aid, not a validated clinical protocol.
Figure 2. Product evidence, local implementation and local outcomes are different assessment questions.
