The ability to go peer to peer to collect the image or clinical document is a key function of the IHE XDS model, however it allows for offsite storage as well. IHE may have started life as a US radiology integration system but it is a lot more versatile now.
I agree in general with the point of minimising any central infrastructure required for communication, however we have to accept that some will be required eg. The internet, Identity services for patients, provider directories and referral management infrastructure for some referral situations and requirements, security management etc. We cant remain total individualists! If we do we wont need to communicate. Regards Peter MacIsaac MacIsaac Informatics Consulting in Health Informatics, Terminology & Data management and Health Policy. [EMAIL PROTECTED] 0411403462 (mobile) 61611327 (office) peter_macisaac (skype) 8 Ewart St. Yarralumla 2600 "We trained hard, but it seemed every time we were beginning to form up into teams, we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising, and a wonderful method it can be for creation the illusion of progress while producing confusion, inefficiency and demoralisation." - From Pertonii Arbitri AD 66, attributed to Gaius Petronus, a Roman General who later committed suicide. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew N. Shrosbree Sent: Wednesday, 10 May 2006 5:01 PM To: [EMAIL PROTECTED]; General Practice Computing Group Talk Subject: Re: [GPCG_TALK] IHE and XDS - sharing of documents and What I find appealing is that when the user needs the image, they establish a direct peer-to-peer connection that does not have to go through an intermediary gateway. Tim Churches wrote: Andrew N. Shrosbree <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> wrote: Gavan, Your question regarding whether it is appropriate to use a US-centric radiology model is very pertinent. The IHE model is, IMO, excellent for handling the kind of huge blocks of data inherent in the retrieval of images. Having only a 'manifest' stored centrally makes the process extremely efficient. In what way does having a central "manifest" make the process extremely, or even more efficient? The actual (large) image files still need to be sent or retreived from provider to client (or v-v). The only difference is that in the IHE model the recipient polls the central "manifest" Web service to see if anything is waiting to be picked up by it, whereas in the direct Web service model which we have been discussing, the sender tries to send directly to the recipient and if the recicient is not contactable, teh sender tries again later and/or takes alternative action (eg if the information is urgent). As has been discussed, the overhead of resending iff (if and only if) a recipient Web service is offline is not likely to be any more than the overhead of everyone having to constantly poll a central "manifest" service or clearinghouse. Plus it avoids the very significant central point of failure which a "manifest" service represents. And as Gavin points out, the IHE model of a central manifest doesn't help when more complex interactions between Web services are involved, rather than just "Here's Mrs Blogg's chest xray". Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk -- Andrew N. Shrosbree B.Sc, B.Ec Technical Director ArgusConnect Pty Ltd http://www.argusconnect.com.au Suite 4, Greenhill Centre, Mt Helen Victoria, Australia Tel: +61 (0)3 5335 2214 Mob: +61 (0)415 645 291 Skype: andrewshroz -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.5.2/330 - Release Date: 3/05/2006 -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.5.2/330 - Release Date: 3/05/2006 _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
