Boulder Community Hospital computer records back on line - but something does not add up

This post is in followup to my March 20, 2013 post "Boulder Community Hospital computer system crash: Either you're in control of your information systems, or they're in control of you".

At a March 24, 2013 Denver Post article "Boulder Community Hospital computer records back on line" the following statements are made:

The computer system that Boulder Community Hospital uses to manage patient records, which had been down for almost two weeks, is now up and running again, hospital officials said Saturday.

Meditech, the system used by the hospital to manage patient records, went down March 12 and affected the hospital, its Foothills campus, eight laboratories and six imaging centers. It was put back into full service at about 3 p.m. Friday, according to hospital spokesman Rich Sheehan.

Sheehan said an investigation showed the outage was a result of a malfunction in one of the main computer servers ... the hospital has replaced the hard drives for the server that failed and are inspecting the remaining servers ... [the failure] resulted in the system being unable to access patient information. The malfunction affected both the primary server and a backup server kept off-site.

A hard drive failure led to a two-week outage of an entire EHR system and its offsite backup server?  A mission-critical system in a hospital is so fragile that a hard drive failure caused a two week outage?

If so, that itself shows, at best, poor overall system design with regard to reliability and redundancy (any server worth its salt has hard drives in a failure-tolerant configuration e.g., RAID), but also is not quite credible on its face.  A remote server should not be taken down by the failure of a local server.  I suspect the failure was more than just a hard drive failure, including software bugs or configuration errors, mass hardware and/or network failure, or even sabotage.

The following statement also lacks believability on its face:

... All patient data was recovered except for an eight-hour period the day of the outage. Sheehan said the hospital had to re-create, re-enter and validate the patient information for that eight-hour period before the system could resume normal operations.

If an information system is down for two weeks, there's two weeks worth of data lost.

... Sheehan said the hospital has replaced the hard drives for the server that failed and are inspecting the remaining servers. The hospital is also now doing data backups every four hours as opposed to every six hours, and is planning on doing hourly backups by the end of the week.

Replacing a failed hard drive is an inadequate precaution.  A 'system redundancy makeover' seems in order for when the next hard drive fails.   Hard drives have a very well known MTBF (mean time between failure) and annual failure rate.  (The very Seagate ST3750528AS hard drive in the PC I am typing this blog post on has an Annualized Failure Rate of 0.34%, per the manufacturer's publicly-available literature.) 

... An independent consulting firm also has been hired to conduct an investigation. The hospital said it expects a report within a few weeks. 

As other organizations are using Meditech products, Joint Commission Safety Standards (as I wrote in a 2009 JAMA letter to the editor "Health Care Information Technology, Hospital Responsibilities, and Joint Commission Standards" available at this link) call for sharing the results of that report with other organizations.  I had discussed this letter numerous times with senior Joint Commission leadership.

Will sharing of the independent consultant firm's report happen?  Probably not.

However, rest assured the Plaintiff's attorneys of Colorado will request it in malpractice suits that arose during the time period of outage.

-- SS

Healthcare IT Transparency Could Stand Some Improvement

Transparency in the health IT sector is akin to the transparency of Pb (lead).

The following report comes from the FDA Maude (Manufacturer and User Facility Device Experience) voluntary-reporting database, reported by a (likely unhappy) biomedical engineer a month after the "incident" - the nature of which is deliberately kept hidden.  This is regarding the PICIS "Pulsecheck" EHR for emergency departments:

Report Date     05/14/2010

PICIS INC. CARESUITE ED PULSECHECK S/W, TRANSMISSION & STORAGE PATIENT DATA
Event Type:  Other
Patient Outcome:  Required Intervention

Event Description

The customer has reported a patient incident that has prompted a review of their internal process and possible issues surrounding the incident. The customer report alleges the involvement of picis' ed (emergency dept. ) electronic health record application, whereby, duplicate results were received by the picis ehr application from an enterprise info system, which, when displayed in their entirety may have contributed to some degree of confusion for the treating physician - the context of which the customer has declined to clarify any further.  [What in the world? -ed.] At this time, we have been informed by the customer that they are restricted by senior leadership from disclosing any specific details regarding the patient's status, the specific type of result or evidence of application performance to support picis' investigation.

"Restricted by senior leadership from disclosing any specific details regarding the patient's status, the specific type of result or evidence of application performance to support Picis' investigation?"

That is perverse on its face, and probably in violation of Joint Commission safety standards on reporting of incidents that could affect other organizations.

Manufacturer Narrative

Picis' investigation into the reported incident is based on a limited exchange of info with the customer, as well as our internal review of the application design and current configuration in use at the reporting site. Review of configuration files, existing system build at the client site, interface specification documents and previous customer communications demonstrate that the customer implemented and accepted the picis edis in 2008. During this process, the picis edis system was configured to display all results sent from the customer's enterprise system rather than configuring the results display in 'overwrite' mode. Prior to acceptance, an investigation by picis and the client revealed that it was the sending system, sending multiple duplicate results messages [great quality - ed.] and a request was made by the customer of that enterprise vendor [I can only wonder who that was - ed.] to investigate. However, due to the enterprise system's protocol for 'add on' tests, it was not possible to utilize the 'overwrite' configuration due to the risk of filtering out unique results and subsequently not presenting the clinicians with important info. Therefore, the customer elected to have all results displayed.

A workaround that apparently, from the limited information provided, led to physician confusion..."the context of which the customer had", not very helpfully, "declined to clarify any further."

Hospitals also are required to have add'l safeguards in place for the handling of critical results including expedited reporting of critical results with a licensed responsible caregiver rather than relying solely on standard results reporting processes (joint commission national patient safety goal 02. 03. 01).

This is not a resounding statement of confidence in health IT...

The customer is currently working with a 3rd party integration consultant to improve the handling of results sent to picis' electronic health record application. We are providing support as it is requested. At this time, no corrective action is needed. 

The "senior leadership" that withheld details was protecting what, exactly?  Money and contracts, perhaps; conflicts of interest, possibly ... but not patients.

All I can say is:

Imagine if this was a report on a new drug suspected of harming people. 

What in heaven's name was going on here?

As I've written many times, and as illustrated by this MAUDE report, the health IT industry must first be transformed into one of evidence-driven IT practices and transparency before anyone touting its products has any business even speaking about the technology "transforming medicine."

-- SS

Did Joint Commission Accredit a Hospital Whose Understanding of Medication Reconciliation is Recklessly Superficial?

I submitted this complaint to the Joint Commission today.

I've been challenging them in recent years (especially since my JAMA letter "Health Care Information Technology, Hospital Responsibilities, and Joint Commission Standards" on hospital executive's violation of JC Safety Standards of July 2009) over the issue of their accreditation of hospitals using bad health IT.

Eventually, I hope, they will take a leadership role on health IT risk, lest they become a target for litigation.  (I think they're already there for their inaction on EHR problems despite admitted knowledge of the problems, in print, e.g., in their 2009 Sentinel Events Alert on Health IT Risks.)

Here is my complaint submitted both via email and via the Joint Commission "Report a Complaint online" page.  I added a few comments for readers in [bold red italics] that, of course, were not part of the submission:

------------------------------

Thank you for submitting your complaint!     Monday, August 20, 2012

Your complaint incident number is:     ########-########

------------------------------

Dear Joint Commission,

I also sent this complaint to PSchyve, AGiuntoli and MChassin via email.

You are already aware of the injury and death from Med Recon failure of my mother at [name redacted] Hospital, in an incident that began May 19, 2010.  Reference Incident #######-######.

I am also filing the issue below as a formal JC complaint:

As demonstrated in the sworn defense response by [name redacted] Hospital today, 8/20/12, the hospital has a very superficial understanding of Med Recon and Med Recon Failure. 

I am assuming they passed Joint Commission Accreditation that includes the ability to ensure continuity of care, including giving correct meds via Med Recon.

The hospital through defense counsel today (8/20/12) writes in a document I've placed at [URL redacted]:  

... 4.  As plead [sic -ed.], the gravamen [the basic gist of every claim or charge in a complaint - ed.] of Plaintiffs complaint is the allegation that he told the treating professionals about Mrs. Silverstein's Sotalol medication.

5.  Therefore, the central issue of this case is one of human communication- i.e., whether Dr. Silverstein told the various staff or not.  [In other words, their obligations to check medications end there - ed.]

In fact, the complaint was quite clear:

...32.  The tortious conduct of defendant [name redacted] Hospital consisted of the following:

a. vicarious liability for the actions of its agents [redacted], [redacted] and [redacted] to ensure continuation of the Sotalol therapy [can we all agree that's a primary responsibility of a hospital and its agents? - ed.];

b. vicarious liability for the actions of its agents [redacted], [redacted] and [redacted] to ensure proper operation of the defendant’s EMR system so as to ensure continuation of a presently active medication;

c. vicarious liability for the failure of its agents identified in this complaint to adequately communicate Ms. Silverstein’s complete medication history with the subsequent treating health care providersduring this admission;

d. vicarious liability for the failure of its agents, identified in this complaint, to question why no Sotalol was ordered given the noted history of arrhythmia [a medical student-level question - ed.];

e. failure to have in place adequate procedures or policies to insure that presently active medications are continuously active in the EMR system unless deactivated by an appropriately qualified health care provider;

f. failure to have in place adequate procedures or policies to insure that the computer generates appropriate alerts for others to see when critical medications become inactive;

g. failure to properly assess the operational effectiveness of its EMR system so as to insure that presently active medications are automatically continued unless specifically deactivated by a qualified and authorized health care provider.

33. As a result of the above identified failures in medication administration and medical record charting, Ms. Silverstein has suffered the following:

a. Intracranial hemorrhage; b. atrial fibrillation; c. damage to her nerves and nervous system, including memory difficulties, and seizure activity; d. brain compression due to the intracranial hemorrhage; e. requirement for additional procedures; f. prolonged hospitalizations; g. need for rehabilitation; h. need for continuous therapies; i. pain, suffering, embarrassment, humiliation, and the loss of life’s pleasures; j. death.

While I gave the history of Sotalol to the clinicians on 5/19/10 (my mother had been on it dating to 2002) as I had done multiple times in this ED, this hospital seems to believe its Med Recon responsibilities end at the family - even when they have records in abundance in their paper records and EHRs (ED and floor), including from just a few weeks prior, with current med lists.

I note (as I had previously sent you) that Pennsylvania's Medicare QIO, Quality Insights, found the hospital had failed in medication continuity, and that the failure to administer Sotalol caused the recurrent A. fib and subsequent complications, the care not meeting professionally accepted standards. [The formal terminology for "malpractice" - ed.]

If you accredited this hospital, as I believe you did, this superficial understanding of Med Recon that you apparently missed or recklessly glossed over poses a serious danger to the community, and contributed materially to my mother's injuries, suffering and death.

Sincerely,

S. Silverstein, MD

Cc:  [attorney handling the malpractice lawsuit]

- end complaint -

--------------------

They defense is also trying to deflect the Judge from the issue of Metadata:

... At this point in time, it is respectfully submitted that the proposed electronic discovery is not relevant to the central issue of this case. For example, if the Triage Nurse and subsequent providers were all to testify that Dr. Silverstein never informed them that Sotalol was a current medication of Mrs, Silverstein, then the fact that medical record does not record this as a current medication has nothing to do with metadata.

Wrong.

"The fact that medical record does not record Sotalol as a current medication" after the ED encounter on 5/19/10 indicates a forensic examination of the metadata is crucial.

It is in fact only through metadata that it can be determined if the medication, listed as "current" only a few weeks prior and normally visible when the user brings up a patient's record to initiate triage, was deleted by the user (e.g., via "use error" per NIST, related to bad IT design) and how and when; if it ended up in another patient's chart due to malfunction (misidentification); if the EHR malfunctioned and simply erased the med; if the chart was altered to try to hide the mistake, etc.  These are all well known failure modes.  See an example of what metadata can show at this link in a case that settled for over $1 million before a trial even began.

In fact, over and above potentially misrepresenting my and my mother's stated medication history at ED triage:

Note their attempting to deflect attention away from health IT and the med recon failure of their own staff.  

Also note a reckless understanding of Medication Reconciliation, that seems to imply the hospital believes it had no duty to reconcile meds with itself, that is, check its own EHR or paper records from just a few weeks prior along with multiple others dating back 8 years, or check with the hospital-affiliated primary care and other physicians treating the patient for years, who were reachable via a simple phone call.  Instead, the issue of whether a family member told "them about the med or not" seems to be their central defense.   

On the issue of who's actually responsible (and liable) for Med Recon, from the American Medical Association monograph entitled "The physician’s role in medication reconciliation", pg. 3.  

... The essence of medication reconciliation is making sense of a patient’s medications and resolving conflicts between different sources of information [paper, electronic, verbal, information from other physicians treating the patient, etc. - ed.] to minimize harm and to maximize therapeutic effects. It is an ongoing, dynamic, episodic and team-based process that should be led by and is the responsibility of the patient’s attending or personal physician in collaboration with other health care professionals. Medication reconciliation is essential to optimize the safe and effective use of medications. It is one element in the process of therapeutic use of medications and medication management for which physicians are ultimately held legally accountable.

The AMA monograph has a special section starting on p. 20 on IT and Med Recon.  It warns explicitly about practicing medicine like a mindless robot:

... IT systems and applications do have the potential to streamline the medication reconciliation process—especially assembling and storing patient information—and to provide the means to effectively transfer patient medication information across the continuum of care. However, health care technology is fragmented and requires close attention by potential users to ensure that implementation does not create additional pressures and problems with accuracy of medications.

The apparent hospital misunderstanding of Med Recon could - and in my view, should - result in charges of gross negligence, perhaps criminal, against its medical leadership if other patients have been, or are, harmed as a result of resultant medication reconciliation errors.

Of course, it's also possible that the defense is just making stuff up again to try to blow smoke up the judge's behind.  However, what's sworn certainly should not be lightly dismissed. 

I also note that this hospital is making a spectacle of itself in front of the Judge, the President Judge in the county where it conducts operations, who already dismissed a boatload of meritless claims.  That does not bode well for them in the future.

-- SS

Joint Commission Should Be Named As Defendant If Patients Harmed by EHR "Outages"

At my recent post "Massive Health IT Outage: But, Of Course, Patient Safety Was Not Compromised" over a massive, outrageous Cerner outage to hospitals contracting their clinical IT via an ASP model (that is, 'software as a service'), I observed:

... The Joint Commission, for example, likely issued its stamp of approval for the affected hospitals, hospitals who had outsourced their crucial medical records functions to an outside party that sometimes went mute.  If someone was injured or died due to this outage, they would not care very much about the supposed advantages.

From the JC's page "About the Joint Commission":

An independent, not-for-profit organization, The Joint Commission accredits and certifies more than 19,000 health care organizations and programs in the United States. Joint Commission accreditation and certification is recognized nationwide as a symbol of quality that reflects an organization’s commitment to meeting certain performance standards.

It's time to up the ante regarding this accreditation body, fully aware of health IT risks (e.g., the Dec 2008 Sentinel Events Alert on Health IT) but to date having done little about them.  Through my legal work and my speaking to Plaintiff's attorneys, I am becoming increasingly aware of medical malpractice cases that  involve an EHR or related clinical IT systems at JC-accredited organizations.

In effect, the JC has accredited hospitals whose entire clinical command-and-control structure (the term EHR is an anachronism; these systems are in reality enterprise clinical resource management and clinician workflow control devices) can disappear in the blink of an eye, without warning, raising risk to patients greatly.

If I discover that a patient was harmed or killed as a result of, or related to, this massive recent outage of outsourced medical records/workflow control  infrastructure, I will be recommending that the Joint Commission, including its leadership, which likely certified the hospital(s) involved for safe operations in areas such as Information Management, be named as defendants.

I have informed the JC leadership by email.
 
-- SS

Doctors and EHRs: Reframing the "Modernists v. Luddites" Canard to The Accurate "Ardent Technophiles vs. Pragmatists" Reality

One manner by which Healthcare's core values are usurped is via distortions and slander about physicians and other clinicians.

At "Health IT: Ddulites and Irrational Exuberance" and related posts (query link) I've described the phenomenon of the:

'Hyper-enthusiastic technophile who either deliberately ignores or is blinded to technology's downsides, ethical issues, and repeated local and mass failures.'

I have called this personality type the "Ddulite", which is "Luddite" with the first four letter reversed. I have also pointed out that the two are not exact opposites, as the Luddites did not endanger anyone in trying to preserve their textile jobs, whereas the Ddulites in healthcare IT do endanger patients.

Yet, in the 20 years I've been professionally involved in health IT, I have frequently heard the refrain, usually from IT personnel and their management, that "Doctors resists EHRs because they are [backwards, technophobic, reactionary, dinosaurs, unable/unwilling to change, think they are Gods, ..... insert other slanderous/libelous comment].

I've heard this at Informatics meetings, at medical meetings, at commercial health IT meetings (e.g., Microsoft's Health Users Group, and at HIMSS), at government meetings (e.g., GS1 healthcare), and others.

The summary catchphrase I've heard and seen (even in the comments on this blog) is that doctors are "Luddites" while IT personnel are forward-thinking, know better than doctors, and are "Modernists."

This slander and libel of physicians and other clinicians needs to stop, and the entire issue needs to be reframed.

Doctors are pragmatists. When a new technology is rigorously shown to be beneficial to patients, and (perhaps more importantly) rigorously shown not to be of little benefit or worse, significantly harmful, doctors will embrace it. There are countless examples of this that I need not go into. They also have responsibilities, obligations, ethical considerations, liabilities, and other factors to consider in their decisions:

Pragmatism (Merriam-Webster):

: a practical approach to problems and affairs

The reality is not:

Luddite doctors <---- are in tension with ----> Modernist IT personnel

but is:

Pragmatist doctors <---- are in tension with ----> Ardent technophiles (Ddulites)

The technophiles' views may be due, on the one hand, to ignorance of medicine's true complexities and "innocent" overconfidence in technology. Unfortunately, it is a gargantuan leap of logic to go from "well, computers work in tracking FedEx packages and allowing me to withdraw money from my U.S. bank when I'm abroad, to "therefore with just a little work they will transform medicine."

Anyone familiar with even the most fundamental issues in Medical Informatics is aware of this. (This is the problem with "generic management" of healthcare IT - healthcare amateurs are unfamiliar with these issues.) Due to the complex, messy social, scientific, informational, ethical, cultural, emotional and other issues relatively unique to medicine, that leap from banking/widget tracking/mercantile computing --> medicine is probably more naive than the leap in logic, for instance, that would have a person believe since a hot air balloon can go high in the sky, it can take a person to the moon, as I observed here.

On the other hand the technophile's expressed views can also be a territorial ploy with full awareness of, and reckless disregard for, the consequences of technology's downsides.

(The CIO where I was a CMIO was well-known to be an aficionado of Sun Tzu's "Art of War" in his corporate politics - the polar opposite of a 'team player.' I might add that the doctors were fully expected to be 'team players'.)

Part of the struggle between the health IT industry and medical professionals has also been control of information flow about HIT.

This has been brought to the fore by my observation of the almost uniformly negative comments on today's HIT at the physician-only site Sermo.com. Sermo is populated, I might add, not by computerphobes but by physicians in a wide variety of specialties using computers for social networking. These comments will hopefully soon be published.

(They are not dissimilar to the many comments I reported in my Jan. 2010 post "An Honest Physician Survey on EHR's", although some might call the sponsor of the latter survey, AAPS, biased. I do not think the same can be said of Sermo.com, an open site for all physicians.)

I have mentioned on this blog the numerous impediments to flow of information about health IT's downsides, and these impediments are well described, for example, in the Joint Commission Sentinel Events Alert on Health IT (link), the FDA Internal Memorandum on H-IT Safety (link) and elsewhere (such as at link, link).

The Institute of Medicine of the National Academies noted this in their late 2011 study on EHR safety:

... While some studies suggest improvements in patient safety can be made, others have found no effect. Instances of health IT–associated harm have been reported. However, little published evidence could be found quantifying the magnitude of the risk.

Several reasons health IT–related safety data are lacking include the absence of measures and a central repository (or linkages among decentralized repositories) to collect, analyze, and act on information related to safety of this technology. Another impediment to gathering safety data is contractual barriers (e.g., nondisclosure, confidentiality clauses) that can prevent users from sharing information about health IT–related adverse events. These barriers limit users’ abilities to share knowledge of risk-prone user interfaces, for instance through screenshots and descriptions of potentially unsafe processes. In addition, some vendors include language in their sales contracts and escape responsibility for errors or defects in their software (i.e., “hold harmless clauses”). The committee believes these types of contractual restrictions limit transparency, which significantly contributes to the gaps in knowledge of health IT–related patient safety risks. These barriers to generating evidence pose unacceptable risks to safety.[IOM (Institute of Medicine). 2012. Health IT and Patient Safety: Building Safer Systems for Better Care (PDF). Washington, DC: The National Academies Press, pg. S-2.]

Also in the IOM report:

… “For example, the number of patients who receive the correct medication in hospitals increases when these hospitals implement well-planned, robust computerized prescribing mechanisms and use barcoding systems. But even in these instances, the ability to generalize the results across the health care system may be limited. For other products— including electronic health records, which are being employed with more and more frequency— some studies find improvements in patient safety, while other studies find no effect.

More worrisome, some case reports suggest that poorly designed health IT can create new hazards in the already complex delivery of care. Although the magnitude of the risk associated with health IT is not known, some examples illustrate the concerns. Dosing errors, failure to detect life-threatening illnesses, and delaying treatment due to poor human–computer interactions or loss of data have led to serious injury and death.”

I note that the 'impediments to generating evidence' effectively rise to the level of legalized censorship, as observed by Koppel and Kreda regarding gag and hold-harmless clauses in their JAMA article "Health Care Information Technology Vendors' Hold Harmless Clause: Implications for Patients and Clinicians", JAMA 2009;301(12):1276-1278. doi: 10.1001/jama.2009.398.

Pragmatist physicians are quite rightly very wary of the technology as it now exists.

Ultimately, even when information on HIT risks or defects does surface, it is highly inappropriately labeled as "anecdotal" (see this post on anecdotes for why this behavior is inappropriate).

This "anecdotalist" phenomenon occurs right up to the HHS Office of the National Coordinator for Health IT (ONC), as I described in my post "Making a Stat Less Significant: Common Sense on 'Side Effects' Lacking in Healthcare IT Sector" and elsewhere.

Therefore, another part of reframing the pragmatism vs. technophilia issue is for clinicians to put an end to censorship of HIT adverse experiences.

I have the following practical suggestions, used myself, to start to accomplish the latter goal.

These suggestions are in the interest of protecting public health and safety:

When a physician or other clinician observes health IT problems, defects, malfunctions, mission hostility (e.g., poor user interfaces), significant downtimes, lost data, erroneous data, misidentified data, and so forth ... and most certainly, patient 'close calls' or actual injuries ... they should (anonymously if necessary if in a hostile management setting):

(DISCLAIMER:  I am not responsible for any adverse outcomes if any organizational policies or existing laws are broken in doing any of the following.)

• Inform their facility's senior management, if deemed safe and not likely to result in retaliation such as being slandered as a "disruptive physician" and/or or being subjected to sham peer review (link).

• Inform their personal and organizational insurance carriers, in writing. Insurance carriers do not enjoy paying out for preventable IT-related medical mistakes. They have begun to become aware of HIT risks. See, for example, the essay on Norcal Mutual Insurance Company's newsletter on HIT risks at this link. (Note - many medical malpractice insurance policies can be interpreted as requiring this reporting, observed occasional guest blogger Dr. Scott Monteith in a comment to me about this post.)

• Inform the Joint Commission (or similar national accreditor of hospital safety if not in the U.S.) via their complaint site at http://www.jointcommission.org/report_a_complaint.aspx . Also consider writing the JC senior officers (link to officer's list), whose awareness of HIT issues I can personally attest to via our correspondences.

• Inform the FDA (or similar healthcare regulator if not in the U.S.) via the FDA Medwatch Form 3500 reporting site at https://www.accessdata.fda.gov/scripts/medwatch/medwatch-online.htm. An example of such an adverse event report I filed myself (when the involved hospital refused) is at this link in the FDA MAUDE (Manufacturer and User Facility Device Experience) database.

• Inform the State Medical Society and local Medical Society of your locale.

• Inform the appropriate Board of Health for your locale.

• If applicable (and it often is), inform the Medicare Quality Improvement Organization (QIO) of your state or region. Example: in Pennsylvania, the QIO is "Quality Insights of PA."

• Inform a personal attorney.

• Inform local, state and national representatives such as congressional representatives. Sen. Grassley of Iowa is aware of these issues, for example.

• As clinicians are often forced to use health IT, at their own risk even when "certified" (link), if a healthcare organization or HIT seller is sluggish or resistant in taking corrective actions, consider taking another risk (perhaps this is for the very daring or those near the end of their clinical career). Present your organization's management with a statement for them to sign to the effect of:

"We, the undersigned, do hereby acknowledge the concerns of [Dr. Jones] about care quality issues at [Mount St. Elsewhere Hospital] regarding EHR difficulties that were reported, namely [event A, event B, event C ... etc.]

We hereby indemnify [Dr. Jones] for malpractice liability regarding patient care errors that occur due to EHR issues beyond his/her control, but within the control of hospital management, including but not limited to: [system downtimes, lost orders, missing or erroneous data, etc.] that are known to pose risk to patients. We assume responsibility for any such malpractice.

With regard to health IT and its potential negative effects on care, Dr. Jones has provided us with the Joint Commission Sentinel Events Alert on Health IT at http://www.jointcommission.org/assets/1/18/SEA_42.PDF, the IOM report on HIT safety at http://www.modernhealthcare.com/Assets/pdf/CH76254118.PDF, and the FDA Internal Memorandum on H-IT Safety Issues at http://www.scribd.com/huffpostfund/d/33754943-Internal-FDA-Report-on-Adverse-Events-Involving-Health-Information-Technology.

CMO __________ (date, time)
CIO ___________ (date, time)
CMIO _________ (date, time)
General Counsel ___________ (date, time)
etc."

• If the hospital or organizational management refuses to sign such a waiver (and they likely will!), note the refusal, with date and time of refusal, and file away with your attorney. It could come in handy if EHR-related med mal does occur.

• As EHRs remain experimental, I note that indemnifications such as the above probably belong in medical staff contracts and bylaws when EHR use is coerced.

These measures can help "light a fire" under the decision makers, and "get the lead out" of efforts to improve this technology to the point where it is usable, efficacious and safe.

-- SS