Lorem Ipsum

I have been mulling over widgets ever since a friend of mine showed me the Yahoo Day Planner widget on his desktop. This was about 3 months ago. Ever since then, I’ve been seeing a lot of buzz on the net regarding widgets. The Yahoo Widget Gallery seems to be flooded with thousands of widgets submitted by users.

Users are getting extremely creative in developing their widgets. And the big “net-daddies” are looking at widgets with increasing interest too.

Sure they are cool and nifty but I’ve always wondered if this technology has the potential of turning into something big by offering a lucrative channel for users and corporations alike. I did find an ebay widget that allowed you to create an ebay watch which was tied directly to the developers referral partner ID.

I’m going to be using this post to brainstorm about a widget idea that I’ve been thinking about. I am a Healthcare technology consultant. I’ve been implementing systems at hospitals for over 3 years now and with each new clinical system we implement, we encounter the same issue….Allergies. Yep, allergies. How we do control the flow of allergies from one system to another? A nurse can document an allergy at any point during a patient’s episode of care. So if it is during admission, it gets entered into the Patient management system, if during an OR procedure, in the OR system and so on. But how does this information follow the patient as he/she moves through different areas of the hospital? How does a floor nurse accurately know all allergies, including any new ones that might have developed during an OR procedure for a patient?

That brings me to my Allergy Widget. A read-only widget that sits on every desktop in a hospital. It simply takes a patient Medical Record Number (MRN) as input and then queries all systems dynamically to compile and display all relevant allergies. Some considerations:

1. HIPAA - Privacy is big, especially in the celeb-savvy hospital where I work. The widget has to be HIPAA compliant, i.e., automatic logoff, security, etc.

2. Interoperability - The widget has to be HL7 compliant…version 3.0 since it is XML-based. But then, it also needs to be backward compliant to receive feeds from older clinical systems. It can probably have a middle-tier communication engine like e-gate, that receives incoming messages from a variety of systems, processes and converts them to 3.0 messages before transmitting it to the widget.

3. Flexible - It should be relatively simple to add/edit incoming feeds. If a system is being upgraded or a new system is being installed, the widget should be able to add a feed from it relatively easily.

Of course, a true specification entails a much longer list of must haves. I would like to invite any interested people to partake in this as an open-source project.

Please reply to this post with questions, comments or feedback.

This entry was posted on Sunday, September 24th, 2006 @ 5:55 pm on the category Tech Churn. You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback from your own site.