I recall reading, sometime in the last 2-3 years, and my wife's often told me, that the solo practitioner has to see a minimum of 48 patients per day in clinic to pay the bills. A few years ago, I suspect this included some salary for the practitioner. Today I bet the number of patients is higher, and the practitioner's take is smaller. My friends are leaving private practice in droves. They're going to hospital or (large) clinic practices. It's how they can earn a living.
HIPAA was envisioned to protect you, the consumer, from data mining, especially by insurers who wanted to use those data for rate adjustments and denials. Or so the theory went. What HIPAA became was a behemoth with an implementation plan designed to make data sharing nigh well impossible, and with costs to the health care provider, clinic and patient that were never anticipated.
I'll posit that a _GOOD_ implementation of an EMR, with a valid and robust data exchange plan, and which has accounted for the human factors aspects of physician, nurse, advanced practitioner, specialist, physical therapist and pharmacist, might reduce costs and provider errors. I'll state that, of the one's I've seen, and from colleagues I've talked to, it just doesn't exist yet.
Post Sandy, at the NYU Medical Center, they recounted the problems associated with no access to EHR after their systems went down. Bad enough when they were still in their own hospital, but very serious when they transferred patients to other hospitals. The story is that staff physicians, nurses and residents went with patient cohorts to the receiving hospitals and served as verbal medical records to get their patients situated best.
Well crafted database and server replication might help in a scenario like this, but so much of the infrastructure in NYC was broken, I doubt it would have.
This is an IT problem but it also extends beyond that simple statement. It requires human factors, so that the medical personnel can use it readily. It requires that common conditions be addressed (e.g., in obstetrics, it should be able to calculate EDC from LMP and project a due-date). I'll accept having separate adult, pediatric and neonate elements to help with dose calculations; that's not too bad and almost everyone's smart-phone can do those calculations close to automagically now. It needs customizable checklists for common procedures, AND an ability to go outside the checklist for issues/complications. It needs a good problem list generator and then a tracking system to allow repeat visits to recognize a problem list entry and bring it up at the next visit... or for a home phone call sooner if need be.
And did I mention it needs a data exchange format that really works? Recent experience: I had to see someone in a new city for care. My primary care physician's clinic (using a large EMR system they're abandoning in favor of EPIC) printed and faxed the whole chart to the doc's office in the other city. And when I asked the doc to send stuff back to my PCP? Yep. They faxed it all back (save the important stuff which didn't get sent at all).
EMR's something I've loked at for over 20 years and played with off and on. I was playing with it when the best way to automate was to create a lab-reporting system using VAX PDP-8's and DECterminals. Expensive? Slow? Yes but with a little screen building and database work, it was useful. I've watched HL7 and its predecessors over the years and they continue to get more robust, so getting the infrastructure standards in place isn't too hard.
What's hard is getting the INDUSTRY to stop being greedy and decide to interoperate. And to respond to the primary users, who are the medical professionals who have to hammer on the damned systems daily.
Several years ago, I had a netbook (before netbooks were cool) made by compaq. As this was in the days before every kid had a computer, and before, well, wifi, and before Facebook, I didn't succumb to today's general distractions. I took abbreviated notes in class often using vi. I'd find a quiet spot later, although the keyboard was too loud to do it in the library, reorganize the notes and rewrite them using complete sentences, add equations (via an equation editor), and generally make 'em useful. These served me well. I've gotta say, though, that the "improvements" to Notepad, Office, OpenOffice, etc., and the advent of tablets overall, has made it HARDER to use a computational platform to do what I did, rather than easier. I'm going back to pencil and paper.
And, I've found that the act of writing the notes, even when I never used them again, helped me better understand and recall the material from the lectures.
There's a tendency now to try to use more common components in new satellites, especially for meteorology birds, while there's always new science, adapting existing hardware to do the work means you might get a couple of instruments on different spaceframes, and not cost as much as the gee-whiz one-offs. Someone already mentioned that R&D, testing, SRM&QA and launch services cost a bunch. If we COULD accomplish this, then restoring capabilities on-orbit would be great.
NASA had a "Flight Telerobotic Servicer" project in the early 90's. Don't know where it went but it did get a fair bit of support and a lot of good engineering talent was pointed at it. From my interactions with DARPA projects in the past, there's a fair chance that something useful will come out of this, even if the whole program is over-ambitious.
If not the exact technology, the concept was first bandied about in the early days of Space Station Freedom design and development. Among other things, Space Station was supposed to lead to a Closed Environmental Life Support System that included reprocessing urine, atmospheric condensate and, well, yeah, fecal water into water of sufficient quality for drinking and even medical uses. A lot of work, by quality scientists and engineers went into this. In 1992, an experiment flew in SpaceLab on STS-47 that demonstrated taking Kennedy Space Center tap water, storing it in a closed container for 90 days, and running it through a process/apparatus called SWIS (Sterile Water for Injection System) to create water that was demonstrably "ultra-pure water for injection" per the US Pharmacopaea. Oh, and it worked, too. Making waste water into something drinkable is considerably simpler.
A poster commented on the potential for cross-transfer of large molecular weight compounds across the ultrafiltration membrane... Unlikely unless it's got holes, and they'd become obvious by the "filtration" rate.
A lot of the monte carlo schemes, and especially the nuclear physics ones I've encountered recently, need a LOT of memory. Most of the cloud options are sort of memory-lite. And, map-reduce (Hadoop) isn't the answer to everything, even if my boss thought so at one time.
As pointed out earlier in the thread, you're not defining requirements well.
I think you're going to want to consider setting up a cluster front-end. You generally do not want to run X on all the nodes: Let them run the monte carlo sims and don't waste memory or resources allowing users to hammer each node. Or, allow it now, and regret it later when performance plummets.
Consider GPGPU (nVidia Tesla, realizing that AMD/ATI have GPGPU options, but I am not versed in them yet) for improved performance in calculations.
Have you looked around your university? Is there anyone else running clusters with whom you could partner? My group does exactly that: We run a cluster and while I also am a numerical modeler, we provision and operate a cluster that serves users in agriculture, nuclear engineering, petroleum engineering, atmospheric sciences, HEP, chemistry and the social sciences. Your questions suggest, to me, that your time is better spent as a researcher and not as a system administrator.
And while we're here... One of my pet peeves is when a professor takes a grad student who came into a program to get their degree in, say, nuclear physics, and turns them into a system administrator and user support girl for the group. Either instead of, or in addition to, their scientific career, they have to manage the computing resources and learn how all the software works. In my experience, if they're good graduate students and conscientious, they will do a great job, but will not get the education they came for. They may get the degree, but they are likely doomed to supporting other users who got a better education. They're still good, in fact, indispensible, to a research program, but they were sacrificed with little input to their future. Better, if that's what you need, to actively recruit for someone who wants to learn the field to better become a computational expert with a discipline track in your field, nurture them, and if they are deserving, provide said terminal degree. I really don't like sacrificing an unsuspecting graduate student to the HPC gods for a faulty member's benefit.
Generally, your head node will need an X client, but NOT the compute nodes. You won't have to log into them per se, but the head node, where you submit your jobs, does have to get to them. In general, the compute nodes in an HPC environment are hidden away on a private network, and don't see the outside world, And, for that matter, shouldn't (let's not talk about OSG requirements, or things that ATLAS and CMS are promulgating).
Another consideration is cluster-local visualization: As datasets grow, it becomes less practical to bring whole datasets back to your desk, and then process them for a quick-look at results. Instead, initial, and perhaps all analysis should be considered on the cluster. This argues in favor of an X installation, and GPU accelleration hardware on at least the head node, a dedicated graphics/analysis node(s), or perhaps the whole cluster.
And, so far, no one has spoken of favorite compilers. gcc's not bad but not stellar for a lot of HPC uses. Portland Group and Intel have done good things, IMNSHO, in the compiler world, and PGI is starting to incorporate nVidia GPU compatibility in their stuff.
There is also the occasional need for something like VNC when you absolutely, positivily have to have that remote desktop look for your visualization software.
A lot of the Russian experience, at least when I was active in Space Station stuff and the Russians were still flying Mir, had small populations, n=1-5. You cannot draw significant conclusions very easily from samples that small.
Electrophoresis is a reasonable drug delivery system for SOME agents, but not all.
While I can't speak to Kirk's problems, the Shuttle isn't a sterile environment. It is kept as clean as possible, mainly because they don't want any more particulate contamination to fly, and get circulated in microgravity than necessary, but you can't get rid of all of it, Historically, on Shuttle, they set up a fan between Middeck and Flight Deck, in the starboard access area, and used a filter on the inlet side. It captured fine particulate matter... and pens, etc., that were dropped or otherwise lost by the crew on-orbit. It all ended up, eventually, in the filter.
Also, while there's a 2-week quarantine period preflight, there are SOME diseases where the incubation period is longer than that. In those cases, isolating the crew for 2 weeks wouldn't catch the problem.
Um... but such changes CAN occur. One of the developments for the Crew Healthcare System included the ability to use available water supplies from stored, or recycled water, to make intravenous solutions, using fluid concentrates (we tried, but the powdered chemicals just don't disolve well and have to be manipulated). The system used a multiple-component water pass-through purification system to prodce at least 50 Mohm water that had also been subjected to ultrafiltration, to assure cellular contaminents such as endotoxins were removed. The system did not use high pressure or heat sterilization, and was demonstrated to meet US FDA and USP standards for ultrapure water for injection, and intravenous fluids.
Water reuse for long-duration spaceflight missions is already achievable, with only the stigma of using recycled water for drinking and medical uses remaining as a potential problem. The processed water is considerably cleaner than anything you'll drink in a conventional water supply, and certainly better than the tap water at Cape Kennedy.
The ability to white-noise (or pink-noise) jam GPS has been around and employed for, literally, years. And, most of the first of these I saw came from China, too. GPS is a relatively fragile system, at least n the L1-C/A world: GPS satellites have limited power budgets so signal levels are low on the ground. Receivers have high gain. Multipath in urban environments can confuse receivers. Emitting a random noise signal over the range of L1 frequencies isn't that hard, and doesn't take much power... or antenna height... to cause problems.
The article makes all of these points. Read it and take note of the fragility of the system. That's its downfall, not a $30 device.
Slack has some benefits if only because you end up having to compile from scratch in most cases, which can be instructional. However, Hook 'em and reel 'em in, then teach 'em what the tricks are for deciding on a distro, and help them do more complex things.
Not necessarily. I've been trying to find a couple of good, linux-savvy student workers, and they're rare. By the time I hear about them, someone else has generally snagged 'em. I'd have to say maybe 10% of our CS freshmen know enough about Linux to have installed it themselves on a home machine.
I'd start with a two-pronged approach. 1. GUI. Using something like Ubuntu, although I'm generally a CentOS bigot, teach them how to do all the things they know how to do in Windows: download and install software (using apt, for instance) and how to add an icon to the desktop. Teach 'em where to find applications of interest. 2. Start teaching the command line. There are times when a GUI... anyone's GUI... is too cumbersome/restrictive to do things quick and dirty. 2a. introduce them to 'script' and the concept of shell (batch) scripting. 2b. as an addendum to 2a, above, give 'em an overview of the major shells and explain why Tom Christiansen thinks csh is totally unsuited for scripting.
Don't preach about how much better Linux is than Windows... If they continue, they'll understand themselves. If they fall by the wayside, they never would have understood, anyway.
You make some good points, but also miss a couple of key elements. 1. Rather than once/day, a once per minute weather update with geopositioning data would, in fact, be useful, especially if it incorporated the standard info but simply substituted precipitation detection and identification for measurement. Otherwise, T, Td, Pbaro,wind, and solar data could readily be obtained. 2. Rather than requiring a fixed location for each measurement, consider relating geolocation to a fixed grid square. This could be very useful for verification 3. There are thousands of volunteer observers in the US, and a lot are giving their data to NWS. It's valuable, but this would be too. 4. Some work is already going on with this at NCAR. Was in a seminar recently where they talked about mobile mesonets. In fact, a major bus line has agreed to have their bus flet instrumented and the data sent to NWS. 4. Consider Homeland security...Yes, a CBRNEevent would benefit from early detection and ongoing modeling of plume release
I've been looking at mobile weather data systems for almost a decade. Getting USPS to do this would be a good thing.
The illustration behind the surgeon in the article looks a lot like an impeller-driven left ventricular assist device. It's not an artificial heart, but could, conceivably, be half of one. In the old days, when most VADs were pulsatile, they could effectively replace a non-functioning ventricle and produce pulsatile flow, very much as the heart does. However, they were bulky and had their own problems. Pulseless, continuous flow, impeller-driven pumps are less likely to develop clots on surfaces, which will help the patient in the long term.
Neither the posting nor the article were long on real facts, though. I don't recall Duschenne's dystrophy having a direct effect on cardiac muscle (but it's been a long time). Striated muscle (and some smooth muscle) degeneration, especially of the respiratory and accessory muscles tends to cause demise. If the heart was also affected by myopathy, then use of a VAD could be either a transient, or "permanent" solution. A surprising number of patients who received VADs as a bridge to allow them to live until a satisfactory donor was found, have been suficiently recovered to no longer require transplantation after weeks or months of service with a left ventricular assist device.
Slashdot Mirror
I recall reading, sometime in the last 2-3 years, and my wife's often told me, that the solo practitioner has to see a minimum of 48 patients per day in clinic to pay the bills. A few years ago, I suspect this included some salary for the practitioner. Today I bet the number of patients is higher, and the practitioner's take is smaller. My friends are leaving private practice in droves. They're going to hospital or (large) clinic practices. It's how they can earn a living.
HIPAA was envisioned to protect you, the consumer, from data mining, especially by insurers who wanted to use those data for rate adjustments and denials. Or so the theory went. What HIPAA became was a behemoth with an implementation plan designed to make data sharing nigh well impossible, and with costs to the health care provider, clinic and patient that were never anticipated.
I'll posit that a _GOOD_ implementation of an EMR, with a valid and robust data exchange plan, and which has accounted for the human factors aspects of physician, nurse, advanced practitioner, specialist, physical therapist and pharmacist, might reduce costs and provider errors. I'll state that, of the one's I've seen, and from colleagues I've talked to, it just doesn't exist yet.
Post Sandy, at the NYU Medical Center, they recounted the problems associated with no access to EHR after their systems went down. Bad enough when they were still in their own hospital, but very serious when they transferred patients to other hospitals. The story is that staff physicians, nurses and residents went with patient cohorts to the receiving hospitals and served as verbal medical records to get their patients situated best.
Well crafted database and server replication might help in a scenario like this, but so much of the infrastructure in NYC was broken, I doubt it would have.
This is an IT problem but it also extends beyond that simple statement. It requires human factors, so that the medical personnel can use it readily. It requires that common conditions be addressed (e.g., in obstetrics, it should be able to calculate EDC from LMP and project a due-date). I'll accept having separate adult, pediatric and neonate elements to help with dose calculations; that's not too bad and almost everyone's smart-phone can do those calculations close to automagically now. It needs customizable checklists for common procedures, AND an ability to go outside the checklist for issues/complications. It needs a good problem list generator and then a tracking system to allow repeat visits to recognize a problem list entry and bring it up at the next visit... or for a home phone call sooner if need be.
And did I mention it needs a data exchange format that really works? Recent experience: I had to see someone in a new city for care. My primary care physician's clinic (using a large EMR system they're abandoning in favor of EPIC) printed and faxed the whole chart to the doc's office in the other city. And when I asked the doc to send stuff back to my PCP? Yep. They faxed it all back (save the important stuff which didn't get sent at all).
EMR's something I've loked at for over 20 years and played with off and on. I was playing with it when the best way to automate was to create a lab-reporting system using VAX PDP-8's and DECterminals. Expensive? Slow? Yes but with a little screen building and database work, it was useful. I've watched HL7 and its predecessors over the years and they continue to get more robust, so getting the infrastructure standards in place isn't too hard.
What's hard is getting the INDUSTRY to stop being greedy and decide to interoperate. And to respond to the primary users, who are the medical professionals who have to hammer on the damned systems daily.
RFC1149/2549 coupled to a keyboard under a line of birds?
Several years ago, I had a netbook (before netbooks were cool) made by compaq. As this was in the days before every kid had a computer, and before, well, wifi, and before Facebook, I didn't succumb to today's general distractions. I took abbreviated notes in class often using vi. I'd find a quiet spot later, although the keyboard was too loud to do it in the library, reorganize the notes and rewrite them using complete sentences, add equations (via an equation editor), and generally make 'em useful. These served me well. I've gotta say, though, that the "improvements" to Notepad, Office, OpenOffice, etc., and the advent of tablets overall, has made it HARDER to use a computational platform to do what I did, rather than easier. I'm going back to pencil and paper.
And, I've found that the act of writing the notes, even when I never used them again, helped me better understand and recall the material from the lectures.
When I read the title, I assumed immediately that the intent was to use the word, 'queue' in appropriate context: Line'em up. Sorry, you blew it.
Boy, ain't that the truth. Ad, having a GS-5 doing the keyword reviews doesn't work well either.
Beat me to it...
There's a tendency now to try to use more common components in new satellites, especially for meteorology birds, while there's always new science, adapting existing hardware to do the work means you might get a couple of instruments on different spaceframes, and not cost as much as the gee-whiz one-offs. Someone already mentioned that R&D, testing, SRM&QA and launch services cost a bunch. If we COULD accomplish this, then restoring capabilities on-orbit would be great.
NASA had a "Flight Telerobotic Servicer" project in the early 90's. Don't know where it went but it did get a fair bit of support and a lot of good engineering talent was pointed at it. From my interactions with DARPA projects in the past, there's a fair chance that something useful will come out of this, even if the whole program is over-ambitious.
If not the exact technology, the concept was first bandied about in the early days of Space Station Freedom design and development. Among other things, Space Station was supposed to lead to a Closed Environmental Life Support System that included reprocessing urine, atmospheric condensate and, well, yeah, fecal water into water of sufficient quality for drinking and even medical uses. A lot of work, by quality scientists and engineers went into this. In 1992, an experiment flew in SpaceLab on STS-47 that demonstrated taking Kennedy Space Center tap water, storing it in a closed container for 90 days, and running it through a process/apparatus called SWIS (Sterile Water for Injection System) to create water that was demonstrably "ultra-pure water for injection" per the US Pharmacopaea. Oh, and it worked, too. Making waste water into something drinkable is considerably simpler.
A poster commented on the potential for cross-transfer of large molecular weight compounds across the ultrafiltration membrane... Unlikely unless it's got holes, and they'd become obvious by the "filtration" rate.
A lot of the monte carlo schemes, and especially the nuclear physics ones I've encountered recently, need a LOT of memory. Most of the cloud options are sort of memory-lite. And, map-reduce (Hadoop) isn't the answer to everything, even if my boss thought so at one time.
Yes. Next question?
As pointed out earlier in the thread, you're not defining requirements well.
I think you're going to want to consider setting up a cluster front-end. You generally do not want to run X on all the nodes: Let them run the monte carlo sims and don't waste memory or resources allowing users to hammer each node. Or, allow it now, and regret it later when performance plummets.
Consider GPGPU (nVidia Tesla, realizing that AMD/ATI have GPGPU options, but I am not versed in them yet) for improved performance in calculations.
Have you looked around your university? Is there anyone else running clusters with whom you could partner? My group does exactly that: We run a cluster and while I also am a numerical modeler, we provision and operate a cluster that serves users in agriculture, nuclear engineering, petroleum engineering, atmospheric sciences, HEP, chemistry and the social sciences. Your questions suggest, to me, that your time is better spent as a researcher and not as a system administrator.
And while we're here... One of my pet peeves is when a professor takes a grad student who came into a program to get their degree in, say, nuclear physics, and turns them into a system administrator and user support girl for the group. Either instead of, or in addition to, their scientific career, they have to manage the computing resources and learn how all the software works. In my experience, if they're good graduate students and conscientious, they will do a great job, but will not get the education they came for. They may get the degree, but they are likely doomed to supporting other users who got a better education. They're still good, in fact, indispensible, to a research program, but they were sacrificed with little input to their future. Better, if that's what you need, to actively recruit for someone who wants to learn the field to better become a computational expert with a discipline track in your field, nurture them, and if they are deserving, provide said terminal degree. I really don't like sacrificing an unsuspecting graduate student to the HPC gods for a faulty member's benefit.
Generally, your head node will need an X client, but NOT the compute nodes. You won't have to log into them per se, but the head node, where you submit your jobs, does have to get to them. In general, the compute nodes in an HPC environment are hidden away on a private network, and don't see the outside world, And, for that matter, shouldn't (let's not talk about OSG requirements, or things that ATLAS and CMS are promulgating).
Another consideration is cluster-local visualization: As datasets grow, it becomes less practical to bring whole datasets back to your desk, and then process them for a quick-look at results. Instead, initial, and perhaps all analysis should be considered on the cluster. This argues in favor of an X installation, and GPU accelleration hardware on at least the head node, a dedicated graphics/analysis node(s), or perhaps the whole cluster.
And, so far, no one has spoken of favorite compilers. gcc's not bad but not stellar for a lot of HPC uses. Portland Group and Intel have done good things, IMNSHO, in the compiler world, and PGI is starting to incorporate nVidia GPU compatibility in their stuff.
There is also the occasional need for something like VNC when you absolutely, positivily have to have that remote desktop look for your visualization software.
A lot of the Russian experience, at least when I was active in Space Station stuff and the Russians were still flying Mir, had small populations, n=1-5. You cannot draw significant conclusions very easily from samples that small.
Electrophoresis is a reasonable drug delivery system for SOME agents, but not all.
While I can't speak to Kirk's problems, the Shuttle isn't a sterile environment. It is kept as clean as possible, mainly because they don't want any more particulate contamination to fly, and get circulated in microgravity than necessary, but you can't get rid of all of it, Historically, on Shuttle, they set up a fan between Middeck and Flight Deck, in the starboard access area, and used a filter on the inlet side. It captured fine particulate matter... and pens, etc., that were dropped or otherwise lost by the crew on-orbit. It all ended up, eventually, in the filter.
Also, while there's a 2-week quarantine period preflight, there are SOME diseases where the incubation period is longer than that. In those cases, isolating the crew for 2 weeks wouldn't catch the problem.
Yes. Some bacteria become mor virulent when incubated in a microgravity environment.
Um... but such changes CAN occur. One of the developments for the Crew Healthcare System included the ability to use available water supplies from stored, or recycled water, to make intravenous solutions, using fluid concentrates (we tried, but the powdered chemicals just don't disolve well and have to be manipulated). The system used a multiple-component water pass-through purification system to prodce at least 50 Mohm water that had also been subjected to ultrafiltration, to assure cellular contaminents such as endotoxins were removed. The system did not use high pressure or heat sterilization, and was demonstrated to meet US FDA and USP standards for ultrapure water for injection, and intravenous fluids.
Water reuse for long-duration spaceflight missions is already achievable, with only the stigma of using recycled water for drinking and medical uses remaining as a potential problem. The processed water is considerably cleaner than anything you'll drink in a conventional water supply, and certainly better than the tap water at Cape Kennedy.
The ability to white-noise (or pink-noise) jam GPS has been around and employed for, literally, years. And, most of the first of these I saw came from China, too. GPS is a relatively fragile system, at least n the L1-C/A world: GPS satellites have limited power budgets so signal levels are low on the ground. Receivers have high gain. Multipath in urban environments can confuse receivers. Emitting a random noise signal over the range of L1 frequencies isn't that hard, and doesn't take much power... or antenna height... to cause problems.
The article makes all of these points. Read it and take note of the fragility of the system. That's its downfall, not a $30 device.
Slack has some benefits if only because you end up having to compile from scratch in most cases, which can be instructional. However, Hook 'em and reel 'em in, then teach 'em what the tricks are for deciding on a distro, and help them do more complex things.
Not necessarily. I've been trying to find a couple of good, linux-savvy student workers, and they're rare. By the time I hear about them, someone else has generally snagged 'em. I'd have to say maybe 10% of our CS freshmen know enough about Linux to have installed it themselves on a home machine.
I'd start with a two-pronged approach.
1. GUI. Using something like Ubuntu, although I'm generally a CentOS bigot, teach them how to do all the things they know how to do in Windows: download and install software (using apt, for instance) and how to add an icon to the desktop. Teach 'em where to find applications of interest.
2. Start teaching the command line. There are times when a GUI... anyone's GUI... is too cumbersome/restrictive to do things quick and dirty.
2a. introduce them to 'script' and the concept of shell (batch) scripting.
2b. as an addendum to 2a, above, give 'em an overview of the major shells and explain why Tom Christiansen thinks csh is totally unsuited for scripting.
Don't preach about how much better Linux is than Windows... If they continue, they'll understand themselves. If they fall by the wayside, they never would have understood, anyway.
You make some good points, but also miss a couple of key elements.
1. Rather than once/day, a once per minute weather update with geopositioning data would, in fact, be useful, especially if it incorporated the standard info but simply substituted precipitation detection and identification for measurement. Otherwise, T, Td, Pbaro,wind, and solar data could readily be obtained.
2. Rather than requiring a fixed location for each measurement, consider relating geolocation to a fixed grid square. This could be very useful for verification
3. There are thousands of volunteer observers in the US, and a lot are giving their data to NWS. It's valuable, but this would be too.
4. Some work is already going on with this at NCAR. Was in a seminar recently where they talked about mobile mesonets. In fact, a major bus line has agreed to have their bus flet instrumented and the data sent to NWS.
4. Consider Homeland security...Yes, a CBRNEevent would benefit from early detection and ongoing modeling of plume release
I've been looking at mobile weather data systems for almost a decade. Getting USPS to do this would be a good thing.
The illustration behind the surgeon in the article looks a lot like an impeller-driven left ventricular assist device. It's not an artificial heart, but could, conceivably, be half of one. In the old days, when most VADs were pulsatile, they could effectively replace a non-functioning ventricle and produce pulsatile flow, very much as the heart does. However, they were bulky and had their own problems. Pulseless, continuous flow, impeller-driven pumps are less likely to develop clots on surfaces, which will help the patient in the long term.
Neither the posting nor the article were long on real facts, though. I don't recall Duschenne's dystrophy having a direct effect on cardiac muscle (but it's been a long time). Striated muscle (and some smooth muscle) degeneration, especially of the respiratory and accessory muscles tends to cause demise. If the heart was also affected by myopathy, then use of a VAD could be either a transient, or "permanent" solution. A surprising number of patients who received VADs as a bridge to allow them to live until a satisfactory donor was found, have been suficiently recovered to no longer require transplantation after weeks or months of service with a left ventricular assist device.
Although this isn't the exact device shown in the Register article, here's a similar "permanent" citation: http://www.texasheart.org/AboutUs/News/2010-01-21news_FDAapprove.cfm