Not only is building Circles intuitive and flexible, it’s also downright fun and pretty to look at. I spent several minutes yesterday just dropping people into Circles from my various integrated address books just to see them bounce around the Circle and settle into place. Speaking of integration, Google offers hooks into Yahoo, Facebook, Twitter and other common sites through the Settings menu.

I’ve only scratched the surface of what Google + has to offer in the last 24 hours, but so far it’s proving to be a very user-friendly experience that bodes well for future usability and adoption. In my opinion, continued integration into other tools may be key to driving adoption so that users don’t get stuck with having to add ‘yet another tool’ to their portfolio of tools.

I have an answer for that: many pocket devices are too small to actually provide many users with a comfortable user experience for consuming the type of media that we want to be able to consume.

This is something that I notice all the time when I’m commuting: people squinting at their phones or awkwardly clutching them while trying to thumb-key something into a browser window or phone-based app. Granted, I haven’t played with an iPhone, I don’t have one and my brother has only let me touch his for about 2 minutes over lunch, once while he was visiting, but it seems to me that what anyone broaching the tablet space is trying to resolve is a very simple human factor: the device-size issue.

Ideally any device that lets us interact with email, web browsing, apps to carry out particular tasks should be highly portable and not awkward to carry around, however, under a certain size the simple fact of not being able to read the screen efficiently gets in the way. When I first got a Blackberry, I made sure to get the version that had a full QWERTY keyboard because at the time, I thought that this would handily solve my desire to be able to type while sitting on the train commuting back and forth to work. My laptop is too big and too unwieldy to haul out for casual use on the train or when out and about away from home, but what I quickly found is that the Blackberry keyboard is too small and cramped for comfortable, much less speedy typing.

This Christmas, I received a Kindle as a gift and immediately felt much more comfortable with this size for a device. Even thumb-keying on the Kindle is much more comfortable and less error-prone than trying to eke out a sentence on the Blackberry. Overall, the Kindle is a nice e-reader, though it falls down for the purpose that I really wanted it for: reading my secured eBooks from the University of Phoenix for the graduate program I’m currently enrolled in. Though UoP fulfills its eBooks through Amazon, they are protected with digital security – not just a simple password-protected PDF – and the Kindle isn’t capable of unlocking the digitally secured eBooks. Big bummer, because what I really wanted that Kindle for, was to be able to read my textbooks, scholarly journals and various other digitally rendered print sources on the go without having to print them out and waste the paper on things I’m only going to read once or twice for class.

Unless I’m misunderstanding the specs for the iPad, I should actually be able to download and unlock my eBooks for my classes and also not have to lug around a heavy laptop to read them and in my mind that is part of the power of this type of device. The usability factor for any kind of student of any age is very high and much more engaging than the black-and-white display on the Kindle or the Sony eReader especially since the iPad isn’t just a reader, but a device oriented on the consumption of different kinds of media.

Where I agree with some about where the iPad falls down, is the lack of multi-tasking. Given the iPad’s size however, browsing websites should be a much more comfortable experience and if the iPad supports a full-featured browser, then a certain amount of multi-tasking can be achieved through the use of web applications. This brings me to my other big hope for any type of tablet device, which is providing a better way to foster portable interaction with health care applications such as electronic medical records and electronic practice solutions.

Currently, the health care industry is somewhat bogged down in trying to go digital, mostly because the means of input is not well-suited to the type of workflow that doctors, nurses and other health care professionals require. While there are many useful apps for handheld devices for the health care industry and many health care organizations are implementing desktop or laptop-based electronic solutions, a high-level observation of how those solutions are used in hospitals and practices shows that they are not ideal for the people who need to use them because they are either too small for the large amounts of data entry that most forms and charts require or too static, in the case of desktops and laptops, interrupting a workflow that requires most health care professionals to be on their feet walking around seeing patients and interacting with those patients for many hours a day.

Tablets are the ideal size to help bridge this big gap in the successful adoption and efficient use of these technologies in the health care space, but up until now the ways to interact with the tablet have not been very good or the tablets themselves have been too heavy to carry around in the way that most of us would carry around an armload of folders, charts or a notebook. It’s this notebook-type experience that I’d really love a tablet to emulate and I think that the iPad gets very very close, but possibly missed the boat about tapping into uses of the tablet in the health care industry.

We’re still on the cusp of something with the tablet format and I think that the iPad goes a long way towards moving us down that road, but I’ll be keeping an eye on other vendors who are bringing tablet devices to market this year to see if anyone really hits the tablet-as-interactive-notebook paradigm out of the park.

The missing component for a lot of these unsuccessful e-health systems is the focus on usability and user experience particularly from a clinical perspective. Beyond even gathering sufficient requirements to provide a successful user experience for doctors, nurses and other health care providers, within a hospital or other health care environment, those requirements then also need to be applied properly to the development of the e-health product. Essentially, usability needs to be considered, taken into account and applied throughout the entire product development life cycle and repeatedly re-applied over the course of the lifespan of the product during reviews.

So a part of the problem with realizing cost savings in health care through the application of information technology, is in fact, bad design on the software end and also in some cases, improper data management design that requires too heavy of a load from a hardware perspective. How many machines does an organization have to purchase just to support all of the storage needs for the vast amounts of data that are housed in your average medical record, for instance? Failover, redundancy and backup are also key considerations on the hardware side and can introduce added costs in terms of hardware to ensure 24/7 availability as well as either a ‘hot’ or ‘cold’ failover system that can be brought online to back up the main system in the event of a catastrophic failure.

In order for health care organizations to realize true cost-savings measures, the following principles and steps need to be applied to the purchase and implementation of any system:

• Requirements. A strong requirements gathering phase so that the needs of the organization are fully understood and documented prior to the consideration of any software system. Ignore the latest buzz about any one system, ignore ‘cool’ factor purchases and concentrate on what your particular organization’s needs actually are. Don’t stint on time spent in the requirements gathering phase, understanding the business needs before making a large purchase is crucial to getting your money’s worth from your software vendor/s.
• Planning. Once the requirements are well understood, then the purchase needs to be carefully planned before any vendors are brought in for a demonstration. Select vendors based on the requirements that are outlined and make sure that any vendor, whether providing an ‘out of the box’ system that can be customized or a vendor who will be custom-building something largely from scratch understands your requirements and includes an analysis of your organization’s workflow both administrative AND clinical and is able to customize elements of the system to match that workflow.
• User Experience Expertise. If possible hire a UX expert or appoint a UX expert from within your organization to work with your administrators and clinicians so that their workflow is incorporated into the requirements before talking to vendors. Involve clinicians in the early stages of the project to ensure that their needs will be met by the systems. A UX expert can work with each of these different groups to capture how they work and help to coordinate with the IT end of the equation to make sure that any system under consideration will dovetail with the user experience that the users actually want and need in order to do their jobs efficiently. Bringing in User Experience early and often in health care system purchases can go a long way towards saving dollars in the long run or avoid making a bad purchase.
• Pilot. Once all the requirements are understood and a decision to build or purchase has been made, strongly consider going into a pilot phase. If possible, get free trial versions of any vendors under consideration, or have the development team build a ‘low scale’ version of the system, then build a pilot group of testers that is a representative sample of your final end user base. Cut them loose on the system. They’ll be able to ferret out road blocks in the system quickly and provide invaluable feedback about what works, what doesn’t work and which systems stand up to the ultimate test of day to day usage. This is just like taking a care out for a test drive and no one really buys a car without taking it for a test drive. Do the same thing with your e-health systems, kick the tires, check all the gears, rev the engine up and see how the system handles at full speed. A vendor-driven demo won’t reveal flaws the way that a test drive or pilot will, though such demos are definitely useful for getting an idea of which system or systems you would like to bring in for a pilot.
• Don’t Be Afraid To Pull The Plug. While there’s often a lot of back room politics, budget concerns and other elements involved with any system purchase, one of the biggest mistakes that gets made in almost any industry, is fear of backing out once a path has been chosen. If a product does badly in demo, if the pilot is generating a lot of negative feedback, if small problems keep cropping up, don’t be afraid to back up a step or two and re-evaluate. Bring in a different system to pilot. Re-visit some of the requirements. What are the key priorities with the system purchase? Is it meeting the needs of the end user? If not and there’s no way to meet those priorities and needs, pull the plug. Far less money will be wasted by backing out before making a final purchase, investing in customizations, documentation and training. Selecting the right system, getting it right the first time can save an organization from making a purchase that ultimately costs more and renders the organization less efficient.
• The User Is The Ultimate Customer. At the end of the day, any efficiencies or cost-savings are going to come back to the usability of the system. Are the people who have to use it every day going to be able to use it with a minimum of training, without a manual? Are they going to be able to seamlessly work the system into their day-to-day work, using the system as a replacement for what they currently use today? Is the system going to offer improvements over what is currently in use? If the users are not satisfied at the end of the day, have not been empowered to do their work either more quickly, efficiently or accurately, then the customer’s needs haven’t been met.

Two real world examples provide a comparison of approach.

System A, implemented on the East Coast, in spite of hours of time spent by the vendor’s analysts shadowing doctors and figuring out workflow, provided a system that did not successfully take all that observation of workflow into account or apply it well to the final product.

The system in question creates backlogs of work for nurses working in specialty clinics especially, because it is not tailored for the specialty. The system apparently also experiences gradual slow-downs over the course of the day as usage peaks, grinding down to a crawl by the early afternoon hours. This likely points to some flaws in the hardware and database set up on the back end. However, more critical is the experience of the nurses using the system and the fact that they’re not able to easily enter data in a way that makes sense from a clinical perspective and have too many clicks to get through to input or read what they need to. Lock-outs and freezes are also apparently common, causing lost work and data re-entry that can take away from time spent conducting follow-up calls to patients or simply, long hours in the office after closing time.

Contrast this with a system from another part of the country that involved the clinicians at every step of the way including four prototypes and a pilot as well as a constant feedback loop via the provider outreach group and a schedule of improvements to the system to address that feedback in a relatively timely manner. While this other system also occasionally experiences hardware difficulties that can slow the system down, in terms of usability, this system is much more successful and lauded by the clinicians who use it daily and have in fact realized huge efficiencies in work, reducing turnaround time on an approval process, from 3 business days to 24 hours in some cases. Mouse-clicks and screens are organized in a logical, hierarchical fashion and the pieces presented to the end user are targeted based on who they are at log on. This allows the user interface to be relatively lightweight and the labeling on all fields is done in a way that is intuitive for the clinicians using it.

What it all adds up to, is that Himmelstein is likely right when he states that computerized systems are not currently saving the health care industry money across the board. However, this does not mean that these kinds of systems can’t save money over the long term if they are designed and implemented correctly. One of the fundamental ways to ensure that both design and implementation are correctly conducted is by espousing the principles of usability and providing intuitive systems that have a strong focus on serving the needs of the users that will use them. Without an eye to user experience design in health care systems, health care organizations will continue not to realize the cost and efficiency benefits that are possible.

I’m currently enrolled in a Master’s of Health Administration, Informatics program with the University of Phoenix. Our assignment this week was to analyze a trend in healthcare and given my specialization within the degree, I chose telemedicine as my topic.

Through the course of my research for the paper, I found an article referencing AFHCAN and the implementation of mobile telemedicine carts for widespread use in Alaska outside of urban centers. What I found most interesting in this article, was the creativity of the networking solution that was put into place to provide remote locations with large volumes of information, including x-rays and graphics.

At the time the article was written in 2006, Alaska’s infrastructure is described as still being highly reliant on dial-up modems at speeds of under 900 baud. Applications and systems that require a high rate of bandwidth therefore wouldn’t suit well for implementing a remote care system.

The AFHCAN project instead focused on the real bottom-line necessities of a telemedicine system and made use of asynchronous data transfer to transmit large amounts of information from remote locations to assisting specialists.

The mobile carts used also combine technologies that are practical for use in the target setting. Some of these technologies are pretty cutting edge, including video otoscopes and similar, or as prosaic as a scanner and a digital camera with a docking port.

The beauty of this system is that it really works and provides excellent health outcomes for patients who are diagnosed through the tool. It’s a case of a good usability, carefully targeted for the audience the tool is intended to serve. On top of all that, the system helps to save money on transport costs, allowing the carts to pay for themselves.

This is the kind of application of technology that really gets me excited about the marriage of high tech and healthcare and where things might be headed in the future.

Related Resources:
Alaska Telemedicine: Growth Through Collaboration

Harler, C. (2006, October). Telemedicine: Alaska net shows how narrow you can go. Business Communications Review, 54-57.