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
