Skip to content Skip to navigation

Water Fountains In The ARRA/HITECH Era

June 26, 2012
by Joe Bormel
| Reprints
Click To View Gallery

Airports have a lot in common with healthcare delivery organizations in terms of needing to accommodate wide variations in volumes, in people’s needs, and the flow of people through the facility.  However, just as in healthcare IT, over-regulation and subsequent design can potentially complicate and impede progress. 


For example, water fountains pose one of the occupational hazards I face as I pass through dozens of airports during the course of a year.  Last week, I noticed what is shown in the picture below: a restroom entrance that was designed to be large enough for two travelers to pass one another while towing their carryon bags, but is nonetheless partially blocked by the placement of a water fountain.




It would be reasonable to presume the water fountain, developed to be handicapped-accessible, was an afterthought relative to higher level design.  It was probably required under the Americans with Disabilities Act, although not necessarily where it’s located.  This is a particularly poor design fixture in light of the increasing number of travelers who have turned to using rolling carry-on bags, the kind too big to fit under an airline seat. 




Dr. Bormel,
I think your analogy is spot on in this blog. And you observation about the incessant piling on of requirements to systems is absolutely correct.

What this industry needs to do is field good concepts and allow them to be thoroughly implemented before attempting to modifications mid-stream. Too many good technological ideas are being hamstrung by over-regulation and stifling requirements long before the systems can mature and be fully exploited. To me, CMS is often at the root of such constraints.

All this waste and abuse is happening to healthcare IT while Medicare continues reimbursing hundreds of millions in fraudulent claims, with far too many unprosecuted, and the General Accountability Office has had to step in to direct HHS to take security issues more seriously. It is, indeed, a sad state of affairs. But I take heart in the fact that retirement will soon be within my grasp.

Could I please ask a favor of you? Although I performed a quick search for Dr. Walker’s paper, all I found were excerpts. Can you provide the correct link so I can read it? Thank you.

Doc Benjamin

Doc Bengain,
Thanks for your comment and your needs assessment.

You'll find the Walker/Carayon/et al paper here:

Regarding your point, "... allowing [good concepts] to be thoroughly implemented, before modifications mid-stream" was particularly interesting. It's related to the question of whether standardization stifles innovation. As you suggest, there is a logical need to establish seasons to defer innovation to establish a new, shared plateau. Without that, it would be impossible to exchanged standardized, interoperable documents, essential to EHR's serving the triple aim (better healthcare, better health, lower costs). When the innovations are necessary to simply get a standard to work at all, then we find ourselves in quick sand! Perhaps that's why it was so important to find ways to make the stage one standards work, and evolve the strongest possible standards for MU stage two.

Thanks again for your insightful comment.

Pithy observation. Yes, I have encountered many such water fountains - both real and virtual - in my travels to and from HIT conferences. At the top of my cognitive game, working around the partial barrier is not terribly burdensome. But throw in jet lag or some of those other endemic complicators and the ability to cope with the partial barrier diminishes. Visualize someone with their carry-on behind them making meaningful use of the water fountain. For those moments, the water fountain becomes not a hindrance, but a showstopper.

And as you point out with MU, the water fountain was probably an add-on to the orginal terminal design. Like MU, what stakeholder group would come before the water fountain FACA to argue against ADA requirements for accessible water fountains - just read the literature on the health consequences of dehydration while flying.

So we bolt on a water fountain here, an AED there, a security screening area over there and before you know it, we need to seriously start thinking rip-and-replace the terminal. What's a billion dollar new terminal when most of the $ can come from the FAA?

On a more sober note, the analogy applies to the stages of MU and all the rest of the associated federal interventions in HIT. While CMS and ONC set the rules for MU incentive payments and EHR certifications in a sort-of coherent whole, there is also the FDA regulation of medical devices, the embryonic NIST efforts to educate itself and the industry about "usability" best practices and the overall drive toward patient engagement, empowerment and health information exchange. No one group, be it provider, vendor or government agency, has the whole picture. Do we need to new authority to regulate placement of water fountains a la the IOM HIT patient safety recommendations?

I suppose the best we can hope for is that we will be able to muddle through for the remainder of the water fountain and airport terminal life cycle, then build it into the next design more organically.

Thanks for your wonderful comments!

I especially appreciation your insight that bad design has an entropic tendency to combine with human exhaustion to become a showstopping barrier. It usually does so while causing pain and discomfort to those around it.

To be candid, I did a double take when I read your commnet, starting with the work "Pithy." It was the right word, and underscores my recommendations (above) and those of Dr Walker et al, referenced as a framework, at the end of that Viewpoint ( They are [paraphrased here:]

1. Use EHRs as part of overall process-improvement efforts, not as an isolated IT project.

2. Design and Implement Safely, with explicit clarity and communication of needs. The concept of augmented EHRs (Greenhalgh) was reference several times, essential for smaller organizations.

3. Safety Testing and Reporting is a grossly under-developed competency; it should be noted that AHRQ took important steps with the PSO framework, enabling some necessary protections. (

4. Prevent and Manage EHR-related Incidents. There is a proposed, multi-step method elaborated in the article, with clear roles for organizations and vendors. It describes Weick and Sutcliffe's description of the establishing a high reliability organization (HRO). A problem, then and now, is that budgeting and competing budget options often effectively usurp the investments necessary to avoid foul water fountain placement. (

5. Communicate Safety Flaws and Incidents - and do so with a well-designed taxonomy of EHR-related system safety flaws and safety incidents. (See related Common Formats, here: )

6. Develop and Communicate EHR Safety Best Practices, and support the developers and utilize those tools.

7. Convene experts to organize and disseminate what is known, and create an appropriate reporting system to shed light on EHR-related safety flaws. As your comment highlights, designating the appropriate and effective authority remains a challenge.

In the course of composing this comment, I found these two blogs to be highly worthwhile:

If nothing else, Dr Lyle's blog has a cartoon which humorously captures part of the tension of this issue.

Thanks again for the comment.

Dr. Joe,
Wonderful observation. Good points.

But I submit the core problem is medicine and health care delivery, they are basically giant 'bolt-ons'.

For example, when we come up with new medical procedures and modalities we bolt them on to the overall care protocol. We created CAT Scans and NMRI’s but still do regular Xrays, we develop more and more lab tests and rarely stop using old ones (just expand the panel), etc. Today's EBM is tomorrow's GAMP, only to be discarded with the next research study.

We constantly add the new medical technology to the old, and expect info systems to keep up.

The same is true for regulation, more regs, changing regs, revise payment /measurement programs, etc., not to mention the on again, off again political nature.

We need Merlin to wave his magic wand and freeze all medical advances and all regs, for about five years and I promise we’ll get the system done on time, on budget, and I know it will work.

At least I can assure you that that fountain will be on that entrance wall for the next seven or so years. Wish I could say that about care protocols and regs.
Frank Poggio
The Kelzon Group is like a runaway train, failing to see the passengers awaiting the riide

Great analogy and, speaking as an architect, wrong conclusion. It's a good design that looks funny. There are two entrances to each restroom, it all complies with the Americans with Disabilities Act (ADA), and you can pull your suitcase out below the water cooler while someone else is coming in -- four people at a time, each restroom, no loss of privacy, minimum possible floor space. Since a lot of airport restrooms look like this, I'll certainly pay attention next time I fly!

My opinion could be wrong, of course, and the door isn't the real issue. My point here is that the ADA was written, reviewed, rewritten and then modified by a lot of people, many of whome were architects, who went out in the field and surveyed with clipboards and interviewed wheelchair users, as well as a lot of advocates. What may look like a bad answer to the rest of us could be a really good answer -- to experts, users, and people who spend the time and calculation to do the reviews -- and it requires getting ALL the data.

I think the ACA and HIT will go through the same process. Sadly, many health care providers will assume that the vendors and IT people have done their best, and, as usual will adapt. It will THEN be up to the HIE experts and IT people with the clipboards who will press on to discover such issues as alert fatigue, inconsistent interfaces, how to use XML, and a host of other issues. As users, let's keep offering opinions -- but then go back and check it out with users, programmers, and payers, before our next opportunity comes along to tweak the standards.

Mike Fraser
New York