Digital Twin-Orchestrated IoT Architecture for Patient Wayfinding in Complex Healthcare Facilities ^†

Abstract

In healthcare facilities, patient wayfinding challenges—especially in complex, multi-unit or campus-scale healthcare environments—extend the patient journey and increase front-desk workload. This work investigates the integration of a Digital Twin-orchestrated, IoT-enabled architecture that links digital scheduling to in-clinic guidance through standardized tokens. The proposed approach relies on (i) an administrative mapping layer that binds unique QR identifiers to cabinets, specialties, clinicians, and human-readable location labels, (ii) an appointment confirmation workflow that issues a confirmation code and delivers an e-mail package including a QR token and an RFC 5545-compliant (Internet Calendaring and Scheduling Core Object Specification) attachment, and (iii) a kiosk-like model (embedded, single-board computer with camera-based QR scanning) that resolves tokens via REST endpoints and presents deterministic guidance using a finite-state-machine workflow with explicit fallback from appointment resolution to cabinet-level QR mapping. An optional biometric module is included for recurrent visits via a database linkage layer, enforced by a single-owner rule for the serial sensor interface to prevent concurrency faults. Scenario-based validation confirms end-to-end operability and robustness, with time–motion quantification scheduled for future on-site evaluation.

1. Introduction

Wayfinding in healthcare facilities affects punctuality, perceived service quality, and front-desk workload. In complex outpatient layouts, patients often traverse several pre-consultation steps before reaching the correct destination, and failures in this stage amplify stress, uncertainty, and circulation inefficiency [1,2,3].

The literature has treated environmental wayfinding design, user-centered healthcare navigation evaluation, and Digital Twin-driven operational coordination as related but still weakly connected directions [1,2,3,4]. A persistent gap therefore remains between scheduled visit information and destination-specific guidance at the point of care. Static signage is rarely appointment-aware, many generic kiosks or mobile tools start only after arrival, and current market solutions do not consistently propagate delay information, fallback recovery, or schedule-offset transparency. The present study addresses this gap through an integrated architecture that binds appointment data to tokenized guidance, kiosk-based deterministic resolution, queue-awareness signaling, and controlled fallback.

2. Materials and Methods

2.1. System Architecture

The proposed solution follows a three-layer architecture, illustrated in Figure 1, that connects pre-visit scheduling with point-of-care guidance through synchronized digital and physical identifiers. This representation was adopted in order to make the orchestration logic explicit and to distinguish user interaction, application logic, and persistent data management within the same system.

The first level of the architecture is the patient interaction layer. It includes the appointment confirmation e-mail, the QR-based token delivered before the visit, and the kiosk-based user interface available at arrival. This layer is responsible for the direct interaction between the patient and the system and is designed to minimize the need for repeated destination search or desk-mediated clarification.

The second level is the application and orchestration layer. It contains the core logic responsible for appointment lookup, token resolution, deterministic routing, fallback execution, and optional delay propagation. Within this layer, the Digital Twin role is operational: the system maintains the synchronized relation between the digital appointment object and the corresponding physical destination, allowing the routing process to remain interpretable even when cabinet allocation or timetable conditions change.

The third level is the data and integration layer. It includes the appointment database, the QR-to-location mapping, the optional biometric linkage, and the REST-based communication mechanisms used by the kiosk and administrative components. This layer ensures data persistence, identifier consistency, and controlled exchange between the embedded interface and the backend services.

The system architecture foresees at the current stage of mentioned optional biometric module intended to facilitate recurrent visits and shorten interaction times for returning users. Due to the sensitivity of biometric and personal data, this functionality is not implemented in the present work, and no personal or biometric information is stored or processed. Instead, future work will focus on the investigation of alternative privacy-preserving approaches, such as the generation of non-reversible personal keys or locally processed identifiers, which could enable user recognition while remaining robust, secure, and compliant with data-protection regulations. The development of such mechanisms, capable of operating without centralized storage of personal data or the need for explicit General Data Protection Regulation (GDPR) or similar directives of approval, requires further research and validation and is therefore left for future work.

From an engineering perspective, the layered design provides three advantages. First, it separates patient-facing interaction from internal routing logic, thereby improving maintainability. Second, it supports resilience through controlled fallback when appointment-level resolution becomes unavailable. Third, it reduces unnecessary exposure of personal information by allowing destination guidance to be derived from tokenized lookup rather than repeated verbal confirmation at the desk.

2.2. Deterministic Guidance and Queue-Awareness Logic

The operational chain is deterministic: appointment created → token issued → token received by patient → token resolved at kiosk → destination guidance displayed. When appointment-level linkage is unavailable, the architecture applies controlled fallback to cabinet-level QR mapping so that navigation continuity is preserved rather than failing silently. The same workflow may also expose schedule-offset information before the service point is reached, allowing the patient to understand in advance whether a local delay has formed.

2.3. Comparative Evaluation Framework

To compare the proposed solution with common market approaches, four criteria were retained: waiting-related burden, perceived satisfaction, traffic fluidity, and data security. The framework is architecture-level and is used to position the contribution against signage-only, generic kiosk, and mobile-only approaches without claiming universal superiority over every product category.

This comparison is consistent with the literature reviewed in Section 1, where environmental wayfinding studies, user-centered healthcare navigation evaluations, and Digital Twin-oriented coordination approaches were identified as the main reference directions.

2.4. Analytical Time Model

A simplified engineering model was used to express the expected time effect without overstating evidence:

$$T_{baseline}=t_{desk}+t_{orientation}+t_{search}+p_{err}·t_{recovery}$$

(1)

$$T_{proposed}=t_{token}+t_{scan}+t_{guided}+p_{err}^{\prime }·t{\prime }_{recovery},$$

(2)

$$\mathrm{G}={\displaystyle \frac{{\mathrm{T}}_{\mathrm{b}\mathrm{a}\mathrm{s}\mathrm{e}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{e}}-{\mathrm{T}}_{\mathrm{p}\mathrm{r}\mathrm{o}\mathrm{p}\mathrm{o}\mathrm{s}\mathrm{e}\mathrm{d}}}{{\mathrm{T}}_{\mathrm{b}\mathrm{a}\mathrm{s}\mathrm{e}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{e}}}}·100\%$$

(3)

Here, t_desk denotes time spent asking staff for directions, t_orientation denotes interpretation of static cues, t_search denotes unguided destination seeking, and the recovery term denotes wrong-turn or uncertainty burden.

The expressions (1)–(3) define an analytical time-decomposition model intended to support illustrative comparison rather than to report field-measured clinical performance, with parameters instantiated using prototype-oriented, scenario-based estimates.

The adopted values were derived from a prototype-oriented engineering decomposition of the implemented interaction sequence, including desk-mediated clarification, token presentation, scan or lookup, directed traversal, and recovery from unsuccessful acquisition; they are used here only as analytical placeholders for future empirical calibration.

For illustration, the analytical comparison instantiates the model with a nominal 8.5 min baseline versus a 4.0 min proposed workflow, corresponding to an estimated gain of approximately 52.9%. These values are illustrative, prototype-oriented estimates derived from scenario-based evaluation and define a future time–motion hypothesis rather than a field-measured hospital outcome.

2.5. Validation and Embedded-Use Test Logic

The validation logic was defined to verify both technical operability and embedded-use feasibility under realistic kiosk-based interaction conditions. The aim was not to claim completed hospital-wide deployment, but to assess whether the proposed workflow remains functional, recoverable, and sufficiently responsive when used in patient-like conditions.

At the technical level, the validation covered the main transitions of the architecture: token issuance, appointment-level resolution, fallback execution, and guidance display. At the interaction level, the test logic considered common embedded-use difficulties, such as incorrect framing, oblique token positioning, or repeated scan attempts before successful acquisition.

Three indicators were retained: task completion rate, number of attempts to successful acquisition, and system response time from valid capture to guidance display. These indicators were selected because they directly reflect the interaction burden addressed by the proposed workflow, especially with respect to repeated clarification, uncertainty, and recoverability.

For the present paper, Figure 2 summarizes a bounded prototype-level comparison under three predefined framing conditions: correct framing, slightly oblique framing, and difficult framing with partial misalignment. The results are derived from a controlled laboratory provided in the UMPhST campus usability experiment involving 10 volunteers, each performing 10 acquisition trials using different device types, under non-clinical, simulated use conditions.

The reported results are not intended as a statistically generalizable usability experiment, but as an illustrative embedded-use benchmark showing how acquisition attempts and kiosk response time may vary under controlled interaction conditions.

The benchmark outputs shown in Figure 2 were derived from prototype-oriented internal testing logic under controlled embedded-use assumptions, with the purpose of illustrating response-time and acquisition-attempt indicators rather than reporting a completed hospital-scale experiment.

Accordingly, this validation stage should be interpreted as a pre-deployment embedded-use framework, while any reported values remain illustrative prototype-level indicators rather than generalized clinical performance claims.

This logic is also consistent with usability-oriented evaluation principles concerning effectiveness, efficiency, and context of use [5].

3. Results

At the prototype level, the architecture completed the intended end-to-end chain from appointment generation to destination-specific guidance. The primary engineering result is continuity preservation between scheduling and point-of-care navigation, including controlled fallback when appointment linkage is incomplete.

Under the analytical model, the proposed workflow yields an estimated reduction in orientation-related burden from 8.5 min to 4.0 min under the adopted analytical parameterization, corresponding to an illustrative gain of approximately 52.9% rather than a field-measured hospital outcome.

Four architecture-level outcomes are emphasized: lower waiting-related burden, clearer and more transparent user interaction, smoother internal traffic through fewer stop-and-ask events, and lower data exposure because the kiosk renders only the minimum attributes required for confirmation and routing [6].

4. Discussion

The contribution of the paper is integrative rather than component-specific. QR codes, kiosks, scheduling artifacts, and Digital Twin concepts already exist separately; the novelty lies in coupling them into a synchronized wayfinding workflow that begins before arrival and remains interpretable at the point of care.

The comparison with existing approaches should remain methodologically careful. Signage-only systems are scalable but not appointment-aware; generic kiosks may be interactive but are not always event-bound; mobile-only approaches depend on device literacy and local adoption conditions. The proposed architecture addresses these limitations by preserving kiosk accessibility while binding pre-visit scheduling to deterministic destination resolution and optional queue-awareness signalling.

Several limitations remain. The study does not report a live hospital deployment; therefore, measured reductions in waiting time, measured increases in satisfaction, and attack-tested security superiority cannot yet be claimed. The time model is analytical rather than empirical, and the optional biometric extension would require separate privacy, maintenance, and governance validation before production deployment.

5. Conclusions

This paper presented a Digital Twin-orchestrated, IoT-enabled architecture for patient wayfinding in complex healthcare facilities. Relative to the state of the art, the novelty lies in binding appointment data to tokenized, destination-specific, kiosk-resolvable guidance within one workflow. The prototype supports coherent guidance, controlled fallback, queue-awareness potential, and privacy-conscious routing, while the analytical model and embedded-use test logic define a tractable path toward field evaluation.

The proposed solution is intended as a conceptual reference architecture for future research framework development rather than as a commercial product. It can be seen as a complementary, open architecture, not as a competitor to currently deployed and widely adopted navigation platforms.