Now this I can agree with. User validation doesn't cut it. It's going to take a company with Apple like design skills and resources to show people what's possible. To say 'this is what you've always wanted, but just didn't know how to build'. That company hasn't come along yet. But when they do, they'll offer solutions to problems that people didn't know they had. And by that, I mean addressing things like how to visualize and interact with ontologies of 50,000+ choices in an intuitive manner. (My guess is mapping and cartography technologies, applied to human atlas/avatar; bundled with search and filtering technologies). People think that their problems are with 'user interfaces' and 'electronic medical records'; when, in hind sight, we'll say that the problems were with ontology mappings, taxonomy searches, medical renderings, longitudinal displays, and the like.
And you're totally right about the small frys on the other end of the spectrum. They're causing half the headaches, no doubt.
It's been about that long since I've worked with EPIC; more recently with Cerner. Nonetheless, I think we have substantially different expectations of what an EMR can and should be. Note that, by your own words, you admit that the UI of EPIC is as good and simple as the people who build it for the hospital want it to be. Not the people who work at the hospital want it to be. It seems to me that the EPIC UI is as good as the people who work at the hospitals will tolerate. The people at the hospital would prefer to have some Star Trek type EMR with tricorders and automated diagnostics. EPIC and Cerner are not that.
I have yet to see a modern EMR come bundled with an anatomical Atlas of the human body, which coregisters a patients scans, blood work, and medical history with a virtual avatar. Until we get to that point, all EMRs and PHRs are lacking and have shoddy interfaces. Google was half way there with Google Body, but they've since scrapped their Google Health product. That's a long story unto itself, involving having their XML expert design the health product, and not understanding their target market needs. But they recognized the need for the atlas to coregister data to, and that it will eventually be a primary interface to EMR and PHRs.
Not being able to add employees fast enough isn't necessarily a sign of a good system.
The story goes that Milton Friedman was once taken to see a massive government project somewhere in Asia. Thousands of workers using shovels were building a canal. Friedman was puzzled. Why weren't there any excavators or any mechanized earth-moving equipment? A government official explained that using shovels created more jobs. Friedman's response: "Then why not use spoons instead of shovels?"
The point being that adding laborers doesn't translate into a better product. In fact, not being able to add employees fast enough and turning away clients seems like a clear sign of scaling problems, training problems, and user interface problems. And just because they're first in the KLAS rankings doesn't mean that they're any good at improving patient health.
Now that's not to say that they fill their role as hospital practice management systems. But the fact of the matter is that hospitals are big money, and attract their own types of politics and special interests. And these KLAS rankings are about just that: politics, special interests, funding, sales, and so forth. Hospitals need practice management systems, and they need a way to evaluate different systems, and Cerner and Epic have put the most work into being on the top of the pile right now. But their systems are horribly designed.
And don't get me started on Cache. It's only redeeming quality is that it's not a relational database. But seriously? MUMPS? You're saying that we should continue deploying health care systems based off MUMPS? I'm sorry, but we've learned a few things in the past 40 years since M/MUMPS was originally created. Now then, I'll concede that object and document oriented databases are the way to go with regards to databases in healthcare. And in that regard, systems based off of Cache at least have that going right for them, and is why they've got the market share. But mark my words: a vendor is going to come along with a modern HTML5 product based off of a next-generation database, and it's going to be transformative. I don't know what that database will be... Cassandra, Hadoop, BigTable, Redis, or what. But when it finally happens, it's going to be the Facebook and Google of healthcare.
50K to 100K works out to be about one support personnel per physician. That sounds about right; particularly if that physician wants somebody they can call 24/7 for support.
Another thing to keep in mind is that healthcare is practiced differently in different states, due to state laws. Not to mention different regional needs. For example, a clinic in the far north needs to offer more services related to frostbite and hyopthermia than a clinic in the south, and may price things differently as such. Therefore, their billing and clinical systems need to be set up differently.
Having supported said systems, I'd say that Cerner and EPIC are lost causes as well. Too much attempted data-modeling in the database layers are causing their database schemas to melt-down and implode. As companies, they're likely to survive through mergers and acquisitions; but their current product lines should be put out to pasture as soon as possible.
Having been an Oracle Database Admin in the healthcare sector, I'm not encouraged by the database implementations either. The bottom line is that company after company gets started developing a EMR/EHR related product, and seems to think that it's a good idea to start data-modeling within the database layer. Everybody else is smoking crack, so apparently they should too.
I'm a little more lenient about the tendency to reboot to fix problems, because it's actually pretty good ergonomics and workflow. Particularly in a high-stress, mission-critical environment. When someone is crashing (ie. having a heart attack), the quick-fix to get a workstation back on line needs to be as simple as rebooting. But if you're going to follow that path, the logging has to be spot-on so that analysts can go back after-the-fact.
Probably has a lot more to do with your implementation and how your hospital culture values it's tech support staff than the Centricity product itself. Most PACS systems can integrate just fine if you put the time and effort and resources into doing so (meaning paying the salary necessary to have a properly staffed support team; meaning spending $500K per year in on-site support costs for a 150,000 patient/yr hospital or clinic system). Not going to argue about click count, because that's simply lousy software design. But your attitude about delegating speaks volumes about why the implementation is considered a failure at your location.
Actually, the employment market for PACS engineers is bottoming out, since HITECH and PPACA.
Long story short, it used to be a specialized niche industry, and now everybody is swarming into the market because it's perceived to be where the money is. If a hospital is willing to pay top money for somebody with 5 to 10 years of experience, then yes, there are a couple engineers out there who stand to make some good money. But why hire somebody with 10 years of experience, when there are plenty of new kids on the block with 2 years experience that they can hire at half the price? Also, in the healthcare field, it's not so much about how much you know about the tech. What's more important, in the eyes of the hospitals, is call rotation, and whether somebody is green and naive enough to sign up to 24/7 call support for two weeks per month.
I was making good money as a PACS Administrator (albeit with long hours) before health care reform. Since then, I've had to move to the vendor side as a Software Architect, since the market is now swamped with entry level PACS engineers.
What evidence suggests that industrialized nations would be the most affected? Viruses and bacteria don't care what kind of technology or manufacturing base a nation has. From an epidemiology perspective, the only thing that matters is population density and proximity to others.
While not authoritative, the standard way to author SVG animations with HTML seems to trending towards a Javascript/jQuery solution. Raphael & Mashi is generally what you're looking for; although it lacks a IDE still.
You're making an assumption here that efficiency of flow is the highest value. To use the food analogy, distribution of food can be modeled as a flow. The most efficient flow, as you would have it, would include selling food without nutrition labels, pasteurization, preservatives, etc. The most efficient thing would be to just sell everything as-is, without regulations, and let the consumers sort it all out themselves, as they figure out which people get sick and/or die from which farms and grocery stores. But we don't do that, because efficiency of flow is less valuable than preservation of human life. To that extent, we *want* the kinks and bumps to introduce eddies. It is better to have turbulent flow than laminar flow when the flow results in sickness and death.
To quote Bill Gates, and bring things back round-circle: "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." Laminar flow may be the optimal form of flow. But if the flow itself is harmful to begin with, then laminar flow merely magnifies the harm. If the system is rigged to drain money from the middle class and deposit it to the covers of rober-barons and plutocrats, then laminar flow merely makes it that much worse.
Ayn Rand actually talks about this a lot. She's not particularly forgiving, and describes them as leeches and parasites.
It's funny, because most conservatives, Randians, and Objectivists use her writings to argue against socialized services and equate the working poor and middle class as being the leeches and parasites to the rich. A close reading of Atlas Shrugged, however, and one comes to realize that she's talking about crony-capitalists, casino-bankers, and rober-barons as the leeches and parasites of society as much as anybody else. She talks often about brokers, agents, account managers, bankers, auditors, and the like as being the very people who suck money out of the system and are the leeches and parasites to the job producers.
Remember that she grow up in the USSR, that was really against centralized monetary planning. Crony-capitalism and casino-banking are just another form of centralized monetary planning; no better than the communist leaders with their 5 year plans. Same behavior, different environment.
Indeed. I was going to mention that 'hack' has two or three definitions now days, but upon looking at dictionary.com, it appears there are *twenty three* known uses of the word! And another 15 if you consider the definitions of 'hack' that are derived from 'hackney', and yet another 6 if you consider the definitions of 'hack' that are derived from 'hatch'. With 40 variations of 'hack' currently in use, I think the English language will survive if we add one more, related to 'cracking'.
7a. Computers . to devise or modify (a computer program), usually skillfully.
7b. Computers . to break into, illegally
–verb (used with object)
1. to cut, notch, slice, chop, or sever (something) with or as with heavy, irregular blows (often followed by up or down ): to hack meat; to hack down trees.
2. to break up the surface of (the ground).
3. to clear (a road, path, etc.) by cutting away vines, trees, brush, or the like: They hacked a trail through the jungle.
4. to damage or injure by crude, harsh, or insensitive treatment; mutilate; mangle: The editor hacked the story to bits.
5. to reduce or cut ruthlessly; trim: The Senate hacked the budget severely before returning it to the house.
6. Slang . to deal or cope with; handle: He can't hack all this commuting.
7. Computers . to devise or modify (a computer program), usually skillfully.
8. Basketball . to strike the arm of (an opposing ball handler): He got a penalty for hacking the shooter.
9. British . to kick or kick at the shins of (an opposing player) in Rugby football.
10. South Midland and Southern U.S. to embarrass, annoy, or disconcert.
–verb (used without object)
11. to make rough cuts or notches; deal cutting blows.
12. to cough harshly, usually in short and repeated spasms.
13. Tennis.
a. to take a poor, ineffective, or awkward swing at the ball.
b. to play tennis at a mediocre level.
14. British . to kick or kick at an opponent's shins in Rugby football.
–noun
15. a cut, gash, or notch.
16. a tool, as an ax, hoe, or pick, for hacking.
17. an act or instance of hacking; a cutting blow.
18. a short, rasping dry cough.
19. a hesitation in speech.
20. Curling . an indentation made in the ice at the foot score, for supporting the foot in delivering the stone.
21. British . a gash in the skin produced by a kick, as in Rugby football.
—Verb phrase
22. hack around, Slang . to pass the time idly; indulge in idle talk.
—Idiom
23. hack it, Slang . to handle or cope with a situation or an assignment adequately and calmly: The new recruit just can't hack it.
It really depends on that the process is for. As a change control system, meant to minimize the introduction of new and unknown quality control issues into the field, it's doing a pretty good job. Admittedly, as a system to get the latest bleeding-edge software configuration to market, it's pretty lousy.
That being said, the conversion from english to metric is a good analogy. In both systems, codes can be added and removed, without requiring certification. It's the hardcoded application stuff, related to the code formats, code versions, and code relationships, that require recertification.
Unfortunately, the old ICD9 is considered broken, so it's not suitable for supersetting. As an example, say that the skull is considered part of the head in ICD9, but the skull is considered part of the skeleton in ICD10. The code for skull has moved from 'head' to 'skeleton'. How do you superset that kind of relationship change? Worse, what if the original ICD9 relationship is considered no longer scientifically valid? What if a disease of an organ is reclassified to be a disease of blood? Or of the nervous system? Supersetting wouldn't fix those broken relationships.
Yes, that's the easy and obvious part. Keeping both versions of the ICD9 code sets around is standard practice. The hard part involves the people and training issues related to phasing out legacy applications which are hard-coded to reference the old ICD9 codes.
It's not just that a bunch of codes have been added or removed. The relationships between the codes have changed as well. What used to be a single code in ICD9 may have been replaced with a list of codes in ICD10 (or, worse, a tree structure of codes); and conversely, what used to be a dozen codes in ICD9 might have been replaced with a single code. The disjoint mapping of codes and their relationships is what's really gumming up the works.
the system should be flexible enough for the codes to change.
Hehe... another person who doesn't work in the medical IT field, eh? If only. Ever heard of the Food and Drug Administration? They have this thing called 'FDA Approval' for software products. The change in format structure from ICD9 to ICD10 generally requires all the vendors of these systems to re-certify.
While these systems *should* be flexible enough to handle the code format changes, most of them aren't, due to federal certification and litigation reasons. The medical community would rather have a buggy system that's well documented and that they can create known work-arounds, than a flexible and adaptable system, with frequent updates, that could inadvertently introduce an undocumented error. In the medical field, '2 steps forward and 1 step back' doesn't cut it. So they require certification to prevent sliding back that one step, even if it prevents them moving forward 2 steps.
I disagree. The requirements for "PHP, RoR, Python, MySQL, Oracle, Apache, Cisco, JavaScript, jQuery, UI/UX, Photoshop, and Flash" is pretty reasonable. It simply describes a Joomla CMS installation with an incoming feed from an Oracle database somewhere, with a one-off Ruby site somewhere. It's actually almost exactly what we have where I work, and I expect all of my hires to be able to work with those technologies.
To use the car analogy, it would be like posting an auto mechanic position that specifies, "must have real experience with Breaks, Transmission, Steering, Engines, Air Filters, Air Conditioning, Fuel Filters, Suspension, Radiators, Stereos, and Upholstery." It would be reasonable to expect an auto mechanic to be familiar with all of those systems. Similarly, it's reasonable to expect IT professionals to be familiar with a long string of technologies.
The trick, I find, is to understand that people can gain that experience in a variety of different ways, and not to expect people who have that kind of experience to have written books on the subject. Those lists of technologies indicate the need for a generalist, rather than a specialist. And that's where the miscommunication usually occurs. Those IT managers aren't seeking for a specialist in each of those technologies. Rather, they're describing their environment, and saying 'we need somebody who can function in this environment with these technologies'.
- First, if photographic memory exists, does videographic or holographic memory exist?
- Second, is memory and recall the same thing?
My take on memory is that photographic memory does, in fact, exist. But photographic memory isn't what most people think it is. In fact, it's only one half of the process. The other half is recall. Just because a person might have a Photographic Memory, doesn't mean that they have Instant Recall or Total Recall. Conversely, a person with Instant Recall may have a regular memory, and have to study hard to remember something.
Examples to consider:
- people with photographic memory, but not instant or total recall, are likely to become photographers
- people with videographic memory, but not instant or total recall, are likely to become videographers
- people with instant recall are likely to win at Jeopardy contests
- people with photographic memory and total recall are the rainmen card-counting types
Anyhow, I'm in the camp that believes that photographic, videographic, and holographic memories exist, as well as total and instant recall. They're all slightly different traits or configurations that a brain can have. But they're not all benefitial in the way people think they would be. More often than not, people get lost and deluged by the details, since they can't filter out the unimportant stuff.
ps. I've a semi-active user of Memory Palaces myself, and use it to do things like memorize everybody's name in my workplace, and similar things.
Ditching experience would be unheard of in medicine, engineering, law, carpentry, pluming, construction, etc, etc, etc....
But only us have the balls to say that youth trumps experience, I wasn't aware kids were born with all computer science concepts from the get go.
I have a theory about this, actually. The idea is that two forces are at work creating this thinking in the tech industry: first, the home computer paradigm shift, and second, globalization. Of the two, it's the home computer paradigm shift probably caused the greater havoc, and the one I'll talk about in this post; in that it created a bubble of sorts, where kids at home were, for the first time, getting as much exposure and access to compupters as students in college were getting. This created a situation where a person just going into college might already have 5 or 10 years of computing and programming experience, whereas somebody just graduating might only have 3 or 4 years. Hence a pressure by the tech industry to not find younger employees, per se; but to find employees who had the most amount of computing exposure and experience, prior to joining the workforce. As an employer, would you rather have an employee with 0 years of work experience, and 4 years of college computing experience? Or an employee with 0 years of work experience, and 14 years of home computing experience.
My family was early on the home-computing bandwagon, and we had a good ol Apple IIc, back in 1984, or there abouts. I was 6 years old. By the time I got to college, I had 10 years of programming experience (albeit, in BASIC, Logo, and AppleScript). When I got out of college, when compared to university graduates who were just graduating, and hadn't grown up with a computer, I had an extra decade of experience compared to them.
However, both the home-computing paradigm and globalization are both bubbles. Once everybody is being raised from pre-school and kindergarten with access to a computer, then the relative advantage no longer applies. Being a GenyYer, and having had access to computers since kindergarten, I'll always have an extra decade of experience relatively to GenXers who learned programming at college. But Millennials won't be able to claim that kind of competitive advantage against myself and other GenYers. At best, they can compete at parity; but they can't claim extra years of experience, compared to their predecesors, that my generation can.
Of course, when the Neural Generation comes around, with their fancy neural implants and all, my generation will get a taste of that medicine. But until then, I suspecct things are going to stabalize a bit within the tech industry.
I thought you were arguing against racial taxonomies in general. But it seems that we're in agreement that it's just the hierarchical phylogenetic taxonomies that don't work.
Here's the problem. If you can't order every single human into one race or another, your model is flawed. If you're forced to resort to mixes of races, well, then you don't have any distinct race left.
Race concepts fall apart once actual taxonomic principles are applied to them.
Sort of. In a traditional hierarchical phylogenetic taxonomy, yes, race concepts fall apart. But if they don't necessarily fall apart with a cladistic genetic taxonomy.
Defining race is a classic problem of, well, classification. Put another way, it's like organizing books. Where do you place 'War and Peace'? In the fiction section? In the history section? In the classics section? In the russian literature section? It could legitimately be placed in any of those sections. The problem is that the book has a single physical instance. The book only exists in one place at one time. So, it can only be placed in one category at a time. And this is the problem with any phylogenetic based hierarchical taxonomy. It's not unique to race; it also applies to species, books, weblinks, and any other number of objects. It's why, before search engines, we had all these portal sites, like Yahoo!, who were focused on creating giant taxonomies of weblinks. And it was always a pain, because we had this intuition that a weblink should only exist in a single category at a time. This was a hold-over from library systems, where any particular book can only be placed on a single shelf at a time.
But then we discovered tagging. With tagging, a new type of taxonomy is possible, where a single entity can be placed in multiple categories at a time. And it turns out that tagging is equivalent to a genetic taxonomy. Each tag is equivalent to a gene (or meme, to be more precise). And we now give webpages lists of keywords, which function like a genome of sorts.
So, you're correct that race concepts fall apart at a hierarchical, phylogenetic based taxonomy. But with a genetic based taxonomy, race is 'tagged' by combination of genes... melanin count, lactose sensitivity, sickle-cell anemia, etc.
And what's more, this tagging and clustering, is a precursor to speciation. Consider the following simplified hypothetical example: a) mutant gene (A) interacts with the gene for lactose sensitivity such that, together, they cause a change in sperm mobility due to a lack of calcium, and b) another mutant gene (B) interacts with the gene for sickle-cell anemia such that, together, they cause a change in permeability to an egg due to lack of iron. If these two things were to hypothetically occur, it would make for a situation where sperm and egg couldn't unite, and a lactose intolerant father and sickle-cell anemic mother couldn't have children. Now then, one more consideration: say that these two mutant genes were actually very advantageous. Mutant gene A protects against flu and pnemonia, and mutant gene B codes for sexy pheremones. If these mutant genes are advantageous, then they'll spread throughout the population. But as the mutant genes spread through the population, the carriers of those genes, who also carry the genese for lactose intolerance and/or sickle cell anemia, would lose the ability to breed together. And this would be defined as a speciation event. Not only would those people be of different races, they would be unable to breed together, and would be different species.
Anyhow, it's worse than people fear. Not only does race actually exist, it's a precursor to speciation. Race just doesn't fit neatly into hierarchical phylogenetic taxonomies. Genetic taxonomies allow for overlapping, fuzzy boundaries. And that's exactly what Race is. Race doesn't fit into neat little hierarchical tree structures; rather, it's a fuzzy network of genes.
Slashdot Mirror
Now this I can agree with. User validation doesn't cut it. It's going to take a company with Apple like design skills and resources to show people what's possible. To say 'this is what you've always wanted, but just didn't know how to build'. That company hasn't come along yet. But when they do, they'll offer solutions to problems that people didn't know they had. And by that, I mean addressing things like how to visualize and interact with ontologies of 50,000+ choices in an intuitive manner. (My guess is mapping and cartography technologies, applied to human atlas/avatar; bundled with search and filtering technologies). People think that their problems are with 'user interfaces' and 'electronic medical records'; when, in hind sight, we'll say that the problems were with ontology mappings, taxonomy searches, medical renderings, longitudinal displays, and the like.
And you're totally right about the small frys on the other end of the spectrum. They're causing half the headaches, no doubt.
It's been about that long since I've worked with EPIC; more recently with Cerner. Nonetheless, I think we have substantially different expectations of what an EMR can and should be. Note that, by your own words, you admit that the UI of EPIC is as good and simple as the people who build it for the hospital want it to be. Not the people who work at the hospital want it to be. It seems to me that the EPIC UI is as good as the people who work at the hospitals will tolerate. The people at the hospital would prefer to have some Star Trek type EMR with tricorders and automated diagnostics. EPIC and Cerner are not that.
I have yet to see a modern EMR come bundled with an anatomical Atlas of the human body, which coregisters a patients scans, blood work, and medical history with a virtual avatar. Until we get to that point, all EMRs and PHRs are lacking and have shoddy interfaces. Google was half way there with Google Body, but they've since scrapped their Google Health product. That's a long story unto itself, involving having their XML expert design the health product, and not understanding their target market needs. But they recognized the need for the atlas to coregister data to, and that it will eventually be a primary interface to EMR and PHRs.
Not being able to add employees fast enough isn't necessarily a sign of a good system.
The story goes that Milton Friedman was once taken to see a massive government project somewhere in Asia. Thousands of workers using shovels were building a canal. Friedman was puzzled. Why weren't there any excavators or any mechanized earth-moving equipment? A government official explained that using shovels created more jobs. Friedman's response: "Then why not use spoons instead of shovels?"
The point being that adding laborers doesn't translate into a better product. In fact, not being able to add employees fast enough and turning away clients seems like a clear sign of scaling problems, training problems, and user interface problems. And just because they're first in the KLAS rankings doesn't mean that they're any good at improving patient health.
Now that's not to say that they fill their role as hospital practice management systems. But the fact of the matter is that hospitals are big money, and attract their own types of politics and special interests. And these KLAS rankings are about just that: politics, special interests, funding, sales, and so forth. Hospitals need practice management systems, and they need a way to evaluate different systems, and Cerner and Epic have put the most work into being on the top of the pile right now. But their systems are horribly designed.
And don't get me started on Cache. It's only redeeming quality is that it's not a relational database. But seriously? MUMPS? You're saying that we should continue deploying health care systems based off MUMPS? I'm sorry, but we've learned a few things in the past 40 years since M/MUMPS was originally created. Now then, I'll concede that object and document oriented databases are the way to go with regards to databases in healthcare. And in that regard, systems based off of Cache at least have that going right for them, and is why they've got the market share. But mark my words: a vendor is going to come along with a modern HTML5 product based off of a next-generation database, and it's going to be transformative. I don't know what that database will be... Cassandra, Hadoop, BigTable, Redis, or what. But when it finally happens, it's going to be the Facebook and Google of healthcare.
50K to 100K works out to be about one support personnel per physician. That sounds about right; particularly if that physician wants somebody they can call 24/7 for support.
Another thing to keep in mind is that healthcare is practiced differently in different states, due to state laws. Not to mention different regional needs. For example, a clinic in the far north needs to offer more services related to frostbite and hyopthermia than a clinic in the south, and may price things differently as such. Therefore, their billing and clinical systems need to be set up differently.
Having supported said systems, I'd say that Cerner and EPIC are lost causes as well. Too much attempted data-modeling in the database layers are causing their database schemas to melt-down and implode. As companies, they're likely to survive through mergers and acquisitions; but their current product lines should be put out to pasture as soon as possible.
Having been an Oracle Database Admin in the healthcare sector, I'm not encouraged by the database implementations either. The bottom line is that company after company gets started developing a EMR/EHR related product, and seems to think that it's a good idea to start data-modeling within the database layer. Everybody else is smoking crack, so apparently they should too.
I'm a little more lenient about the tendency to reboot to fix problems, because it's actually pretty good ergonomics and workflow. Particularly in a high-stress, mission-critical environment. When someone is crashing (ie. having a heart attack), the quick-fix to get a workstation back on line needs to be as simple as rebooting. But if you're going to follow that path, the logging has to be spot-on so that analysts can go back after-the-fact.
Probably has a lot more to do with your implementation and how your hospital culture values it's tech support staff than the Centricity product itself. Most PACS systems can integrate just fine if you put the time and effort and resources into doing so (meaning paying the salary necessary to have a properly staffed support team; meaning spending $500K per year in on-site support costs for a 150,000 patient/yr hospital or clinic system). Not going to argue about click count, because that's simply lousy software design. But your attitude about delegating speaks volumes about why the implementation is considered a failure at your location.
Mod parent up Informative and Insightful. Particularly the newer PACS systems like Amicas and Merge. They all play nicely with DHCP and LDAP nowdays.
Actually, the employment market for PACS engineers is bottoming out, since HITECH and PPACA.
Long story short, it used to be a specialized niche industry, and now everybody is swarming into the market because it's perceived to be where the money is. If a hospital is willing to pay top money for somebody with 5 to 10 years of experience, then yes, there are a couple engineers out there who stand to make some good money. But why hire somebody with 10 years of experience, when there are plenty of new kids on the block with 2 years experience that they can hire at half the price? Also, in the healthcare field, it's not so much about how much you know about the tech. What's more important, in the eyes of the hospitals, is call rotation, and whether somebody is green and naive enough to sign up to 24/7 call support for two weeks per month.
I was making good money as a PACS Administrator (albeit with long hours) before health care reform. Since then, I've had to move to the vendor side as a Software Architect, since the market is now swamped with entry level PACS engineers.
What evidence suggests that industrialized nations would be the most affected? Viruses and bacteria don't care what kind of technology or manufacturing base a nation has. From an epidemiology perspective, the only thing that matters is population density and proximity to others.
While not authoritative, the standard way to author SVG animations with HTML seems to trending towards a Javascript/jQuery solution. Raphael & Mashi is generally what you're looking for; although it lacks a IDE still.
http://raphaeljs.com/
http://mashi.tv/
They can never give roads or bridges? I didn't know I already had roads or bridges.
You're making an assumption here that efficiency of flow is the highest value. To use the food analogy, distribution of food can be modeled as a flow. The most efficient flow, as you would have it, would include selling food without nutrition labels, pasteurization, preservatives, etc. The most efficient thing would be to just sell everything as-is, without regulations, and let the consumers sort it all out themselves, as they figure out which people get sick and/or die from which farms and grocery stores. But we don't do that, because efficiency of flow is less valuable than preservation of human life. To that extent, we *want* the kinks and bumps to introduce eddies. It is better to have turbulent flow than laminar flow when the flow results in sickness and death.
To quote Bill Gates, and bring things back round-circle: "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." Laminar flow may be the optimal form of flow. But if the flow itself is harmful to begin with, then laminar flow merely magnifies the harm. If the system is rigged to drain money from the middle class and deposit it to the covers of rober-barons and plutocrats, then laminar flow merely makes it that much worse.
Ayn Rand actually talks about this a lot. She's not particularly forgiving, and describes them as leeches and parasites.
It's funny, because most conservatives, Randians, and Objectivists use her writings to argue against socialized services and equate the working poor and middle class as being the leeches and parasites to the rich. A close reading of Atlas Shrugged, however, and one comes to realize that she's talking about crony-capitalists, casino-bankers, and rober-barons as the leeches and parasites of society as much as anybody else. She talks often about brokers, agents, account managers, bankers, auditors, and the like as being the very people who suck money out of the system and are the leeches and parasites to the job producers.
Remember that she grow up in the USSR, that was really against centralized monetary planning. Crony-capitalism and casino-banking are just another form of centralized monetary planning; no better than the communist leaders with their 5 year plans. Same behavior, different environment.
Indeed. I was going to mention that 'hack' has two or three definitions now days, but upon looking at dictionary.com, it appears there are *twenty three* known uses of the word! And another 15 if you consider the definitions of 'hack' that are derived from 'hackney', and yet another 6 if you consider the definitions of 'hack' that are derived from 'hatch'. With 40 variations of 'hack' currently in use, I think the English language will survive if we add one more, related to 'cracking'.
.
7a. Computers . to devise or modify (a computer program), usually skillfully.
7b. Computers . to break into, illegally
http://dictionary.reference.com/browse/hack
–verb (used with object)
1. to cut, notch, slice, chop, or sever (something) with or as with heavy, irregular blows (often followed by up or down ): to hack meat; to hack down trees.
2. to break up the surface of (the ground).
3. to clear (a road, path, etc.) by cutting away vines, trees, brush, or the like: They hacked a trail through the jungle.
4. to damage or injure by crude, harsh, or insensitive treatment; mutilate; mangle: The editor hacked the story to bits.
5. to reduce or cut ruthlessly; trim: The Senate hacked the budget severely before returning it to the house.
6. Slang . to deal or cope with; handle: He can't hack all this commuting.
7. Computers . to devise or modify (a computer program), usually skillfully.
8. Basketball . to strike the arm of (an opposing ball handler): He got a penalty for hacking the shooter.
9. British . to kick or kick at the shins of (an opposing player) in Rugby football.
10. South Midland and Southern U.S. to embarrass, annoy, or disconcert.
–verb (used without object)
11. to make rough cuts or notches; deal cutting blows.
12. to cough harshly, usually in short and repeated spasms.
13. Tennis
a. to take a poor, ineffective, or awkward swing at the ball.
b. to play tennis at a mediocre level.
14. British . to kick or kick at an opponent's shins in Rugby football.
–noun
15. a cut, gash, or notch.
16. a tool, as an ax, hoe, or pick, for hacking.
17. an act or instance of hacking; a cutting blow.
18. a short, rasping dry cough.
19. a hesitation in speech.
20. Curling . an indentation made in the ice at the foot score, for supporting the foot in delivering the stone.
21. British . a gash in the skin produced by a kick, as in Rugby football.
—Verb phrase
22. hack around, Slang . to pass the time idly; indulge in idle talk.
—Idiom
23. hack it, Slang . to handle or cope with a situation or an assignment adequately and calmly: The new recruit just can't hack it.
It really depends on that the process is for. As a change control system, meant to minimize the introduction of new and unknown quality control issues into the field, it's doing a pretty good job. Admittedly, as a system to get the latest bleeding-edge software configuration to market, it's pretty lousy.
That being said, the conversion from english to metric is a good analogy. In both systems, codes can be added and removed, without requiring certification. It's the hardcoded application stuff, related to the code formats, code versions, and code relationships, that require recertification.
Unfortunately, the old ICD9 is considered broken, so it's not suitable for supersetting. As an example, say that the skull is considered part of the head in ICD9, but the skull is considered part of the skeleton in ICD10. The code for skull has moved from 'head' to 'skeleton'. How do you superset that kind of relationship change? Worse, what if the original ICD9 relationship is considered no longer scientifically valid? What if a disease of an organ is reclassified to be a disease of blood? Or of the nervous system? Supersetting wouldn't fix those broken relationships.
Yes, that's the easy and obvious part. Keeping both versions of the ICD9 code sets around is standard practice. The hard part involves the people and training issues related to phasing out legacy applications which are hard-coded to reference the old ICD9 codes.
It's not just that a bunch of codes have been added or removed. The relationships between the codes have changed as well. What used to be a single code in ICD9 may have been replaced with a list of codes in ICD10 (or, worse, a tree structure of codes); and conversely, what used to be a dozen codes in ICD9 might have been replaced with a single code. The disjoint mapping of codes and their relationships is what's really gumming up the works.
the system should be flexible enough for the codes to change.
Hehe... another person who doesn't work in the medical IT field, eh? If only. Ever heard of the Food and Drug Administration? They have this thing called 'FDA Approval' for software products. The change in format structure from ICD9 to ICD10 generally requires all the vendors of these systems to re-certify.
While these systems *should* be flexible enough to handle the code format changes, most of them aren't, due to federal certification and litigation reasons. The medical community would rather have a buggy system that's well documented and that they can create known work-arounds, than a flexible and adaptable system, with frequent updates, that could inadvertently introduce an undocumented error. In the medical field, '2 steps forward and 1 step back' doesn't cut it. So they require certification to prevent sliding back that one step, even if it prevents them moving forward 2 steps.
I disagree. The requirements for "PHP, RoR, Python, MySQL, Oracle, Apache, Cisco, JavaScript, jQuery, UI/UX, Photoshop, and Flash" is pretty reasonable. It simply describes a Joomla CMS installation with an incoming feed from an Oracle database somewhere, with a one-off Ruby site somewhere. It's actually almost exactly what we have where I work, and I expect all of my hires to be able to work with those technologies.
To use the car analogy, it would be like posting an auto mechanic position that specifies, "must have real experience with Breaks, Transmission, Steering, Engines, Air Filters, Air Conditioning, Fuel Filters, Suspension, Radiators, Stereos, and Upholstery." It would be reasonable to expect an auto mechanic to be familiar with all of those systems. Similarly, it's reasonable to expect IT professionals to be familiar with a long string of technologies.
The trick, I find, is to understand that people can gain that experience in a variety of different ways, and not to expect people who have that kind of experience to have written books on the subject. Those lists of technologies indicate the need for a generalist, rather than a specialist. And that's where the miscommunication usually occurs. Those IT managers aren't seeking for a specialist in each of those technologies. Rather, they're describing their environment, and saying 'we need somebody who can function in this environment with these technologies'.
So, a couple considerations:
- First, if photographic memory exists, does videographic or holographic memory exist?
- Second, is memory and recall the same thing?
My take on memory is that photographic memory does, in fact, exist. But photographic memory isn't what most people think it is. In fact, it's only one half of the process. The other half is recall. Just because a person might have a Photographic Memory, doesn't mean that they have Instant Recall or Total Recall. Conversely, a person with Instant Recall may have a regular memory, and have to study hard to remember something.
Examples to consider:
- people with photographic memory, but not instant or total recall, are likely to become photographers
- people with videographic memory, but not instant or total recall, are likely to become videographers
- people with instant recall are likely to win at Jeopardy contests
- people with photographic memory and total recall are the rainmen card-counting types
Anyhow, I'm in the camp that believes that photographic, videographic, and holographic memories exist, as well as total and instant recall. They're all slightly different traits or configurations that a brain can have. But they're not all benefitial in the way people think they would be. More often than not, people get lost and deluged by the details, since they can't filter out the unimportant stuff.
ps. I've a semi-active user of Memory Palaces myself, and use it to do things like memorize everybody's name in my workplace, and similar things.
Ditching experience would be unheard of in medicine, engineering, law, carpentry, pluming, construction, etc, etc, etc....
But only us have the balls to say that youth trumps experience, I wasn't aware kids were born with all computer science concepts from the get go.
I have a theory about this, actually. The idea is that two forces are at work creating this thinking in the tech industry: first, the home computer paradigm shift, and second, globalization. Of the two, it's the home computer paradigm shift probably caused the greater havoc, and the one I'll talk about in this post; in that it created a bubble of sorts, where kids at home were, for the first time, getting as much exposure and access to compupters as students in college were getting. This created a situation where a person just going into college might already have 5 or 10 years of computing and programming experience, whereas somebody just graduating might only have 3 or 4 years. Hence a pressure by the tech industry to not find younger employees, per se; but to find employees who had the most amount of computing exposure and experience, prior to joining the workforce. As an employer, would you rather have an employee with 0 years of work experience, and 4 years of college computing experience? Or an employee with 0 years of work experience, and 14 years of home computing experience.
My family was early on the home-computing bandwagon, and we had a good ol Apple IIc, back in 1984, or there abouts. I was 6 years old. By the time I got to college, I had 10 years of programming experience (albeit, in BASIC, Logo, and AppleScript). When I got out of college, when compared to university graduates who were just graduating, and hadn't grown up with a computer, I had an extra decade of experience compared to them.
However, both the home-computing paradigm and globalization are both bubbles. Once everybody is being raised from pre-school and kindergarten with access to a computer, then the relative advantage no longer applies. Being a GenyYer, and having had access to computers since kindergarten, I'll always have an extra decade of experience relatively to GenXers who learned programming at college. But Millennials won't be able to claim that kind of competitive advantage against myself and other GenYers. At best, they can compete at parity; but they can't claim extra years of experience, compared to their predecesors, that my generation can.
Of course, when the Neural Generation comes around, with their fancy neural implants and all, my generation will get a taste of that medicine. But until then, I suspecct things are going to stabalize a bit within the tech industry.
Ah, yeah. I'd agree with that. :)
I thought you were arguing against racial taxonomies in general. But it seems that we're in agreement that it's just the hierarchical phylogenetic taxonomies that don't work.
Here's the problem. If you can't order every single human into one race or another, your model is flawed. If you're forced to resort to mixes of races, well, then you don't have any distinct race left.
Race concepts fall apart once actual taxonomic principles are applied to them.
Sort of. In a traditional hierarchical phylogenetic taxonomy, yes, race concepts fall apart. But if they don't necessarily fall apart with a cladistic genetic taxonomy.
Defining race is a classic problem of, well, classification. Put another way, it's like organizing books. Where do you place 'War and Peace'? In the fiction section? In the history section? In the classics section? In the russian literature section? It could legitimately be placed in any of those sections. The problem is that the book has a single physical instance. The book only exists in one place at one time. So, it can only be placed in one category at a time. And this is the problem with any phylogenetic based hierarchical taxonomy. It's not unique to race; it also applies to species, books, weblinks, and any other number of objects. It's why, before search engines, we had all these portal sites, like Yahoo!, who were focused on creating giant taxonomies of weblinks. And it was always a pain, because we had this intuition that a weblink should only exist in a single category at a time. This was a hold-over from library systems, where any particular book can only be placed on a single shelf at a time.
But then we discovered tagging. With tagging, a new type of taxonomy is possible, where a single entity can be placed in multiple categories at a time. And it turns out that tagging is equivalent to a genetic taxonomy. Each tag is equivalent to a gene (or meme, to be more precise). And we now give webpages lists of keywords, which function like a genome of sorts.
So, you're correct that race concepts fall apart at a hierarchical, phylogenetic based taxonomy. But with a genetic based taxonomy, race is 'tagged' by combination of genes... melanin count, lactose sensitivity, sickle-cell anemia, etc.
And what's more, this tagging and clustering, is a precursor to speciation. Consider the following simplified hypothetical example: a) mutant gene (A) interacts with the gene for lactose sensitivity such that, together, they cause a change in sperm mobility due to a lack of calcium, and b) another mutant gene (B) interacts with the gene for sickle-cell anemia such that, together, they cause a change in permeability to an egg due to lack of iron. If these two things were to hypothetically occur, it would make for a situation where sperm and egg couldn't unite, and a lactose intolerant father and sickle-cell anemic mother couldn't have children. Now then, one more consideration: say that these two mutant genes were actually very advantageous. Mutant gene A protects against flu and pnemonia, and mutant gene B codes for sexy pheremones. If these mutant genes are advantageous, then they'll spread throughout the population. But as the mutant genes spread through the population, the carriers of those genes, who also carry the genese for lactose intolerance and/or sickle cell anemia, would lose the ability to breed together. And this would be defined as a speciation event. Not only would those people be of different races, they would be unable to breed together, and would be different species.
Anyhow, it's worse than people fear. Not only does race actually exist, it's a precursor to speciation. Race just doesn't fit neatly into hierarchical phylogenetic taxonomies. Genetic taxonomies allow for overlapping, fuzzy boundaries. And that's exactly what Race is. Race doesn't fit into neat little hierarchical tree structures; rather, it's a fuzzy network of genes.