A Note From An Interaction Designer

On occasion, someone actually believes me to be wise in matters pertaining to PACS. It's amazing how far you can get on self-promotion.

Anyway, I've been working with several companies on their PACS designs, taking great care to avoid any cross-talk. Today, I received the email below from one company:

A request for your thoughts. . . You're unique in that you have notoriety in the medical imaging world, and actually have advocated for the need for interaction design. . . .

I am the interaction designer who works on user research and interaction design; as well as working with programmers to actually try to get the designs built. My goal is to make physicians happy and fully engaged in their software, or at least get rid of some of the "grr" :)

The questions I have for you:

1) How much of what you (or the average "Joe" rad persona) cares about in a PACS system is in the interaction design (behavior/workflow) and visual design?

2) Do you think other vendors have picked up on having dedicated interaction designers? I wonder what our best competitors are doing. If they don't call it interaction design, do they have people continually focusing on users and the user interface, planing the workflow of a user through the interface toward his goals rather than on how to architect-build-code-program the user interface?

3) How effective are seeing designs in giving you a sense of the final user experience (and workflow)? The intention of the this early review is always deeper understanding to fix on an initial plan of what to build (a design); that design is then built in software and can be tested out by rads hands-on. Having users try out an iPod is the best way to make alterations to the iPod experience, but you need to design an iPod in the first place, and not a Zune or worse a Sandisk player (I hate the Sandisk, the buttons change meaning on each level of navigation argh! Impossible to use, a pure waste of $45).

Wow. I have notoriety! Is that sort of like credibility? Oh well....

If you have a look at my old post, The Inmates Are Running The Asylum, you will see more or less where I'm coming from. Alan Cooper, of Cooper Designs, promotes the concept of software tailored for the user, and not simply cobbled together by the coders/programmers, the "inmates of the asylum".

Cooper designs interactive products that deliver power and pleasure to the people who use them. Our design methodology is founded on the observation that people will gladly use and recommend products that are designed to advance their goals, while they dislike products that merely satisfy feature checklists or are informed solely by abstract notions of simplicity.

Cooper’s Goal-Directed design methodology places the goals of the user at the center of the design process. Rather than focusing exclusively on underlying technologies or the tasks that users must perform to use their current products, our process identifies what it is that users want to accomplish in the first place and results in designs that satisfy those goals.

Thoroughly understanding the environments in which people use products, and determining the goals they expect to accomplish, yields designs that deliver a satisfying customer experience. Goal-Directed design delivers power to users without intimidating them and guards against the development of products that lack features and affordances essential to the satisfaction of users. Conversely, Goal-Directed design also prevents the addition of features that, however clever, are rarely used or irrelevant to core goals of the product users

There is a major PACS product that was revamped with the help of Cooper Design. Sadly, no one appears to have actually listened to Cooper's advice that must have cost them hundreds of thousands, if not millions to obtain. The result of the interaction was a "prettier" product which was far more esoteric and harder to use than its predecessor.

But let me answer the questions. First, how much of what I care about in a PACS is in the interaction, etc.? Are you kidding me? Is this a trick question? You could say that the images are the most important thing, and of course, that is the purpose of the PACS, to show me those images. Every single PACS out there, from the very worst to the very best, from free open-source software to the most expensive gold-plated diamond-encrusted magnum opus extravaganza will do that. The ONLY differentiating feature IS the interaction design! I guess this is one of those universal truths that is so very fundamental that it is not as obvious as it should be.

What makes one PACS easy to use and another difficult? It is the consideration of the user's needs, the interaction design as Cooper calls it, and perhaps to a bit lesser degree the visual design, the skin if you will. The designer (in general, this should NOT be the same guy that writes the code, although I know a few folks in the business that excel at both) needs to see how the radiologist will use the program, and make that interaction smooth and easy. I have said in numerous posts that the PACS shouldn't get in my way, and that is perhaps the simplest explanation of how to design it. This doesn't just happen; the program has to be written such that the images are easily available, and amenable to whatever manipulation is needed for their interpretation. Like a fine automobile connects you to the road, PACS connects you to the images. When driving, your focus should be on the road, and the car should allow you to make that connection without demanding so much of your attention that you become dangerous. When reading imaging studies, PACS should let you focus on the patient, without superflous controls or buttons, or sliders, or tabs, or whatever. Distracting me from the images can be rather dangerous to the patient, and profitable for the litigators.

In essence, PACS IS the workflow, it IS the interaction. I care about this. A lot.

Have other vendors figured this out? Yes, to varying extents. No one seems to call it interaction design, but then Cooper's influence may not be all that wide-spread. But those systems that have won my admiration definately zero-in on my interface goals. Do they have people that focus on users and interfaces? Yes, they do. Some of them do the coding, some don't, but all of them understand that the damn thing is being written to facilitate radiologists interpreting images. Such a simple concept.

The design reviews referred to above certainly do help. Like my friend's example of the iPod vs. the Sandisk player, having a functioning framework for testing is certainly one of the best ways to see what works and what doesn't. I can't really think of a better way to do this. You have to see how your model performs in the hands of the users doing with it what they do every day. A focus-group or questionnaire won't get you very far in the real world.

It's sort of ironic that my friend hates his Sandisk because the buttons change meaning on each level of navigation. Kind of like screens toggling in a state-dependent manner isn't it? Arrrggghhh is right!

I don't have a handle on what the rest of the radiologists in the world think about the various interface issues, but I know what works for me. I have said a number of times that Amicas has come close to figuring this out, and they have done so by listening to their users, perhaps more than many other companies. Creating a great PACS is simple if you follow this simple recipe. Lots of happiness, little "grrrrrr".

How much of what I care about in a PACS system is in the interaction design (behavior/workflow) and visual design? A heck of a lot. But then I've been saying that for a long time, in my quest for notoriety.

Questions From ANOTHER Interaction Designer

Another anonymous PACS designer chimes in:

I'm an interaction designer/programmer as well. And I find Cooper & Reimann's book Interaction Design 2.0 to be useful in educating programmers about generic user expectations and behavior. It also introduces some important concepts which we use in our design guidance documents.

As much as I agree about the importance of good interaction design, market forces are such that what people pay for (from among what is offered) is what the market will provide more of. So I have some questions related to that.

1) When purchasing a PACS, how do radiologists evaluate the software interaction? To what extent are they willing to try out unfamiliar(but possibly better) interaction models, and how much time are they willing to give to that process?

2) Does anyone evaluate the ease of use of anything besides the radiologist's workstation? If so, what?

3) How much is usability weighted in the purchase decision? And how much of a premium (in purchase price) is a superior design worth?

Very good questions, all. Here, we really get to the crux of the matter, whether a more usable product is a sales advantage, and worth more than Brand X.


Now, I can answer all of these according to my own, biased, radiologist-centric viewpoint, which might not be accurate for all involved. Based on my experience and research and observation, it is probably rare for the radiologists to actually decide which PACS to buy. As often as not, the choice lies in the hands of bean-counters, and/or the IT folks, who may or may not pay attention to the needs, wants, desires, and whines of the radiologists.


So, how do radiologists evaluate the software interaction from a 10-minute demo? Very poorly. It is impossible to see how a complex piece of software will behave in your hands in that short a time. In most cases, the sales or apps person is "driving" anyway, and we poor rads get no hands-on time at all. From this brief exposure, we are supposed to make a million-dollar decision. I have long advocated prolonged web-based demos, and I still think they represent the best approach.


When I'm looking at new software, I try to use it as if I were actually in a production environment. This isn't easy, especially in a 10-minute demo, but it can and should be done. Now, trying new processes is a problem. I, for one, am willing to do so, but some are not. If the keys to the "new process" are not immediately obvious, if it is not intuitive, it will be bypassed.


Let me go off on a tangent for a moment. I received a disk from St. Elsewhere over the weekend with a client program from a smaller PACS company. The damn thing loaded VERY slowly, and the GUI was esoteric. I was actually in the middle of writing a hatchet-piece about the program in between call cases. However, the more I worked with the viewer in the process of digging up dirt on it, the more I found it useful, or put another way, the less I hated it. Thus, unfamiliarity in this business breeds contempt. Now, this particular program will never reach the level of Dalai-usability, but it wasn't quite as bad as I first thought. There is a balance, a threshold of what works well for all immediately, and what will eventually work better than you think it will initially.


How much time will we give to checking out something new? Probably not enough. Again, we need to see quickly that your new process is better than the old way.

Hopefully, PACS admins and IT types are allowed to look at the back-end of the system as well as the front. The best GUI in the world is useless if its underpinnings don't work well. The support folks need to be checking out the administrative tools, ease of fixing studies, and ten dozen other things that I couldn't even begin to name. Yes, I do indeed acknowledge their importance!

The part usability plays in the purchase goes right back to who is really in charge. If the rads ignore the job of selection, and just depend on the proverbial "someone else" to do the picking, then it probably doesn't matter at all. The same is true if the rads are excluded from the decision altogether. (It happens, trust me.)

And it needs to be stated that usability is in the eyes (and mouse) of the beholder. One of my senior partners proclaimed for the first time yesterday that he vastly prefers Agfa Impax 6 to Amicas LightBeam. Why? Because with Impax, you can access the ruler tool via the right-click menu, and with LightBeam, you have to scoot the mouse up to the tool-bar. The other features (no matter how well or poorly done) don't matter to him one bit, at least they didn't yesterday. Now, my other 27 partners think just the opposite, but you see the dilemma. Whom should the designers target? Why me, of course!

How much is a good design worth? That's somewhat of a trick question. In the PACS business, there is a significant disconnect between price and design. I don't have to go there again, do I? Designing a program that actually works properly in the hands of real users might well cost more that just letting the engineers/designers/programmers run loose. There should be numerous iterations of redesign and retesting with real live radiologists, especially those who do not already use the company's product. That's a hard process to quantify and deciding what it's really worth is even harder.

I've been preaching about GUI design for years and years. It's nice to see the concept finally get some attention, and I really appreciate hearing from the guys on the front lines in this effort. Will their hard work pay off? It should! The better, more usable PACS should sell better than the clunker, but that may not work so well in the real world, where IT may decide to purchase from the company that "no one ever gets fired for chosing," whichever that might be this week. But keep up the good work guys; sooner or later someone WILL be fired for picking an unusable system. Someday. I promise.

The Inmates Are Running The Asylum

I have stolen my title from a book of the same name by one Alan Cooper. Mr. Cooper is Founder and Chairman of the Board of the Cooper company, which is devoted to leading-edge, customer/user oriented product and software design. From the company website:

For over 30 years Alan Cooper has been a pioneer of the modern computing era. His groundbreaking work in software invention, design and construction has influenced a generation of programmers and business people—and helped a generation of users. Alan is the author of two best-selling books, About Face: The Essentials of User Interface Design and The Inmates Are Running the Asylum, and his visionary ideas and outspoken style make him a popular speaker. Whether you know him as the "Father of Visual Basic," the inventor of personas, or the guy who thinks software should be spanked, we know him as the man whose ideas are the foundation of what we do.

Mr. Cooper has a rather radical outlook on software and indeed other high tech offerings. From his "Inmates" book:

No matter how early in the development process specifications are drafted, they cannot substitute for interaction design. And no matter how hard they try, programmers cannot consistently arrive at a successful design. Not only are their methods, training, and aptitude wrong for the job, but they are caught in a strong conflict of interest between serving the user's needs and making their programming job easier. Yet, in company after company, software engineers are allowed to control the development process, often from start to finish. Sometimes, their control is overt, but more typically it is indirect.

Hence, the inmates (the programmers...no offense!) are running the asylum. This is more or less what yours truly has been saying for a while in reference to PACS. The vendors are allowing their engineers and programmers to create technological magnum opuses which allow too many permutations, and ultimately get in the way of my reading my studies. Why is this tolerated? Cooper compares this to a dancing bear: we are all so impressed with the fact that bear is dancing at all, that we fail to observe just how badly it is choreographed.

So few software-based products have exhibited any real dancing ability that most people are honestly unaware that things could be better-a lot better. Most people using spreadsheets and word processors on modern computers imagine that all the problems that a computer can solve have been solved, and solved adequately if not well...Bill Gates once observed, with uncharacteristic cynicism, that the way you made software user friendly was by making a rubber stamp and stamping each box with the legend "USER FRIENDLY." Unintentionally, his method has become the computer industry's real method.

Mr. Cooper's premier design company will help one create a software product (or hardware, for that matter) that does not suffer from these maladies. The company motto is: "Companies are more successful when their products help users achieve their goals." Accomplishing this gargantuan task takes several steps, including Planning, Research, Modeling, Requirements, Framework, Refinement, and Support. Of these, modeling may be the most characteristic of Cooper's contributions.

Are you frustrated by trying to develop a product that serves thousands--or even millions--of different users? Imagine if instead of trying to please everyone, you could design for three distinct people you knew very well. Wouldn't that make your job easier?

This is the power of personas, a technique for modeling users that we invented here at Cooper. As we interview and observe users in their natural habitats, we look for patterns of behavior and goals shared by multiple people. Each distinct behavior pattern becomes the basis for a persona: a description of an archetypal user.

Personas help everyone from programmers to executives understand users in a way no other tool can: at a gut level. Personas help guide design decisions, end those lengthy arguments about what users need, and get everyone to agree on what product you're building.

You don't need an enormous project to enjoy the benefits of personas. For short projects, personas may just be quick sketches based on limited data. For large initiatives with distributed teams, a well-researched and thoroughly documented set of personas can be an essential reference and communication tool.

In an article about Cooper, Allison J. Head further describes this process:

The gist of Cooper's argument is fairly straightforward: There will be far greater success designing an interface that meets the goals of one specific person, instead of trying to design for the various needs of many. At first blush, though, it may seem downright counterintuitive to design for just one person, whether hypothetical or not. How can designing for a single soul possibly ensure an interface that supports the needs of many users? But as an interface becomes more layered and complex and tries to serve an ever-widening audience base, Cooper's argument holds true.

As long as personas are developed with diligence, the planning and development tool has three key benefits for interface design projects of all kinds. First, personas introduce teams to hypothetical users who have names, personal traits, and habits that in a relatively short time become believable constructs for honing design specifications. Second, personas are stand-ins with archetypal characteristics that represent a much larger group of users. Third, personas give design teams a strong sense of what users' goals are and what an interface needs to fulfill them.

She goes on to describe what may happen if programmers and designers don't user personas:

One of the best arguments for using personas comes from some misguided design efforts at Microsoft. When the software giant geared up to redesign its well-known Microsoft Office Suite for a 1997 release, the research team soon discovered that many of the features users wanted already existed. In fact, four out of five of the features users requested for Office 97 came with Office 95. The outcome of Microsoft's design approach is just what Cooper warns against. In trying to support the diverse tasks of many conceivably different software users, Microsoft cobbled together a product that was bloated with capabilities and ended up satisfying few users.

I think most would agree. I am reminded of some PACS systems I have used....

Anyway, how might this approach be used to create a PACS? Can we assemble a "Joe Radiologist" persona that would cover most radiologists? Well, let's see.... What do radiologists do all day with respect to PACS? We sit in front of the darn things and read studies. That pretty much is all we do, except for the interventional types and the barium-slingers. The real question is how Joe Radiologist wants to interface with his PACS. That is indeed the question. If I were taking this approach, I would talk with all of my partners, and ask them what they like and what they don't like about the PACS systems we already use. In fact, I would post the question here on the blog, and open it up to as many rads as possible. I would then synthesize and distill this wide pool of answers down to a usable persona.

The key to this process is, I believe, to drop all preconceived notions, but not to forget lessons learned. If you are going to build a PACS (or a car, or a toilet-paper holder) you would like to make it usable, and comfortable. There should be adequate features to cover at least 95% of situations that will arise (easy with toilet-paper holders, harder with cars, easier than some think with PACS.) Many products out there are obsessed with how to handle something that Joe Radiologist might have to do once a week, or once a month, and pay little attention to the repetitive grind that makes up 95% of our work. And many vendors are stuck in the rut of doing things the same way, version after version. Therefore, it is critical to see how a wide swath of your potential customers would use your product, and it is very important to understand how they work with your competitors' versions of the same thing. When Saab designs a new car, for example, it is probably wise to determine if the 99% of the world that buys cars other than Saab's would appreciate having the ignition key on the center console, which is where Saab (and no one else) puts it. If you are a PACS company, it is probably not terribly wise to gear your Joe Radiologist persona to those who are mostly users of your PACS, and then proceed to come up with the next generation of a PACS with its ignition key on the center console. I should also add that real radiologists need to be reintroduced to the process; don't go with the stereotyped "Joe" for a prolonged period without a reality-check from the flesh-and-blood version. Trust me, if these caveats to the Cooper approach are discarded, the result will not be what "Joe Radiologist" wants at all.

One of my partners told me in all seriousness that I should create my own PACS system. I wish I had the time and the wherewithall to do so. Of course, out of vanity, my persona would be used instead of "Joe's" which would naturally yield the most wonderful system ever. Absolutely. Guaranteed.

Lingering Frustration And Bad Design

Mrs. Dalai loves HGTV, and so I end up watching it quite a bit. I think I've even become somewhat of a house connoisseur after all this time.

So let's look at a house, pictured above. Wouldn't you love to live in this house? It's a great house! 4 bedrooms, 3 bathrooms, gourmet kitchen with granite countertops, stainless steel appliances, the whole nine yards! The house contains every gadget you could possibly want.

But there's a problem. The house was designed by someone who lives in a cave and doesn't drive a car. It is part of, well, a rental community, owned by an absentee landlord who will never set foot in the neighborhood, living in a corner office suite in some skyscraper somewhere. Can you see what's wrong? Hopefully, you did before you moved in. Because once you're in, it's too late.

My metaphor might be a bit stretched, but I think it is clear nonetheless. It is all too easy to design something wrong when you don't know anything about those who will use your product, and when the end-users aren't even the targets of your sales pitch.

So it is with PACS and EMR's, and so I've been saying here and elsewhere for a very long time. But it seems that with the greater penetration (government-mandated or not) of EMR's has come a deeper understanding and acknowledgement of just how flawed they are from the user's standpoint, the only one that counts.

This graphic from Gomerblog nicely outlines the problem:

And I will shout about the problem as loudly as I can:

THE PEOPLE THAT CREATE THESE PRODUCTS AND THE PEOPLE THAT BUY THESE PRODUCTS ARE NOT THE PEOPLE THAT USE THEM!!!

Moreover, there seems to be very little interest in correcting this.

But wait, the world is beginning to feel our pain, and attention is coming from a very unlikely source: the government! Read this article, "Frustrations linger around electronic health records and user-centered design" in Healthcare IT News, and be encouraged. At least some in relatively high places seems to get it:

In a provocative prime-time speech, meanwhile, Acting CMS Administrator Andy Slavitt threw down the gauntlet: "I'm certainly not bashful about what we need to do better, and I'm not going to be bashful here, even in the face of some very good reasons for optimism, about ways we need to take our game up across the board.”

The health IT industry has done very well in the years since the HITECH Act, said Slavitt. "But we're still at the stage where technology often hurts rather than helps physicians providing better care."

Wow. Someone from the government is here to help us!  He actually said out loud what I've been saying for years. These poorly-written, outlandishly expensive software extravaganzas can HURT patients. Yowza!

Mr. Slavitt, my new governmental hero, continues my, I mean his, rant:

To bolster his case, he rattled off a series of actual quotes from frustrated clinicians. One complained that in his EHR, "to order aspirin takes eight clicks; to order full-strength aspirin takes 16."


Slavitt said CMS is newly committed to taking a "user-centered approach to designing policy." He asked vendors to do the same, with a similar spirit of empathy: "Step back and look at what you don't think is working, and make it better."

This, from CMS? Someone pinch me...

Perhaps the additional attention comes from the fact that more and more physicians have become disgusted with the status quo:

That dissatisfaction is getting worse, not better. A study published this summer by the American Medical Association and the American College of Physicians found that physicians are more frustrated with EHRs than they were five years ago.

Forty-two percent of respondents said their EHR system’s ability to improve efficiency was "difficult or very difficult." Some 72 percent said the same about its ability to decrease workload.

We saw similar feedback in Healthcare IT News' first-ever EHR Satisfaction Survey this past fall. In addition to numerical scores, we also asked for anecdotal feedback from more than 400 people who took the poll. Opinions such as "not very intuitive," "cumbersome" and "too many clicks" cropped up over and over again.

So what's the problem? As usual, that can be stated with two little letters:  I and T. The article continues:

In his landmark book, The Design of Everyday Things, Don Norman, director of The Design Lab at University of California San Diego wrote:

"The reasons for the deficiencies in human-machine interaction are numerous. Some come from the limitations of today's technology. Some come from self-imposed restrictions by the designers, often to hold down cost. But most of the problems come from a complete lack of understanding of the design principles necessary for effective human-machine interaction. Why this deficiency? Because much of the design is done by engineers who are experts in technology but limited in their understanding of people."

Of course, in healthcare IT there are other challenges. EHR vendors would probably love to have all their products look as sleek and intuitive as the latest iOS release. But they also have to ensure they check all the boxes to comply with certification criteria from the Office of the National Coordinator – all 560 detailed pages of the 2015 Edition.

"I know some people inside big EMR companies who want to do excellent design, but in an organization that's owned by IT, it's difficult for even a design advocate to have their voice heard and affect the process," Amy Cueva, co-founder of the design-centric Health Experience Refactored conference, told Healthcare IT News in 2013.

I have been saying this in reference to PACS for much of my career, and it applies equally to the superset of EHR's. Let me emphasize these very important statements:

Why this deficiency? Because much of the design is done by engineers who are experts in technology but limited in their understanding of people.

(B)ut in an organization that's owned by IT, it's difficult for even a design advocate to have their voice heard and affect the process...

There is some light at the end of the tunnel, but...

That's changing, thankfully, as more and more efforts are being made industry-wide to make EHRs easier to use and perhaps a bit better-looking. One of those ONC certification criteria, after all, is that vendors employ a user-centered design process when developing their tools, and report the results of usability testing.

A study published this past November in the Journal of the American Medical Informatics Association took a look at UCD processes at 11 unnamed vendors, seeking to understand the challenges and opportunities for better design practices.

"Our analysis demonstrates a diverse range of vendors’ UCD practices that fall into 3 categories: well-developed UCD, basic UCD, and misconceptions of UCD," wrote researchers from MedStar Health's National Center for Human Factors in Healthcare, noting that the latter category might refer, say, to the mistaken belief that responding to end-users' requests and complaints qualifies as user-centered design..."

But we aren't there yet...

Dishearteningly, the researchers found some respondents still didn't see the business case for investing in UCD processes. It even found that some smaller EHR vendors didn't even have any usability experts on their staff.

And this is the bottom line. As with PACS, in most places, IT controls every facet of the EHR. Software wonks create these jumbled messes while insulated from the actual users. IT folks buy the stuff while equally removed from the wants and needs of those who have to use it. It needs to be reiterated...physicians use EHR's (and PACS) to take care of patients. What a concept. Healthcare IT is used for HEALTHCARE! This isn't some app for your iPhone that won't hurt anyone if it fails or if it isn't usable. This is life and death, people. That's not an exaggeration. It has to work and work well. And today, it doesn't. It gets between physician and patient, impairing instead of facilitating that sacred relationship.

We just aren't there, yet. But maybe someday...

TabCo...er...Grid Tablets Launched!

I recently posted about some stealthy company named Tabco with some new take on tablet computing. Like every other new product, this was supposed to be the NEXT BIG THING, rendering iPads, Galaxy Tabs, and so on to the garbage heap (as well as their lemming-like owners, according to the ad.)

Well, as reported in Techie Buzz, it turns out that TabCo is REALLY FusionGarage, based in Singapore, and their new product line includes the Grid 10 tablet, and the Grid 4 phone. Yes, phone! These little gems utilize the new Grid OS:

GridOS is a groundbreaking operating system that features many first-of-its-kind functionalities. It reinvents touch computing from the ground up. Its user interface is unlike anything out there. It’s a groundbreaking, visceral experience. GridOS is stunning, smart, social and transportable. It features a groundbreaking animations engine. Every feature had been rethought and made better. Web Surfing, Email, Video, Music, Photos, Home Screen Navigation and more. It’s like nothing you have experienced before and it’s what makes Grid10 an exhilarating experience.

GridOS user interface is fresh and intuitive. Its grid layout is fluid, easy to use and unique compared to any other device. User interface innovations extend across all its functionalities. Even the way you interact with a volume dial has been rethought and delivered.

GridOS was built leveraging an android kernel. It was built on top of Android. Similar to how Apple built Mac from Unix BSD. GridOS is highly secure and scalable.

GridOS supports Android Apps. Android Apps runs on GridOS without requiring and redevelopment or new code. With thousands of apps available, you with never be bored with GridOS.

One key to GridOS appears to be the reinvented wheel:

This is no vanilla UI. It fundamentally changes the way you will experience a tablet. Completely gesture-based and button-free, Grid10 lets you navigate naturally, easier and without restriction. We’ve even eliminated the boring slide bar to access Grid10. You sign on – literally – with your signature. Sounds like we have reinvented the wheel, doesn’t it? Well, we have with our wheel-based interaction. A finger tap brings up the wheel and its spokes offer a multitude of functions. Just slide your finger around the wheel and choose the desired function.

I might have chosen another example than Lady Gag Gag, but you get the idea.

The Grid10 is a nice-looking monolithic slab with a 10-inch screen:

Under the hood, or screen, or whatever, it's pretty advanced for a tablet (from Techie Buzz):

Some other technical aspects of note is that it packs a Nvidia Tegra II 1.2Ghz Dual Core processor, 512MB RAM, and 16GB of storage. It runs on the GridOS. It is Wi-Fi and 3G capable. It has a front facing camera that will work with its video calling feature that boasts one to one, and one to many, video calls. It also allows for HDMI connectivity.

More specs here. The WiFi version is $499, and the 3G (no 4G, I guess) is $599.

The Grid4 phone looks like a squared off version of the iPhone 4, but with no home-button:

FusionGarage is rather proud of the minimalist design:

It will be hard to look away from a Grid4. It’s amazingly sexy. It’s amazingly sleek. There are no buttons. There are no curves. Its just 4 inches of all screen. The straight edges scream simplicity. It’s a triumph of honest design. The all-aluminum back is a nice touch. It’s shaped around the function with no artificial design. You will turn heads with a Grid4 in your hands.

The 4 inch screen has resolution of 800x480 pixels, as compared to the iPhone 4's 960x640 pixels on its 3.6 inch diagonal screen. Sorry, Verizon-lovers; the Grid4 has a quadband GSM chipset.

In rather amusing fashion, all the accessories, such as the adapter plug below, are done up in Grid Red:

Are the Grids iPad/iPhone killers? Hard to say at this point. Frankly, based on the very limited views on the FusionGarage website, they have more potential to be Android killers. They seem to build nicely upon the Android kernel, with what seems to be a far more pleasing interface. But the market will decide.

If this all sounds a bit familiar, you may be remembering the last production from FusionGarage, the rather unfortunately-named Joo-Joo, which was formerly known as the Crunchpad. It ran Linux, and barely saw the light of day. I expect FusionGarage will have significantly more success with the Grids. Seems to me they will appeal to those who don't want to give Apple (and Steve Jobs) their due, but are looking for something beyond the Androids.

I would love to hear from any bleeding edgers who've actually purchased one of these things...

IT Laments From An ER Doc The 10th Anniversary Post on DoctorDalai.com

Fellow blogger and ER physician Edwin Leap, M.D. has apparently discovered the joys of poorly written software I've been bemoaning for so long.

In a December entry, Dr. Leap opens with an apology for the behavior of some less-than-tech-savvy physicians:

I know that, on many levels, physicians must be the absolute banes of your existence. We are grumpy and resistant to change. And some of us are still confused by graphing calculators, much less complex modern computer systems. We call you because we forgot our passwords, then because we forgot the new passwords. We call because the system crashes and we call because the voice recognition doesn’t work and we curse the screen and shake our collective fists at things that slow us every day. I get it.

He's a bit more conciliatory in this than I've been, but he's right. There are some docs for whom the acronym P.B.K.A.C. (Problem Between Keyboard and Chair) is 100% applicable. These unfortunate folks are the inspiration for Dalai's XIIth Law: 

XII. The PACS needs to be operable by the least technically-savvy radiologist on staff.

That being established, Dr. Leap takes the gloves off, and picks up my battle-flag, starting with his disgust with his EMR.

However, there are some things that you and those who develop your systems need to understand. Allow me to elucidate.

We didn’t ask for EMR in its current incarnation. It is now a gargantuan billing and data collection industry, with precious little utility in our day to day practices. As such, your bosses love it because it squeezes the last gasping penny out of every chart. They write your checks, we don’t. Nevertheless, we have difficulty being excited about ever more fields to fill out, ever more time-stamps, ever more screening exams, and the caucophanous symphony of key-strokes and mouse clicks that echo through the modern hospital and threaten to muffle the sound of suffering and human interaction.

The vast majority of EMR's, CPOE's, etc., are unwieldy, unusable pieces of convoluted trash, which add to the hours of the already full day of a busy physician. More on this in a moment.

Next, passwords and security make a lot of sense to you. You dwell in a world of hackers and identity theft and you worship at the silicon altar of HIPAA. We, however, are busily seeing patients and trying to do it as quickly as possible in hospitals, clinics and especially ER’s that have no ‘off’ switch but which do track our ‘quality’ in part by tracking our speed and efficiency. Thus, we have little time to spend logging on. And when we step away to, say, intubate a dying patient, the last thing we want to do is log back on to 1) the computer 2) the hospital EMR system and 3) the particular department system and 4) the radiology viewing system. But here’s the really, really important part: nobody is busily stalking behind us trying to look at medical records or interpret xrays on strangers so that they can violate their privacy. We’re watching; trust me.

It was a nice idea but now it’s a poison. It is the law of unintended consequences on steroids. It’s all redundant, irrelevant, obnoxious busy work that stands between us and efficiency. If you really insist on it, then make it all biometric with thumb prints. Because tracking usernames and passwords is starting to take up more of our fragile brains than drug doses and diagnoses. And that, my friends, is not good.

Yes, security. We all understand the importance of keeping hackers and other slime out of patient data. I wonder how many passwords Anthem had that didn't prevent 80 MILLION records from being compromised. Screw passwords. Let's try biometrics, wrist-worn RFID's, implanted chips, retina scans, anything that will get the job done painlessly (well, after the chip implant, anyway). We simply don't have the time to re-log in 35 times per day.

You might recall my tale of IT tyranny from the same Laws of PACS lecture wherein I used AutoHotKey to create a little macro script that pushed the button that kept my RIS active. IT at first banned the macro because "someone might use the program to bypass a password screen." Yeah, right. They knew quite well that I was the only radiologist in my group capable of even understanding how that might be done, and they knew me well enough to know that I wasn't going to do it. I did win out in the end, but as usual, it was a battle that really didn't need to be fought.

Dr. Leap continues his velvet-gloved attack, documenting another pet peeve of mine, the inability of IT to grasp the mission-criticality of what we physicians do, day in and day out.

Now, about tech support and system back-ups. We have to use these systems. There is no option. And we have to use them 24/7/365. Because that’s when people get sick and die. Therefore, every system needs to have a parallel back up system that kicks in whenever a data transfer or update or repair or anything else is happening. ‘We’ll be shutting down for four hours’ isn’t an option anymore. Since ‘we won’t see heart attacks for four hours’ isn’t an option either. Furthermore, when things are going badly, when we need a reset password or when the computers are locked up in some loop that looks like an alien language, we need help immediately. We don’t need ‘a ticket’ submitted. A round-the-clock job that requires EMR necessitates round-the-clock IT. No questions asked.

And finally, my new friend the ER doc rediscovers the travesties I've been bellowing about for just over 10 years on this very blog:

Finally, to those who design these monstrosities and those who buy them to the protests of clinicians, what are you thinking? Medicine is about caring for patients. And anything you create that makes it more difficult is an insult. Shame on you. You should do better, for your staff and for the patients who ultimately pay your salaries and fees.

Dr. Leap ends with a leap of niceness toward IT that I wish I could manifest as well...

And for you IT folks, I’m sorry. I’ll keep trying to do better. I generally know where to find ‘start’ when I’m talking to you and I can actually navigate the directions you give in a fairly efficient manner. I know that the disc drive isn’t a cup-holder and that I have PC, not a Mac. I’ve even been storing my passwords on my smart phone! I realize you have a tough job; made tougher for dealing with physicians and nurses.

All I’m saying is this: I understand your frustrations. Try to understand ours!

Yes, IT departments, and particularly software vendors...TRY to understand our frustrations. I have been blogging for TEN YEARS, saying basically the same thing. A significant plurality, if not the vast majority, of medical software is utter, complete, unmitigated GARBAGE. It is designed by engineers with no experience in healthcare and tuned to the specs of bean-counters, with no experience in healthcare. It is pitifully clear that absolutely NO thought has been given to the usability in the hands of those who need to make these abominations work in the process of treating patients and hopefully saving lives. It is nothing short of criminal, but it is no surprise. These Rube-Goldberg contraptions are NOT selected and purchased by the people that use them, but rather by those beholden to the bean-counters or other administrative influences, and those who wish to have the easiest time servicing the product.

Sadly, even after 10 years, I don't know the solution to this situation. CIO's and IT departments are not about to give up their influence over these huge expenditures, and I'm not sure how to take it away from them. Perhaps the only thing I can do is to slap the vendors in the face repeatedly with the fact that their software sucks, and hope that the subsequent embarrassment will prompt them to clean up their acts. I'm not holding my breath, and I have grave doubts that I've influenced anything much at all. Perhaps once I'm fully retired, I can turn my attention more fully toward this effort.

In the meantime, the frustration continues, with potentially deadly consequences.