Scary Thought
|
| Author | Content |
|---|---|
| beirwin Mar 04, 2007 1:16 PM EDT |
Now there's a scary thought --- Microsoft handing medical records. |
| jimf Mar 04, 2007 1:56 PM EDT |
Well, I'm not suprised, but, to my mind , it's morally reprehensible that 'anything' in the public interest should be run with proprietary software. Education, medicine, government should all strive to use open source exclusively. |
| vainrveenr Mar 04, 2007 4:42 PM EDT |
Quoting:Now there's a scary thought --- Microsoft handing medical records...... or systems more directly involved with patient care. How TERRIFIED do you all think the less-technical therapists would actually become upon seeing the Blue Screen of Death, http://bsod.org/, during an actual patient treatment!! |
| swbrown Mar 04, 2007 4:46 PM EDT |
I work on stuff in this field (and yes, GPLed and paid for by the DHS :)) - the issue right now is a LOT of medical devices are being built around Windows CE - pulseoxes, 5 lead EKGs, etc.. The problem is that Windows CE is total ass for such applications (it's impossible to keep the things connected when roaming without user intervention, a powerfail renders it unusable without fixing by some IT person as it saves a lot of its data in ram, it's hard to disable everything but your application, etc..), but you can't easily point people to a handheld Linux that's sold as a product. This situation REALLY needs to be fixed soon, as it's forcing that segment to standardize on Windows CE. I'm hoping if the OpenMoko comes out and doesn't suck, and they add wifi or wifi can somehow be added (maybe a carried bluetoothwifi agent), it would function as such a replacement device. |
| swbrown Mar 04, 2007 4:57 PM EDT |
> How TERRIFIED do you all think the less-technical therapists would actually become upon seeing the Blue Screen of Death, [HYPERLINK@bsod.org] during an actual patient treatment!! When we used to use Windows CE for the devices, the most important part of training the first responders was how to push the reset pin (seriously), as the default way wifi roaming works is to try and stick to the last access point, even if the signal is so low it can't send and it's sitting right on top of an AP with super high signal. They'd obviously be roaming around treating people, and the devices would simply fall off the network. The solution is to first design applications that are tolerant of flakey connectivity - think like a version control metaphor where you can still work while disconnected then merge your changes when next online, except this also smooths the transition so it's not even something that interrupts the user (e.g., no popups saying "You've lost connection!" or other nonsense) - and then be automatically, aggressively manhandling the wifi stack to favor total connectivity over breaks in connectivity (as you've designed your apps to be tolerant of frequent breaks in connectivity, you can get away with this). I call it opportunistic networking. Works GREAT, but you need that lower level access to manhandle the wifi stack or you get nowhere. I get that via flashing iPAQs with Familiar Linux (GPE). |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!