spud023
commented
2 months ago Hi team,
After doing a proper scan of the material, I think my comments here are mostly irrelevant, and the answers to my questions/suggestions are already in the body of the work.
kyle-mwnz
Summary
I'm troubled by the mixture of language about what I'd call "styles of interaction", and "technical modes of delivery".
The following paragraph uses language that usually describes a protocol layer, or middleware style that is down the communications stack from what I would expect here, which is a description of the "application layer" in the OSI 7-layer model, or "Computational Viewpoint" in the RM-ODP.
once you use the word "API", you're implying a blocking, guaranteed delivery protocol, even if the receiver may take the parameters (the "event notification contents") and return an acknowledgement-of-receipt only, and not of content processing... which logically constitutes "non-blocking", but this language is usually used to describe lower level protocol behaviour of a send-and-hope-for-best approach, like the use of UDP instead of (usually HTTP over) TCP/IP. The language used here should be changed or clarified that it is for use in a Synchronous API environment, but that the roles of sender and receiver are reversed, using a "Publish/Subscribe" paradigm (which I think should really be called "Subscribe/Publish" as that's the temporal order of the two actions).
I think a short discussion of Pub/Sub would be in order here. Perhaps refer to the "Listener" or "Callback" Pattern in Gamma et al. This is clearly in the "styles of interaction", and not the "technical modes of delivery" paradigm, the latter of which I think should be avoided in "design" discussions. (Here's a discussion: http://blog.danieldee.com/2009/06/callback-vs-listener.html, and the reference to the Gamma et al Patterns book... which I'm sure has individual web pages for each pattern online somewhere - Wikipedia?)
If you literally mean the use of different network protocols, then this list of benefits does not go together, and is actually in conflict. Truly asynchronous network protocols (UDP being my example again) do not have guaranteed delivery, and cannot be used to create reliable updates to important information such as patient records, especially not to ensure a "Unified Patient Record" as stated a few bullet points below. (Refer to my previous issue about the use of the word "Realtime", which is a different systems discipline, requiring specialised hardware, protocols, redunancy and so forth.). For API-based systems "Near Realtime" is the best you can promise.
Link to standards item
https://apistandards.digital.health.nz/draft/api-development/Asynchronous%20APIs/Introduction#what-is-an-asynchronous-api
Which area of the standards does this apply to?