Try Amazon Simple Queue Service (Amazon SQS) for cross-org messaging, RHIO, NHIN data

One of the foremost requirements of an Inter-Enterprise data interoperability (sending data between organizations) solution like a RHIO or even NHIN is to have a solid messaging service or technology. Buying a messaging engine for inside the interprise is fairly easy but setting one up for cross-organizational use is not trivial.

One of the services that Amazon offers, called the Simple Queue Service (Amazon SQS), is a great option for multiple organizations that want to share data but don’t know how to do reliable messaging. Here’s what Amazon says about it:

Amazon SQS offers a reliable, highly scalable hosted queue for storing messages as they travel between computers. By using Amazon SQS, developers can simply move data between distributed application components performing different tasks, without losing messages or requiring each component to be always available. Amazon SQS works by exposing Amazon’s web-scale messaging infrastructure as a web service. Any computer on the internet can add or read messages without any installed software or special firewall configurations. Components of applications using Amazon SQS can run independently, and do not need to be on the same network, developed with the same technologies, or running at the same time.

The pricing is pretty reasonable, too: no startup costs and just 10 cents per 1,000 messages queued plus 20 cents per GB of data transferred. Not bad at all.

Check it out and start interoperating without all the hosting headaches.

Newsletter Sign Up

5 thoughts on “Try Amazon Simple Queue Service (Amazon SQS) for cross-org messaging, RHIO, NHIN data

  1. You must be kidding!?

    I wouldn’t recommend anyone to send highly confidential data through a third-party like Amazon, especially not healthcare institutions etc.


    Lars Wilhelmsen
    Senior Software Engineer
    Teleplan Globe AS

  2. Lars — I’m as security concious as the next guy but I’ve seen many small to medium sized implementations that would not be as secure as what Amazon has in place already. If you’re a big shop and you know exactly what you’re doing then doing all this on your own is great. If you’re a small or medium shop you’re better off going to someone else because getting right yourself is always a challenge.

    My experience has been that many of the guys that are protecting financial data (like Amazon) do a better job of security than some of us do in healthcare anyway.

    Of course, nobody should enter any deal without a good amount of due diligence and proper SLAs but I wouldn’t dismiss it outright 🙂

  3. I don’t really understand what the security issue is with SQS. This kind of problem has been well solved with encryption techniques. It’s hardly different to send an encrypted message via SQS from sending one over the public Internet inside a VPN.

    There is some kind of argument about decrypting the data if a copy is siphoned off, but really, that’s pretty significant resources. Not to mention that you would have to have access to the Amazon network or queuing system(s).

    It’s not just about whether your data can be attacked, it’s also about how practical the attack is.

  4. Pingback: Trusted.MD Network

Add Comment