My parents' laptop was marooned in one room of their house, chained by a wired connection to the DSL modem. I decided that adding a wireless router (Linksys WRT160N in this case) would be great to untether the machine. I expected the installation to be limited to daisy-chaining the new router between the DSL modem and the laptop, setting up a few things (admin password, SSID, wireless security and band options) and enjoying wireless connection in 5 minutes. And to do it all from 400 miles away. Piece of cake!
This could be a long blog post because my projected 5 minutes rapidly expanded into 5 hours, but I'll keep it short. Trouble manifested itself when after several failed attempts we reverted to old wired setup (new router not connected) and I noticed the laptop reporting being connected to a gateway at 192.168.1.1 - weird! Did I mention that the laptop runs Vista and I wanted to mock around with it as little as possible? So why would a DSL modem be at 192.168.1.1??? As usual, an extended Googling session brought clarity to this murky issue. Verizon's DSL modem - Westell 6100F in our case - turns out to be a router/modem combo! This box was acting as a router and the modem, and when new Linksys entered the picture, we had two devices - both routers! - competing for 192.168.1.1 address. No wonder things weren't working right.
I found excellent instructions on how to turn Westell's router functionality off, placing it in "bridged" mode, and effectively making it into dumb modem. Scary thoughts crossed my mind; "bridging" sounded eerily similar to "bricking," and being 400 miles away, last thing I wanted was a bricked Verizon's box! Nonetheless, after some deep breathing, we carried out the instructions. A few tense moments ensued when Westell in its new bridged mode was not connecting to the Internet. Turns out my parents particular flavor of Verizon's DSL uses PPPoE and newly dumbed-down Westell was no longer providing the necessary authentication information. Luckily, at this point configuration of Linksys proceeded smoothly and it was all too happy to take over the necessary PPPoE duties and we were online in no time.
Moral of the story? There can be only one 192.168.1.1! One for each private network, that is.
Wednesday, December 30, 2009
Monday, December 21, 2009
Raw Burgers and Future of Clinical Decision Making: A Ramble
The inspiration for this post was the final episode of "The Next Iron Chef". I was definitely psyched to see Jose Garces win. There was a moment in the show when the other finalist, Chef Mehta, served the judges a dish featuring a pork burger, and they commented that the pork was undercooked or even raw. This got me thinking - here are highly trained professionals, experienced practitioners of the art of cooking, and they are making such basic mistakes? In this day and age of advanced technologies, can't we come up with some gizmo to stick inside that burger patty, take its temperature and figure out - definitively - its state of doneness? Why rely on these rules of thumb (or rather the thenar eminence) - pun intended - by touching the meat to gauge whether it will still moo when I cut into it? Why am I talking about this? Well, think intravenous lines placement by highly trained professionals, experienced practitioners of the art of medicine. How are these lines placed? Essentially, by blindly poking around until you find the right blood vessel! Why not use the fancy technology? There are portable ultrasound thingies that help to visualize the needle and the vessel. Yes, they are far from perfect, but nothing new will be developed unless there is a demand for it, and there will be no demand until we stop thinking that relying on technology somehow makes doctors less cool.
Of course, same goes for information technologies. In his blog entry "Health IT: What’s the Future?" Steve Downs of Robert Wood Johnson Foundation recaps themes from a recent "Discovery and Innovation in Health IT" workshop. One presenter focused "on the need for cognitive support, showing a hockey stick graph of the number of facts that will be relevant to a given clinical decision over time (this theme reappeared several times over the two days). The number is expected to reach 1000 by 2020, while the number of facts that a human can contemplate while making a decision remains stuck at um, five." Healthcare practitioners need clinical decision support (CDS). I am surprised that such a statement could still be considered controversial...
Just like those ultrasound vein visualizing gizmos, CDS technologies are far from perfect. Thus far the CDS efforts are targeted at individual systems. The challenges are to figure out how to get/represent/manage/update/share clinical care guidelines logic that drives CDS recommendations, how to surface these recommendations to clinicians at the right place and time in a workflow-aware fashion so that they do not dismiss them outright, how to make these recommendations "actionable" to facilitate carrying out an order should a clinician decide to follow a recommendation. Necessarily, these efforts are hard - if not impossible - to generalize. These systems tend to be tightly bound to their initial implementation environments and are therefore non-interoperable in any meaningful way.
Ken Mandl and Zak Kohane proposed an idea of a plugin-friendly platform instead of a typical monolithic EHR. For this to work, the underlying clinical data must be handled in a way that abstracts it from individual applications. Alternatively, leave your monolithic applications alone and pool your data into a near-real-time repository that is application-agnostic. Ether way, if data can be separated from applications (how's that for a radical idea?), there is hope for the kind of interoperability that would result in scalable CDS. Automated processes are needed to abstract and represent domain knowledge encoded in clinical guidelines so that it can be machine-processable (consider baby-steps like HQMF); and it will probably take a miracle to figure out how to deliver CDS recommendations to practicing clinicians in such a way that they are useful. But despite these challenges, if the right incentives are in place to ensure a healthy demand for CDS technologies, we will see progress. The end-goal is the realization of the potential of healthcare IT - safe, appropriate, timely, high-quality care.
Of course, same goes for information technologies. In his blog entry "Health IT: What’s the Future?" Steve Downs of Robert Wood Johnson Foundation recaps themes from a recent "Discovery and Innovation in Health IT" workshop. One presenter focused "on the need for cognitive support, showing a hockey stick graph of the number of facts that will be relevant to a given clinical decision over time (this theme reappeared several times over the two days). The number is expected to reach 1000 by 2020, while the number of facts that a human can contemplate while making a decision remains stuck at um, five." Healthcare practitioners need clinical decision support (CDS). I am surprised that such a statement could still be considered controversial...
Just like those ultrasound vein visualizing gizmos, CDS technologies are far from perfect. Thus far the CDS efforts are targeted at individual systems. The challenges are to figure out how to get/represent/manage/update/share clinical care guidelines logic that drives CDS recommendations, how to surface these recommendations to clinicians at the right place and time in a workflow-aware fashion so that they do not dismiss them outright, how to make these recommendations "actionable" to facilitate carrying out an order should a clinician decide to follow a recommendation. Necessarily, these efforts are hard - if not impossible - to generalize. These systems tend to be tightly bound to their initial implementation environments and are therefore non-interoperable in any meaningful way.
Ken Mandl and Zak Kohane proposed an idea of a plugin-friendly platform instead of a typical monolithic EHR. For this to work, the underlying clinical data must be handled in a way that abstracts it from individual applications. Alternatively, leave your monolithic applications alone and pool your data into a near-real-time repository that is application-agnostic. Ether way, if data can be separated from applications (how's that for a radical idea?), there is hope for the kind of interoperability that would result in scalable CDS. Automated processes are needed to abstract and represent domain knowledge encoded in clinical guidelines so that it can be machine-processable (consider baby-steps like HQMF); and it will probably take a miracle to figure out how to deliver CDS recommendations to practicing clinicians in such a way that they are useful. But despite these challenges, if the right incentives are in place to ensure a healthy demand for CDS technologies, we will see progress. The end-goal is the realization of the potential of healthcare IT - safe, appropriate, timely, high-quality care.
Saturday, December 12, 2009
Newton MessagePad 2100 is back
No, Apple is not resurrecting the Newton, but my very own Newton MessagePad 2100 is making a comeback. It is running an NPDS webserver software and is available online! Come visit and leave a note on my Whiteboard if you'd like.
I owned this Newton since 1997 and early in its life it served as my primary computer - I did my wordprocessing, printing, e-mail, Telnet, etc. on this machine and it was fantastic. Since about 2002 I tried on and off to keep it up and running as a webserver. You can learn more about its setup when you visit. In short, the Newton is connected to my home network via Ethernet by way of a PCMCIA card.
What is different this time around? First, I did not want to rely on pre-MacOS X operating system (namely System 9) to connect to the Newton for synchronization, software uploads and backups. But I ran into a catch-22: Newton connection tools (NCX) available for MacOS X require a piece of software to be installed on the Newton. My solution was to fire up Classic mode on my old and trusty PowerBook G4, download and install original Apple's Newton Connection Utility, and use that to install the required package on the Newton. That worked flawlessly. And now I can connect to my Newton right from my MacBook Pro!
I also needed to take care of what is known as the Y2010 bug - read more about it here.
Lastly, I wanted to make sure that Newton's clock is accurate. For that I ended up using NewtSync.
There is a community of Newton enthusiasts who continue to use this incredible machine to do wonderful things. For example, this tracker shows which Newtons are online at any given moment. I am grateful to folks who continue to work on maintaining existing capabilities and developing new ones. I hope that by keeping my Newton online I am participating in some small measure in ensuring that innovations represented by this platform are recognized and appreciated.
I owned this Newton since 1997 and early in its life it served as my primary computer - I did my wordprocessing, printing, e-mail, Telnet, etc. on this machine and it was fantastic. Since about 2002 I tried on and off to keep it up and running as a webserver. You can learn more about its setup when you visit. In short, the Newton is connected to my home network via Ethernet by way of a PCMCIA card.
What is different this time around? First, I did not want to rely on pre-MacOS X operating system (namely System 9) to connect to the Newton for synchronization, software uploads and backups. But I ran into a catch-22: Newton connection tools (NCX) available for MacOS X require a piece of software to be installed on the Newton. My solution was to fire up Classic mode on my old and trusty PowerBook G4, download and install original Apple's Newton Connection Utility, and use that to install the required package on the Newton. That worked flawlessly. And now I can connect to my Newton right from my MacBook Pro!
I also needed to take care of what is known as the Y2010 bug - read more about it here.
Lastly, I wanted to make sure that Newton's clock is accurate. For that I ended up using NewtSync.
There is a community of Newton enthusiasts who continue to use this incredible machine to do wonderful things. For example, this tracker shows which Newtons are online at any given moment. I am grateful to folks who continue to work on maintaining existing capabilities and developing new ones. I hope that by keeping my Newton online I am participating in some small measure in ensuring that innovations represented by this platform are recognized and appreciated.
Subscribe to:
Posts (Atom)
