On Sat Mar 17 14:43 , Tony Eviston <[EMAIL PROTECTED]> sent:
>Tim Churches wrote: >> 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. Currently there is no API which allows the clinical app to report problems back to the messaging app: they are "over-separated". Obviously it's that happy standards-based medium between the monolithic super-app and the current scenario we are looking for. >It would also allow a one to many relationship between the message >broking agent and the onsite clinical applications. This means each clinical application has to keep it's own record, and creates havoc with defining ACKs: what if one clinical app accepts the message, but the other rejects, what's the messaging app to do then? IMHO there will always need to be a central app that, if nothing else, stores the data, (even if it's a 'black box' file like radiograph data that is only understood by another module) it is the ultimate decider of whether data is accepted or not. Ian _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
