Tim Churches wrote:
I think this is the key point. ACKs and NACKs do need to be at the application level - as well as at the transport level, although the latter is redundant if there are app level ACKs/NACKs, but do no harm. This implies that the "smarts" need to be built into the sending and receiving clinical applications, and that putting smarts, sophistication and features into the transport layer is the wrong thing to do.
Personally I would like to see the messaging separate from the clinical applications (many of which are obviously getting too hard to maintain at a programming and support level already). As long as the message broking applications have open APIs there is less chance of the unholy alliances which Andrew warns us against. It would also allow a one to many relationship between the message broking agent and the onsite clinical applications.
Tony _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
