Advertise provider communication capabilities to consumers

[PaulMartinsen]

SDC and SDPi are not clear on how provider communication capabilities, such as the maximum number of current connections, can be discovered by consumers to support the wide range of implementations expected.

PR#518 describes scenarios that clarify the issue in SDPi for MDPWS communications and includes examples on how consumers and providers could work together to maintain interoperability without extending the device description to advertise capabilities. This approach requires consumers to react and recover from faults. It may be helpful if consumers can discover connection limitations in advance to plan a suitable strategy.

For example, see the discussions on:

• distributing consumer connections & signalling limitations,
• one approach for metadata in DPWS to advertise capabilities,
• limitations consumers might need to know about,
• using custom http status codes.

Any solution needs to be practical and accommodate the diversity of participants that might be expected in an SDC network from pulse oximeters, with limited processing power, to high-performance ventilators with cycles to spare.

The main use case for multiple, concurrent connections appears to be timing risk for executing remote operations on a second channel so that processing delays on the first channel (e.g., requesting mdib, renewing subscriptions), don't impact remote operation. These risks will also be considered and/or addressed in the external control pkp standard.

Related issue in external control pkp

[ToddCooper]

2026.07.10 SDPi Friday - @PaulMartinsen
Though it was recognized that the need for this proposal emerges from the related #518 and the need for some means of communicating the information, it was also recognized that this is the "tip of the iceberg" on a much broader topic that might be summarized as:

• Real-time monitoring & management of network health + (potentially) forensics for when things don't go as expected

This is a long running topic, especially in the "ICE" world where standards like the ICE Data Logger have emerged. In the early days of SDPi, we also talked about systems communicating "computable instructions for use" (e.g., QoS & QoD safety envelope that is required to ensure proper performance of the intended functionality using a devices SDC interface.

Also, this is ultimately an SDC participant topic and not simply a provider->consumer topic.

There are questions as to the use cases that would motivate supporting these capabilities, and who will drive the business value proposition for implementation. Additionally, is it something that would be exchanged at run-time by the device itself? Or at implementation / deployment when the device is put into service? Would there be a separate less real-time dynamic info stream that a vendor (in a standardized way, like MDS2 forms) could provide for Medical Device Network Risk Managers? And if so, who would require this of manufacturers.

NOTE: In the past, I have proposed inclusion in SDPi of a profile or profile option around (roughtly) "medical device network health management" that would pull the various pieces of this discussion into something that stakeholders could say, "Yes, that's what we need to do" and is implementable, etc.

As a result, the issue was assigned to Milestone 3.0 and the topic should be queued up for discussion at a future workshop.

IOW - It is a good idea, but whose time has not quite yet "come" ... soon! (hopefully)

[PaulMartinsen]

This isn't really about monitoring network health. There are a diversity of choices (1, 2) participants can make to meet various requirements, some of which aren't compatible.

So its more about providing information all participants need to interoperate successfully whether they have more or less processing power than Apollo 11. Still a good one for SDPi 3.