<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>medical device interoperability &#8211; Science</title>
	<atom:link href="https://scienmag.com/tag/medical-device-interoperability/feed/" rel="self" type="application/rss+xml" />
	<link>https://scienmag.com</link>
	<description></description>
	<lastBuildDate>Wed, 30 Sep 2026 22:19:23 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.2</generator>

<image>
	<url>https://scienmag.com/wp-content/uploads/2024/07/cropped-scienmag_ico-32x32.jpg</url>
	<title>medical device interoperability &#8211; Science</title>
	<link>https://scienmag.com</link>
	<width>32</width>
	<height>32</height>
</image> 
<site xmlns="com-wordpress:feed-additions:1">73899611</site>	<item>
		<title>Wi-Fi 6 beats 5G in the race to cut the cables from surgical navigation</title>
		<link>https://scienmag.com/wi-fi-6-beats-5g-in-the-race-to-cut-the-cables-from-surgical-navigation/</link>
		
		<dc:creator><![CDATA[Ophelia Keating]]></dc:creator>
		<pubDate>Wed, 30 Sep 2026 22:19:23 +0000</pubDate>
				<category><![CDATA[Medicine]]></category>
		<category><![CDATA[5G]]></category>
		<category><![CDATA[5G cellular networks for surgery]]></category>
		<category><![CDATA[computer-assisted surgery]]></category>
		<category><![CDATA[cordless surgical devices]]></category>
		<category><![CDATA[impact of wireless tech on surgical safety]]></category>
		<category><![CDATA[interoperability standards in medical devices]]></category>
		<category><![CDATA[ISO IEEE 11073 SDC]]></category>
		<category><![CDATA[latency]]></category>
		<category><![CDATA[medical device interoperability]]></category>
		<category><![CDATA[medical engineering advancements]]></category>
		<category><![CDATA[operating room]]></category>
		<category><![CDATA[operating room workflow optimization]]></category>
		<category><![CDATA[private cellular networks]]></category>
		<category><![CDATA[reducing surgical staff workload]]></category>
		<category><![CDATA[RWTH Aachen]]></category>
		<category><![CDATA[surgical navigation]]></category>
		<category><![CDATA[surgical navigation system innovation]]></category>
		<category><![CDATA[tracking camera]]></category>
		<category><![CDATA[Wi-Fi 6]]></category>
		<category><![CDATA[Wi-Fi 6 in operating rooms]]></category>
		<category><![CDATA[wireless medical device connectivity]]></category>
		<category><![CDATA[wireless medical devices]]></category>
		<category><![CDATA[wireless surgical navigation]]></category>
		<category><![CDATA[wireless tracking technology in healthcare]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=219710</guid>

					<description><![CDATA[Researchers at RWTH Aachen University tested private 5G and Wi-Fi 6 networks for cable-free surgical navigation and found that Wi-Fi 6 consistently met the latency requirements while the tested 5G system suffered congestion and outliers.]]></description>
										<content:encoded><![CDATA[<p>Operating rooms are among the most technologically saturated spaces in medicine, yet many of the devices that surround the surgical table remain tethered to the wall by a web of cables and tubing. Those tangles are more than an aesthetic nuisance. Studies of operating room workflow have repeatedly identified cabling as a cause of trips and falls, detours, and heightened mental load for staff, particularly circulating nurses who must manoeuvre around obstacles in an already crowded space. In navigated surgery, where a tracking camera, a display and a planning workstation must all be connected to each other and often to a CT scanner, the problem is especially acute. A research team at RWTH Aachen University has now put two of the most promising wireless technologies, private 5G cellular networks and sixth-generation Wi-Fi, through a rigorous head-to-head test to determine whether either can finally cut the cord on surgical navigation.</p>
<p>The team, led by Noah Wickel and colleagues at the Chair of Medical Engineering, built a prototype wireless tracking system designed around the ISO/IEEE 11073 Service-oriented Device Connectivity standard, known as SDC. This interoperability standard, which has recently entered clinical use in patient monitoring for operating rooms and intensive care units, allows medical devices from different manufacturers to discover each other and exchange data over a network. The researchers mounted a surgical tracking camera, an embedded Linux computer, a lithium battery and power electronics on a mobile base with a medical holding arm, creating a self-contained unit that can run for more than 24 hours on a single charge. The embedded computer calculates surgical tool poses from the raw camera data and broadcasts them to navigation software over the network, using either a private 5G standalone network or an off-the-shelf Wi-Fi 6 router.</p>
<p>The choice of these two technologies reflects a broader debate in industrial and medical connectivity. Wi-Fi is cheap and ubiquitous, but its shared spectrum and collision-avoidance mechanisms make it difficult to guarantee the very low, bounded latencies that safety-critical applications demand. Fifth-generation cellular networks, by contrast, use licensed private spectrum and a strictly scheduled air interface, which has fuelled expectations that they could serve demanding medical control loops. The Aachen team operated their own private 5G campus network in the 3.7 to 3.8 GHz band licensed in Germany, running the open-source OpenAirInterface software for both the core network and the radio access network, connected to a low-power O-RAN radio unit over fibre. The tracking system was the only device on the network, giving 5G the most favourable possible conditions.</p>
<p>To measure end-to-end latency in a realistic way, the researchers devised an elegant experimental trick. The navigation computer controlled an infrared LED through a USB-to-serial adapter, and the tracking camera registered that LED as a fiducial marker. By timestamping the moment the LED was switched on and the moment the corresponding tracking message arrived at the navigation software, the team captured the entire acquisition and transmission chain, including the camera&#8217;s internal image processing that earlier measurements had omitted. Each configuration was measured for a full hour in an underground laboratory whose characteristics resemble a medium-sized operating room. As a benchmark for unimpeded surgical performance, the team adopted 100 milliseconds as an upper latency bound, drawing on studies of visual delay in laparoscopic and telesurgical settings showing that delays up to 100 milliseconds do not degrade task completion time or error rates, while longer delays double execution times and significantly increase errors.</p>
<p>The wired Ethernet baseline set a demanding standard. At a 100 Hz update rate, mean latencies of about 11 to 14 milliseconds were achieved with no packet loss, depending on whether the tracking system acted as the SDC provider sending reports or as a consumer triggering operations on the navigation computer. The Wi-Fi 6 configuration came remarkably close to this benchmark. At 50 Hz, mean latencies of 16.5 and 26.2 milliseconds were recorded in the conventional and reversed role set-ups respectively, with worst-case values of 36.7 and 97.2 milliseconds. Even at 100 Hz, the system operated without congestion or dropped messages, though maximum outliers grew larger. Crucially, the updated prototype consistently kept tracking events below 30 milliseconds on average and below 100 milliseconds in the worst case, a substantial improvement over the team&#8217;s earlier Wi-Fi 5 generation, which had shown unacceptable outliers exceeding 300 milliseconds.</p>
<p>The 5G results told a strikingly different story. Even at reduced update rates of 10, 20 and 50 Hz, the cellular link produced mean latencies roughly an order of magnitude higher than Ethernet, reaching 94.3 milliseconds at 10 Hz in the conventional configuration. Maximum delays approached 300 milliseconds, and at 100 Hz the system consistently descended into congestion, with messages arriving out of order, high drop rates of up to 16.85 percent, and subscription renewal failures that severed the SDC connection entirely. In the reversed role set-up, where the tracking system triggered operations on the navigation provider rather than streaming reports, the 5G link sustained 20 and 50 Hz without losses, but mean latencies of about 49 to 61 milliseconds still fell short of the Wi-Fi performance, and every 5G-based configuration saw at least one percent of data points arrive later than the critical 100-millisecond threshold.</p>
<p>Digging into the 5G uplink behaviour revealed why the cellular link struggled. In a series of controlled experiments using timestamped UDP packets, the researchers found that latency was highly sensitive to packet frequency: round-trip times changed little between 5 and 50 Hz but deteriorated sharply at 100 Hz and above. A clever mitigation strategy of bundling multiple tracking values into single packets, trading a small buffer delay for a lower packet rate, produced a remarkably stable transmission delay of 24 to 26 milliseconds and allowed simulated data rates of up to 800 Hz to be delivered within 45 milliseconds at the 99th percentile. That would be fast enough for the quickest clinical tracking systems on the market, which run at 400 to 500 Hz. However, maximum delays above 100 milliseconds reappeared whenever packet rates exceeded 20 Hz or background uplink traffic was present, underscoring the non-deterministic character of the link. Parallel downlink traffic was largely harmless, but even modest competing uplink traffic above 30 Mbit/s quickly congested the cell entirely.</p>
<p>The authors point to a likely culprit for the 5G shortcomings: the software-based radio access network. Their analysis of the literature shows that the OpenAirInterface implementation suffers from unpredictable jitter and frequent user-equipment disconnects, with comparable studies reporting outliers of 200 to 500 milliseconds, while alternative software stacks and dedicated hardware radio networks achieve far more stable results. The uplink also bears a structural handicap, since a device must first request a transmit grant from the network before sending, adding scheduling delay that downlink traffic avoids. Even so, neither the tested software radio network nor the dedicated hardware networks described in comparable studies currently meet the 3GPP standardisation target of 4 milliseconds user-plane latency, suggesting that the gap between cellular promise and surgical reality remains substantial.</p>
<p>The practical implications are significant. Wi-Fi 6, in this configuration, already delivers latencies compatible with the hand-eye coordination demands of navigated procedures such as neurosurgical spine instrumentation, meaning a wireless tracking camera could be prepped outside the sterile field, rolled in without cables, and repositioned freely to maintain line of sight to the instruments. That would ease set-up schedules, reduce trip hazards, and free mental capacity for the surgical team. Yet the researchers are careful not to write off 5G. Cellular networks handle dense user populations far better than Wi-Fi, and their behaviour in obstructed hospital environments remains an open question. Future work will explore higher 5G numerologies, pre-scheduled uplink grants, alternative radio network implementations, and deeper integration of SDC signalling into the 5G core, alongside Wi-Fi 7 features such as restricted target wake time that promise a further 30 percent latency reduction. For now, the cable-free operating room is closer than ever, and it will likely arrive first over Wi-Fi.</p>
<p><strong>Subject of Research:</strong> Evaluation of 5G and Wi-Fi 6 wireless networks for latency-critical cable-free surgical navigation using the ISO/IEEE 11073 SDC standard</p>
<p><strong>Article Title:</strong> Evaluation of 5G cellular and Wi-Fi 6 for cable-free surgical navigation using ISO/IEEE 11073 SDC</p>
<p><strong>Article References:</strong> Wickel, N., Schollmaier, P., Radermacher, K., &amp; Janß, A. (2026). Evaluation of 5G cellular and Wi-Fi 6 for cable-free surgical navigation using ISO/IEEE 11073 SDC. <em>International Journal of Computer Assisted Radiology and Surgery</em>. <a href="https://doi.org/10.1007/s11548-026-03774-1" rel="noopener noreferrer">https://doi.org/10.1007/s11548-026-03774-1</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1007/s11548-026-03774-1" rel="noopener noreferrer">10.1007/s11548-026-03774-1</a></p>
<p><strong>Keywords:</strong> 5G, Wi-Fi 6, surgical navigation, ISO/IEEE 11073 SDC, wireless medical devices, operating room, latency, tracking camera, private cellular networks, medical device interoperability, computer-assisted surgery, RWTH Aachen</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">219710</post-id>	</item>
		<item>
		<title>Automated Time-Sensitive Networking Brings Deterministic Delays to Connected Operating Rooms</title>
		<link>https://scienmag.com/automated-time-sensitive-networking-brings-deterministic-delays-to-connected-operating-rooms/</link>
		
		<dc:creator><![CDATA[Ophelia Keating]]></dc:creator>
		<pubDate>Wed, 30 Sep 2026 16:57:40 +0000</pubDate>
				<category><![CDATA[Medicine]]></category>
		<category><![CDATA[automated network configuration]]></category>
		<category><![CDATA[bounded-latency communication]]></category>
		<category><![CDATA[Gate Control List]]></category>
		<category><![CDATA[ISO IEEE 11073 SDC]]></category>
		<category><![CDATA[medical device interoperability]]></category>
		<category><![CDATA[operating room networks]]></category>
		<category><![CDATA[patient safety]]></category>
		<category><![CDATA[QUIC]]></category>
		<category><![CDATA[RWTH Aachen University]]></category>
		<category><![CDATA[Surgical robotics]]></category>
		<category><![CDATA[Time-Aware Shaper]]></category>
		<category><![CDATA[Time-Sensitive Networking]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=217298</guid>

					<description><![CDATA[Researchers at RWTH Aachen University have demonstrated an automated workflow that configures Time-Sensitive Networking for ISO IEEE 11073 SDC-based medical device networks, achieving stable bounded-latency communication under heavy load when schedules are generously dimensioned.]]></description>
										<content:encoded><![CDATA[<p>In the modern operating room, a surgeon&#8217;s foot switch can trigger a high-frequency surgical device, a robot can respond to force feedback, and dozens of monitors, pumps and cameras all compete for the same network cables. For years, the industry has promised a future in which medical devices from different manufacturers talk to each other seamlessly over standard Ethernet, without proprietary black boxes or tangled extra wiring. A new study from RWTH Aachen University brings that future measurably closer, while also delivering a sober warning about how easily it can go wrong. The research, published in the International Journal of Computer Assisted Radiology and Surgery, demonstrates for the first time a fully automated workflow that configures Time-Sensitive Networking (TSN) for medical device networks built on the ISO IEEE 11073 Service-oriented Device Connectivity (SDC) standard, and then stress-tests the result under realistic traffic loads.</p>
<p>SDC, standardized since 2019, is the backbone of the vendor-independent operating room. It defines how a medical device describes itself, its measurements, its settings and its remote operations, so that any compliant consumer can subscribe to a ventilator&#8217;s data or invoke a function on a surgical device without knowing who built it. At the heart of every SDC provider sits the Medical Device Information Base, or MDIB, a structured, XML-based model that captures both the static anatomy of a device, organized as a containment tree of systems, subsystems, channels and metrics, and its dynamic state, from live measurement values to alert conditions. What SDC does not define, however, is any guarantee about when those messages arrive. Previous studies have shown that while average latencies in SDC networks are low, they can spike unpredictably when the network gets busy, which is precisely the wrong behavior for applications where a delayed foot-switch signal or a lagging robot command could compromise patient safety.</p>
<p>Today, teams that need deterministic timing often fall back on proprietary solutions or dedicated real-time fieldbuses running alongside the standard network. One example cited in the literature is the Surgical Real-Time Bus, which achieves deterministic communication but demands additional cabling, driving up installation and maintenance costs in an environment where cable clutter is already a documented safety hazard. Time-Sensitive Networking offers an elegant alternative: a suite of IEEE 802.1 extensions that turns ordinary switched Ethernet into a time-controlled transmission system. Its centerpiece, the Time-Aware Shaper specified in IEEE 802.1Qbv, divides time into repeating cycles of slots, and a Gate Control List (GCL) dictates, for every slot and every traffic queue on every device, whether the gate is open or closed. Critical traffic gets reserved windows; everything else waits its turn. The catch is that computing these schedules is hard, and the effort grows with every device and stream added to the network.</p>
<p>The Aachen team, led by Maja Dohms with Noah Wickel, Klaus Radermacher and Armin Janß, attacked exactly that bottleneck. Their automated workflow starts by mining the MDIB of each SDC device: every metric and every service operation is identified as a communication stream, payload sizes are estimated from the SDC message structure and the technical ranges declared in the device description, and transmission periods are derived from the determination and invocation periods stored in the model. Safety classifications are mapped to priority levels, and custom MDIB extensions supply the jitter constraints and string-length bounds that the standard does not natively define. Network parameters are not left to guesswork either: processing delays are measured directly by exchanging UDP packets between devices and comparing hardware and application time stamps, while propagation delays are calculated and link speeds read from the device configuration. The result is a complete stream set and topology description, fed automatically into an open-source scheduling framework.</p>
<p>For schedule computation, the researchers used the TSNKit framework with a joint routing-and-scheduling algorithm, extended to model temporal dependencies between streams and to assign traffic queues. The computed Gate Control Lists are then translated into device-specific configuration files and deployed across the network through the fully centralized configuration model defined in IEEE 802.1Qcc, in which a Centralized Network Controller distributes schedules to every TSN-capable participant. On the Linux end systems, the team used the TAPRIO queuing discipline, which implements the Time-Aware Shaper, with configuration scripts generated automatically and pushed over SSH. Underpinning the entire scheme is the Precision Time Protocol, which synchronizes every clock in the network to a grandmaster so that all gate openings happen in a shared timeframe. The workflow even schedules the PTP synchronization messages themselves at the highest priority, since the whole edifice collapses without accurate time.</p>
<p>The experimental testbed consisted of two virtual end devices, one acting as SDC provider and network controller, the other as consumer, connected through a TSN-enabled switch. The provider, running on a Dell PC with an Intel I225-LM network interface, transmitted two numeric metric updates every 500 milliseconds and processed one activate operation per second, with latency bounds of 500 and 100 milliseconds respectively. Background load was generated with iperf, hammering the network with parallel UDP streams at up to 3 gigabits per second, in two scenarios: traffic between the two endpoints themselves, and external traffic from a third node. Three window-dimensioning strategies were compared: a minimal fixed window of 75 microseconds, which proved to be the lower bound for a stable SDC connection, and two strategies scaling windows proportionally to message size by factors of ten and one hundred.</p>
<p>The results reveal a delicate balancing act. Without any TSN configuration, SDC latencies stayed below 23 milliseconds on an idle network, but under load, sporadic peaks exceeded ten times the median value. With the tightest 75-microsecond schedule, communication became unstable: state update messages accumulated in queues that never had time to drain, latency climbed steadily, and the consumer eventually terminated its subscription. The factor-10 schedule improved matters but remained fragile, particularly under external load, where state updates were lost almost immediately. Only the generously dimensioned factor-100 schedule kept communication stable under both internal and external traffic, with maximum SDC latency remaining in the same range as under unloaded conditions. Yet even this best configuration could not consistently meet its timing constraints, and a sawtooth-like latency pattern betrayed a phase misalignment between the message transmission period and the schedule cycle. Improperly dimensioned windows, the authors found, can produce latency peaks of up to four times the planned transmission time, connection loss and outright instability.</p>
<p>The team also experimented with a modified SDC library that replaces the conventional HTTP/2 over TCP transport with HTTP/3 over QUIC, a UDP-based protocol designed for faster connection establishment. The QUIC-based variant showed slightly lower median latencies in baseline measurements and required fewer scheduled time slots, since fewer protocol messages needed reserving. Under the factor-100 schedule with background load, latencies stabilized after brief transient outliers, suggesting that when the message cycle aligns with the schedule cycle, stable timing can be maintained even under heavy interference. Intriguingly, the measurements also showed that unscheduled SDC communication tolerated load and timing deviations better than overly restrictive schedules, a counterintuitive finding that underscores how a poorly fitted deterministic regime can be worse than none at all.</p>
<p>What makes this work significant is less any single latency number than the demonstration that the configuration burden, historically the great obstacle to TSN adoption, can be lifted almost entirely off the shoulders of clinical engineers. Because the communication requirements are extracted automatically from the very device descriptions that SDC already mandates, a network of interoperable medical devices could in principle configure itself for bounded-latency operation after initial setup, with little manual intervention. That is a prerequisite for any realistic deployment in hospitals, where networks change as devices are wheeled in and out and staff cannot be expected to hand-tune gate control lists. The authors are careful to note, however, that their reported window sizes and scaling factors are empirical observations specific to their testbed, not transferable design rules, and that topology information still must be supplied manually.</p>
<p>The road ahead involves automated device discovery, dynamic acquisition of processing and queue parameters through a centralized device manager, and runtime validation and adaptation of schedules, along with extension to larger networks and coordinated device groups operating as real-time communication ensembles. Reliable worst-case latency bounds, the gold standard for safety-critical certification, remain to be established. But the direction of travel is clear. A connected operating room in which a robot, an electrosurgical unit and a navigation system share one cable, one standard and one predictable clock is no longer a white-paper fantasy. It is an engineering problem with a demonstrated, automated solution, and the remaining work is a matter of tightening schedules, not reimagining them.</p>
<p><strong>Subject of Research:</strong> Automated TSN configuration for bounded-latency communication in ISO IEEE 11073 SDC-based medical device networks</p>
<p><strong>Article Title:</strong> Evaluation of an automated workflow for TSN-based bounded-latency communication in ISO IEEE 11073 SDC-based medical networks</p>
<p><strong>Article References:</strong> Evaluation of an automated workflow for TSN-based bounded-latency communication in ISO IEEE 11073 SDC-based medical networks. (n.d.). <a href="https://doi.org/10.1007/s11548-026-03801-1" rel="noopener noreferrer">https://doi.org/10.1007/s11548-026-03801-1</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1007/s11548-026-03801-1" rel="noopener noreferrer">10.1007/s11548-026-03801-1</a></p>
<p><strong>Keywords:</strong> Time-Sensitive Networking, ISO IEEE 11073 SDC, medical device interoperability, operating room networks, bounded-latency communication, automated network configuration, Time-Aware Shaper, Gate Control List, QUIC, surgical robotics, patient safety, RWTH Aachen University</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">217298</post-id>	</item>
	</channel>
</rss>
