01 / THE WHOLE SERVICE JOURNEY
See the moments
between the screens.
A booking interface is one part of a wider service. People also need to know whether an appointment is confirmed, what information is required, how to change arrangements and who to contact when a step fails. The operating team needs a corresponding view of outstanding work.
Map the service with the people who run it. Identify the trigger, responsible role, expected status and exception route for every handoff. Validate the proposed journey with clinical and operational stakeholders; not every organisation follows the same sequence.
- 01 / APPOINTMENT
Confirm the request
Owner: Scheduling team
Visible state: Requested / confirmed
Next: share the confirmed arrangements. - 02 / PREPARATION
Clarify what is needed
Owner: Assigned coordinator
Visible state: Pending / complete
Next: route authorised information to the right team. - 03 / HANDOFF
Assign the next task
Owner: Receiving team
Visible state: Assigned / acknowledged
Next: confirm responsibility and required action. - 04 / FOLLOW-UP
Track the agreed action
Owner: Designated care team
Visible state: Open / completed
Next: review exceptions through the agreed route. - 05 / CLOSURE
Make completion explicit
Owner: Responsible team member
Visible state: Closed / further action
Next: retain the appropriate record and contact route.
Roles and statuses are illustrative. Clinical actions and escalation rules must be defined by the responsible healthcare organisation.
Do not equate sending a message with completing a task. A reminder can be delivered while the underlying request remains unresolved. Model the service state separately from notification delivery and show the difference to staff.
02 / MAKE RESPONSIBILITY VISIBLE
A handoff needs
more than a notification.
When a request moves between teams, preserve the context needed for the receiving task without exposing unrelated information. The next team should be able to understand what is pending, who assigned it and how to acknowledge or return it.
Patient view
Use plain language for confirmed arrangements, pending steps and contact options. Avoid showing internal queue labels as if they were meaningful instructions.
Coordinator view
Show assigned tasks, ownership and unresolved exceptions. Provide a clear route to reassign work with a recorded reason.
Clinical-team view
Present information relevant to the authorised role and workflow. Clinical decisions and instructions remain with qualified professionals.
Operational view
Use appropriate aggregate information for workload and service review. Management access should not automatically expose all patient details.
Four questions every handoff should answer.
- What action is required?
- Who is responsible now?
- How will acceptance or completion be recorded?
- Where does the exception go if the normal route fails?
03 / ACCESS THAT WORKS FOR PEOPLE
Clarity should not
depend on confidence with technology.
People may use a service on a small screen, through an assistive technology or with an unreliable connection. Design clear labels, readable content and predictable navigation. Do not rely on colour alone to communicate status or errors.
Test keyboard use, focus visibility, text enlargement and form recovery. Explain mistakes next to the relevant field and preserve entered information where it is safe to do so. Provide an appropriate assisted route for people who cannot complete a digital step.
Where a caregiver or representative is involved, make delegated access explicit. A family relationship should not silently grant access to all records. Ask the healthcare organisation to define authority, identity checks and the scope of representation.
Design reference: the W3C WCAG quick reference covers accessibility criteria such as keyboard operation, readable presentation, labels and error assistance. Referencing it is not a claim that a product has passed a formal accessibility assessment.
04 / INFORMATION WITH BOUNDARIES
Connect systems.
Keep access intentional.
Start with the minimum information each task needs. Enforce role and record-level permissions on the server, not only in the interface. Plan identity matching, audit records, retention and the handling of corrections with the relevant operational, privacy and security specialists.
- 01 / EXPERIENCEPatient & staff interfacesClear tasks · role-appropriate views
- 02 / CONTROLAccess & workflow servicesIdentity · authority · task state
- 03 / EXCHANGEIntegration boundaryValidated data · mapping · retries
- 04 / RECORDSAuthorised source systemsDefined ownership · audit · retention
The diagram separates responsibilities. The chosen clinical systems, interfaces and data-sharing arrangements require project-specific assessment.
HL7 FHIR provides a standard for exchanging healthcare information electronically. Where it fits the environment, evaluate the supported versions, profiles, terminology and interfaces with the systems involved. A standard name alone does not prove interoperability, authorisation or a working integration.
Build for partial failure. A timed-out integration may have accepted a request even when the interface received no confirmation. Use duplicate protection, reconciliation and clear pending states before retrying actions that could create conflicting records.
Technical reference: HL7’s FHIR overview. Actual connectivity, security and conformance must be evaluated for the specific implementation. No certification or regulatory compliance is claimed here.
05 / EVIDENCE BEFORE EXPANSION
Evaluate coordination.
Do not assume clinical impact.
Test representative service journeys with appropriate stakeholders before a wider release. Use synthetic or properly authorised test information, and include the situations where booking changes, notifications fail or a receiving team does not acknowledge work.
Unowned tasks, pending handoffs and duplicate entries.
Task completion, usability barriers and help requests.
Integration failures, notification status and recovery.
Agree definitions and baselines before interpreting those measures. Faster screen completion or fewer open tasks does not by itself demonstrate improved patient health, safety or clinical outcomes.
- 01 / Map the current serviceDocument responsibilities, information needs and existing failure routes.
- 02 / Test a bounded workflowReview permissions, usability and difficult handoff scenarios.
- 03 / Prepare for downtimeDefine manual coordination, support ownership and reconciliation.
- 04 / Review before expandingCheck access, incidents and unresolved work with responsible stakeholders.
Digital coordination channels should not imply that urgent requests are continuously monitored unless the organisation actually operates such a service. Publish the appropriate contact and escalation instructions after approval by the responsible healthcare team.
06 / QUESTIONS LEADERS ASK
Before designing the next screen.
What is a connected digital healthcare experience?
It links service steps, responsible teams and relevant information across a patient journey. Software makes the next action, its status and its owner understandable while supporting, not replacing, clinical judgement.
Should patients and staff see the same information?
Not necessarily. Each view should match the person’s task and authority. Patients need understandable service information, while staff need appropriate operational context. Access must be enforced on the server rather than only hidden in the interface.
Does using FHIR guarantee a working integration?
No. FHIR is a healthcare information-exchange standard. Supported versions, profiles, terminology, identity matching, permissions and actual interface behaviour still need to be agreed and tested with each system.
What should happen when an integration is unavailable?
Show an accurate pending or failed state, preserve appropriate context and use an agreed manual route. Plan retries, duplicate protection and reconciliation so a later recovery does not create conflicting requests or records.
Can workflow metrics prove better clinical outcomes?
No. Workflow metrics can help evaluate coordination, usability and reliability. They do not by themselves establish an improvement in patient health, safety or clinical outcomes; those claims require appropriate evidence and specialist evaluation.
About this perspective
Prepared by Web Cincture Private Limited as software and service-design guidance. The journey and architecture are illustrative, not a clinical pathway, customer case study or claim of compliance. This article is not medical or legal advice. Last updated 24 October 2026.
About Web Cincture ↗