Health Care Information Technology Vendors Hold Harmless Clause
Total Page：16
File Type：pdf, Size：1020Kb
Health Care Information Technology Vendors’ “Hold Harmless” Clause Implications for Patients and Clinicians
In case you haven't seen, please see the attached Commentary from the 3/25 issue of JAMA. The authors discuss the "hold harmless" clause that ostensibly is common in contracts between EHR vendors and health care provider organizations. They argue that this clause, combined with the principle of “learned intermediary” (i.e., the clinician is required to mediate the output of software) excessively shifts liability to the users of EHRs. The result is that users are liable for adverse patient consequences that result from use of the software, even if the software contains errors. The authors review the historical and contextual factors that have led to the current state. They suggest some approaches that might “rebalance” responsibilities between the vendor and the clinician (mostly legal and regulatory approaches). The authors do not state explicitly that the current model decreases the incentives for vendors to do high quality work, but one may take that impression away from the article.
Clearly, many factors contribute to the safe and effective use of health information technology. It seems to me that this Commentary has focused on one factor but has ignored several other important ones. For example, although the article mentions the provider organization’s role in implementation, it doesn’t mention the fact that clinical software almost always needs to be configured by the customer organization and such configuration may be an important source of error. The Commentary also overlooks the work of Randy Miller and Reed Gardner (Ann Int Med;127:842-5, 1997 and JAMIA;4:442-57, 1997) on behalf of AMIA and other organizations that argued for, among other things, formal software oversight activities at provider organizations.
Other organizations also have argued for additional government regulation of EHR systems to assure safety (http://www.thehastingscenter.org/Bioethicsforum/Post.aspx?id=3284). I am concerned that a singular belief that the best way to increase the safety and effectiveness of EHR systems is by legal or regulatory action directed at the system vendor themselves is misplaced. I worry that could stifle innovation and not assure the desired goals. I think at a minimum equal attention needs to be given to the role that provider organizations bring to configuration, management and oversight of the software and related processes. GK
Per Koppel and Kreda, in thinking further about the "hold harmless" and "defects gag clause" originated by Health IT vendors and agreed to by hospital executives as I described at Have Hospital Executives Violated Their Fiduciary Responsibilities by Signing Such Contracts?, I can state I feel a sense of (past) betrayal.
Only now do we formally find out that hospitals have been literally dumping on physicians by signing contracts with the HIT vendors leaving the docs "holding the bag" for software errors and malfunctions, and gagging their organizations from openly talking about defects and problems. In other words, physicians hold the risk, everyone else holds the money.
Actually, since EMR mostly benefits the payers, I'd more correctly say hospital administrations have largely sold physicians down the river, an act that echoes of betrayal let alone breach of fiduciary responsibility and Joint Commission standards I believe apply. Now I know why as CMIO/Director of Informatics Christiana Care in the late 1990's I never got to see the HIT contracts. Ironically, as a Group Director at Merck Research Labs I did review my department's informatics contracts, all several million dollars' worth, and in fact was involved in vendor negotiations.
As a CMIO I likely would have been a lot less eager to try to "sell" the EMR idea to the medical staff if I had been aware of the "vendor held harmless" provisions they faced if a software design problem or glitch contributed to patient harm. I wonder how many former and present CMIO's out there are now thinking along the same lines. SS
I agree that this is a seminal article. I'm fascinated by the learned intermediary concept as a rationale for apportioning blame for errors onto the end users. On one hand, we hear that rates of medical errors are too
Health Informatics Issues Page 1 of 15 2018-04-07 high, that doctors (and other health professionals) can't possibly keep all of the relevant factoids in their heads and that an EHR system (with associated decision support) is the way to reduce errors by making accurate information available at the point of care.
Now we hear that regardless of what the computer tells you (including distracting your clinical thought processes with an endless parade of irrelevancies), you have to be even more careful to keep all of the important factoids in your head, so you can not only determine what to do for your patient but also determine when the computer is making a mistake. Not to mention that some of the mistakes require the skill of Sherlock Holmes to find them ..... One example, without mentioning any vendor names:
Yesterday one of my residents placed an order for a long-acting (Decanoate) injectable psychotropic medication. She chose the correct drug name and dose out of CPOE and the order displayed correctly on the order line. (The dose was a usual one, straight out of the package labeling.) This medication also comes in a short acting injection. Ordering the Decanoate on the floor activated the order for the non-Decanoate short-acting medication in the pharmacy system (made by the same vendor, so it shouldn't be an interface problem). The dosing of the Decanoate and short-acting medication differs (with the Decanaoate dose being 5-10 fold higher); the number of mg of drug/mL of injectable solution also differs between the short acting and Decanoate formulations (the short acting drug is 2.5 mg per mL and the Decanoate is 25 mg per mL). We learned of this problem when the pharmacist called and said that the dose was too high (since she was seeing an order for short-acting drug). It took several of us quite some time (>1 hr) to figure out what was happening, including drilling down through multiple screens to compare order details, going to other on-line databases to find information on the injectable solution concentrations, etc. And we are "highly learned intermediaries" with many years of academic clinical experience, specific expertise in psychopharmacology and even some knowledge of informatics!
How is the typical front-line physician seeing 4+ patients per hour supposed to catch these things? LF
I can hardly wait for the legal beagles in the crowd to jump into the fray. I assume that the “intermediary” is there to distinguish this technology as not dealing directly with the patient, which would move it into the medical device (liability) category. So, to me, this isn’t unusual, but rather – from the vendor’s viewpoint – necessary. The errors are something else again. This is an issue of “Information Systems Assurance” (e.g., http://accounting.uwaterloo.ca/uwcisa/aboutus.htm), which the accountants are promoting. We are in a situation where systems are being fielded without proper regard for their error-proneness and the damage these errors can cause. It seems to me that only through the concepts of ISA can we hold the vendor responsible for errors while retaining these systems as non-directly used devices. DC found this discussion and the Koppel and Kreda article to be quite fascinating. The implications for physicians and patients are certainly distressing (and eye-opening). To me, the concepts of betrayal and being sold up the river include some contribution of intentionality or cognizance on the part of the betrayer.
My first thought on reading this posting was the quotation "Never ascribe to malice that which is adequately explained by incompetence." (which has been attributed to Napolean Bonaparte with multiple related variations being attributed to others). On further reflection, I wondered if it's simply a matter of "fine print" fatigue, analogous to alert fatigue. How many people assiduously read all of the fine print on everything they sign? And when they do read the fine print, how many stop to think of the consequences (intended and unintended) of each of the multiplicity of phrases in such documents?
If all EHR software includes these clauses, do the administrators see themselves as having any element of choice, even if they do recognize the issues? Or are they seeing themselves as picking the lesser of two evils -- an EHR system which is touted to improve safety, reduce costs, enhance nursing
Health Informatics Issues Page 2 of 15 2018-04-07 satisfaction/retention, etc. (but with a flawed contract) versus the current broken system with appropriate ressure from all quarters to reduce the astronomical rates of medical errors? Plus they see various Medicare penalties coming at them that essentially require EHR adoption. Don't get me wrong -- I find the hold harmless clauses and gag provisions extremely problematic -- I'm just not sure that demonizing the hospital administrators is appropriate or productive.
I think it's certainly conceivable to be related to the ordering dictionaries. I don't know the extent to which these come from the vendor vs. constructed/modified by the organization. We were trying to troubleshoot from a purely clinical standpoint so I have no idea what the root cause is at this point -- though we've certainly forwarded the information to IT so that it can be addressed. I actually don't know much about the ordering dictionaries (except that they seem to be too complicated to do much customization, no matter how clinically important). I'm just a poor front-line clinician, who happens to love computers, believes in the promise of EHRs and has invested enough time in that promise to be nearly done with a Master's in Informatics. So I was just trying to provide a very recent example of the way that the clinician and patient are impacted by the learned intermediary concept.
Even so, when health care organizations place a great deal of reliance (and lots of extra funds) on consultants provided by the vendor in terms of setting up such dictionaries, it's hard to see the vendor as totally outside the scope of responsibility. The additional factor that I would see as adding to the murkiness of the picture relates to the software usability at the design level. Even if the dictionary design were done by employees of the organization, I'm not sure how large a contribution the EHR software might play in the error-proneness of that design. From my limited experience, it seems that there are significant numbers of aspects of system infrastructure that are extremely confusing to configure and/or require elaborate (often undocumented) workarounds to get the system to do essential tasks. I've not heard this aspect of EHR usability discussed as a contributor to costs, including error. LF
I have found that most often this type of error occurs when the person mapping the data lacks the clinical background to distinguish between the two formulations. Our CPOE med build team consisted of a physician/informaticist, a PharmD, and a pharmacist reviewing every med built. (Each med built was reviewed by all 3 people.) We have been up on CPOE for 3.5 years with no reports of this type of mapping error in the med build. Consider this to be anecdotal evidence favoring this type of team approach. I have heard many anecdotal examples of med mapping failures when a team with lesser clinical credentials was assigned the task. IMO, med mapping is =not= a place where you want to cut costs. I believe that you will pay later with medical errors. TW
At the risk of being repetitious, this ALL needs to be licensed with a Free/Open Source license. The Affero General Public License is the best for medicine in my opinion. Where we are currently headed with proprietary EMR software is pseudo-science and Alchemy with potentially (I think it is more like 'already') disastrous results. Actually it will be Government-Certified-and-Paid-For-Alchemy which is even worse.
None that aren't little more than 'walled gardens' for the reasons you state. Once the conditioned notion of obligatory charging for licenses is given up then many or the problems simply disappear. It is getting over that notion which is so conditioned that is the hard part. When I tell people about the VistA installers I've released under the AGPL, they invariably ask if I'm going to make a ton of money. They regard me as freaky when I say that I want to benefit society so I do not charge or use a proprietary license for them. IV
Here is a verbatim response from a vendor CEO I received to my post at http://hcrenewal.blogspot.com/2009/03/health-it-hold-harmless-and-defects-gag.html :
As a vendor I am not unsympathetic to your cause - but the reality this is a litigious nightmare - and thus the "hold harmless" cause.
Health Informatics Issues Page 3 of 15 2018-04-07 First the general principle of caveat emptor - the executives often buy without testing the EMR system first - hence 50% of hospitals have EMRs but less than 9% use them significantly.
Second, if the hospital does not install maintain and test a redundant roll over system and hot backup system whose fault is that?
Third, hospitals make it almost impossible to run sophisicated IT systems, that EMRs are, by chronically understaffing, under paying and underfunding the IT functions of their hospitals.
Fourth, determining liability of a missed data point that may or may not have caused all or part of an adverse event and the doctors ultimate responsibility or part responsibilty would be complicated beyond anything but capcious verdicts in the courts.
Fifth, the government is certifying EMRs, so if a certifed EMR, because of that certification feature, causes an error in medical treatment then the government too is liable as whole or part in any legal action.
Sixth, software is a published work - like a manual - if you go out buy a bomb making manual is the publisher responsible if you blow something up? The same can be said in a gun anology - manufacturers are responsible but the bar is high on purpose, it has to be willful or gross negligence.
Finally, just posting or saying you are not responsible for being negligent does not legally exempt you from such.
While I applaud your efforts in making failures known, making political with stronger negligence liability is only going to make lawyers rich and stifle progress.
I won't even comment on my response to these points, only to say that if these (to my eye) elitist and entitled sentiments are at all common, we have a startling cultural barrier to overcome. I also believe if these sentiments are commonplace, my statements about needed to partition business computing and clinical computing leadership and management become even more imperative than I thought.
I believe the Koppel/Kreda article, in fact, further substantiates my belief that business computing and clinical computing are distinct computing subspecialties. By conflating them and using the business practices of MIS for clinical IT, ignoring that there are special third parties, clinicians and patients with rights (the latter two do have rights, correct?), a dire situation has been needlessly created.
Loss of clinician trust in management for not following their fiduciary obligations to protect employees from undue jeopardy, loss of clinician enthusiasm to use clinical IT, loss of patient trust due to lack of informed consent in face of known issues with HIT, etc. are a few of the unexpected, adverse outcomes I see.
If we conflate neurosurgery and psychiatry because thy both involve physicians targeting the brain and CNS, and start treating brain tumors with psychotherapy and mental illness with surgery, we would certainly not expect the best outcomes. Technological determinism a popular cultural fairy tale, however, IT gets a pass from such considerations. To its own detriment. SS
HIT has had the most acceptance in the VHA. Note the title of the book written about that experience: “Medical Informatics 20/20: Quality And Electronic Health Records Through Collaboration, Open Solutions, And Innovation"
Health Informatics Issues Page 4 of 15 2018-04-07 Peter Groen, one of its authors, wrote me this last year and permitted me to share his observations with my students, including this:
... It is weird. I looked at your slides [about HIT difficulty] and the reality you have lived in is very different from mine. I remember when I was hired as the IT person/manager for the Atlanta VA medical center. The first day the Chief of Staff welcomed me. I was not seen as an IT guy, I was seen by him as a fellow member of his clinical team. From there it went uphill for the next 30 years in the VA ...
After the Koppel article, what the commercial HIT industry has done might be summed up by a book title like this:"Medical Informatics 1900 [pre Flexner]: Profit and Electronic Medical Inventory Systems Through Secrecy, Proprietary Closed Busywork Generators, and Innovation Failure."
Finally, one of my correspondents also relates that HIT contracts often have a vendor stipulation that the software "will not be used for medical purposes." Can anyone else comment on knowledge of such clauses? SS
Perhaps because I know Ross Koppel wouldn't in any way disagree that organizational configuration, implementation, and oversight activities are terribly important, I did not read the JAMA piece he co- authored as advocating only a regulatory approach to safety and effectiveness. Ross is a sociologist, and his work on patient safety looks at multi-faceted interactions that can result in creating potentially harmful situations, including unintended consequences of mandates, whether contractual, organizational, or governmental. As a fellow social scientist, I'd certainly like to see efforts on multiple fronts and, as Gil suggests, "more fulsome" viewpoints that recognize the multiplicity of actors and interrelationships among them within the kinds of legal, regulatory, contractual, organizational, and societal structures currently in existence or that might be proposed. There are many branches and sub-groups within AMIA that could (and do) address these concerns, including WGs and committees as well as ACMI. This JAMA paper can have the positive effect of getting more attention for such issues. My sense of the authors is that they would welcome carrying the conversation forward. BK
Question: Has there ever yet been a lawsuit involving patient harm where this “hold-harmless” clause has been tested? Think in terms of cars: no one would think of holding an automobile manufacturer responsible for an accident unless it can be proven that it was the car itself, and not how it was driven, that was responsible for the accident. If a healthcare provider was going to build a EMR system “in-house”, or, like many organizations, put a web front-end in front of a bunch of different best of breed applications, the healthcare organization itself would be responsible for any patient harm that occurs as a result, except for when they can prove that the harm resulted from someone else’s negligence, and that the system was tested adequately and not used inappropriately.
I don’t see how a complete system purchased from a vendor is any different. I think the “hold-harmless” clause is to protect the vendor from organizations that don’t test their systems and/or use the systems inappropriately. I don’t think the clause would protect the vendor from their own negligence, if it can be proven. JG
> Question: Has there ever yet been a lawsuit involving patient harm where this “hold-harmless” clause has been tested? Good question. If there isn't one, or if there were no such cases that were settled and sealed, I'd be surprised. Expand HIT a hundred fold by 2014, though, and I'd say such suits would be inevitable as things stand. A related question: how many examples of health IT risk has been suppressed by these agreements? It is profoundly unsettling, for example, that my website on HIT difficulties remains nearly unique considering the targeted "hits" it receives from search engines worldwide and the unsolicied stories of woe I receive.
Health Informatics Issues Page 5 of 15 2018-04-07 > Think in terms of cars: no one would think of holding an automobile manufacturer responsible for an accident unless it can be proven that it was the car itself, and not how it was driven, that was responsible for the accident. HIT is a far more complex beast than a car, since factors such as cognitive overload from cluttered screens as well as "Never" events like disparities between input and output can contribute to healthcare mistakes. Perhaps a jet is a better example. If the mfg. of jets knows of a defect that causes autopilot to malfunction or structural element to fall off, and a plane crashes, they certainly share liability. However, what if the design of the cockpit instruments is ill conceived or confusing to the average pilot, especially at times of emergency or stress?
> If a healthcare provider was going to build a EMR system “in-house”, or, like many organizations, put a web front-end in front of a bunch of different best of breed applications, the healthcare organization itself would be responsible for any patient harm. Maybe. It would depend on where the flaw originated and if the web front end contributed in any way (i.e., is it just a windowing system for the applications' own front ends).
> I don’t see how a complete system purchased from a vendor is any different. I think the “hold-harmless” clause is to protect the vendor from organizations that don’t test their systems and/or use the systems inappropriately. I think it's more likely the kind of blanket exculpatory statement one finds in business software EULA's, not to mention I now find out many vendors include a "not to be used for clinical purposes" clause as well. I hope to be getting some examples of that type of language and will post them.
Here's the liability EULA for Windows for example:
LIMITATION ON REMEDIES; NO CONSEQUENTIAL OR OTHER DAMAGES. Your exclusive remedy for any breach of this Limited Warranty is as set forth below. Except for any refund elected by Microsoft, YOU ARE NOT ENTITLED TO ANY DAMAGES, INCLUDING BUT NOT LIMITED TO CONSEQUENTIAL DAMAGES, if the Software does not meet Microsoft's Limited Warranty, and, to the maximum extent allowed by applicable law, even if any remedy fails of its essential purpose. The terms of Section 17 ("Exclusion of Incidental, Consequential and Certain Other Damages") are also incorporated into this Limited Warranty. Some states /jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so the above limitation or exclusion may not apply to you. This Limited Warranty gives you specific legal rights. You may have other rights which vary from state/jurisdiction to state/jurisdiction. YOUR EXCLUSIVE REMEDY. Microsoft's and its suppliers' entire liability and your exclusive remedy for any breach of this Limited Warranty or for any other breach of this EULA or for any other liability relating to the Software shall be, at Microsoft's option from time to time exercised subject to applicable law, (a) return of the amount paid (if any) for the Software, or (b) repair or replacement of the Software, that does not meet this Limited Warranty and that is returned to Microsoft with a copy of your receipt. You will receive the remedy elected by Microsoft without charge, except that you are responsible for any expenses you may incur (e.g. cost of shipping the Software to Microsoft). This Limited Warranty is void if failure of the Software has resulted from accident, abuse, misapplication, abnormal use or a virus. Any replacement Software will be warranted for the remainder of the original warranty period or thirty (30) days, whichever is longer, and Microsoft will use commercially reasonable efforts to provide your remedy within a commercially reasonable time of your compliance with Microsoft's warranty remedy procedures. Outside the United States or Canada, neither these remedies nor any product support services offered by Microsoft are available without proof of purchase from an authorized international source. To exercise your remedy, contact: Microsoft, Attn. Microsoft Sales Information Center/One Microsoft Way/Redmond, WA 98052-6399, or the Microsoft subsidiary serving your country.
16. DISCLAIMER OF WARRANTIES. The Limited Warranty that appears above is the only express warranty made to you and is provided in lieu of any other express warranties or similar obligations (if any) created by any advertising, documentation, packaging, or other communications. Except for the Limited Warranty and to the maximum extent permitted by applicable law, Microsoft and its suppliers provide the Software and support services (if any) AS IS AND WITH ALL
Health Informatics Issues Page 6 of 15 2018-04-07 FAULTS, and hereby disclaim all other warranties and conditions, whether express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of reliability or availability, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the Software, and the provision of or failure to provide support or other services, information, software, and related content through the Software or otherwise arising out of the use of the Software. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON- INFRINGEMENT WITH REGARD TO THE SOFTWARE.
17. EXCLUSION OF INCIDENTAL, CONSEQUENTIAL AND CERTAIN OTHER DAMAGES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, PUNITIVE, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF PROFITS OR CONFIDENTIAL OR OTHER INFORMATION, FOR BUSINESS INTERRUPTION, FOR PERSONAL INJURY, FOR LOSS OF PRIVACY, FOR FAILURE TO MEET ANY DUTY INCLUDING OF GOOD FAITH OR OF REASONABLE CARE, FOR NEGLIGENCE, AND FOR ANY OTHER PECUNIARY OR OTHER LOSS WHATSOEVER) ARISING OUT OF OR IN ANY WAY RELATED TO THE USE OF OR INABILITY TO USE THE SOFTWARE, THE PROVISION OF OR FAILURE TO PROVIDE SUPPORT OR OTHER SERVICES, INFORMATON, SOFTWARE, AND RELATED CONTENT THROUGH THE SOFTWARE OR OTHERWISE ARISING OUT OF THE USE OF THE SOFTWARE, OR OTHERWISE UNDER OR IN CONNECTION WITH ANY PROVISION OF THIS EULA, EVEN IN THE EVENT OF THE FAULT, TORT (INCLUDING NEGLIGENCE), MISREPRESENTATION, STRICT LIABILITY, BREACH OF CONTRACT OR BREACH OF WARRANTY OF MICROSOFT OR ANY SUPPLIER, AND EVEN IF MICROSOFT OR ANY SUPPLIER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
18. LIMITATION OF LIABILITY AND REMEDIES. Notwithstanding any damages that you might incur for any reason whatsoever (including, without limitation, all damages referenced herein and all direct or general damages in contract or anything else), the entire liability of Microsoft and any of its suppliers under any provision of this EULA and your exclusive remedy hereunder (except for any remedy of repair or replacement elected by Microsoft with respect to any breach of the Limited Warranty) shall be limited to the greater of the actual damages you incur in reasonable reliance on the Software up to the amount actually paid by you for the Software or US$5.00. The foregoing limitations, exclusions and disclaimers (including Sections 15, 16 and 17) shall apply to the maximum extent permitted by applicable law, even if any remedy fails its essential purpose. SS
The article Health Care Information Technology Vendors' "Hold Harmless" Clause - Implications for Patients and Clinicians, Ross Koppel and David Kreda, Journal of the American Medical Association, 2009; 301(12):1276-1278 (JAMA) has caused much discussion in healthcare IT circles.
I have become aware of discussions centered on issues such as:
The factors besides vendor design flaws and defects that contribute to the unsafe and ineffective use of health information technology, The degree of effect caused by end user organization customizations, whether a focus on legal or regulatory action is misplaced Whether such regulation could "stifle innovation", and Other interesting and stimulating related issues.
Health Informatics Issues Page 7 of 15 2018-04-07 These discussions miss the forest for the trees, unfortunately. They are all speculation. I could just as easily argue that vendor defects, shortcomings, ill conceived user interfaces etc. are the greatest cause of HIT problems, that a sole focus on regulatory action is the best path, and that regulation would not stifle innovation but promote it by forcing complacent, lazy companies protected by the current status quo to become competitive, to hire the very best and brightest and most experienced who they now forgo as "too disruptive, too expensive, don't have the latest programming skills", etc.
None of this speculation really matters in the big scheme of things. What does matter is the fact that we now have before us a "grand confounder" - the anechoic effect caused by vendor contracting - that throws into doubt existing assumptions about HIT-caused errors. Who among us can now say what the number of physician observed defects really is, what the rate of HIT error really is? I've had several of my colleagues already tell me since the Koppel article that they know of HIT caused errors and even patient adverse consequences, but they are afraid to speak out. What is the morbidity and mortality change associated with use of HIT vs. paper?
Who really knows? There is a significant, perhaps high likelihood that the current state of HIT contracting, and the muting effect it creates, combined with fear of retaliation by potential objective HIT evaluators (a.k.a. whistleblowers) makes any such estimation highly questionable. Speculation is irrelevant. What we need is a return to the rigor of medicine - to science - in HIT itself. That can only happen in an environment where users are free(er) to share their observations and findings about HIT problems. Such one-sided, safety adverse HIT contractual clauses must end. SS
------
I agree with your statement of the problem. I have troubling concerns with a government regulation solution. 'The government' (which government? which bureaucracy? which person?) is nearly always incompetent and takes far too long to understand that there is even a problem, much less find and act on a effective solution. It is also too easy to corrupt. It leads to big business 'too big to fail' corporations re- writing the rules to suit them and controlling politicians and agencies. This is happening now in Health IT. The real regulatory solution is for the government to insist upon and fund purchases of only public domain or Affero General Public Licensed software so that analysis, research and best practices can occur and spread at a much greater speed and without government intervention. Federal regulation is too centralized, slow and expensive to be effective. IV
------
The “non-disclosure rule” prohibit docs from sharing HIT software problems with other docs; hospitals from sharing HIT software problems with other hospitals. They can't take a screenshot and show it to others. It's been recently argued that this clause creates an ethical dilemma for a doc who knows that the same software is in use in X hundred hospitals or X thousand practices. Recently, too, some others say it appears to be against professional ethics, and JC codes. AMIA, to my knowledge, has never spoken out against it. I don't know why. Perhaps because they were not fully aware of it although we know many physicians and hospital folk have raised it repeatedly. Critically here, the clause creates a disincentive for vendors to repair problems quickly...and prevents clinicians from sharing the patient threats with others.
I suspect AMIA will not vigorously fight a discussion of it (although the letter from AMIA leaders did call my JAMA article "mis-directed.") The “hold harmless/learned intermediary clauses”are indeed different from the non-disclosure clause.
(BTW, the learned intermediary clause is used to ensure the vendors are held harmless via the following legal argument: Only the doctor is with the patient. It's the doctor's call about all treatment. If because of a computer bug, the Rx is changed enroute to the pharmacy, or a lab result is put in the wrong chart, or whatever, the doctor should have noticed the error and stopped it from creating any unwanted event. The doctor is the "learned intermediary" with all contextual and theoretic knowledge.") (Oh, to be clear,
Health Informatics Issues Page 8 of 15 2018-04-07 nurses and pharmacists are also considered learned intermediaries and any faults in the software they use is likewise their problems.)
Now, the reason that the hold harmless/learned intermediary clause is so relevant to these working groups and to AMIA is that it also creates a strong disincentive for rapid and responsive correction of known faults. In this way, the effects are similar but for differing reasons.) CMIOs from throughout the nation have each told me they each report up to 5,000 to 7,000 bugs to the vendors -- bugs reported to the vendor, of which many go unfixed for years or forever. Now, I think we all can assume a proportion of those bugs are created in house, and are not the fault of the vendor. (And as Eta points our, for inhouse HIT, there is no vendor to report to) But undoubtedly there are many errors that are even acknowledge by the vendor that go on the backlist of repairs or that are subsequently sold as "updates" in the next iteration/version.
In this sense, the hold harmless/learned intermediary clause has significant patient safety implications. Remember also, the other side of the hold harmless/learned intermediary clause is that the doctor and the hospital are entirely responsible for all errors, even those reported to the vendor by hundreds of hospitals and thousands of users. It has powerful implications for clinicians too. RK
Dr. Koppel,
This is an open letter that I plan to publish on Linux Medical News and elsewhere. As you probably know, your JAMA 'Hold Harmless' article presents just the tip of the iceberg. Your article and more data from the Washington Post article http://www.washingtonpost.com/wp- dyn/content/article/2009/05/15/AR2009051503667.html?hpid%3Dtopnews&sub=AR make it abundantly clear that proprietary vendors are intent on establishing private property rights for something that private property rights are clearly not appropriate for. It leads to the logical absurdities, expense, and moral hazards we are experiencing now. The obvious dangers, enormous conflict of interest, as well as highly practical considerations such as simple non-performance of proprietary Electronic Medical Record software is manifest. What the proprietary industry could not achieve with vendor lock-in, legislative help like Stark exceptions, trade secrets, and inadequate products they are attempting to achieve by pure politics. Politicians, proprietary vendors and its lobby are playing 'heads we win, tails you lose, we are king, it is good to be king' games with our safety, our privacy, taxpayer money, and our lives. This may well succeed in ushering in a kind of digital feudalism with the most intimate details of our lives. Such landlord type games are entirely inappropriate for the practice of medicine. They are antithetical to American history and values. A generous and virtuous society should not allow this to occur.
The medical profession no longer condones even 15 cent pens with pharmaceutical company logos on them because of the moral hazard and the perception of untoward financial coercion. Yet we are now by law embarking on a program of essentially bribing physicians with approximately $40,000 each of taxpayer money and then punishing them if they cannot be bribed in order to implement problematic proprietary health IT loaded with legal, financial, and practical minefields. Have we as a nation taken leave of our senses?
The Free/Open Source licensing in medicine crowd has been discussing these issues and showing demonstrable results for years but has received little attention and practically no funding. We have the legal, practical, and licensing means for achieving the transparency and rights guarantees that nearly everyone says that they want, solving many practical as well as moral issues. The AMIA Open Source working group white paper can be found here http://www.amia.org/files/Final-OS-WG White Paper_11_19_08.pdf Unfortunately, it was rejected from entering into the scientific literature by JAMIA on a technicality and voted down by the AMIA board of directors as AMIA policy on methodology and 'ideological' grounds. Such a stance and public declarations by AMIA's leaders seems to be in direct conflict with AMIA's mission.
Relying on government bureaucrats, proprietary vendor lobbies, and marketing representatives giving "trust us" type guarantees versus legally enforceable Free/Open Source licenses is a recipe for national disaster.
Health Informatics Issues Page 9 of 15 2018-04-07 Again, a generous and virtuous society should not allow this to occur. A practical solution is a law that only allows taxpayer money to be expended only for Electronic Medical Record software that is licensed only with Free Software Foundation approved licenses. Preferably the Affero General Public License which closes the software as a service loophole. The nations health, privacy, safety, finances and destiny are at stake. IV
------
But there were two clauses in the earlier discussion. 1. The `hold harmless' clause protects vendors from being sued for apparent system failures. Such lawsuits would be costly and can be fatal to the vendor.
2. The clause that was referred to as the `gag rule' prohibits users from publicizing information about such failures. It protects vendors from negative publicity. Such publicity can often be misleading due to careless or absent analysis of the problem. Bad publicity can also be costly to the vendors.
Imposing a gag rule can easily cause systemic failures to affect the health of patients health.at other sites. And medical personnel can well argue that their responsibility is to the patients, and the financial well- being of vendors. The balance of costs to benefits here is quite different. A vendor who is open and responsive can counteract the effects of negative publicity without having to go to court, employ lawyers etc. Here the issue becomes fair and equal treatment. If any HIT vendors insist on the gag rule, then those that do not will be disadvantaged. I believe that discussion of the gag rule is appropriate for ELS and AMIA, and that convoluting it with the `hold harmless' clause has caused harm. IV
------
It seems that patient benefit and patient safety sometimes have the functional role akin to a "sink" for that heat generated by systemic pressures on health care. Preservation of "stakeholders", ROI, etc. get the most attention and funding, the negative impacts get distributed widely and incrementally, but no longer invisibly. Grounding the discussion in the intended primary purpose of the health care enterprise is purposeful. Otherwise, it seems sometimes we're, in effect, looking at patients as "consumers", faceless intermediaries through which must inconveniently pass resources for assuring the continued operations of the infrastructure "as is". Fortunately, as we all know and can attest, many are solving real, practical problems. That's where most of the solutions will come from, not from the Beltway.
Perhaps we should also be more patient, as our society moving along a learning process? Having experimented with treating patient care implicitly as a consumptive industry, but not liking the results, we've first applied basic safety and efficacy, then will advance measurable benefit. All this requires functional, trustworthy HIT infrastructure of course and I'm very optimistic we're getting there bit by bit. We're on our way but its sure a lot bumpier road when so many policymakers seem to think it's simple, easy, plug-n-play... Patience?
This particular thread began with the Session Proposal and then a concern that the proposal had an adversarial tone. I have no problem with the proposal being buffed and wordsmithed to an acceptably neutral tone because the unvarnished facts cannot help but incite ire whether intellectualized or conveyed in an argumentative mode. An industry selling non-standardized, minimally certified, unregulated products that become the infrastructure for patient care cannot reasonably expect to remain both unregulated and protected from market forces through "gags" and hold harmless clauses. This is especially the case when this preserves the position of inferior products and suppresses the value of better products, and in the presence of accumulating evidence of risks and harms resulting from poorly implemented, improperly used, and defective HIT.
The first purpose of HIT is to provide trustworthy pertinent information at the bedside in a timely manner. To this end, give HIT transparency or give HIT regulation. If vendors insist on fighting the former, they will inevitably get the latter as outrages accumulate to a point where legislators get pummeled by public
Health Informatics Issues Page 10 of 15 2018-04-07 demand for a quick fix. Since it took until the 2009 CCHIT Certification requirements to get agreement on requiring retention of the original version of an altered/amended record, regulation seems to me to be the most likely outcome given the fierce resistance to even this most basic Records Management upgrade in Certification.
However, this past week even Mark Leavitt, the CCHIT Chair, conceded that going forward Certification must take up anti-fraud requirements, one piece of the "trustworthy" puzzle. To hear that from him was a reassuring reminder that change happens. RG http://www.modernphysician.com/apps/pbcs.dll/article? AID=/20090511/MODERNPHYSICIAN/305039989/-1
Re-reading this, though, the important role of clinician professionals' demands for poor designs (such as cloning, authorship obfuscation, etc.) was neglected. Also, the slow pace of development of authoritative EHR-specific standards for vendor use was neglected as well. However, with clinicians demanding, and vendors delivering systems that violate even the most fundamental requirements for Records Management (RM), in my opinion there is justification for at least raising the Certification floor to immediately align with long-established RM fundamentals such as in long-accepted "floor" requirements like DoD 5015 requirements for RM, as well as long-established standards for Amendments to Health Care Info like ASTM E2017, translating long-established Health Info Management principles into a EHR Standards format. Whittling away at the 2007 EHR Functional Model Standard and the 2009 Records Management- Evidentiary Support Profile can then follow incrementally. Identifying and substantiating such key "choke points" and means/processes past them could be a focus for AMIA research. RG
I had a discussion with my colleague Martin Buijsen, who is professor of health law at Erasmus, about IT contracting, the non-disclosure, hold harmless, etc. things, and what it meant for patients. One of the claims is that patient safety might be compromised by such contracting. He had sobering remark. He said: "What the heck, if a patient gets hurt by software malfunctioning, she can sue the hospital and possibly the doctor. It is irrelevant for her how the contracting is stipulated. The hospital and the doctor will have to pay damages, and it is their problem or call if they want to sue the vendor." The relevant law in the Union and in the Netherlands, which seems to have resemblance with US law, is about contracting for diagnosis and treatments between provider and patient and the right of the patient to challenge the providers in court if there is a breach of contract (Wet op de Geneeskundige Behandelingsovereenkomst). He said: "I care about the legal position of the patient. I don't care about the position of the hospital, doctor or vendor, because there always a party (usually the provider) who will have to foot the bill." How is the situation in the US? Or is my colleague too simplistic in his reasoning? Can you enlighten me? JA
This has been an interesting discussion. I am reminded of the book Medical Nemesis as I read the postings. Technological iatrogenesis is certainly a formidable issue for healthcare institutions, clinicians, and vendors to uniformly address. Unfortunately, vendors do not always work in good faith with healthcare management and physicians (I know this from experience) to improve systems of care. Often, critical information about system functionality or the probability for debacles is not disclosed prior to purchase. Once again, from experience, I can tell you that the vendors are happy to sell new versions of software to fix serious issues in recently purchased software. Even more importantly, when vendors continue to maintain systems, new or continual problems are often not disclosed.
Why should any for-profit company be shielded from liability for the iatrogenic properties of their products? This shield would be an exceptional gift for HIT corporations that release flawed or substandard products into the market place. I think the argument about primary legal positions that exclude well
Health Informatics Issues Page 11 of 15 2018-04-07 intentioned clinicians as a consideration is precisely why many people decline medicine, nursing, and pharmacy as career choices. The thoughts offered by Professor Buijsen simply perpetuate the attribution forces aimed squarely at clinicians for patient harm when in fact managers and vendors design, implement, and manage critically flawed systems. Clinicians work, at risk, in these systems but have very little control over such systems -especially in hospitals outside of our academic medical center comfort zones.
The conversation about this hold harmless issue has been too black and white. As we should all know from the work of James Reason and the multitude of IOM reports, latent errors manufactured by poorly designed systems kill patients. I suggest the solution to this debate is for vendors to design better and more thoughtful products, healthcare administrators to draft contracts with vendors that include provisions to detail performance expectations, and clinicians to report system problems to their professional organizations for public disclosure in special areas of their journals. PP
Here is the dilemma: Define the specific qualifications for "better and more thoughtful products".
Having worked for the past 4.5 years on the Records Management-Evidentiary Support (RM-ES) Profile, even within one specific subset of qualifications (the ability of an EHR to support basic Health Information Management requirements) "better" can be extremely difficult to define comprehensive qualifications for. (I can also tell you we are already well into identifying its gaps and misalignments with other standards and our WG could use more help, volunteers invited!)
One major contributor (I would say the most important contributor) to the speeding improvement is learning what works, what doesn't. The main problem with gag/hold harmless is that it both suppresses learning and insulates one party from the consequences of ignorance, which are in turn suffered by everyone else. However, the good news is that there seems to be nobody raising serious objection to eliminating gag/HH, but there are differences in what should occur instead.
Given that, let's focus on what can we propose instead.
One initiative AMIA could undertake is to roapmap and then help steer policy (and funding) towards an effort to:
1. 1. Identify and rank the fundamental principles of medical informatics, beginning with the most basic (Ex: When the computer is turned on, the software should run-I remember when this was not a reasonably assured attribute for EHRs, not long ago...) Maybe this is already done somewhere within AMIA's domain?
2. For those the highest ranking fundamental requirements, evaluate the extent to which "better" is already at least partially defined.
3. Where gaps are identified in "better", focus discussion, research on most those deemed most critical.
4. Where "better" is partially defined, that becomes minimum necessary for usability.
I believe (as distinguished from I know) that 3 and 4 were at least the implicit intent of CCHIT. It was more explicit in HHS's original charge to HL7 in its request for the development of the EHR-S Functional Model standard (passed Feb. 2007). The problem has been that there is a huge embedded investment in existing EHRs and in poor data/documentation/workflow habits in the health care sector and those interests have been overrepresented in CCHIT, and basic data quality and records integrity requirements have been under-represented or ignored. No surprise that resistance is high to rendering obsolete (and illuminating the noncompliance) of the health care sector including EHRs.
Health Informatics Issues Page 12 of 15 2018-04-07 The other thing that I think AMIA could help with is managing the absurd expectations that there will be such a thing as a comprehensive trustworthy US NHIN by 2014 (or 2024 for that matter). There could be, but not without a level of focus such as FAA's on flight safety or Navy's Sub Safe Program and for whatever reason, national policy has not chosen that path. Until it does, cultivating reasonable expectations would be greatly helped by highlighting AMIA writings on where substantial improvements have occurred. Lab, rad standards and interoperability (still not 100% but good nonetheless), the Continuity of Care Record (from my days as ER doc, if I could get that body of info and I could trust it, it would be an 80%- plus solution for the rare event where immediate info makes a difference, my scariest and most challenging patient, the unconscious patient in extremis). There are others of course. It would be purposeful to collate what we've learned about how to focus effort to assure substantial incremental gains.
Similarly, the NAS report from January 09 highlighting where the 8 cutting-edge HIT sites are at, and get their experience generalized faster, cheaper; that would be useful. Furthermore, the US Military Health Services' 20+ years of experience with CPOE, lab/rads/consults reporting, eRx, and more has been nearly totally ignored and unutilized in informing the civilian sector in the US. Similarly international experiences where EHR use is 90%+ has been used in the past to inform US policy, let's go back to that well too.
In the meantime, as others have posted, where patients are harmed, all the hold harmless/gags in the world won't stop the legal process from "having at it". (In those anecdotal reports I've collected over time about patient injuries involving HIT, the facility and its clinicians are more likely the reason for the non- transparency for patient injury than the EHR vendor.) In my contacts with various folks in the law enforcement/anti-fraud/prosecution areas their reported state is that they are awash with messy and incomprehensible HIT systems where discovery is a nightmare and, among other problems, they find little guidance for where the cutoffs and benchmarks are for what HIT must, at the very least, do in 2009. I agree with those suggesting we can let the lawyers take care of their domain. Let's distill and make succinct an AMIA plan, with the uncoupling of gag/HH followed closely by a "state of research" assessment with the goal of "what's next" directives. All will be served by transparency, clarity, and focused effort.
P.S. In the meantime, for those with contact with an EHR, check to see whether it can produce an output from a multi-author clinical encounter showing who did what accurately. RG
You bring up important points. I am not a lawyer, but I have some in-depth, working, and practical knowledge and experience with licensing of software and intellectual property. In my experience:
1) Lawyers are good at one thing: suing. (I know that I'm oversimplifying and it is not my intent to smear the legal profession) 2) Those that write the contract or license are the ones that hold the power. 3) Your rights can be taken away completely by the EULA of a single upgrade. 4) FUD (Fear, Uncertainty and Doubt) surrounding licensing and support contracts with proprietary EMR vendors definitely exist and it shouldn't. 5) We need uniform contracts that safeguard 3rd party rights.
Solution:
Licenses such as the GNU General Public License (GNU GPL), the Affero General Public License (AGPL) and others that provide legally enforceable guarantee's of third party rights and solve most of the problems you pointed out below. Maybe you haven't heard of them: http://www.amia.org/files/Final-OS-WG%20White%20Paper_11_19_08.pdf
The answer is right under everyone's noses but isn't being acted upon, perhaps because of simple ignorance (not insulting, just stating a fact), conditioning, greed, wholesale disenfranchisement and emphasis (at all costs it seems) on proprietary EMR products. Scot Silverstein has pointed out http://hcrenewal.blogspot.com/2009/05/machinery-behind-healthcare-reform-how.html how wrong headed
Health Informatics Issues Page 13 of 15 2018-04-07 the 'without the crippling policy debate' comment is that occurred for stimulus law. This has resulted in a completely unbalanced and potentially quite dangerous situation.
Practically the only things that DID NOT get directly funded in the titanic wave of spending: incentives for use of and further development of existing EMR software licensed in a Free/Open Source Software (FOSS) way like GNU GPL and AGPL. Fine, I understand that this may be regarded for whatever reason as 'kook, fringe' stuff. Still, with that amount of spending in stimulus let me emphasize that there is:
A Serious Lack of a Contingency Plan.
I say this not to impress you but to impress upon you: my belief which is backed up by 22 years as a software engineer for such companies as IBM and Compaq, author of things like Astronaut on Sourceforge.net, and 2 degrees in computer science is: if we do not have incentives for these types of FOSS licensed software and spend nearly everything on proprietary EMR software, it will lead to huge, expensive nests of practical, ethical and legal conundrums, privacy/security/forensic snarls, rampant toll-boothing, and logical absurdities just like this: Right-to-Repair Law Proposed ... for Cars http://www.eff.org/deeplinks/2009/05/right-repair-law-pro IV
I discovered the incredible liability of doctors in USA case law, when I was researching the topic in the Technology Law Library at the U of Utah, while I was a grad student in informatics in 1998. The last adjudication then was in the mid 1980s. Even in the 1980s, it was pretty difficult for the average doc to determine what the computer was doing. Now (2009) detecting computer based errors is essentially impossible for the clinician. For the younger generation, who has come to trust “the computer” this is a very difficult medico-legal situation. Nearly no doc is aware of how many errors computers can make due to innumerable factors (especially older systems with patches and adaptations upon adaptations), and thus no clinician has any real capability to make validity judgments. A major testing lab is needed (and does not exist in any hospital that is not also a development shop).
Moreover, many vendors actively exclude physicians from all steps of the purchase, install (and non- testing) processes. The situation is a terrible risk for physicians – and for their patients. I can’t blame resistors for resisting – they have every right to declare a “STOP until you can show me this installed system actually does what you think it will, under the clinical circumstances where I have to work”!
Right now, my greatest fear is that the big, funded push now underway will simply magnify the existing risks, until nearly all docs simply refuse to participate, despite incentives. The CCHIT is the venue I’ve been using to urge for installed validation – CCHIT’s position has to date been ~ that “we can’t be responsible for what the vendors/hospitals/clinics do the system after we’ve passed the ~ 200 things we tested, in formal, fairly simple scenario-driven ~ 1 day testing, each year”. The CCHIT testing goals are limited to the amount of new things that can actually be tested in a day, I think. All helpful thoughts and suggestions are really needed at a national level right now. The pressure on doctors, from all sources, is rapidly becoming too much for them to continue in the profession – many are quitting, even without this added wrinkle, which has been largely unknown by them ‘til now - when this discussion shows the responsibility issue is resurfacing – and obviously hasn’t changed since the 1980s. WD
These kinds of detailed elaborations are very helpful, thank you for sharing. I also have been working within CCHIT on basic documentation integrity requirements over three years' voluntary effort. Similarly, my experience has been that the outputs are purposeful and do advance year-to-year, but in the context of the billions now being dumped into HIT, the slow pace of raising "floor" requirements and the minimal focus on fundamentals of Records Management integrity have become untenable to unconscionable.
I agree that next steps in Certification must eventually include site testing and more in-depth testing. Today, though, I hasten to add that current EHR defects include such gross and fundamental documentation
Health Informatics Issues Page 14 of 15 2018-04-07 integrity failures that no special testing is necessary. Affirming key documentation requirements attributes, like authorship accuracy, is well within the expertise of even a solo practice physician. My associate and I published a very simple testing vignette in 2005 in the Journal of AHIMA. (I will ask their permission to post it on the ELSI wiki, in the past they've always agreed with its free distribution as long as its attributions are intact.)
If you've followed this thread over the past weeks, you'll recall my recurring example, repeated here for convenience. Consider the ambulatory setting, where the vast majority of encounters involve two authors, myself and my nurse, MA, whatever. If my EHR can produce no form of record output that shows who actually did what (including within audit functions) then this is a material defect that should render that product too risky to install because it strongly suggests that any representation of source author may be unreliable or, in some circumstances, falsified. This isn't rocket science, it's basic documentation rules consistent with the most basic principles of Records Management. Indeed more rigorous testing facilities are needed to get at much more subtle problems or defects, but let's not overlook ways anyone can do due diligence on such obvious defects as inaccurate record authorship.
The recurring sidebar mystery is why Records Management has been largely silent on these matters. Insofar as they've not been entirely silent, what event or publication will bring "Authorship Error" into the full light of day as Koppel/Kreda brought Hold Harmless irrefutably and irrevocably into the HIT "field of vision"? RG
Health Informatics Issues Page 15 of 15 2018-04-07