Richard Hosking <[EMAIL PROTECTED]> wrote: > > Might be a possible architecture for the "web services" NEHTA has in > mind > It would mean that each provider did not have to maintain a web server.
Yes, that's exactly what I was thinking. > Still have the problem of keys etc. You still need an effective PKI to enable it all. > I guess it is effectively E mail in > another format. Yes, but one in which each message "attachment" can be up to 5GB in size. Tim C > Tim Churches wrote: > > >Tim Churches wrote: > > > > > >>Amazon S3 may be of interest to subscribers to this list, both > software > >>developers and end-users. > >> > >>Here is the blurb from the S3 Web page at > >>http://www.amazon.com/gp/browse.html/104-1570532-7764752?node=16427261 > >> > >> > >... > > > > > >>Lots of things, but a few things spring immediately to mind. > >> > >>1) Off-site secondary storage of back-up files for practices or > clinics > >>running their own EMR systems or other clinical applications on > >>locally-hosted servers. The advantage of the simple API provided by S3 > >>is that the EMR/clinical application for a practice/clinic could > >>automate the back-up-and-copy-to-S3 cycle, and could even automate > >>periodic test retrievals and restores (to a separate test database or > >>file system on the clinic's EMR server). I wouldn't trust the Amazon > >>assurances of privacy for the data (as Amazon are still subject to US > >>search warrants and court orders for example, as well as simple > security > >>blunders - so any patient data would need to be strongly encrypted > >>before sending it to S3 for off-site backup storage - but that should > be > >>routine practice for any off-site back-ups of patient data on > removable > >>or transportable media anyway). The cost structure for the S3 service > >>would make such use very cheap, since the back-up data are sent once > and > >>would be rarely accessed, so the bandwidth charges should be quite > >>modest, and the per-month storage charges are very cheap. Cheap enough > >>for even small clinics in developing and transitional countries to > >>afford, assuming they have broadband Internet access to enable the > >>upload of back-ups to S3 in the first place. Certainly cheap enough > for > >>even small practices/clinics in rich countries - no more than $10-$20 > >>per month I would think, maybe much less. > >> > >> > > > >I had a play with Amazon S3 over the weekend. Well, I tried to, because > >it was down for about 22 hours from Sat evening to Sunday evening, > which > > puts their claims of 99.99% uptime in doubt. However, it was only > >launched two weeks ago so some teething problems might be expected. I > >expect they will iron out the bugs and achieve their reliability > >targets, eventually. > > > >Anyway, I did manage to store various bits of data and some files on > it, > >and to get them back. Of primary interest is the transfer speed for > >large files eg encrypted backups. I stored a 15MB encrypted file on S3 > >in 10 minutes. Retrieval took about the same length of time. according > >to my online S3 account summary, I now owe Amazon US$0.01 - of course, > >the longer I leave the file there on S3, the more I will be charged - > >US$0.15 per GB per month for storage - but it is not going to send me > to > >the poorhouse. > > > >The primary issue is the transfer speed. I am using Optus cable, which > >uploads and downloads to local Web servers at over 500 kB (kilobytes, > >not kilobits) per second - so at full speed, my 15MB upload should have > >taken just 30 seconds. Thus, the rate-limiting step seems to be > >elsewhere - perhaps the speed of the link to the US where the Amazon > >servers are located, or perhaps Amazon is throttling upload and > download > >speeds to and from S3 to preserve their bandwidth. Anyway, the point is > >that 15MB in 10 minutes is probably what you can expect here in Oz, > >regardless of what sort of Internet connection you have (as long as it > >is not a dial-up modem). > > > >Is this fast enough to be useful for offsite encrypted back-up copies? > >Well, its fast enough for our purposes, which is backup storage of > >encrypted ad hoc public health outbreak data collections which are > often > >collected "on the road". But for a 3 or 4GB practice backup? Let's see, > >15MB in 10 minutes equates to 3GB in 50 hours. > > > >Hmmm, that effectively rules it out for offsite GP encrypted backup > >copies. Pity. I'll continue to collect data points on transfer speed. > >Perhaps the forthcoming Google Gdrive and the start-up OmniDrive online > >data storage services, which are expected to be priced similarly but > >which may have servers located in Australia, will be much faster. > We'll > >see when they are available. I still think that Amazon S3 might be of > >interest to radiology practices wishing to provide a cheap > >store-and-forward facility to clients for their digitised image files, > >which tend to be rather large and thus not well suited to SMTP-based > >(email) transport - without either party needing to run 24x7 Web > >services (Amazon S3 does that for you and both the sender and receiver > >of an image file would just act as clients to it). It would also work > >very nicely as a store-and-forward facility for interchange of HL7 > >messages - Amazon S3 would effectively be the unintelligent > >data-store-and-retrieve middleman - but gee, they don't charge much - I > >suspect that the bill for even a large path lab might only be a few > tens > >of dollars per month. Some open source code to add the smarts and > >encryption at the sending and receiving ends and you have the makings > of > >a very cheap but potentially very robust secure health data exchange > >service with an architecture rather similar to that offered by > >Healthlink etc, but with negligible per-message costs. Add Google and > >OmniDrive into the picture as alternative unintelligent > >data-store-and-retrieve middlemen, which the client software could > >automatically fall back to and you would really have something. There's > >a business opportunity there for someone or some group to, um, make > >almost no money at all, but to receive accolades heaped upon their > head(s). > > > >Tim C > > > >_______________________________________________ > >Gpcg_talk mailing list > >[email protected] > >http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > > > > > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
