Interestingly, your billion dollar mark isn't too far off the mark in regards to what it takes to create a state-of-the-art EMR in todays market place. Check out Cerner Millennium. They've invested over a billion dollars in it's development, and are working through their second billion of R&D. 10 million dollars will get you an EMR for *a single department*.
Well, the DICOM format specifies JPEG 2000 lossless as the preferred image format, which is what we were using. Common format was 1536 x 2048 for a 3 megapixel image. I think it was 72dpi.
Now then, I should mention that is *per image*. So, if you have a knee study that has four images, that's 42MB. If you get a CD that has your X-Rays from this year as well as your prior exams, then you could be talking about a lot more than 10MBs.
And for what it's worth, the only doctors who I ever saw magnify their analog radiographs were the Mammographers, and they used a 3x or 5x magnifying glass. They weren't going trying to go microscopic with the x-ray image. If you need to get cellular levels of detail from something in the middle of the body, the way to do that is with a biopsy, not with an x-ray and magnifying glass.
You remember studying significant figures in introductory chemistry? Unlike number theory or pure mathematics, when it comes to scientific measurements, if I multiply the number 3.14159, which has 6 significant figures, by the number 2.0, which only has two significant figures, the result is only 3.2. Anything else is prone to measurement errors. Such is the case with radiographs and the human eye.
Yes, the analog film will record at very high fidelity, but there is camera jitter, patient movement, camera distance and angle, mass density, and x-ray intensity to account for. And those factors will reduce the significant figures in the measurement, which is what an X-ray is. If a clinician needs to look at a microscopic area, they'll get an imaging modality that's calibrated to adjust that microscopic size and display it in a format that's visible to the human eye. Hence, biopsy and microscope. Not x-ray and magnifying glass.
Well, Cerner Millennium certainly wouldn't win the award either if it were measured by glitzy GIFs and user interface.
I think I'm biased against MUMPS because of it's tendency to create obfuscated code, and that it only has a single data type. Yes, I know some people say that it's concise and that the single data type is a feature, not a flaw. But obfuscated code quickly leads to a support nightmare.
And for what it's worth, I think that MUMPS may be in the process of disappearing. I know that I've been involved in at least one project to phase out a MUMPs system with an Oracle database. And having a single data type defeats the purpose of having data types to begin with.
My standard for 'state-of-the-art' is an integrated system that can be installed in every department of a major hospital, and which supports diagnostic software agents. Not glitz.
You do know that some of the biggest problems with paper records is, don't you? Mice, mildew, and silverfish. Yum. Many hospitals want to get the hell rid of the originals because they're a health hazard. Seriously. To expect hospitals to digitize the records and then keep the originals is foolish. At best, they'll send them to an "off site archive", meaning a warehouse. And even that costs money, sometimes upwards of tens or hundreds of thousands a year. Unfortunately, I can pretty much guarantee you that as soon as those records get digitized, the originals are getting shredded as quickly as the file room staff can manage it.
End result was that we we reduce staff by about 7 people, or 40%, and payroll costs were reduced by $150,000 or 20%.
There wont be any part-time jobs, by the way. It will simply be the existing low-level staff being kept on an extra couple years to do the data entry, with management knowing that they're destined to be fired eventually. They will be fired through attrition or through a layoff eventually.
Now, I work at the VA which has the most advanced, state of the art electronic medical record system on the planet, and I defy anyone to point to a large scale health care system that has one that's really better in the aggregate. So, here at the VA we don't have the same barriers to adoption that private sector hospitals consider as the great majority of our patients are with us for life, so there is value in tracking them for the long term. I certainly don't agree with the private sector barriers philosophically, but practically speaking I understand the thought processes.
srsly?
You're claiming VISTA as being the most state-of-the-art EMR on the planet? Based on MUMPS?
I'll grant that it's probably the most mature and stable EMR on the planet. But for most state-of-the-art, I'd probably have to go with an integrated Cerner Millennium installation.
The fact that digital records could be transmitted very quickly, at any hour, for accident victims and save numerous lives has not stirred doctors into action.
You're just being silly. Not all doctors are money sharks. Some are, but the majority aren't.
And one things for sure: you've never sat in a Medical Informatics Committee meeting a community hospital.
You're only accounting for a portion of the entire scenario. Did you know that insurance companies and the US government value a human life around $9,800,000 dollars? Average term life-insurance is about $129,000 per year, and the average person lives something like 76 years in the US.
Humans are a finite resource, and it's in societies interest to keep it's population healthy. Economically speaking, it's true that money being spent on scanning old medical records isn't adding to the material economic base, in so far as import/export is concerned. But import/export isn't the only measure of an economy.
Rather, scanning in those old records results in better upkeep of the work force. It's more akin to equipment repairs of manufacturing equipment, I suppose. But the point is that it's an operational expense. More specifically, it's an infrastructure development expense that will decrease the annual operational expenses of maintaining manufacturing equipment (if you'll go so far as to consider a person a type of manufacturing equipment).
Anyhow, the point is that it's a maintenance fee, and keeps America economically viable by making sure that it's workforce is in good health and repair, so to speak.
Nice idea, but FDA approval requirements and legal code won't allow it. Do you really want people to be able to go changing code in your medical equipment willy-nilly? No, hospitals are very serious about their change control processes, as is the FDA. For a piece of medical software to get used in a healthcare setting, it has to be forked, stabalized, and passed through an FDA process.
Now, don't get me wrong. In theory, open source would be great in the medical and healthcare industry. But the GPL which requires the source code to be free isn't going to gain any traction in the industry, because it's at odds with the legal requirements that medical code be audited, stable, and not subject to casual change. In short, the GPL is at odds with the FDA certification process.
- Originals of a lot of records (x-rays for one example) do not transfer well to digital. Heck, transferring any analog recording, visual or auditory, to digital inevitably means a loss of fidelity at some point or another. You either save a far-too-small file that someone looks at and misses detail (or dismisses an important detail as compression artifacting) later, or your file is completely freaking huge.
Having worked in Radiology IT, I'd point out that the human eye is actually a limiting factor in our ability to see things. So, yes, you are correct in that an analog X-Ray had more diagnostic information encoded into it than a digital one. However, the human eye can only see so much data. The human eye isn't a microscope. So you don't need to scan an image to microscopic precision. You only need to scan it to a level of precision that the human eye can't detect a difference. And it turns out that to do a scan of an X-Ray at that level of details results in a file that's approximately 10.5MB in size. It's a very well known metric, actually.
And if you have a 600 bed hospital which sees 150,000 patients per year in the Department of Radiology, and 50% of those are X-Rays images, with 2 images (PA, Lateral) per exam, that results in, oh... about 75,000 x 0.5 x 2 x 10.5MB = 787 GB of data per year. Add some extra space for buffering, swap space, and so forth, and you're talking about a Terrabyte of data per year for the X-Rays at a large community hospital. MRI, CT, Ultrasound, Angiography, and all the rest will add more, of course.
The hospital I used to work at stored about 2.5 terabytes of images per year.
1. Physical space and layout. Many hospitals are over 100 years old, and have 100 years of history of doing things with paper. Rooms, offices, and facilities are simply not designed for laying computer cables, fitting CRT monitors on desks, and so forth. Flat panels and wireless networking are helping solve some of the structural problems.
2. Training. About 80% of healthcare workers only have an associates degree. When I started in healthcare IT, a boss explained to me "There are a lot of caring unintelligent people who work in healthcare." The fact of the matter is that most nurses and techs and many medical doctors don't know how to use computers. The Chairman of Radiology at the hospital I used to work at would have somebody else use the computer mouse before him, because he couldn't get the 'double clicking' down. He would also dictate reports and had a staff of transcriptionists and secretaries to enter all his notes for him.
3. Unionization. Many unions are 50+ years old at healthcare settings. Techs and nurses have it written into their bylaws and union labor contracts that using computers is *not* part of their jobs.
4. Lack of IT Staffing. Hospitals aren't IT shops. Hospitals are in the business of providing healthcare, not supporting computer equipment. Between hiring more nurses and hiring more IT personnel, they would rather hire nurses. When I started at the hospital I used to work at, there were a total of 12 IT people out of a staff of 3,000. That's a 1:250 ratio. Most hospitals simply don't have the personnel to implement and support electronic medical records, even if they wanted to. So this becomes a staffing issue.
5. Liability Costs. Unlike a department store, where a downtime of the computer systems means some lost sales, in a healthcare environment, a downtime of a computer system can mean people die. The liability cost of an electronic medical record not working is much higher than the liability cost of a catalog or billing system not working.
6. Legal Requirements - There are many old legal requirements for keeping records in triplicate and so forth. Many of the medical records folks feel that they have to continue working with those older laws. We implemented an electronic medical record system at the hospital I worked at, and the Radiology department kept printing out physical copies for 4 years after the go live of the digital system because they felt that the old laws requiring physical copies in triplicate were still in effect.
7. FDA Approval and Market Barriers to Entry - It's very costly to develop products for the medical industry. In particular, medical devices are required to go through FDA approval. In the case of a medical scanner, such as an MRI scanner or Ultrasound machine, these devices generate portions of the electronic medical record and have to go through FDA approval. This can costs tens or hundreds of thousands of dollars for the approval. Which means that the costs are passed on to the hospitals, meaning that the equipment is very expensive to purchase. Electronical medical records are a funny area, because there is confusion as to whether a medical record server should be considered a "medical device" and thus requiring FDA approval. There's a new certification body, the CCHIT that's trying to resolve the issue by providing a healthcare IT certification process instead of the FDA certification process, but it's still unclear how to go about getting EMR equipment and software certified as being kosher to use in a healthcare environment.
I could go on and on.
FYI... I do Picture Archiving and Communication Systems (aka PACS) for Departments of Radiology, and have experience installing electronic medical record applications at large community hospitals. If anybody has more questions about this topic, wants to know more about the topic, etc. feel free to ask and I'll let you know the details of the industry.
Not to nitpick, but VMWare Fusion runs on the Mac OS host, and as of version 2.0, Fusion now supports Mac OS X Server as a guest operating system. Your VMWare knowledge is about 6 months stale.
While parent post was obviously meant to be funny, there's a grain of truth in his post in so far as the term 'penetration tester' is a rather unfortunate term to use, and one you probably want to avoid using.
Yes, it might be common jargon in the industry, but you need to really think about how you're marketing yourself. Talking about "penetration testing" at work could reasonably be viewed as creating a hostile or harassing work environment at any corporation that takes it's sexual harassment policies seriously. Moreover, if a woman in human resources scans "penetration testing" in your resume, how quick do you think it's going to take her to click 'delete' and toss your resume in the garbage? I'm guessing between 2 and 3 seconds.
"Security Auditor" is probably a much better term to use.
Properly used, automation is a good thing. Blindly relying on it will get you burned, but to totally dismiss it out of hand is foolish.
First Rule of Automation: Automation applied to an efficient task increases it's efficiency; likewise, automation applied to an inefficient task will simply increase the problem until it's an all out clusterfuck.
Second Rule of Automation: Automation applied to an effective task will be effective; likewise, automation applied to an ineffective task will still be a pointless waste of time.
Or something like that. My eloquence appears to be -1 today.
Fyi, you need an evolution algorithm to set up a population of A* algorithms to effectively use the 1000 processors. The evolution algorithm then sets the routes up to basically compete with each other, and mixes-and-matches different routes, looking for the most fit one. It's a fairly well understood bit of computer science, and scales effectively.
And for what it's worth, evolution algorithms and genetic algorithms are going to be all over the place in 5 or 10 years, because they can handle 1000 or 10,000 cores without any problems. They're sort of like 'meta-algorithms' for parallelizing a linear algorithm. The only requirement is that the linear algorithm has to be set up to compete with other copies of itself. So you then have to deal with a bunch of stuff like encoding populations of potential answers, creating mutation and crossover operators, defining selection thresholds, and creating competition scenarios.
The most difficult part, in many respects, is creating an intuitive user interface for all of it.
Um, how about design blueprints? CAD files and the like? A copy of the Guttenberg Project and the Visible Human project? etc. etc. I could go on and on, but the point is that storing information through a global nuclear war is just as important as storing seeds.
They'll justify operation costs through leasing server space to various businesses. But they justify their capital expenditures for the installation and upgrade through the disaster recovery and business continuity planning services they offer.
Better service. They're creating an environment where the monkeys will want to work at and keep in good condition. Those will be very well maintained and optimized servers. There's more to managing a data center than simply swapping hard drives.
Slashdot Mirror
assuming 24 bit color depth
24 bits / pixel = 3 bytes / pixel
1536 x 2048 = 3,145,728 pixels
3,145,728 pixels x 3 bytes/pixel = 9,437,184 bytes = 9.4 MB
add an extra megabyte for the overhead of file headers, which include all the patient demographics, and you get 10.5 megabytes.
what part don't you understand?
I worked with this equipment for four years on the job. The average file size of an XRay is 10.5MB.
Interestingly, your billion dollar mark isn't too far off the mark in regards to what it takes to create a state-of-the-art EMR in todays market place. Check out Cerner Millennium. They've invested over a billion dollars in it's development, and are working through their second billion of R&D. 10 million dollars will get you an EMR for *a single department*.
Well, the DICOM format specifies JPEG 2000 lossless as the preferred image format, which is what we were using. Common format was 1536 x 2048 for a 3 megapixel image. I think it was 72dpi.
Now then, I should mention that is *per image*. So, if you have a knee study that has four images, that's 42MB. If you get a CD that has your X-Rays from this year as well as your prior exams, then you could be talking about a lot more than 10MBs.
And for what it's worth, the only doctors who I ever saw magnify their analog radiographs were the Mammographers, and they used a 3x or 5x magnifying glass. They weren't going trying to go microscopic with the x-ray image. If you need to get cellular levels of detail from something in the middle of the body, the way to do that is with a biopsy, not with an x-ray and magnifying glass.
You remember studying significant figures in introductory chemistry? Unlike number theory or pure mathematics, when it comes to scientific measurements, if I multiply the number 3.14159, which has 6 significant figures, by the number 2.0, which only has two significant figures, the result is only 3.2. Anything else is prone to measurement errors. Such is the case with radiographs and the human eye.
Yes, the analog film will record at very high fidelity, but there is camera jitter, patient movement, camera distance and angle, mass density, and x-ray intensity to account for. And those factors will reduce the significant figures in the measurement, which is what an X-ray is. If a clinician needs to look at a microscopic area, they'll get an imaging modality that's calibrated to adjust that microscopic size and display it in a format that's visible to the human eye. Hence, biopsy and microscope. Not x-ray and magnifying glass.
heh....
Well, Cerner Millennium certainly wouldn't win the award either if it were measured by glitzy GIFs and user interface.
I think I'm biased against MUMPS because of it's tendency to create obfuscated code, and that it only has a single data type. Yes, I know some people say that it's concise and that the single data type is a feature, not a flaw. But obfuscated code quickly leads to a support nightmare.
And for what it's worth, I think that MUMPS may be in the process of disappearing. I know that I've been involved in at least one project to phase out a MUMPs system with an Oracle database. And having a single data type defeats the purpose of having data types to begin with.
My standard for 'state-of-the-art' is an integrated system that can be installed in every department of a major hospital, and which supports diagnostic software agents. Not glitz.
You do know that some of the biggest problems with paper records is, don't you? Mice, mildew, and silverfish. Yum. Many hospitals want to get the hell rid of the originals because they're a health hazard. Seriously. To expect hospitals to digitize the records and then keep the originals is foolish. At best, they'll send them to an "off site archive", meaning a warehouse. And even that costs money, sometimes upwards of tens or hundreds of thousands a year. Unfortunately, I can pretty much guarantee you that as soon as those records get digitized, the originals are getting shredded as quickly as the file room staff can manage it.
Did I mis-sunderstand the thread of the conversation? Ah well. You win some, you loose some.
Having done a file-room to EMR conversion in a Department of Radiology, it generally went like this:
/yr /yr
/yr /yr /yr
Before conversion
4 transcriptionists @ $42,000/yr
12 file room staff @ $42,000
1 supervisor @ $55,000
Total: $725,000 / yr
After conversion
1 PACS Admin @ $80,000/yr
1 RIS Admin @ $80,000
2 Systems Analysts @ $75,000
2 transcriptionists @ $50,000/yr
4 file room staff @ $42,000
Total: $575,000 / yr
End result was that we we reduce staff by about 7 people, or 40%, and payroll costs were reduced by $150,000 or 20%.
There wont be any part-time jobs, by the way. It will simply be the existing low-level staff being kept on an extra couple years to do the data entry, with management knowing that they're destined to be fired eventually. They will be fired through attrition or through a layoff eventually.
At each hospital. They're planning about $2,000,000 per hospital for equipment, from what I understand.
Now, I work at the VA which has the most advanced, state of the art electronic medical record system on the planet, and I defy anyone to point to a large scale health care system that has one that's really better in the aggregate. So, here at the VA we don't have the same barriers to adoption that private sector hospitals consider as the great majority of our patients are with us for life, so there is value in tracking them for the long term. I certainly don't agree with the private sector barriers philosophically, but practically speaking I understand the thought processes.
srsly?
You're claiming VISTA as being the most state-of-the-art EMR on the planet? Based on MUMPS?
I'll grant that it's probably the most mature and stable EMR on the planet. But for most state-of-the-art, I'd probably have to go with an integrated Cerner Millennium installation.
The fact that digital records could be transmitted very quickly, at any hour, for accident victims and save numerous lives has not stirred doctors into action.
You're just being silly. Not all doctors are money sharks. Some are, but the majority aren't.
And one things for sure: you've never sat in a Medical Informatics Committee meeting a community hospital.
You're only accounting for a portion of the entire scenario. Did you know that insurance companies and the US government value a human life around $9,800,000 dollars? Average term life-insurance is about $129,000 per year, and the average person lives something like 76 years in the US.
Humans are a finite resource, and it's in societies interest to keep it's population healthy. Economically speaking, it's true that money being spent on scanning old medical records isn't adding to the material economic base, in so far as import/export is concerned. But import/export isn't the only measure of an economy.
Rather, scanning in those old records results in better upkeep of the work force. It's more akin to equipment repairs of manufacturing equipment, I suppose. But the point is that it's an operational expense. More specifically, it's an infrastructure development expense that will decrease the annual operational expenses of maintaining manufacturing equipment (if you'll go so far as to consider a person a type of manufacturing equipment).
Anyhow, the point is that it's a maintenance fee, and keeps America economically viable by making sure that it's workforce is in good health and repair, so to speak.
Two possible ways in which your math may be off:
1st. You may be forgetting to factor in approximately $2M per hospital for equipment costs.
2nd. Could that $471,000 be spread over 5 years? That would equate to a $95,000 salary, I suppose. That might make sense.
Nice idea, but FDA approval requirements and legal code won't allow it. Do you really want people to be able to go changing code in your medical equipment willy-nilly? No, hospitals are very serious about their change control processes, as is the FDA. For a piece of medical software to get used in a healthcare setting, it has to be forked, stabalized, and passed through an FDA process.
Now, don't get me wrong. In theory, open source would be great in the medical and healthcare industry. But the GPL which requires the source code to be free isn't going to gain any traction in the industry, because it's at odds with the legal requirements that medical code be audited, stable, and not subject to casual change. In short, the GPL is at odds with the FDA certification process.
- Originals of a lot of records (x-rays for one example) do not transfer well to digital. Heck, transferring any analog recording, visual or auditory, to digital inevitably means a loss of fidelity at some point or another. You either save a far-too-small file that someone looks at and misses detail (or dismisses an important detail as compression artifacting) later, or your file is completely freaking huge.
Having worked in Radiology IT, I'd point out that the human eye is actually a limiting factor in our ability to see things. So, yes, you are correct in that an analog X-Ray had more diagnostic information encoded into it than a digital one. However, the human eye can only see so much data. The human eye isn't a microscope. So you don't need to scan an image to microscopic precision. You only need to scan it to a level of precision that the human eye can't detect a difference. And it turns out that to do a scan of an X-Ray at that level of details results in a file that's approximately 10.5MB in size. It's a very well known metric, actually.
And if you have a 600 bed hospital which sees 150,000 patients per year in the Department of Radiology, and 50% of those are X-Rays images, with 2 images (PA, Lateral) per exam, that results in, oh... about 75,000 x 0.5 x 2 x 10.5MB = 787 GB of data per year. Add some extra space for buffering, swap space, and so forth, and you're talking about a Terrabyte of data per year for the X-Rays at a large community hospital. MRI, CT, Ultrasound, Angiography, and all the rest will add more, of course.
The hospital I used to work at stored about 2.5 terabytes of images per year.
Answers to your question:
1. Physical space and layout. Many hospitals are over 100 years old, and have 100 years of history of doing things with paper. Rooms, offices, and facilities are simply not designed for laying computer cables, fitting CRT monitors on desks, and so forth. Flat panels and wireless networking are helping solve some of the structural problems.
2. Training. About 80% of healthcare workers only have an associates degree. When I started in healthcare IT, a boss explained to me "There are a lot of caring unintelligent people who work in healthcare." The fact of the matter is that most nurses and techs and many medical doctors don't know how to use computers. The Chairman of Radiology at the hospital I used to work at would have somebody else use the computer mouse before him, because he couldn't get the 'double clicking' down. He would also dictate reports and had a staff of transcriptionists and secretaries to enter all his notes for him.
3. Unionization. Many unions are 50+ years old at healthcare settings. Techs and nurses have it written into their bylaws and union labor contracts that using computers is *not* part of their jobs.
4. Lack of IT Staffing. Hospitals aren't IT shops. Hospitals are in the business of providing healthcare, not supporting computer equipment. Between hiring more nurses and hiring more IT personnel, they would rather hire nurses. When I started at the hospital I used to work at, there were a total of 12 IT people out of a staff of 3,000. That's a 1:250 ratio. Most hospitals simply don't have the personnel to implement and support electronic medical records, even if they wanted to. So this becomes a staffing issue.
5. Liability Costs. Unlike a department store, where a downtime of the computer systems means some lost sales, in a healthcare environment, a downtime of a computer system can mean people die. The liability cost of an electronic medical record not working is much higher than the liability cost of a catalog or billing system not working.
6. Legal Requirements - There are many old legal requirements for keeping records in triplicate and so forth. Many of the medical records folks feel that they have to continue working with those older laws. We implemented an electronic medical record system at the hospital I worked at, and the Radiology department kept printing out physical copies for 4 years after the go live of the digital system because they felt that the old laws requiring physical copies in triplicate were still in effect.
7. FDA Approval and Market Barriers to Entry - It's very costly to develop products for the medical industry. In particular, medical devices are required to go through FDA approval. In the case of a medical scanner, such as an MRI scanner or Ultrasound machine, these devices generate portions of the electronic medical record and have to go through FDA approval. This can costs tens or hundreds of thousands of dollars for the approval. Which means that the costs are passed on to the hospitals, meaning that the equipment is very expensive to purchase. Electronical medical records are a funny area, because there is confusion as to whether a medical record server should be considered a "medical device" and thus requiring FDA approval. There's a new certification body, the CCHIT that's trying to resolve the issue by providing a healthcare IT certification process instead of the FDA certification process, but it's still unclear how to go about getting EMR equipment and software certified as being kosher to use in a healthcare environment.
I could go on and on.
FYI... I do Picture Archiving and Communication Systems (aka PACS) for Departments of Radiology, and have experience installing electronic medical record applications at large community hospitals. If anybody has more questions about this topic, wants to know more about the topic, etc. feel free to ask and I'll let you know the details of the industry.
Not to nitpick, but VMWare Fusion runs on the Mac OS host, and as of version 2.0, Fusion now supports Mac OS X Server as a guest operating system. Your VMWare knowledge is about 6 months stale.
You mean that you're not suppose to spread rumors about a company being sold so you can short it's stock??? What's the world coming to?
While parent post was obviously meant to be funny, there's a grain of truth in his post in so far as the term 'penetration tester' is a rather unfortunate term to use, and one you probably want to avoid using.
Yes, it might be common jargon in the industry, but you need to really think about how you're marketing yourself. Talking about "penetration testing" at work could reasonably be viewed as creating a hostile or harassing work environment at any corporation that takes it's sexual harassment policies seriously. Moreover, if a woman in human resources scans "penetration testing" in your resume, how quick do you think it's going to take her to click 'delete' and toss your resume in the garbage? I'm guessing between 2 and 3 seconds.
"Security Auditor" is probably a much better term to use.
I think he was pretty spot on regarding the visual cortex simulation:
http://tech.slashdot.org/article.pl?sid=08/06/13/2014225
Properly used, automation is a good thing. Blindly relying on it will get you burned, but to totally dismiss it out of hand is foolish.
First Rule of Automation: Automation applied to an efficient task increases it's efficiency; likewise, automation applied to an inefficient task will simply increase the problem until it's an all out clusterfuck.
Second Rule of Automation: Automation applied to an effective task will be effective; likewise, automation applied to an ineffective task will still be a pointless waste of time.
Or something like that. My eloquence appears to be -1 today.
Fyi, you need an evolution algorithm to set up a population of A* algorithms to effectively use the 1000 processors. The evolution algorithm then sets the routes up to basically compete with each other, and mixes-and-matches different routes, looking for the most fit one. It's a fairly well understood bit of computer science, and scales effectively.
And for what it's worth, evolution algorithms and genetic algorithms are going to be all over the place in 5 or 10 years, because they can handle 1000 or 10,000 cores without any problems. They're sort of like 'meta-algorithms' for parallelizing a linear algorithm. The only requirement is that the linear algorithm has to be set up to compete with other copies of itself. So you then have to deal with a bunch of stuff like encoding populations of potential answers, creating mutation and crossover operators, defining selection thresholds, and creating competition scenarios.
The most difficult part, in many respects, is creating an intuitive user interface for all of it.
Either that, or Stephenson was simply anticipating the direction things are going in society.
Um, how about design blueprints? CAD files and the like? A copy of the Guttenberg Project and the Visible Human project? etc. etc. I could go on and on, but the point is that storing information through a global nuclear war is just as important as storing seeds.
They'll justify operation costs through leasing server space to various businesses. But they justify their capital expenditures for the installation and upgrade through the disaster recovery and business continuity planning services they offer.
Better service. They're creating an environment where the monkeys will want to work at and keep in good condition. Those will be very well maintained and optimized servers. There's more to managing a data center than simply swapping hard drives.
it's just the gel lighting.