It was good to see the critical thought processes and the scientific methods inherent in modern medicine applied to the irrational exuberance and marketing-dominated field of healthcare IT.
It seems in 2010 the trend may continue.
Two new very interesting publications have recently come to my attention regarding the complications that can, and are, introduced by HIT.
These complications are worsened by the "boatload of cash," as one author expressed it, that is helping fuel what I term an irrational exuberance, or purchased exuberance, in this technology and its use in social re-engineering in medicine.
-----------------------
The first publication of note is a newsletter "Medical Risk Management Advisor" from ProAssurance Indemnity Company, Inc. and affiliates, a provider of medical insurance for clinicians. It can be downloaded here (PDF). It advises:
On choosing an EHR system:
Be sure to obtain physician input and review of the software prior to purchase to ensure it meets the needs of your practice. Consider talking to other medical practices already using the software, not only to assist in your decision, but to anticipate flaws or errors existing users may have encountered. Lastly, establish a process to address problems discovered after implementation.
"Anticipating flaws or errors existing users may have encountered" seems to be at odds with nondisclosure clauses in heathcare IT contracts, but this insurer seems to have gotten the message that HIT is not a perfected technology by a long shot.
On Alert fatigue:
Physicians may ignore e-prescribing alerts for a variety of reasons (e.g., excessive alerts or alerts that are not clinically useful). Again, input from physicians prior to implementation can help prioritize and choose alerts appropriate to the practice.
That the advice has to be given by an insurance company to healthcare organizations that "input from physicians prior to implementation" is crucial reflects a pathology, whose root is within the paternalistic and patronizing IT culture.
This culture and occupation has invaded medicine and supplied endless predictions of utopia for at least the past thirty years, in a domain it generally understands at the level of a layperson.
On "additional features" creating risk: [HIT incurs risk? How can the tool touted to revolutionize medicine incur risk? - ed.]
For example, some software programs require a diagnosis listed with each prescription. Consider the following: a patient is on Depakote for bipolar and seizure disorders, but the e-prescribing system only notes bipolar disorder because of its one-diagnosis limitation by design.
Subsequently, the patient becomes manic and the on-call psychiatrist starts the patient on lithium for the bipolar disorder. Checking the e-prescribing system, he notes Depakote was prescribed for bipolar disorder so he titrates the Depakote to discontinuation.
The patient has a seizure during the titration which leads to death.
The on-call psychiatrist assumed the patient was on Depakote solely for bipolar disorder and not seizures. If the diagnosis feature had been more extensive or had not been used with the software, the on-call psychiatrist might have explored further before discontinuing the Depakote.
Again, input from physicians prior to implementation may help prevent potential risks.
(According to Socky the Meditech Sockpuppet, such events are impossible.)
On Interoperability:
Another issue is whether your e-prescribing system fully integrates with pharmacy systems. Using the previous example, what if the diagnosis was changed in the psychiatrists’ system, but the pharmacy system did not automatically update this information? Be sure to investigate the compatibility of your system with others in your area. Not all pharmacies have e-prescribing capabilities. Many rural areas do not have the broadband internet access required.
It is unfortunate that the HIT vendor community is based on a business-computing model. That culture is extremely territorial. Seamless interoperability will be a long time in coming in HIT.
On Medication Reconciliation:
Physicians and pharmacies may find it difficult to trust the completeness and currency of the medication history and reconciliation, since medication histories often derive from multiple sources. Continue to verify medication histories with patients, and update records accordingly.
What? Actually not rely on the computer? What kind of extremist anti-health IT Luddite advice is this insurer proffering?
On Indemnity or "Hold Harmless" agreements:
Finally, be cautious about entering into hold harmless agreements with software vendors. Your ProAssurance policy excludes from coverage liability assumed under any contract or agreement, unless the liability would be imposed by law in the absence of the contract or agreement. It covers only the insured’s professional liability and not the liability of another party that the insured may assume through an indemnity agreement. If you are asked to sign such an agreement, you should have your attorney carefully review the agreement and your insurance policy.
I did not think of this issue when I wrote my July 2009 JAMA letter to the editor and a fuller posting on this issue at my Drexel HIT difficulties website here.
In addition to violating their fiduciary responsibilities and Joint Commission Safety Standard obligations, hospital executives signing nondisclosure and hold harmless agreements may be putting their organizations under undue financial risk if a HIT-related catastrophe occurs.
-----------------------
The second publication of note is an article from the IEEE (Institute of Electrical and Electronics Engineers). A Jan. 6, 2010 IEEE Spectrum article entitled "More Hurdles Appear in U.S. Electronic Health Record Adoption" has been published. I would actually have entitled it "More Hurdles Exposed in U.S. EHR Adoption", but that's not important now.
What is important, once again, is the Management Information Systems (business computing) approach to healthcare IT. The typical convoluted licensing arrangements for this software (really a virtual clinical tool that happens to reside on a computer) has created this fine mess:
The first was a story from a few months back that [the IEEE author] ran across recently from the Washington State Spokesman-Review about Inland Northwest Health Services suing the owner of Deaconess Medical Center, which the paper said alleged breach of "contracts and bad faith dealings that imperil the region's acclaimed electronic medical records network.
It is a bit complicated, but in essence, in 1994, Spokane's Deaconess Medical Center, Providence Holy Family Hospital, Providence Sacred Heart Medical Center & Children's Hospital and Valley Hospital & Medical Center established the non-profit Inland Northwest Health Services (INHS) as a way to merge competing lines of business and to oversee them. One of the things INHS did was to invest in electronic medical records using MEDITECH's technology. [You mean this Meditech? - ed.]
Apparently, Community Health Systems, a Tennessee company that bought Spokane's Deaconess Medical Center and Valley Hospital & Medical Center in 2007 decided that it was going to start charging INHS $150,000 a month to use the MEDITECH license, claiming that Deaconess Medical Center was owner of the license. INHS says that Deaconess transferred ownership to it years ago.
The Spokesman says some 38 hospitals along with many private practices and clinics are affected by the dispute.
The upshot of all this is that license ownership of the underlying EHR technology will likely be a big issue in the future as more regional health information networks are started, as will be technology lock-in (INHS has been using MEDITECH technology for 13-years, and it moving to another EHR is unlikely to be an easy or inexpensive proposition). Neither issue has appeared much in the EHR literature.
Yes, indeed, except once again I would have written:
The upshot of all this is that license ownership of the underlying EHR technology will likely be a big disaster in the future...
... as the HIT vendors will likely only allow their profitable licensing practices to be pried from their cold, dead fingers (metaphorically speaking, of course).
Then, this on EHR patient data trafficking:
... there was also a story in the American Medical News in late November about the Cleveland Clinic giving $1 million to a start-up company called Explorys to "commercializing the patient database search system Cleveland Clinic developed." The Cleveland Clinic has a very extensive EHR system and data base of patient information that it now wishes to exploit.
As I mentioned last month, there was a report by PricewaterhouseCoopers LLP that found 76% of healthcare executives surveyed felt that all the data being collected in their EHR systems was going to be their organization's greatest asset over the next five years. It also found that the executives only felt they could recoup their investments if they could exploit that information in some way.
The IEEE author largely addresses health IT failure as an impediment to such EHR patient data trafficking. In my Oct. 2009 post "Health IT Vendors Trafficking in Patient Data?" I came at the issue from an ethical and legal angle. I wrote:
This practice [trafficking in EHR patient data] raises numerous questions:
- Meaningful informed consent issues: as an example, of 1000 patients at one of the facilities using this vendor's HIT products, what percentage would be able to tell me they know their data is being trafficked to pharmaceutical companies and other organizations for profit?
- Healthcare data ownership and stewardship issues: who, exactly, extracts the data for aggregation and sale? Hospital employees properly trained and bonded (i.e., Healthcare Information Management professionals) regarding privacy of patient data? IT personnel lacking such credentials and experience? HIT vendor employees?
- De-identification issues: what processes are being used to de-identify data? Who is performing it? At some point before the data is de-identified, it is protected information in identifiable form. Is access to the data during de-identification audited in any way, and if so, by whom? If not, why not? (Also see article on re-identification below.)
- Legal issues: who is, by contract, liable for data breaches that occur in the transfer process?
- Fiduciary issues: as I expressed in my July 22, 2009 JAMA letter to the editor regarding "vendor hold harmless" and IT defects gag clauses, are hospital executives further violating their fiduciary responsibilities by signing HIT contracts that surrender ownership of patient data to third parties? (see my posts "JAMA letter: Health Care Information Technology, Hospital Responsibilities, and Joint Commission Standards" and "Inquiry to Joint Commission on points I raised in my JAMA letter on HIT" for more on those issues.
- Pharma integrity issues: with the many stories on this blog and others about ethically questionable pharma practices such as ghostwriting, manipulation of clinical research, suppression of research, pushing drugs on physicians and patients for unapproved off-label uses, etc., what are these organizations going to do with the data? Who will have access to it, and will their access be audited? Are they going to resell it? Might they try to re-identify data to locate individuals of interest? And so forth.
Serious consideration of these issues in vendor-led healthcare data trafficking becomes more imperative in the face of just how easy it is to "re-identify" data:
Ohm, Paul: "Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization" (August 13, 2009). University of Colorado Law Legal Studies Research Paper No. 09-12. Available at SSRN: http://ssrn.com/abstract=1450006
In Dec. 2007 I'd also presented to the IEEE Medical Technology Policy Committee on some of these issues in "To the Moon in a Hot Air Balloon: Why is Clinical IT Difficult?". In response, they introduced me to the term "resilience engineering" in the sense that healthcare IT was lacking in that particular characteristic:
The term Resilience Engineering represents a new way of thinking about safety. Whereas conventional risk management approaches are based on hindsight and emphasise error tabulation and calculation of failure probabilities, Resilience Engineering looks for ways to enhance the ability of organisations to create processes that are robust yet flexible, to monitor and revise risk models, and to use resources proactively in the face of disruptions or ongoing production and economic pressures.
Health IT as a cybernetic miracle? As I've stated before, healthcare is a harsh environment for cybernetics, talent to accomplish the needed IT and medical culture changes essential to successful computerization in medicine is grossly mismanaged by the HIT and hospital industries, and reality is a harsh mistress.
-- SS
RSS Feed (xml)