The adventure began with a visit to my parents’ basement to rescue my first Mac from a non-life of quiet, damp darkness and being used as a litter box for mice. After some mild cussing and digging through a box of parts, I left my parents’ place armed with the LCII, the monitor that went with it, a chunky 1990s Apple keyboard, two mice (the electronic kind, not the fuzzies that so kindly left their excrement behind) and a Color StyleWriter 4100 with a power brick.

At home, a pair of busy weeks followed with the kids arguing a lot in the evenings, so the only restoration I was able to accomplish was cleaning off the mouse droppings, vacuuming the keyboard and chasing a few recalcitrant spiders out of the computer case. Finally a free day presented itself and I re-assembled all of the pieces carefully, discovered I’d forgotten to dig for the cable that connects the printer to the computer, shrugged and hit the ‘power’ button on the computer and monitor. Hope surged as the monitor flickered to life and the screen slowly painted the familiar gray background of pre-System 8 machines. And the dreaded unhappy Mac face popped up in the middle of my screen.

Next step, frantic search through a bunch of boxes and file folders for that old system boot disk I know I made yea these many years ago. No dice. Without a boot disk and after multiple attempts to re-boot, it seemed that the LCII was just not going to boot up.

I gave the project a rest for a few days, then poked around on eBay to see what I could find. Lo and behold, a seller had a fully functioning Quadra 630 available with System 7.5 and Word 6 for Mac installed and an ethernet card installed. I threw up my hands in celebration and clicked ‘bid’. An hour later, I’d secured the machine for about $60 including shipping across the country and I flipped off my laptop feeling very accomplished.

A week later, the Quadra arrived and I unpacked and set it up immediately, attaching it to the working LC monitor and waited eagerly to see what happened when I hit the power switch on the keyboard. Huzzah! Happy Mac Face! Now all I had to do was start popping floppies into the drive to check on the status of my ancient papers. Shortly I found most of my files safely intact on the backup disks and I saved them down to both floppy and the hard drive in Rich Text Format in anticipation of emailing them to myself and opening them on my PC. In the meantime, I also took a walk down memory lane, opening up files I haven’t clapped eyes on since at least 1998 when I stopped using my Mac 520c laptop.

The kids interrupted at this point and I stepped away from my desk for a few hours. When I came back to it, I clipped my ethernet cable from the cable modem into the ethernet port on the back of the Quadra and waited expectantly for something to happen. Apparently every computer customer service brain cell I used to have for supporting a Mac of this generation died sometime between birthing my kids and now, because of course, no connection magically appeared.

Cue looking through the Control Panels and applications to find things I used to be an expert at wrangling, like Kermit and Mac TCP/IP. The upshot is that it looks like a thing or two might be missing, but I should be able to download them from Apple’s archives … if I could download to a Mac format floppy that the Quadra can take. That’s where things stand today: I need to install some things on the machine to see if I can get it up on the internet. Another option is to update the PC Exchange software and see if I can save my RTF copies of my papers down to a PC format disk and pick up a USB floppy drive to transfer the papers to my Inspiron 6400.

For all the myriad small disappointments on this particular adventure, there’s something fun about doing this kind of troubleshooting again and trying to think outside the box to solve the problem. It’s like the old days, sitting in the basement of Seelye with an array of Macs and PCs, repairing disks for desperate School for Social Work students or miraculously unjamming the printer for stressed out seniors during finals.

Those were the days.

Along the way, here’s some useful sites I’ve found for assistance with vintage Mac file access:

• Apple’s Archives – An extensive collection of software and supporting applications for old Apple versions downloadable for free.
• Oakbog – Professional file transfer services and vintage Mac advice.
• Vintage Mac Museum Blog – Run by Adam Rosen of Oakbog, the blog has many interesting articles about vintage Macs including tips for transferring files.
• Low-End Macs Vintage Mac Pages – The site catalogs all older Macs and provides useful links and articles for troubleshooting a host of issues as well as transfer tips.

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.

Once your template is fully understood so that you know without really thinking about it, which blocks of code need to be used to apply design effect X or positioning area Y, then it’s time to jump into cutting up the code into discrete pieces, be it include files or CMS templates and folding dynamic code around elements to really make the template come alive.

It pays to go slowly at first so that any mistakes are caught early and you’re sure that no stray lines have made their way into your pages or that that loop there got properly closed, so that when you’re applying everything within the CMS later, there’s few or no surprise error messages with arcane references to a variable on line 367 that you remember looking at, but can’t place in context right away.

Long story short, preparation, preparation, preparation and deliberation up front can actually pay off in a shorter turnaround time over all and save a hard-working developer from a serious case of monitor eyes.

One of the most exciting statements from the lead product manager for collaboration states that: “…Google wants to make sure that Apps users can not only pull into Docs and Sites any document created in Office, but that they can also push those documents from Apps back to Office, all without losing formatting fidelity.”

One of my greatest frustrations with using GoogleDocs as a collaboration tool to write proposals has been the loss of formatting fidelity between Docs and Office. Proposals are large, heavy, unwieldy documents that combine a stock format with highly individualized responses to Requests For Proposals (RFPs). Proposals also require a high level of collaboration between technical authors who are providing key tecnical solution components, business authors who are providing key business-oriented solution information and editors who are smoothing out the entire document into a logical whole.

GoogleDocs would appear to be the ideal environment for creating this type of document, however because of the loss of formatting-fidelity, it’s nearly impossible to pull a proposal template into GoogleDocs for consistent use. What can be done, is writing small chunks of a proposal in a relatively format-agnostic way that can then be copied and pasted into the template ad-hoc as each pieces is completed.

Authors and editors can conduct the collaborative back and forth using the version control available in GoogleDocs or the automatically time-stamped and color-coded commenting system to highlight areas where changes are required. Then the edited pieces of text can be cobbled together ‘offline’ into the document template.

However, without strong fidelity between Office and GoogleDocs, an end-to-end final document can’t be fully loaded into the application for sharing and versioning, because the proposal template formatting with its complex headers and intricate interlinked styles won’t survive the upload into Docs.

If, as Google’s product manager is saying, full fidelity is a goal and this issue is ultimately resolved, GoogleDocs and other Apps could become a very strong contender for collaborative proposal-writing.

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.

A List Apart: Articles: JavaScript MVC.