How to deal with conditionalities that are not (currently) framed as profile options

[JavierEspina]

How do / should we deal with conditionality other than as formal profile options (e.g., is it possible to have conditional text in requirement statements + a "conditional" hidden label?). If we have only profile options we may see an explosive proliferation of those!

Here is the concrete example that triggered these questions, coming from the review of PR#469, and moved from there to this new issue to unlock progress on PR#469:

R0800, R0801and R0802 are shall level requirements that, accordingly, show up as "r" in the ICS table 3:Z.2.2-1 for SOMDS Providers. Shouldn't that be conditional on (1) the Participant using the sdpi:ReportSequence extension (which is "should" in all 2:A.5.2 requirements) AND (2) the Participant using MDPWS (as that extension is defined in 2:A)?

[JavierEspina]

@PaulMartinsen looped in.

[PaulMartinsen]

This seems to open a large can of worms for testing, since every "should" requirement seems an optional requirement. Would the test candidate submit a completed ICS table to indicate which "options" they've selected? With not-applicable for some "mandatory" requirements. Then the use case would be for the test tooling to decide if the selected set of requirements meet the overall profile. So we'd want some way to capture those requirement sets in the source.

Incidentally, the json export captures requirements R0800 etc "belong" to the biceps content module and R1031 "belong" to the mdpws protocol (through the owner field).

[PaulMartinsen]

There's a similar issue with ICS statements from external standards. For example, in 10700 RR1074 requires base consumers to consider risks from receiving alert information. However, in SDPi, the SOMDS Medical Alert Consumer, not a SOMDS consumer, receives alert information.

[JavierEspina]

There's a similar issue with ICS statements from external standards. For example, in 10700 RR1074 requires base consumers to consider risks from receiving alert information. However, in SDPi, the SOMDS Medical Alert Consumer, not a SOMDS consumer, receives alert information.

A SOMDS Medical Alert Consumer is, in a way a specialization of a SOMDS Consumer (well, strictly speaking it is paired to it, inheriting all it's capabilities). Does this address that issue?

[PaulMartinsen]

There's a similar issue with ICS statements from external standards. For example, in 10700 RR1074 requires base consumers to consider risks from receiving alert information. However, in SDPi, the SOMDS Medical Alert Consumer, not a SOMDS consumer, receives alert information.

A SOMDS Medical Alert Consumer is, in a way a specialization of a SOMDS Consumer (well, strictly speaking it is paired to it, inheriting all it's capabilities). Does this address that issue?

It does if participants are required to implement, for example, the SOMDS Medical Alert Consumer. My understanding was participants would chose which SDPi profiles they wanted to conform to. In that situation, there seem to be obligations from 10700 related to alerts on consumers that chose not to support the, for example, SDPi-A profile. So I'd wonder why SDPi is broken up into various profiles at all.