Buy for the work your team actually does

What we found in the news

NICE's guide to using its evidence standards framework (opens in a new tab), updated in August 2022, describes how purchasers can assess digital health technologies. It asks evaluators and suppliers to:

identify the intended purpose of the DHT

DHT means digital health technology. The framework has a defined health-and-care scope; it is not a general endorsement scheme. What interests us here is the starting point: agree what the technology is meant to do before judging the evidence for it.

Why this matters to us

A demonstration tends to show the smooth path. Information is ready, the right person is signed in, and the next action is obvious. An ordinary Tuesday can be less cooperative.

For a service leader, the purchase decision needs to include that Tuesday. Who will maintain the information? What will an occasional user understand? How will staff learn the changed process while continuing to support people?

We think a useful buying conversation begins with a piece of real work. The supplier should be able to discuss where the product fits, what needs configuring and what remains the organization's responsibility.

Bring a situation, not only a feature list

Imagine a hypothetical community organization comparing ways to manage activity reservations. It needs more than a screen that displays bookings. A participant may telephone to change a session. A coordinator may need to review capacity. A family supporter may help with the request, with the person's agreement.

Use a fictional version of that sequence in the demonstration. Ask the supplier to show what each authorized person sees and where confirmation happens. Then introduce a change: the session is canceled, the coordinator is away, or the person wants help using a different channel.

A feature checklist can still be useful. The scenario gives those features a purpose and shows where another process or tool is required. It also makes it easier for frontline colleagues to contribute meaningfully to the decision.

Name the work of introducing the tool

Ask who prepares the initial information, checks access, trains staff and keeps instructions current. Identify time for practice before the service relies on the new process.

A supplier may offer configuration or training support. Clarify what that includes and what your team must provide. A promise to support implementation needs enough detail for both organizations to plan the work.

Consider people who will not use the tool directly. Reception colleagues may need to explain a confirmation message. Participants may want someone to help them understand a choice. A successful technical installation does not tell you whether those encounters are ready.

Agree a manageable scope for the first use. Trying to change every connected process at once can make it difficult to understand which part needs attention.

Decide what evidence will count locally

Before a trial, write down the question it is meant to answer. Perhaps staff need to find outstanding requests without keeping a separate personal list. Perhaps participants need clearer confirmation of a reservation.

Watch the process, invite feedback and examine the cases that did not follow the expected route. Be careful with promises about time saved or outcomes improved. Those require evidence appropriate to the claim, including the work that may have moved elsewhere.

Keep a record of unresolved limitations alongside the attractive features. They are part of an honest decision, not an embarrassment to remove from the presentation. If the tool is suitable only with a particular module, workflow or permission, say so in the agreement.

What this means for the people you serve

A purchasing decision can change how someone asks for help, shares a preference or finds out what happens next. Include people who will experience those changes in appropriate testing and discussion. Ask whether the proposed process preserves their choice, including a practical alternative when using the technology is difficult.

The genus connection

The current genus partner portal and insights (opens in a new tab) describe configurable staff workspaces and operational capabilities. Their fit depends on the organization's selected modules, permissions, information and processes.

We welcome a discussion grounded in a concrete service situation. Connections to other systems, reporting needs and responsibilities should be scoped explicitly. A plausible demonstration is a beginning; agreed implementation and local review are how the organization establishes whether the setup serves its work.

One question for your next team meeting

Which ordinary, slightly awkward service situation should every supplier be able to walk through with us?