Someone still owns the next step

What we found in the news

The Task definitions in HL7’s March 2023 FHIR R5 release (opens in a new tab) distinguish several stages of work. In the associated status definitions, accepted means the intended performer:

“has agreed to execute the task”

— HL7 International, Task Status

The definition also makes clear that work has not necessarily begun. This is an established technical specification, not evidence that two organizations already use it together. It offers a useful distinction for any team discussing connected work: sending something and taking responsibility for it are separate events.

Why this matters to us

Imagine a community coordinator asking a partner to contact someone about a transport option. The coordinator sends the request through a digital route and sees a delivery confirmation. At the partner organization, the request has reached an inbox awaiting review.

Meanwhile, the person expects a call because they were told the request had gone through. Neither screen explains whether anyone has agreed to make that call.

At genus, we are interested in the point where information becomes an understood commitment. A person’s next step should not depend on interpreting an unfamiliar status word.

Agree what each stage means

Bring the sending and receiving teams together around one ordinary example. Ask what sent, received, accepted, and completed mean in their actual process.

Different software may use those words differently. A sent label might confirm that a message left one system. A received label might indicate technical delivery or a person opening a queue. Neither meaning should be guessed from the color of an icon.

Choose the meaning the teams need to communicate, then confirm what the supported connection can reliably show. If acceptance still happens by telephone, describe that honestly in the workflow.

Use a fictional request for the exercise. Staff can work through responsibilities without displaying somebody’s personal circumstances to a wider meeting.

Find the person who can accept the work

In our example, a receiving colleague needs to decide whether the request fits the partner’s service and available capacity. They may need clarification before taking it on.

Make that question easy to return to the sender. An incomplete request should not disappear into silence, and a declined request should not leave the person believing that a call is being arranged.

The original coordinator still needs an understood responsibility while acceptance is pending. That might involve checking the status or helping the person explore another option, according to the service’s actual arrangements.

Ask how cover works when either colleague is away. A shared queue can help organize work, but someone still needs authority and time to review what has arrived.

Tell the person what has actually happened

The explanation to the participant should match the state of the work. If a request is awaiting review, say what is awaiting review and how they can ask about progress. Avoid presenting a proposed next step as an appointment.

Agree which information the person wants shared and what the receiving service needs. A technically possible transfer is not a reason to send an entire record.

When the partner accepts the request, confirm the next contact arrangement through the agreed channel. Where practical, invite the person to tell the team if that arrangement does not work for them.

Finally, check what counts as completion. Leaving a voicemail, speaking with the person, and arranging a suitable next step may be different outcomes. The team should know which one it is reporting.

What this means for the people you serve

People need enough information to understand who is doing what next. Give them a way to ask about an outstanding request without having to chase several organizations or decode their systems. Their preferences and availability belong in the handoff.

The genus connection

Today, genus Partner Portal workspaces can support configured coordination and review tasks. Connections to other systems require an agreed purpose, permissions, technical scope, and operating responsibilities.

We would use those agreements to decide which states a particular workflow needs to display. The aim is to make the supported exchange understandable to staff and to the person waiting for its result.

One question to take away

When our system says a request went through, who has actually agreed to the next step?