Tom Bowden wrote: > I believe IHE is very effective for ensuring system interoperability > and its Connectathons are an ideal way to progress that, however > for the very reasons Tim has pointed out, the messaging concepts Ross > referred to are a 'dead duck'.
Tom, perhaps so, but I would also venture that any secure health messaging model in which the service provider seeks to interpose their own server on a mandatory basis between the parties wishing to communicate, so that it can monitor traffic and hence collect toll charges is also a "dead duck", or at least a fowl very likely to come down with a bad case of H5N1 fairly soon. The future, as NeHTA has shown us, is peer-to-peer Web services, through which parties can do their own delivery/response tracking. Messaging service providers will still have a role, but that is to provide and support the Web services software and interfaces to clinical systems at both ends - but having done that, they should get out of the way and let the health service providers' computers talk to each without an obligatory middle man. That's the ArgusConnect model, albeit via SMTP rather than Web services for the moment, and it works perfectly well. Converting the Argus model to Web services will make it even better. And no, the ArgusConnect people are not altruistic saints - they charge market rates for the provision and support of their software. But the main thing which distinguishes their model is that users (of any shape or form, including the big path labs etc) are not obliged to pay Argus for either message delivery nor support - if you stop paying, then your Argus message delivery system still keeps chugging along, since none of the messages are routed through any Argus servers. The fact that the source code for the software is available under an open source license provides an added buffer against lock-in. Thus, ArgusConnect doesn't have a monopoly on the delivery of messages using ArgusConnect, nor on the software. That's good, because monopolies are bad, or dangerous, especially for basic infrastructure. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
