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.
Still have the problem of keys etc. I guess it is effectively E mail in
another format.
R
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
