UNITED STATES DISTRICT COURT, NORTHERN DISTRICT OF ILLINOIS, EASTERN DIVISION; BRISTOL COUNTY RETIREMENT SYSTEM, Individually and on Behalf of All Others Similarly Situated, Plaintiff, vs. ALLSCRIPTS HEALTHCARE SOLUTIONS, INC., GLEN E. TULLMAN, WILLIAM J. DAVIS AND LEE SHAPIRO, Defendants.
The Lead Plaintiffs' Amended Complaint is available here in PDF: http://securities.stanford.edu/1048/MDRX00_01/2013515_r02c_12CV03297.pdf. It is worth reading, if just to understand the inner workings of an unregulated healthcare device industry on which your well-being and that of your family increasingly depends.
 |
| Lead Plaintiffs' Amended Complaint, available here in PDF: http://securities.stanford.edu/1048/MDRX00_01/2013515_r02c_12CV03297.pdf |
The lawsuit is primarily about alleged misrepresentations made to investors by Allscripts and Eclipsys in a merger regarding inability to integrate products, leadership chaos, and materially false and misleading statements and omissions made during the Class period by these companies about their progress.
I note that in a chaotic environment such as alleged, product safety is not likely a big concern.
However, even more ominous are the allegations of deliberate use of beta software on patients without informed consent or any knowledge by patients whatsoever of its use, which apparently did not work out well. Not indicated is if patient harm occurred. If the allegations are true, considering the ECRI Deep Dive health IT risk study results of nearly 200 health IT "incidents" in 36 hospitals over 9 weeks voluntarily reported, including 8 harm incidents and 3 possible deaths - see http://hcrenewal.blogspot.com/2013/02/peering-underneath-icebergs-water-level.html it would not be surprising.
From the Complaint, allegations on software beta testing are as follows. Emphases mine:
41. CW1 [coded person's name - ed.] explained the different interface integration systems as native integration, disparate integration, and High Level 7 “HL7” interface. The goal of native integration was to have the ability to update patient information throughout the Allscripts’ software offerings. This would allow Allscripts’ Sunrise products to seamlessly integrate with Allscripts’ Enterprise, Professional and MyWay products and allow the products to update patient health records without the use of industry standardized codes. Allscripts branded its native software as ADX. [see Complaint footnote 2.] CW1 described disparate integration as allowing Allscripts software to interface with non-Allscripts software which he described as a Health Information Exchange (“HIE”) software that allowed data to be read and
updated from different software vendors.
42. CW1 said ADX 1.0 was designed to pull and update patient electronic health records automatically and was Allscripts’ native integration software. In approximately July 2011, he learned that Allscripts began a complete reworking of ADX 1.0 because customers were complaining about the lack of functionality and integration, and that it did not allow the user to review and approve changes made in other healthcare settings before being accepted by the hospital or physician practice systems. [If the allegations are true, these problems would be creating on its face significant risk of oversights, confusion and medical errors - ed.] The upgrade was going to be known as ADX 1.5, but the method and interface for data integration changed. In particular, the interface was changed to allow clinicians to approve changes before they were entered into the system. He also learned from other Allscripts employees that ADX 1.0 was being beta tested [see Complaint footnote 3] at Blessing Hospital in Quincy, Illinois and another place he could not recall, but it was suspended in approximately the middle of 2011 because it failed to perform to expectations. [see Complaint footnote 4] [Remarkable - if the allegations are true, experimental software was being beta tested on live patients and was stopped because it did not "perform to expectations" - and what of the unconsenting meatbags a.k.a. patients it was purportedly tested on? - ed.]
Complaint footnotes:
[2] CW1 described the HL7 interface as using industry standardized codes or language to allow users of disparate software systems to update patients electronic health records.
[3] In software development, “beta testing” generally refers to a testing phase in which a subset of the intended user population tries the product out, in order to see how the product works in real-world conditions. [What sane patient would consent to such testing of medical IT involved in their care, to 'see how it works in real-world conditions'? - ed.]
[4] See also ¶158 (Defendant Davis’ May 8, 2012 statement “our initial release of our integrated capability...was launched in the middle of last year”); ¶189; cf. ¶76 (CW11’s statement that beta testing at Blessing occurred in late 2011 and was halted in Spring 2012);
Again, I find the allegations of great concern - that experimental software was being beta tested on live patients and was stopped because it did not "perform to expectations." If true, what of the unconsenting meatbags a.k.a. patients? They would not have counted for much.
More from the Complaint in Count 50:
50. Consistent with CW2, CW3 said the Helios system was never taken to production while he worked at Allscripts. After he left to join Medicity he had heard that Allscripts delivered a Helios type product for beta testing in the fall of 2011 at the New York Presbyterian Hospitals and it did not go well and that the beta testing of the Helios product at the North Shore Long Island Jewish Community Hospital was scratched prior to implementation.
If the allegations are true, New York Presbyterian Hospitals in the fall of 2011 were performing beta testing of software so bad it was deemed unacceptable for LIJ Community Hospital. Again, if true, what about the risks patients were subjected to, and ... were any harmed?
Still more in Count 76:
76. CW11 said that Blessing Hospital in Quincy, Illinois was beta testing ADX 1.0 sometime in late 2011, but could not recall specifically when it began. CW11 said he was told that the testing was stopped in early 2012 because the product was not working properly and Allscripts deployed a product development team to Blessing Hospital to develop a workflow which lead to ADX 1.5. As far as CW11 knew, no one went live on ADX 1.0. Blessing Hospital began testing ADX 1.5 in late Spring 2012, and was the first to go live using ADX 1.5 in July 2012 which allowed the integration of patient information seamlessly between Sunrise and Enterprise applications. Components of Helios went into ADX 1.5. ADX 1.5 allowed for integration of patient data relating to PAMI (problems, allergies, medications, and immunizations) but some competitor products allow for significantly more types of data to be seamlessly exchanged and Allscripts was working to increase the types of data that could be seamlessly exchanged between acute care and ambulatory applications.
In effect, if the allegations are true, sancrosanct patient's rights have been trivialized, while poor software of non-trivial risk has been sanctified.
This would be, needless to say, deranged. Software can be debugged in test environments without putting patients at risk - if one is willing to invest the resources to do so.
The Class Action lawsuit Plaintiffs should perhaps seek to discover if there were patient harms or deaths as a result of the alleged software beta testing - assuming that information was not thoroughly "cleansed" by now.
I also note that even small NIH SBIR/STTR grant proposals involving use of new or modified IT on patients, on whose study sections I am an invited reviewer in the domain of Medical Informatics, are subject to human subjects protection evaluation:
http://grants.nih.gov/grants/peer/critiques/sbir-sttr.htm
... Protections for Human Subjects. For research that involves human subjects but does not involve one of the six categories of research that are exempt under 45 CFR Part 46 [see http://www.research.uci.edu/ora/forms/hrpp/categories_of_exempt_human_subjects_research.pdf - ed.], the [grant review] committee will evaluate the justification for involvement of human subjects and the proposed protections from research risk relating to their participation according to the following five review criteria: 1) risk to subjects, 2) adequacy of protection against risks, 3) potential benefits to the subjects and others, 4) importance of the knowledge to be gained, and 5) data and safety monitoring for clinical trials.
In health IT tests in hospital settings, which is most certainly experimentation, there are simply no human subjects protections whatsoever. Hospital IT deserves no special accommodation regarding Protections for Human Subjects. There are no justifiable reasons I can think of.
-- SS
Addendum: Perhaps I'm wrong about people's generosity and altruism. I would like to hear from people who would gladly submit, say, their newborns as test subjects for the beta testing of experimental health IT software.
Would be interested in your take:
ReplyDeletehttp://www.healthcareitnews.com/blog/era-epic?single-page=true
Anonymous July 31, 2013 at 1:59:00 PM EDT said...
ReplyDeleteWould be interested in your take [with link to article by John Halamka]:
Dear Anonymous,
I long ago stopped listening to John Halamka.
Every time I do read his pronouncements I am reminded why, e.g.,
"Epic eases the burden of demand management ... With Epic, demand is more easily managed by noting that desired features and functions depend on Epic's release schedule. It's not under IT control."
In other words, physicians needing special EHR features to meet their needs - and the needs of patients, (a "burden" according to Halamka) - can be more easily blown off by IT by taking advantage of the inflexibility of this vendor's "release schedule."
In my opinion, that is a clinician-hostile attitude.
-- SS
The doctors and nurses are guinea pigs for the vendors, and are forced to comply with threats of retaliation, dismissal, or sham peer review.
ReplyDeleteI have to believe that much of the enthusiasm for EMR’s is driven by articles like this:
ReplyDeletehttp://www.blogger.com/comment.g?blogID=9551150&postID=2181374536109593851&isPopup=true
Problematic is the lack of in depth analysis:
“Employment of HIT tools, including EHRs, is escalating, with 43 percent of office-based physicians adopting all 14 core criteria for Stage One, and 42 percent of hospitals reporting the implementation of all functionalities…”
Missing from the discussion is that over half of doctor offices and over half of hospitals do not have EMR’s systems that meet some type of government standard. The reason for this should be the question.
From my perspective many young doctors follow the ROAD and are not entering primary care, thus leaving an older generation who simply want to finish out their careers doing what they have been doing without the expense and confusion of a new computer system.
Hospitals I am sure are reading the fine print on those contracts and finding they do not own their data, and are subject to vendor scheduled upgrades and pricing are finding an EMR does not fit their business model.
The result is that most Americans will be treated by a doctor or hospital that does not use an EMR or their EMR will not exchange data with another EMR which has been publicly stated by one vendor as a part of their business model.
This article really needed a more balanced approach than the academic statements of those who are not involved in implementation.
Steve Lucas
All of the vendors use hospitals' patients as experimental subjects without their awareness or IRB approval.
ReplyDeleteWhen the US Government wants something done, nothing stands in its way.
So what, a few patients die from the flawed HIT.
HIT is the agenda at any and all costs.