When nuclear missiles and capabilities were first developed, the military and others argued that with only 15 minutes to react to a missile attack, it is not possible to locate the executive branch member still alive with the authority to give the retaliation commands. Remember, this is early 50's - no cell phones and even POTS networks weren't always reliable over great distances. They pretty much got their way; the SIOP for a nuclear strike allowed field commanders to take control if necessary and issue the orders to retaliate a nuclear strike.
So this is just the same thing all over again, except that we don't get radioactive fallout everywhere and make the planet uninhabitable for thousands of years. Instead, all the SCALA systems are infected, shutdown, and cause nuclear power plants to go critical, dams to release water, and all kinds of other fun stuff...
I'm not sure getting a warrant allows any entity to break the law as a means to an end, no matter how just that end seems to be.
Entering the computer with a search warrant, fine. Creating and distributing malware? I believe that's against the law. Now, malware is a loaded term subject to broad interpretation, I'll grant you that, so really the line is pretty grey. While I'd be tempted to draw an extreme comparison to, say, killing someone because you have a warrant to do so in order to capture some other criminal - I can't say they are the same kind of black and white.
A book by James P. Hogan. In the novel they built a large collider and produced microscopic black holes accidentally. Their future selves found a way to send a message back in time despite the noise degradation to tell their past selves not to turn the damned thing on.
Healthcare is really in the dark ages with respect to this. True, there are many doctors offices that use computers, but nowhere near the majority do. As a previous poster stated, those offices have to shell out money for moving to EMR systems, and it's not cheap. That means that most of those health records really are in paper form. Not in a bunch of databases manned by DBA's as someone else posted. That would be nice, but it's nowhere near the truth.
Be real here - in a typical small physician's practice, they are probably using paper records. Why? Because it doesn't take a freaking IT staff to make it work and keep it working day in and day out. It costs a lot of money from that practice's perspective to initiate an EMR system and to keep it running for very little overall ROI. Once it's up and running, it may or may not be easier to deal with but the practice will probably have to change the way they do things to conform to the system's way of doing things, and that's not easy, especially for physicians. In my experience they do things a particular way for what, in their minds, is a perfectly good reason.
Let's scale this up to a hospital. Another poster stated if this was such a good thing and save so much money, why haven't hospitals already done this. It's because it's not just plopping a computer down and telling someone, "here ya go". It's a complete business process re-engineering effort on a huge scale for each and every hospital. That's not easy when you are trying to treat people at the same time and not loose critical med orders or lab reports. It normally takes a hospital a year or more to make that transition, and that's *after* they've planned it all. It's not just doctors in a hospital - it's pharmacy, labs, emergency, trauma, oncology, nursing, medication administration, medical order tracking, the list goes on.
Microsoft has HealthVault and Google has Google Health, but neither are under HIPAA guidelines as other posters have erroneously stated. While they have pushed themselves as interoperable Patient Health Record repositories, they haven't even scratched the surface, yet. And would you place your data in MS or Google, knowing that they are unregulated? Obviously the first thing they want is to be able to search that data - it's worth a fortune to the pharma companies and other researchers.
I just hired two college graduates from a really large pool of candidates that our HR team recruited and winnowed. My team's process is simple.
1. Grammar and spelling. If there's a single error on your resume or anything you send us, something that you've had time to prepare and check, then what does that say about your habits in general? Seeing a simple spelling or grammar mistake just casts a shadow over things and will throw the decision towards the negative if we're on the fence.
2. Learn how to program. We don't give a damn what language you like best, but whatever it is, show us that you can solve simple problems with it. Coding style is very important, so we send candidates two simple programming problems. And I really mean simple. No big deal, right? But you wouldn't believe how few people can pass this simple test. A good number of submissions don't even compile! What are we looking for? Good programming practices, that's all. It just gives us an idea of where you are and how you think. If you're going to be writing code for us, then we need to see some examples.
3. Unit testing. Those programming problems should have a complete set of unit tests. You get extra points if you code the tests so they can be run by a framework like NUnit or Junit or whatever. But we need to see that you've thought about what will make the code fail.
Those are the things that will get you to the interview. Once in the interview we're going to ask you questions to test the limits of your knowledge, and how you think, especially under pressure. What we're looking for is someone who understands that software is a craft and we are all at various levels of apprentice, journeyman, or artisan. To continually work at one's craft is something that transcends programming languages, and we look for people who recognize that.
... they must have been dazzled by IBM's total bs when it comes to sales. I've worked on many recent projects where IBM has been pushing WebSphere really really hard. Some of it is interesting stuff, other parts of it is real crap. But then I suppose I could say that about any technology.
And then there's IBM Global Services...
It's a great win for J2EE, but it's too bad for eBay.
Slashdot Mirror
When nuclear missiles and capabilities were first developed, the military and others argued that with only 15 minutes to react to a missile attack, it is not possible to locate the executive branch member still alive with the authority to give the retaliation commands. Remember, this is early 50's - no cell phones and even POTS networks weren't always reliable over great distances. They pretty much got their way; the SIOP for a nuclear strike allowed field commanders to take control if necessary and issue the orders to retaliate a nuclear strike. So this is just the same thing all over again, except that we don't get radioactive fallout everywhere and make the planet uninhabitable for thousands of years. Instead, all the SCALA systems are infected, shutdown, and cause nuclear power plants to go critical, dams to release water, and all kinds of other fun stuff...
I'm not sure getting a warrant allows any entity to break the law as a means to an end, no matter how just that end seems to be. Entering the computer with a search warrant, fine. Creating and distributing malware? I believe that's against the law. Now, malware is a loaded term subject to broad interpretation, I'll grant you that, so really the line is pretty grey. While I'd be tempted to draw an extreme comparison to, say, killing someone because you have a warrant to do so in order to capture some other criminal - I can't say they are the same kind of black and white.
A book by James P. Hogan. In the novel they built a large collider and produced microscopic black holes accidentally. Their future selves found a way to send a message back in time despite the noise degradation to tell their past selves not to turn the damned thing on.
Healthcare is really in the dark ages with respect to this. True, there are many doctors offices that use computers, but nowhere near the majority do. As a previous poster stated, those offices have to shell out money for moving to EMR systems, and it's not cheap. That means that most of those health records really are in paper form. Not in a bunch of databases manned by DBA's as someone else posted. That would be nice, but it's nowhere near the truth. Be real here - in a typical small physician's practice, they are probably using paper records. Why? Because it doesn't take a freaking IT staff to make it work and keep it working day in and day out. It costs a lot of money from that practice's perspective to initiate an EMR system and to keep it running for very little overall ROI. Once it's up and running, it may or may not be easier to deal with but the practice will probably have to change the way they do things to conform to the system's way of doing things, and that's not easy, especially for physicians. In my experience they do things a particular way for what, in their minds, is a perfectly good reason. Let's scale this up to a hospital. Another poster stated if this was such a good thing and save so much money, why haven't hospitals already done this. It's because it's not just plopping a computer down and telling someone, "here ya go". It's a complete business process re-engineering effort on a huge scale for each and every hospital. That's not easy when you are trying to treat people at the same time and not loose critical med orders or lab reports. It normally takes a hospital a year or more to make that transition, and that's *after* they've planned it all. It's not just doctors in a hospital - it's pharmacy, labs, emergency, trauma, oncology, nursing, medication administration, medical order tracking, the list goes on. Microsoft has HealthVault and Google has Google Health, but neither are under HIPAA guidelines as other posters have erroneously stated. While they have pushed themselves as interoperable Patient Health Record repositories, they haven't even scratched the surface, yet. And would you place your data in MS or Google, knowing that they are unregulated? Obviously the first thing they want is to be able to search that data - it's worth a fortune to the pharma companies and other researchers.
I just hired two college graduates from a really large pool of candidates that our HR team recruited and winnowed. My team's process is simple. 1. Grammar and spelling. If there's a single error on your resume or anything you send us, something that you've had time to prepare and check, then what does that say about your habits in general? Seeing a simple spelling or grammar mistake just casts a shadow over things and will throw the decision towards the negative if we're on the fence. 2. Learn how to program. We don't give a damn what language you like best, but whatever it is, show us that you can solve simple problems with it. Coding style is very important, so we send candidates two simple programming problems. And I really mean simple. No big deal, right? But you wouldn't believe how few people can pass this simple test. A good number of submissions don't even compile! What are we looking for? Good programming practices, that's all. It just gives us an idea of where you are and how you think. If you're going to be writing code for us, then we need to see some examples. 3. Unit testing. Those programming problems should have a complete set of unit tests. You get extra points if you code the tests so they can be run by a framework like NUnit or Junit or whatever. But we need to see that you've thought about what will make the code fail. Those are the things that will get you to the interview. Once in the interview we're going to ask you questions to test the limits of your knowledge, and how you think, especially under pressure. What we're looking for is someone who understands that software is a craft and we are all at various levels of apprentice, journeyman, or artisan. To continually work at one's craft is something that transcends programming languages, and we look for people who recognize that.
... they must have been dazzled by IBM's total bs when it comes to sales. I've worked on many recent projects where IBM has been pushing WebSphere really really hard. Some of it is interesting stuff, other parts of it is real crap. But then I suppose I could say that about any technology. And then there's IBM Global Services... It's a great win for J2EE, but it's too bad for eBay.