Agreed. Twitter is taking a strong stance against censorship today and providing a checks-and-balances approach to censorship. They are containing censorship, rather than allowing global blackouts. They're actively tracking censorship and then routing around it. There is wide spread misunderstanding here.

Mod parent up! Twitter is making lemonade from lemons here.

Mod parent up! Cultural relativism is a fact. International groups can claim that human rights like free speech are universally applicable, but an Ebola outbreak, zombie apocalypse, nuclear holocaust, or a planet smashing comet is all that it will take to send us back to feudalism and might-makes-right morality. We may advocate for treating free speech as a universal right; but as long as other nations have the might to protect their borders and claim their own sovereignty, they can make their own laws. Including ones that involving censorship. The claiming that a free speech is universal is, itself, a morally and culturally relative act.

Mod parent up! This is a strong move *against* global censorship on Twitter's part; while at the same time respecting local laws and tracking censorship activities. They've made lemonade from lemons.

Mod parent up!

I'm sure Adam Bosworth is a nice guy and all, and is a very competent developer. But from what I understand, his claim to fame is being one of the pioneers of XML. That's nice and all; and from a storage perspective, it gives a company an approach to handling many different types of data. But from a clinical usability perspective, Bosworth and team simply didn't understand the needs of the patients or the marketplace. The UI of Google Health was, if possible, even worse than that of Centricity and Cerner. They simply had no idea what the UI challenges are of patient medical records; nor of the use cases and workflows between clinicians and patients.

The OSI 7 Layer Networking Model is very informative in this kind of product. Google Health was basically just a database layer technology. It had no presentation or application layer functionality. And a health record will live and die by it's presentation and application layers, because that's the UI by which the patient will interact with it.

Call 911, and ask that they send police to the location immediately. Report that you suspect a person or a group of people impersonating the TSA, and that you suspect a fraud or mugging is about to occur.

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.