I'll spot them some skepticism or overconfidence. It's been proven again and again that they're right to think OpenBSD is a hard target, so it's understandable that they wanted to see proof before bumping their counter up.
As for a "cover up"... well, if such a thing happend I'd say they must really suck at coverups, since we all know about it.:-)
Good for them. The attribution requirement is, I think, a good idea. They put the effort into capturing the event, so they should get the credit.
But more than that, they have the option of editorial control over the content they capture and process. If they pass it through unchanged, it's helpful for us to have attribution so that we can learn what honest brokers they are. And if they alter the content, it's also helpful for us to know the source of the alteration so that we can judge the merit of the edits. Attribution actually enhances public trust and access here.
(Of course, if c-span is the only authorized recorder of these events, then I think there may be more to discuss. But if others can record the events too, then I think this is a great balance.)
"Whether or not we find the asteroids, there's nothing we can do it about them if one is going to hit us."
We can land rovers on Mars. Japan came very close to putting a lander on an asteroid. We have space-launchable fission-powered electricity generators. We have ion thrusters that can turn electricity and relatively small masses of reaction gas into steady low thrust for years. Put that all together, and we have the technologies we need to build a vehicle which can rendezvous with an asteroid, land on it, and fire up a thruster to start pushing it very slowly.
If we can build and emplace one, we can build and emplace a dozen. Or a hundred. Or a thousand.
With enough such vehicles - and enough warning - we can probably deflect even large asteroids by enough to miss the Earth on any particular close approach.
So don't go thinking that there's nothing we can do. If we don't detect the threat until just a few years before the potential collision, then yes there may be nothing that can be done. But with at least twenty years' warning, asteroid deflection is very likely to be possible.
And since that's the case, it's going to mighty embarrassing if we find one too late just because we didn't look hard enough.
OOo is not as good as MS Office. Sure, I'll buy that.
But for 80% of what 80% of Windows users do with text documents and spreadsheets, it's good enough.
Letters, term papers, resumés... OOo is good enough for all of that. It doesn't need to be a feature-complete replacement; to be competitive, OOo only needs to be good enough to make up for the price difference. And at the light-duty end of the office suite market, it's there.
Well, thank you for the encouragement. I decided to go to one of my preferred vendors (Insight) and get a quote on Minis. The results are very interesting.
Dell OptiPlex 745 with Core 2 Duo 1.86GHz = $902 ea. Apple Mac Mini Core Duo 1.66Ghz w/XP-Pro OEM = $975 ea.
Now, these are not quite equivalent machines, but they're about as close as I can get. (1 gig of RAM each, smallest available HDD, 3-year warranty for each.) There's clearly more hardware bang for the buck in the Dell. But if you're actually interested in a low-end desktop - which I am - and you don't care about PCIe expandability - which I don't, really - then this is a very competitive price.
It's all the more competitive when you put Tiger in the picture. I'm not totally ready to deploy Tiger in my network... but having the option to go to OSX later is very attractive.
I may have to put my money where my mouth was after all.
I was asked to do this, too. The network had its own DNS server, so I redirected myspace.com to the company's own intranet website.
It was a dirty hack, and wouldn't be too hard for a technically-inclined user to work around, but they didn't need an airtight blockage. They just needed the misbehaving employees to know that management saw a problem, that the gentle measures taken before that had not produced the desired corrections, and that much blunter enforcement instruments were available.
Actually, no. You just need a cloner to record and replay the signal. It's cloners - such as what's described in TFA - that make attacks-of-opportunity a viable threat. And it's this threat that - while pretty unlikley - drove me to crypto-enabled cards.
See, I work in a medical clinic with several primary care docs. They're over at the hospital quite often, doing rounds and whatnot. The hospital uses HID prox badges (so far as I know) for entry. So our docs are carrying their cards for both the clinic and the hospital together. An ideal place to acquire keycodes would be in the hospital cafeteria, which most staff visit at one point or another. It would be almost trivially easy to masquerade as patient's family and emplace a logging keycard reader in the cafeteria, and collect all card codes that pass close enough for a few hours or days. Such a card cloning attack aimed at the hospital stands a good chance of acquiring our entry codes, too.
If you're a cracker who has just snarfed up a couple dozen (hundred?) entry codes among a city's medical staff, you might be tempted to go "rattle doorknobs" on pretty much every medical clinic entry cardreader in the area. I admit that this scenario is a little farfetched, but it's still a sufficient threat to dictate using crypto-cards, even if the price differential were fairly large. (Which it's not.)
Until I read last year that card cloners that can read and replay any number of codes were easy to make, I wouldn't have known to worry about it. It never occured to me that a security device would send codes in the clear, frankly. The interesting thing is that none of the security vendors I had bid on our project - including at least one who really should have known better - were worried about this vulnerability. They would have cheerfully recommended and sold plain prox cards.
The problem with prox for locks is that keys can be copied invisibly and perfectly in one pass. With physical keys the locksystem is compromise-evident (in the event of key loss) and physical keys are "hard" to copy from an image.
If you're the target of a determined and specific attack neither system will hold up, but with prox keys you're vulnerable to more casual attacks of opportunity. (Once the equipment to clone cards becomes widespread, anyway.)
The key management advantage for cards is huge, though, so card keys are worth considering. But cards and readers that are not vulnerable to this attack are only a little more expensive than vulnerable ones, so there's really no excuse any more for implementing vulnerable prox locks.
Absolutely yes. I'd buy Apple desktops - and cheerfully pay the premium to run Parallels/XP on some of 'em - if Apple made the right hardware product. I would buy seven next week. But right now, they don't make what I need.
The Mac Pro is grossly overpowered for what we need, which makes it much too expensive for us to consider. The Mac Mini's laptop-class hard drive is probably too unreliable (and not user-serviceable enough) for our 5-year desktop replacement cycle. And while the iMac is about right in many ways, I already have LCDs throughout so buying an all-in-one makes no sense for us.
What I'd need to buy Macs for the office is a headless machine that delivers a single Core 2 Duo, a gig of RAM, integrated graphics, and a basic desktop-class SATA drive in a user-serviceable chassis for around $1100.
But Apple does not seem to be interested in the low-end desktop market, so it's back to Dell for me.
Basic HID Prox cards just report a serial number. HID also makes a version that has some cryptographic component, called iClass. When I spec'd a security system last year, I insisted on crypto-enabled cards and readers. (We ended up with HID's iClass.)
If this is just a tool to clone HID Prox cards, then it's nothing new... but it'll make me look good to my boss. (Sweet!)
If it's a tool to spoof iClass readers then it's new, a pretty big deal, and I just wasted a few thousand bucks. (Boo!)
It's a medical clinic setting. We have an electronic medical records system, which has a very pointer-friendly interface. A medical assistant bringing a patient back to a room must stop at a station to gather heights annd weights, then proceed into the room and collect some preliminary info before sending the doc in. Ideally they're entering data as they go.
Making this work well calls for a device that is small and light enough for the MA to carry easily in one hand and use without a desk while herding young patients. A keyboard is very nearly a requirement (although really spectacular handwriting recognition could theoretically do the job) and a mouse isn't an option. Trackpads and pointer-sticks are not really quick and accurate enough. Touchscreens are an ideal solution.
At the moment, we use a variety of Fujitsu Lifebooks with touchscreens: the notebook P1120 and B3020D, and the convertible tablet P1510D, P1610, and T4210 models. (All but the last of which use compatible power adapters, thank God.) However, the lifebooks - and similar machines from other manufacturers - are really overpowered and overpriced for what we need. We don't really need to run a full version of Windows (with all the issues that entails) to access our EMR app; an RDP client is all we really need on most handhelds.
There's two killer solutions for us that simply don't exist so far as I can tell: a sub-$1000 touchscreen notebook thinstation, or a sub-$1600 touchscreen Mac [convertible]tablet, both in the 10-12"/800x600+ range.
What gets me is that the thin client I want used to exist, but is gone from the market. We used NEC 880s, which were great - but they were WinCE, only supported 802.11b/WEP, and NEC stopped making them. Same goes for the Vadem/Mainstreet/Whomever Clio. I can't use anything that's limited to WEP in a medical setting anymore, so they're out.
Since apparently I'm doomed to paying for full PC hardware anyway to get what I need, I'd be only too happy to buy touchscreen Macs and save myself some Windows-specific administration headaches. (Sure Macs have headaches, too... but for what I need, they'd be easier.)
I can guaran-friggin-tee that if someone makes something that works for us, they'll sell zillions of them to medical clinics everywhere.
If Apple makes a 10" ultraportable with a touchscreen, I'll buy one. If it's good, I'll buy 4 within a year. If it's really good, I'll buy 12 within two years. (For my company, of course.)
Seriously. I love the Fujitsu Lifebook p-series, but I'd be happier if I could use OSX on something similar.
(Unless Wyse or Neoware get their gorram act together and produce a linux-based touchscreen notebook thin client first, anyway. Get on it, people!)
Any model from this series of calculator is an excellent tool. (Except the HP48II, which is apparently a dog.)
The bad news is that HP's calculator division ain't what it used to be. The good news is that almost all HP calculators are extremely durable. I have personally worn out multiple HP calculator keypads, but it took about two years of heavy use to wear out each one. And by heavy use I don't mean mere homework... I mean 8 to 10 hour days at my job, where 60% of my job was to crunch numbers. (Yes this job was better suited to other hardware, but I worked with what I could get.) If you can find a used one that works at all, it should prove very durable.
If you can find one, a 48G or 48GX would be excellent.
(I am less impressed with the newer HP49 and its derivatives. It seemed to be a step backwards in usability to me, mainly because of the keypad layout. The all-important "enter" key is in a bad spot, and not double-sized.)
As I read TFQ, he's interested in exploring solar as a potentially practical solution to his problem, not as part of some Greenpeace covert op.
I think you don't need to tell him how good generators are, since he says he's got one. He goes on to say that fuel scarcity is an issue. It sounds like he operates the sort of service that goes in and stays for a while, so generator fuel supply is not necessarily trivial.
Also, I think he knows the disadvantages of solar cells right enough, but recall that he's setting up satellite links for networks. It's a good bet that he's already hauling around bulky equipment, such as satellite dishes, that needs to be set up and weatherized in the open. Solar cells may not be much more of a burden.
Before you tell a guy he's nuts, it'd probably pay to consider the possibility that knows a lot more about his logistical requirements and options than you do.
"Finally, when I heard all the stuff that goes on that device, I would think you'd want a 30gb version. 4 and 8 gb of Flash almost seems like an insult for something that powerful. I suppose a hard drive would have made it too big and heavy, but still, people carry around hard drive based iPods just fine, and a hard drive iPod's not much different in size from the sidekick."
The 30Gb hard drive will be in the 12", GSM-enabled, Core 2 Duo MacTablet with a multitouch display. Available next September for $1799, plus $149 for the factory-installed AirPort GSM module. Cingulair service not included.
"[...] OpenBSD whores will derail this entire discussion."
Damn. Gotta be a pretty cheap date to whore out for a BSD-licensed OS!
Seriously, man, you've got your terminology all wrong. Whores do it for money. While OpenBSD users don't object to getting paid for it, mostly we do it for free 'cuz we like it. That makes us sluts.
If you'd ever gotten laid without paying for it, you'd know about this stuff.
"Yes, but what happens when you have a situation of Denial of Service by Backhoe?"
Then you're screwed.:-)
But seriously.
Then you fall back on the Emergency Operations Plan that HIPAA Security mandates you have. Backhoe, tornado, widespread power failure, fire in the server room, whatever... it's all going to result in a denial of service. Eventually, everyone with a medical records system is going to have an outage, and they need to be prepared for it. (Note that the inevitability of outage includes paper storage systems. What happens if there's a fire in document storage? Maybe the sprinklers contain the fire, but the records will still be inaccessible for a time even if they survive undamaged.)
In your case, the criticality of the data made local copies a good plan. Better, the plan actually worked when needed. Good on you, mate!
"I only made mention of an all-in-one system for an organization that size."
Aha. I wondered if that might be the case. You implied as much, but I thought it best to address the non-careful readers.
Yeah, a single EMR for all of Keizer is... hard to imagine. I can see why they'd want to do it, but wow. I wouldn't want any part of chewing up that bite. The stated cost of over $70,000 per physician per year is just staggering.
It puts into perspective the unified US EMR, which has been proposed now and then. That idea strikes me as entirely daft at this point. I think in time such things may be feasible, but to do it right would take something on the order of Google's network.
EMR is a huge problem. But when thinking about the problems with an EMR, one should remember to compare it to the alternative: Paper Charts.
Let's take the Keizer case. Let's say they have a hundred facilities, and a hundred docs in each. Each patient has one canonical paper chart, stored at their nearest Keizer facility. How available is that paper chart?
During an emergency admit, that chart is completely unavailable to 99% of the Keizer facilities, except by fax. It probably would take upwards of 15 minutes to get the chart to the admitting doc even when (as would be most common) the admit happens at the same facility where the chart is stored, and probably a good deal longer to fax it to another facility.
For a scheduled visit, a paper system will perform better than that. There's (usually) time to get the chart pulled in advance. However, in both emergency and scheduled encounters only one provider can examine the chart at a time, and changes to the chart at another facility must be merged back into the canonical chart wherever it may be.
An EMR with only 98% availability is still more effective than this paper system. (Never mind efficiency.)
And it's not like a clinic with a down EMR comes to a standstill; HIPAA requires everyone to have an emergency operations plan, so unless they're completely daft they should still be able to see patients and record the details of the encounter. (And, in fact, the HIPAA regs are an excellent framework for success. Read 'em sometime, especially the Security section.)
Of course, the argument can be made also that an EMR is more expensive. And it's true that they are pricey beasts. But have you priced paper chart storage lately? A really good paper chart system can store maybe a hundred midsized charts per square foot of building. Multiply that by the cost of office space and a clinic's patient base and the cost is considerable.
Also, with paper charts offsite backups and disaster recovery are rather difficult.
So yes, EMR is a pain. But, most of the time, it's better than the alternative.
Citrix offers one huge advantage in the world of healthcare IT: When the thin client is not connected, no patient data exists on a thin client machine.
The HIPAA Security regulations are good regs, as such things go. But one of their demands is that you know exactly which machines have Electronic Personally-identifiable Health Information (ePHI) on them. Any such data must be protected, backed up, and audited. Further, each machine containing ePHI is subject to the organization's media disposal policy.
Now, ideally an EMR system should not leave tracks on the client machine even with its fat client. But if the EMR's fat client does leave data on the client machine, then meeting HIPAA Security requirements would be one heck of a lot easier to accomplish if all you have is thin clients. I have no idea if the EPIC client does leave data on the client computers, but if it did there would be reason to be very interested in using Citrix to keep all ePHI off of all periphrial machines.
Slashdot Mirror
"Of course, you can't ever say a leaf made the tree..."
It did, however, require a lone nut.
I'll spot them some skepticism or overconfidence. It's been proven again and again that they're right to think OpenBSD is a hard target, so it's understandable that they wanted to see proof before bumping their counter up.
:-)
As for a "cover up"... well, if such a thing happend I'd say they must really suck at coverups, since we all know about it.
Good for them. The attribution requirement is, I think, a good idea. They put the effort into capturing the event, so they should get the credit.
But more than that, they have the option of editorial control over the content they capture and process. If they pass it through unchanged, it's helpful for us to have attribution so that we can learn what honest brokers they are. And if they alter the content, it's also helpful for us to know the source of the alteration so that we can judge the merit of the edits. Attribution actually enhances public trust and access here.
(Of course, if c-span is the only authorized recorder of these events, then I think there may be more to discuss. But if others can record the events too, then I think this is a great balance.)
"Whether or not we find the asteroids, there's nothing we can do it about them if one is going to hit us."
We can land rovers on Mars. Japan came very close to putting a lander on an asteroid. We have space-launchable fission-powered electricity generators. We have ion thrusters that can turn electricity and relatively small masses of reaction gas into steady low thrust for years. Put that all together, and we have the technologies we need to build a vehicle which can rendezvous with an asteroid, land on it, and fire up a thruster to start pushing it very slowly.
If we can build and emplace one, we can build and emplace a dozen. Or a hundred. Or a thousand.
With enough such vehicles - and enough warning - we can probably deflect even large asteroids by enough to miss the Earth on any particular close approach.
So don't go thinking that there's nothing we can do. If we don't detect the threat until just a few years before the potential collision, then yes there may be nothing that can be done. But with at least twenty years' warning, asteroid deflection is very likely to be possible.
And since that's the case, it's going to mighty embarrassing if we find one too late just because we didn't look hard enough.
Doesn't Halliburton do asteroid diversion?
OOo is not as good as MS Office. Sure, I'll buy that.
But for 80% of what 80% of Windows users do with text documents and spreadsheets, it's good enough.
Letters, term papers, resumés... OOo is good enough for all of that. It doesn't need to be a feature-complete replacement; to be competitive, OOo only needs to be good enough to make up for the price difference. And at the light-duty end of the office suite market, it's there.
Well, thank you for the encouragement. I decided to go to one of my preferred vendors (Insight) and get a quote on Minis. The results are very interesting.
Dell OptiPlex 745 with Core 2 Duo 1.86GHz = $902 ea.
Apple Mac Mini Core Duo 1.66Ghz w/XP-Pro OEM = $975 ea.
Now, these are not quite equivalent machines, but they're about as close as I can get. (1 gig of RAM each, smallest available HDD, 3-year warranty for each.) There's clearly more hardware bang for the buck in the Dell. But if you're actually interested in a low-end desktop - which I am - and you don't care about PCIe expandability - which I don't, really - then this is a very competitive price.
It's all the more competitive when you put Tiger in the picture. I'm not totally ready to deploy Tiger in my network... but having the option to go to OSX later is very attractive.
I may have to put my money where my mouth was after all.
I was asked to do this, too. The network had its own DNS server, so I redirected myspace.com to the company's own intranet website.
It was a dirty hack, and wouldn't be too hard for a technically-inclined user to work around, but they didn't need an airtight blockage. They just needed the misbehaving employees to know that management saw a problem, that the gentle measures taken before that had not produced the desired corrections, and that much blunter enforcement instruments were available.
It got the message across loud and clear.
Actually, no. You just need a cloner to record and replay the signal. It's cloners - such as what's described in TFA - that make attacks-of-opportunity a viable threat. And it's this threat that - while pretty unlikley - drove me to crypto-enabled cards.
See, I work in a medical clinic with several primary care docs. They're over at the hospital quite often, doing rounds and whatnot. The hospital uses HID prox badges (so far as I know) for entry. So our docs are carrying their cards for both the clinic and the hospital together. An ideal place to acquire keycodes would be in the hospital cafeteria, which most staff visit at one point or another. It would be almost trivially easy to masquerade as patient's family and emplace a logging keycard reader in the cafeteria, and collect all card codes that pass close enough for a few hours or days. Such a card cloning attack aimed at the hospital stands a good chance of acquiring our entry codes, too.
If you're a cracker who has just snarfed up a couple dozen (hundred?) entry codes among a city's medical staff, you might be tempted to go "rattle doorknobs" on pretty much every medical clinic entry cardreader in the area. I admit that this scenario is a little farfetched, but it's still a sufficient threat to dictate using crypto-cards, even if the price differential were fairly large. (Which it's not.)
Until I read last year that card cloners that can read and replay any number of codes were easy to make, I wouldn't have known to worry about it. It never occured to me that a security device would send codes in the clear, frankly. The interesting thing is that none of the security vendors I had bid on our project - including at least one who really should have known better - were worried about this vulnerability. They would have cheerfully recommended and sold plain prox cards.
The problem with prox for locks is that keys can be copied invisibly and perfectly in one pass. With physical keys the locksystem is compromise-evident (in the event of key loss) and physical keys are "hard" to copy from an image.
If you're the target of a determined and specific attack neither system will hold up, but with prox keys you're vulnerable to more casual attacks of opportunity. (Once the equipment to clone cards becomes widespread, anyway.)
The key management advantage for cards is huge, though, so card keys are worth considering. But cards and readers that are not vulnerable to this attack are only a little more expensive than vulnerable ones, so there's really no excuse any more for implementing vulnerable prox locks.
Absolutely yes. I'd buy Apple desktops - and cheerfully pay the premium to run Parallels/XP on some of 'em - if Apple made the right hardware product. I would buy seven next week. But right now, they don't make what I need.
The Mac Pro is grossly overpowered for what we need, which makes it much too expensive for us to consider. The Mac Mini's laptop-class hard drive is probably too unreliable (and not user-serviceable enough) for our 5-year desktop replacement cycle. And while the iMac is about right in many ways, I already have LCDs throughout so buying an all-in-one makes no sense for us.
What I'd need to buy Macs for the office is a headless machine that delivers a single Core 2 Duo, a gig of RAM, integrated graphics, and a basic desktop-class SATA drive in a user-serviceable chassis for around $1100.
But Apple does not seem to be interested in the low-end desktop market, so it's back to Dell for me.
Basic HID Prox cards just report a serial number. HID also makes a version that has some cryptographic component, called iClass. When I spec'd a security system last year, I insisted on crypto-enabled cards and readers. (We ended up with HID's iClass.)
If this is just a tool to clone HID Prox cards, then it's nothing new... but it'll make me look good to my boss. (Sweet!)
If it's a tool to spoof iClass readers then it's new, a pretty big deal, and I just wasted a few thousand bucks. (Boo!)
It turns out that someone else beat them to a solution that's probably close enough, if maybe overpriced: Motion Computing's C5 was released Tuesday.
It's a medical clinic setting. We have an electronic medical records system, which has a very pointer-friendly interface. A medical assistant bringing a patient back to a room must stop at a station to gather heights annd weights, then proceed into the room and collect some preliminary info before sending the doc in. Ideally they're entering data as they go.
Making this work well calls for a device that is small and light enough for the MA to carry easily in one hand and use without a desk while herding young patients. A keyboard is very nearly a requirement (although really spectacular handwriting recognition could theoretically do the job) and a mouse isn't an option. Trackpads and pointer-sticks are not really quick and accurate enough. Touchscreens are an ideal solution.
At the moment, we use a variety of Fujitsu Lifebooks with touchscreens: the notebook P1120 and B3020D, and the convertible tablet P1510D, P1610, and T4210 models. (All but the last of which use compatible power adapters, thank God.) However, the lifebooks - and similar machines from other manufacturers - are really overpowered and overpriced for what we need. We don't really need to run a full version of Windows (with all the issues that entails) to access our EMR app; an RDP client is all we really need on most handhelds.
There's two killer solutions for us that simply don't exist so far as I can tell: a sub-$1000 touchscreen notebook thinstation, or a sub-$1600 touchscreen Mac [convertible]tablet, both in the 10-12"/800x600+ range.
What gets me is that the thin client I want used to exist, but is gone from the market. We used NEC 880s, which were great - but they were WinCE, only supported 802.11b/WEP, and NEC stopped making them. Same goes for the Vadem/Mainstreet/Whomever Clio. I can't use anything that's limited to WEP in a medical setting anymore, so they're out.
Since apparently I'm doomed to paying for full PC hardware anyway to get what I need, I'd be only too happy to buy touchscreen Macs and save myself some Windows-specific administration headaches. (Sure Macs have headaches, too... but for what I need, they'd be easier.)
I can guaran-friggin-tee that if someone makes something that works for us, they'll sell zillions of them to medical clinics everywhere.
If Apple makes a 10" ultraportable with a touchscreen, I'll buy one. If it's good, I'll buy 4 within a year. If it's really good, I'll buy 12 within two years. (For my company, of course.)
Seriously. I love the Fujitsu Lifebook p-series, but I'd be happier if I could use OSX on something similar.
(Unless Wyse or Neoware get their gorram act together and produce a linux-based touchscreen notebook thin client first, anyway. Get on it, people!)
Any model from this series of calculator is an excellent tool. (Except the HP48II, which is apparently a dog.)
The bad news is that HP's calculator division ain't what it used to be. The good news is that almost all HP calculators are extremely durable. I have personally worn out multiple HP calculator keypads, but it took about two years of heavy use to wear out each one. And by heavy use I don't mean mere homework... I mean 8 to 10 hour days at my job, where 60% of my job was to crunch numbers. (Yes this job was better suited to other hardware, but I worked with what I could get.) If you can find a used one that works at all, it should prove very durable.
If you can find one, a 48G or 48GX would be excellent.
(I am less impressed with the newer HP49 and its derivatives. It seemed to be a step backwards in usability to me, mainly because of the keypad layout. The all-important "enter" key is in a bad spot, and not double-sized.)
As I read TFQ, he's interested in exploring solar as a potentially practical solution to his problem, not as part of some Greenpeace covert op.
I think you don't need to tell him how good generators are, since he says he's got one. He goes on to say that fuel scarcity is an issue. It sounds like he operates the sort of service that goes in and stays for a while, so generator fuel supply is not necessarily trivial.
Also, I think he knows the disadvantages of solar cells right enough, but recall that he's setting up satellite links for networks. It's a good bet that he's already hauling around bulky equipment, such as satellite dishes, that needs to be set up and weatherized in the open. Solar cells may not be much more of a burden.
Before you tell a guy he's nuts, it'd probably pay to consider the possibility that knows a lot more about his logistical requirements and options than you do.
"Finally, when I heard all the stuff that goes on that device, I would think you'd want a 30gb version. 4 and 8 gb of Flash almost seems like an insult for something that powerful. I suppose a hard drive would have made it too big and heavy, but still, people carry around hard drive based iPods just fine, and a hard drive iPod's not much different in size from the sidekick."
The 30Gb hard drive will be in the 12", GSM-enabled, Core 2 Duo MacTablet with a multitouch display. Available next September for $1799, plus $149 for the factory-installed AirPort GSM module. Cingulair service not included.
Maybe.
"[...] OpenBSD whores will derail this entire discussion."
Damn. Gotta be a pretty cheap date to whore out for a BSD-licensed OS!
Seriously, man, you've got your terminology all wrong. Whores do it for money. While OpenBSD users don't object to getting paid for it, mostly we do it for free 'cuz we like it. That makes us sluts.
If you'd ever gotten laid without paying for it, you'd know about this stuff.
Great sig.
Well, yeah. I meant to refer to the advantages of thin clients in general, not Citrix in particular. Sorry if I was unclear.
"Yes, but what happens when you have a situation of Denial of Service by Backhoe?"
:-)
Then you're screwed.
But seriously.
Then you fall back on the Emergency Operations Plan that HIPAA Security mandates you have. Backhoe, tornado, widespread power failure, fire in the server room, whatever... it's all going to result in a denial of service. Eventually, everyone with a medical records system is going to have an outage, and they need to be prepared for it. (Note that the inevitability of outage includes paper storage systems. What happens if there's a fire in document storage? Maybe the sprinklers contain the fire, but the records will still be inaccessible for a time even if they survive undamaged.)
In your case, the criticality of the data made local copies a good plan. Better, the plan actually worked when needed. Good on you, mate!
"I only made mention of an all-in-one system for an organization that size."
Aha. I wondered if that might be the case. You implied as much, but I thought it best to address the non-careful readers.
Yeah, a single EMR for all of Keizer is... hard to imagine. I can see why they'd want to do it, but wow. I wouldn't want any part of chewing up that bite. The stated cost of over $70,000 per physician per year is just staggering.
It puts into perspective the unified US EMR, which has been proposed now and then. That idea strikes me as entirely daft at this point. I think in time such things may be feasible, but to do it right would take something on the order of Google's network.
EMR is a huge problem. But when thinking about the problems with an EMR, one should remember to compare it to the alternative: Paper Charts.
Let's take the Keizer case. Let's say they have a hundred facilities, and a hundred docs in each. Each patient has one canonical paper chart, stored at their nearest Keizer facility. How available is that paper chart?
During an emergency admit, that chart is completely unavailable to 99% of the Keizer facilities, except by fax. It probably would take upwards of 15 minutes to get the chart to the admitting doc even when (as would be most common) the admit happens at the same facility where the chart is stored, and probably a good deal longer to fax it to another facility.
For a scheduled visit, a paper system will perform better than that. There's (usually) time to get the chart pulled in advance. However, in both emergency and scheduled encounters only one provider can examine the chart at a time, and changes to the chart at another facility must be merged back into the canonical chart wherever it may be.
An EMR with only 98% availability is still more effective than this paper system. (Never mind efficiency.)
And it's not like a clinic with a down EMR comes to a standstill; HIPAA requires everyone to have an emergency operations plan, so unless they're completely daft they should still be able to see patients and record the details of the encounter. (And, in fact, the HIPAA regs are an excellent framework for success. Read 'em sometime, especially the Security section.)
Of course, the argument can be made also that an EMR is more expensive. And it's true that they are pricey beasts. But have you priced paper chart storage lately? A really good paper chart system can store maybe a hundred midsized charts per square foot of building. Multiply that by the cost of office space and a clinic's patient base and the cost is considerable.
Also, with paper charts offsite backups and disaster recovery are rather difficult.
So yes, EMR is a pain. But, most of the time, it's better than the alternative.
Citrix offers one huge advantage in the world of healthcare IT: When the thin client is not connected, no patient data exists on a thin client machine.
The HIPAA Security regulations are good regs, as such things go. But one of their demands is that you know exactly which machines have Electronic Personally-identifiable Health Information (ePHI) on them. Any such data must be protected, backed up, and audited. Further, each machine containing ePHI is subject to the organization's media disposal policy.
Now, ideally an EMR system should not leave tracks on the client machine even with its fat client. But if the EMR's fat client does leave data on the client machine, then meeting HIPAA Security requirements would be one heck of a lot easier to accomplish if all you have is thin clients. I have no idea if the EPIC client does leave data on the client computers, but if it did there would be reason to be very interested in using Citrix to keep all ePHI off of all periphrial machines.