Early "pre-published" Alert PKP Integration into SDPi-A

[JavierEspina]

The full-fledged SDPi adoption / integration of the final A-PKP standard with all its envisaged capabilities (DAS, Clinician alert acknowledgement, Alert Delegation, Silent ICU, etc.) - currently slated for SDPi 3.0 - is anticipated to be a heavy lift!. Therefore it would be advisable to follow a step-wise approach.

Proposal:
As as a first step, the parts of the A-PKP that are currently stable (enough) should be integrated. As of July 2025, and as a first step, this concerns the technical requirements for managing a DAS (Distributed Alarm System). For that, one or more new transactions will likely be needed for which no numbers have been pre-allocated yet*.

*DEV-41 and DEV-42 transactions are reserved for future use in alert delegation, and should not be used for this. They will be developed later on (also note that a DAS is needed BEFORE Alert Delegation can be exercised).

[JavierEspina]

SDPi call July 18:
Vol 2 will be definitely affected. But also Vol 1 for use cases (1:C) and SPDi-A.

[JavierEspina]

@ToddCooper @PeterKranich @d-gregorczyk - I have drafted this diagram of a potential new transaction DEV-48 Manage Distributed Alarm System

My main question right now is whether we want to go that way or rather split the last box (intentional ending of the DAS) into another transaction. In the latter case we would be talking about two transactions: DEV-48 Establish Distributed Alarm System and DEV-49 End Distributed Alarm System. Thoughts?
Note that SDPi is not quite consistent on this. The all-in-one-transaction option takes DEV-27 as reference. The two-transactions option takes DEV-38 as reference. Also note that Peter has pointed out that splitting in two transactions could be beneficial for the future Alert Delegation and Silent Mode Options / Transactions, which will have to have a dependency on the DAS being established and running

[ToddCooper]

@JavierEspina - Thanks for moving this forward ... with pictures too!!!

"Thoughts?"

1. Consistency? In coming up with the transaction model for TF-1 and the four SDPi profiles, it was a real challenge to abstract the PnT / SOMDS architecture into something that isn't too granular - MDPWS message-by-message - and not too high-level (one transaction to "establish SDC connectivity" that was too all inclusive to be useful!). So the fact that there is variability in the transactions design pattern is not a surprise! Right or wrong ... it was a judgement call! That said, if this is an issue, we can always have a discussion NOW vs. when we're further down the pike and any such adjustment would run into implementations.
2. One or Two? Given (1) above and the "judgement call" ... I'd take @PeterKranich 's lead about the value of splitting it out now so as to make future capabilities and architectural extensions easier to add in (vs. requiring demolition first) ... TWO transactions makes sense to me.

Hopefully that is helpful.

[JavierEspina]

@JavierEspina - Thanks for moving this forward ... with pictures too!!!

"Thoughts?"

1. Consistency? In coming up with the transaction model for TF-1 and the four SDPi profiles, it was a real challenge to abstract the PnT / SOMDS architecture into something that isn't too granular - MDPWS message-by-message - and not too high-level (one transaction to "establish SDC connectivity" that was too all inclusive to be useful!). So the fact that there is variability in the transactions design pattern is not a surprise! Right or wrong ... it was a judgement call! That said, if this is an issue, we can always have a discussion NOW vs. when we're further down the pike and any such adjustment would run into implementations.
2. One or Two? Given (1) above and the "judgement call" ... I'd take @PeterKranich 's lead about the value of splitting it out now so as to make future capabilities and architectural extensions easier to add in (vs. requiring demolition first) ... TWO transactions makes sense to me.

Hopefully that is helpful.

Thank you Todd. Feedback appreciated.

Regarding #1: I think it is not a enough of an issue to make changes to the current content of SDPi. There are ways of seeing it as consistent...at least in my head! :-) - e.g. "manage" standing for the most complete transactions and "establish" for transactions that deal with the first steps of managing.

Regarding#2: OK, I am going to go ahead with two transactions in this issue's branch.

[JavierEspina]

New question: should the Vol2 transaction description use the "more abstract" SOMDS Consumer/Provider actors or the specific ones described in Vol1 (e.g., SOMDS Medical Alert Consumer/Provider)?