Home » Readers Write » Currently Reading:

Readers Write: FDASIA and Healthcare’s Moon Shot Goal of ICU Safety

May 15, 2014 Readers Write 7 Comments

FDASIA and Healthcare’s Moon Shot Goal of ICU Safety
By Stephanie Reel


Preparing for the FDASIA panel was an energizing opportunity. It allowed me to spend a little time thoughtfully considering the role of government and the role of private industry in the future of health IT integration and interoperability. It gave me an opportunity to think a great deal about the important role ONC has played over the past few years and it made me question why we haven’t achieved some of the goals we had hoped to achieve.

As I was preparing my remarks, I reflected on the great work being done by my colleagues at Johns Hopkins and our vendor partners. We have the distinct privilege of having the Armstrong Institute at Hopkins focused on patient safety and quality, which is generously funded by Mr. Mike Armstrong, former chairman of our the Board of Trustees for Johns Hopkins Medicine. It is unequaled and a part of our fabric and our foundation. The Armstrong Institute is inspirationally led by Dr. Peter Pronovost, who is an incredibly well-respected leader in the field of patient safety, and also a trusted colleague and a good friend.  

We in IT at Hopkins receive exceptional support from our leadership – truly. We also have amazingly strong partnerships with our school of medicine faculty, our nurses, and our enterprise-wide staff. I suspect we are the envy of most academic health systems. The degree of collaboration at Hopkins is stunning – in our community hospitals, physician offices, and across our academic medical centers. Our systems’ initiatives derive direct qualitative and quantitative benefit from these relationships. Our CMIO, Dr. Peter Greene, and our CNIO, Dr. Stephanie Poe, are the best of the best in their roles. The medical director of our Epic deployment, Dr. John Flynn, is a gift.  

We are luckier than most. We could not do what we do without them. But despite this impressive and innovative environment, we still have significant challenges that are not unique to Hopkins. 

Despite huge investments and strong commitments to Meaningful Use, we have challenges across all  health IT initiatives. They aren’t new ones and they aren’t being adequately addressed by our current commitment to Meaningful Use criteria. We are still not operating in a culture adequately committed to safety and patient- and family-centered care. We are still not sufficiently focused on technologies, processes, and environments that consistently focused on doing everything in the context of what’s best for the patient. 

We decided to try harder. All across Johns Hopkins Medicine, we published a set of guiding principles that guide our approach to the deployment of information technology solutions. These guiding principles reduce ambiguity and  provide constancy of purpose. They drive the way we make decisions, prioritize our work, and choose among alternatives – investment alternatives, deployment alternatives, vendor alternatives, integration tactics, and deployment strategies. They provide a “true north” that promotes the culture we are hoping to create.

Our first guiding principle expects us to always do what is best for the patient. No question, no doubt, no ambiguity. We will always do what is best for the patient and for the patient’s family and care partners. We are committed to patient safety and it is palpable. This is our true north.

Our  second guiding principle allows us to extend our commitment even further. We commit to also always doing what is best for the people who take care of patients. So far, we have never found this to be in conflict with our first guiding principle. We view the patient and the patient’s family as our partners. Together, we are the team. Our environment, our work flow, our processes, and our technologies need to do what is best for all members of the team and all of the partners in the process of disease prevention, prediction, and treatment.

Our remaining guiding principles deal with our commitment to integration, standardization, and best practices. We know that unmanaged complexity is dangerous. We know that there are opportunities to improve our processes and our systems if we are always focused on being a learning healthcare system. We know we can achieve efficiencies and more effective solutions if we also achieve some degree of standardization and data and system integration. This is essential, critically important, and huge. It is something FDASIA (the FDA,FCC, and ONC) and the proposed Safety Center may be able to help us address. 

Is this the best role for government?

Government has an important role and government has the power to convene, which is often critical. But I also feel strongly that market forces are compelling and must be tapped to help us better serve our patients and the people who care for our patients. Health systems and hospitals have tremendous purchasing power. We should ensure we define our criteria for device and system selection based upon the vendor’s commitment to integration, standardization, and collaboration around best practices. We must find a way to promote continuous learning if we are to achieve the triple aim. 

We need to step up. We need to say we will not purchase devices, systems, and applications if the vendors are not fully and visibly committed to interoperability and continuous learning. This must be true for software, hardware, and medical devices. It must be true for our patients and for the people who care for our patients.

Moon shot goal

This relates my plea that we define a moon shot goal for our nation. We must commit to having the safest healthcare delivery system in the world. We should start with our intensive care units. We must ensure that our medical devices, smart pumps, ventilators, and glucometers are appropriately and safety interoperable. We must  make a commitment to settle for nothing less. We must agree that we will not purchase devices or systems that do not integrate, providing a safe, well-integrated solution for our patients and for the people taking care of our patients.

Let’s decide as a nation that we will place as much emphasis on safety as we have on Meaningful Use. Or perhaps we can redefine Meaningful Use to define the criteria, goals, and objectives to be achieved to ensure that we meet our moon shot goals. We will ensure that we have the safest hospitals in the world and we will start with our ICUs, where we care for the most vulnerable patients. We might even want to start with our pediatric ICUs, where we treat the truly most vulnerable patients.

More than 10 years ago, I was given an amazing opportunity to “adopt a unit” at The Johns Hopkins Hospital as a part of a safety program invented at Hopkins by Dr. Peter Pronovost. Each member of our leadership team was provided with an opportunity to adopt an ICU. We were encouraged to work with our ICU colleagues to focus on patient safety. We were educated and trained to be “preoccupied with failure” and focused on any defects that might contribute to patient harm. We didn’t realize it at the time, but we were learning how to become a High Reliability Organization.  

I learned quickly that our ICUs are noisy, chaotic, extremely busy, and not comforting places for our patients or their families. I learned that our PICU was especially noisy. Some of our patients had many devices at their bedside, nearly none of which were interoperable. They beeped, whirred, buzzed, and sent alarms – many of which were false alarms — all contributing to the noise, complexity, and feeling of chaos. They distracted our clinicians, disturbed our patients, and worried our family partners. 

Most importantly, they didn’t talk to one another. So much sophisticated technology, in the busiest places in our hospitals, all capable of providing valuable data, yet not integrated – not interoperable – and sometimes not even helpful.

I realized then, and many times since I adopted the PICU, that we all deserve better. Our patients and the people who care for our patients deserve better. We must build quiet ICUs where our care team can listen and learn and where our patients can receive the care they need from clinicians who can collaborate, leveraging well-integrated solutions and fully integrated information to provide the safest possible care. Many of these principles influenced the construction of our new clinical towers that opened two years ago. Again, we are fortunate, but huge challenges remain.

What about Quality Management Systems? Are we testing and measuring quality appropriately?

In many ways, I think we may focus too much on the back end. Perhaps we focus too much on testing and not enough time leading affirmatively. A commitment to excellence – to high reliability – might lessen the complexity of our testing techniques. I am very much committed to sophisticated quality assurance testing, but it seems far better to create and promote a culture that is committed to doing it right the first time. It will also be important that we affirmatively lead our design and deployment of systems that rely only on testing our solutions. 

With that in mind, I would prefer to see an additional focus or strategy that embraces High Reliability at the front end in addition to using quality management techniques. We undoubtedly need both. 

As I have recently learned, most High Reliability Organizations have much in common related to this dilemma. We all operate in unforgiving environments. Mistakes will happen, defects will occur, and we need to be  attentive. But we must also have aspirational goals that cause us to relentlessly focus on safety at the front end. We must remain passionate about our preoccupation with failure. We must recognize that our interventions are risky. We must have a sense of our own vulnerabilities and ensure we recognize we are ultimately responsible and accountable despite our distributed and decentralized models. We must continue to ask ourselves, “How will the next patient be harmed?” and then do everything possible to prevent harm at the front end as well as during testing.  We must create a culture that causes us to think about risk at the beginning.  And of course, we must be resilient, reacting appropriately when we do recognize errors, defects, or problems.

I should note that many of these ideas related to High Reliability are very well documented in Karl Weick and Kathleen Sutcliffe’s book, Managing the Unexpected. They encourage “collective mindfulness” and shared understanding of the situation they face. Their processes are centered around the five principles: a preoccupation with failure, reluctance to simplify interpretations, sensitivity to operations, commitment to resilience, and deference to expertise.

Why the moon shot goal?

As Dr. Pronovost at Johns Hopkins Armstrong Institute often says, “Change travels at the speed of trust.” We need to learn from one another. We need to be transparent, focused, and committed to doing what is best for our patients and for the people who care for our patients. We must commit to reducing patient harm. We must improve the productivity and effectiveness of our healthcare providers. We must have faith in our future and trust our partners. We need to make a commitment to no longer expect or accept mediocrity. 

From a recent study performed at the Armstrong Institute under Dr. Pronovost’s leadership, we know that patients around our country continue to die needlessly from preventable harm. Healthcare has little tangible improvement to show for its $800 billion investment in health information technology. Productivity is flat. Preventable patient harm remains the third leading cause of death in the US.

In addition, costs of care continue to consume increasingly larger and unsustainable fractions of the economy in all developed countries. While cutting payments may slightly decrease the cost per unit of service, improving productivity could more significantly deflate costs. Other industries have significantly improved productivity, largely through investments in technology and in systems engineering to obtain the maximal value from technology. Yet healthcare productivity has not improved. Our nurses respond to alarms — many of them false alarms – on average, every 94 seconds. This would be unthinkable in many other environments.

Despite my view that we must encourage market forces, we know that we have a long way to go to have an ICU that has been designed to prevent all patient harm while also reducing waste. Clinicians are often given technologies that were designed by manufacturers with limited usability testing by clinicians. These technologies often do not support the goals clinicians are trying to achieve, often hurt rather than help productivity, and have a neutral or negative impact on patient safety.

Moreover, the market has not yet integrated technologies to reduce harm. Neither regulators nor the market has applied sufficient pressure on electronic health record vendors or device manufacturers to integrate technologies to reduce harm. The market has not helped integrate systems or designed a unit that prevents all patient harm, optimizes patient outcomes and experience, and reduces waste. Hospitals continue to buy technologies that do not communicate.

It is as if Bloomberg News would have been successful if there were no standards for sharing of financial and market data. It would be unthinkable that Boeing would continue to partner with a landing gear manufacturer that refused to incorporate a signal to the cockpit informing the pilot whether the landing gear was up or down. We need the same engineering, medical, clinical trans-disciplinary collaboration expectations to ensure the same is true for healthcare.

Back to the moon shot….

An ideal ICU is possible if we decide it matters enough. If we agree to combine trans-disciplinary collaboration with broad stakeholder participation and demand authentic collaborations, we can get there in less than five years. But it won’t be trivial. It will require a public/private partnership.

The cultural and economic barriers to such collaborations are profound. Engineers and physicians use different language, apply different theories and methods, and employ different performance measures. We must take a holistic approach to create the ideal ICU and the ideal patient and family experience.

A safe, productive system is possible today. Technology is not the barrier. Let’s make it happen. Let’s have a goal for 2020 that we will have the safest ICUs (and the safest hospitals) on the planet – focused on patient- and family-centered care, disease prevention, and personalized and individualized healthcare.

Stephanie L. Reel is CIO and vice-provost for information technology at Johns Hopkins University and vice-president for information services for Johns Hopkins Medicine of Baltimore, MD.

View/Print Text Only View/Print Text Only

HIStalk Featured Sponsors


Currently there are "7 comments" on this Article:

  1. Stephanie Reel tells the truth with elegance and thoughtfulness. Often, Ms. Reel incorporates nuance that many may miss, i.e., her statement about the obligation NOT to buy lousy software and software that is not interoperable is a very polite way of saying we should not subject ourselves to software that endangers patient safety or clinician sanity. Brava!

  2. What a great read! A thoughtful, interesting article with something to say.

    Since Ms. Reel writes about standardization and interoperability – and, in passing, Epic – I can’t let pass the opportunity to make a point. Epic seems, admirably, to be doing a lot right. However, in terms of standards and interoperability the Epic approach leaves much to be desired. Their customers generally don’t know this.

    To date Epic has steadfastly refused to leverage internationally-recognized standards for medical records sharing (I’m talking here about regional eHealth standards like IHE’s XDS) in a comprehensive way – to the detriment of their customers. Epic has an alternative, proprietary approach, shared by a handful of U.S. vendors. Downsides for their clientele are techie in nature (therefore not well understood by many) and include:

    – tougher integrations (and ultimately more expensive ones). In a standards-based world, integrations are easier (ideally they vanish altogether)

    – data is stored in a proprietary format – so if an institution wants to use their data in the future in a way that Epic doesn’t support off-the-shelf, either the institution is out of luck, or they end up paying through the nose for a custom application.

    Note that neither of these is really a downside for Epic.

    Whenever I ask Epic about this, they tell me that they will become more interested in complying with IHE standards when their customers start asking them for it. Since Epic’s customers and prospects are generally clinically-focused, most of them have no idea about IHE standards — so they don’t ask.

    CIOs, CMIOs, please, start asking Epic for XDS & other related IHE standards! There is much to be gained here.

  3. I find Stephanie Reel’s leadership with the concept of the Moon Shot and the directives toward integration and interoperability a most significant mandate. I believe her insight that only through market forces can we expect to achieve the highest results is spot on. Failure to demand the best, most effective integration is tantamount to accepting mediocrity and that results in refusing to accept responsibility for striving for the best outcomes, best care and best overall team effort. My short time service with Altruista Health Systems was dedicated to predictive outcomes, an integrated process of care analysis and responsible care management. Stephanie Reel’s leadership can be the catalyst for a new Moon Shot.

  4. Re: Standards devotee from Leafsprout

    As far as I am aware, Epic’s approach is strictly based on IHE standards (XCA, XCPD, and XDR in particular). XDS, also as far as I am aware, was the initial, registry-based centralized approach to records (or rather documents) sharing. XCA, XCPD and XDR were added by IHE to enable point-to-point sharing, without the need for a centralized entity.

    It is probably better to ask the question why healthcare organizations that use Epic seem to prefer the latter over the former, instead of incorrectly claiming some proprietary approach.

  5. Re: Eddie T. Head

    Agreed – it is a good question.

    As you say, the interfaces you mention (XCA, XCPD and XDR) are all point-to-point interfaces and work well between communities. XDS is meant to mediate sharing within the community (by use of centralized indexing and by storing documents in a standard format inside that community).

    Although Epic uses some IHE profiles, they neglect key ones, XDS being chief among these. This approach – implementation of a few select IHE profiles that deal with outside world – will work just fine for communication between communities. However within the community things can get costly, messy, and ultimately fall short of expectations for the reasons I mentioned earlier:

    – Integration hell – in the event that new hospitals/clinics with systems from other vendors are added to the community, ease and cost of integrating them becomes an issue: more point-to-point XDR-like interfacing, or costly migrations, or creation of sub-communities within a community (entailing long-term scalability and maintainability issues).

    – Information controlled by the vendor not the community – the use of proprietary format for data storage within a community effectively locks that community to a given vendor. If Epic doesn’t support the application you’re looking for, you may be out of luck. It’s an issue for new clinical uses, research uses, and for future analytics applications, if you’re hoping for any of that.

    Why do Epic users seem to prefer the point-to-point approach? I’d love to know the user’s perspective. I can guess that Epic simply prefers their users to be locked in.

    – Elizabeth Stark

  6. Re: Standards devotee

    I find no logical connection between the facts and the conclusions you present.

    I know for a fact that the transactions comprising XCA and XDR are identical to the transactions in XDS. What is different is the purpose of the transactions. and the expected actions of the sender and receiver. The difference in purpose has little to do with “within a community” and “between communities” – I’ve heard suggestions that XCA can be useful within an enterprise.

    Furthermore there is no connection between data storage and the IHE profiles, which limit themselves to the transactions on the wire, and the above mentioned requirements for senders and receivers. Anything that is implementation specific (like data storage) is out of scope, and therefore irrelevant.

  7. It may be that XCA can be useful within an enterprise or between enterprises, but that is certainly not its intended purpose. XCA stands for Cross-Community Access, so it does have to do with info flowing between communities. It’s right there in the name. Similarly, XDS stands for Cross-Enterprise Document Sharing. Cross-enterprise meaning between enterprises (i.e., within a community).

    In terms of data storage not being directly specified by the IHE profiles, I guess that’s true to some extent – although the IHE specifies DICOM for images, which is a data storage format, but for the most part the IHE profiles do limit themselves to transactions. Storage format, while not directly specified by the IHE profiles, is nonetheless suggested by them and follows as a downstream consequence. Having a data format that is comprehensible to others is also well aligned with the IHE’s stated mission of seeing healthcare computer systems share information through coordinated use of established standards (although I may be guilty of a leap there).

    It sounds to me like you may have a dog in this fight. Are you an Epic guy/gal? If so, I’d really like to know Epic’s take on the two points I mentioned earlier: the issue of integration hell and the issue of control of the information by the vendor.

Subscribe to Updates



Text Ads

Report News and Rumors

No title

Anonymous online form
Rumor line: 801.HIT.NEWS



Founding Sponsors


Platinum Sponsors































































Gold Sponsors















Reader Comments

  • Annon: 100% agree, this is vaporware, they are not doing anything remotely close to interoperability. Not the only ones though,...
  • Brian Too: Wait... I thought that any voids in the brain automatically filled up with cerebro-spinal fluid? Wouldn't an air void c...
  • Ophelia: Where are you seeing the 97% MIPS claim? I'm aware of their claimed 97% attestation rate for MU, but I haven't seen anyt...
  • Sue Powell: Re: "airhead". Maybe Q04.9 Congenital malformation of brain, unspecified or G93.9 Disorder of brain, unspecified? #notac...
  • Not Mr. Bush: It is very interesting that they claim to be able to guarantee something that is so dependent on physician behavior....
  • Debtor: Athena has a long history of supporting MU and PQRS attestation. It wouldn’t surprise me if they have insight into the...
  • Frank Discussion: Cerner--the best Visual Basic 5 application our tax dollars can buy! Then there's CCL (*vomits into nearest trashcan)...
  • Stormy MU: Hi, Does anyone have any feedback on athena's claim of 97% MIPs success rate? How can they publish that when 2017 at...
  • HypocritOath: This post was all over the place, but I can't help but notice some huge inconsistencies in your stance here. In one ...
  • HIT Girl: Holmes swindles people out of millions, pays a fine (with the swindled money?!), and is sent to CEO-timeout for a few ye...

RSS Industry Events

  • An error has occurred, which probably means the feed is down. Try again later.

Sponsor Quick Links