COMMENTARY -- Really Simple Syndication (RSS) is now nearly ubiquitous. RSS is a communications protocol for updating readers on news and the content of news-like sites, including major sites such as The New York Times, news-oriented community sites such as Slashdot, and personal weblogs (blogs). It's been very useful for doing "pull-based" alerts for online news sites. But RSS is not just for blogs and news. Almost anything that can be split into discrete items can be syndicated via RSS: the "recent changes" page of a wiki, the change history of a document, updates to a project plan, etc. As soon as information about distinct items is translated into RSS format, any program that can understand RSS (e.g., a news aggregator) can check the feed for changes and react to the changes in an appropriate way.

RSS is a wonderful solution to the "how do we tell everyone we have new stuff without sending out a bunch of e-mails?" problem. Although it's quite popular for syndicating content such as news, blog articles, and related information, I think RSS has a chance to make a huge impact on healthcare and medical data sharing as well.

Today medical devices send out alerts using one or more mechanisms in a "push-based" approach. For example, the device manufacturer has to write software to send alerts via e-mail, pager, phone, etc., whenever some programmed action occurs in the device. In the health-IT world, data sharing occurs through HL7 in a hub-and-spoke or publish/scribe model where all information is published to a broker and that broker is queried for things such as new lab results, updated patient information, etc.

Well, what if all medical devices had the ability to respond to RSS requests on various channels? For critical messages, the push method would be fine, but for other kinds of messages, we could have a channel that an IT system could poll every second, minute, or over many hours depending on how often the system wanted an update from a device. Instead of all the devices always sending out all messages, why not put in some simple code to respond to RSS requests and separate the different message types into RSS channels? This way, the pull-based approach allows the device to be more responsive to each client instead of having to use a broker model to send out all messages.

What if health-IT systems from Cerner, Misys, McKesson, etc., also had this capability? Suppose I wanted to use my mobile device (which will have RSS feed readers installed) to be able to check on labs for a particular group of patients? I could simply subscribe to a specific channel in a lab management system's RSS feed and get what I need without having to go through a broker. If I'm a doctor and I have a finite number of patients, I can simply subscribe to an RSS feed of my patient's data in all the various IT systems and pull together my own aggregator.

Think about RHIOs and how they could use RSS to subscribe to information across multiple health-IT systems.

I think with a little creativity, building in RSS publishers inside our medical devices and health-IT systems such as EMRs and HIS would go a long way towards helping create more interoperable systems. Of course, content and messaging standards such as HL7 would not be replaced but would become the de facto standard of the payloads in the messages that RSS feeds could publish.

the way, in this commentary I've talked a great deal about RSS, but only as a concept. The actual protocol that would be able to maintain appropriate security and reliability would be Atom, but Atom is less familiar to most users.