Showing posts with label HHS. Show all posts
Showing posts with label HHS. Show all posts

Thursday, November 29, 2012

Cybernetik Über Alles Again: HHS and Sebelius - Hospitals And Their Computers Have More Rights Than Patients

A Nov. 29, 2012 New York Times article by Reed Abelson entitled "Medicare Is Faulted on Shift to Electronic Records" observes that:

The conversion to electronic medical records — a critical piece of the Obama administration’s plan for health care reform — is “vulnerable” to fraud and abuse because of the failure of Medicare officials to develop appropriate safeguards, according to a sharply critical report to be issued Thursday by federal investigators [the report from HHS OIG is here - ed.] ... Medicare, which is charged with managing the incentive program that encourages the adoption of electronic records, has failed to put in place adequate safeguards to ensure that information being provided by hospitals and doctors about their electronic records systems is accurate. To qualify for the incentive payments, doctors and hospitals must demonstrate that the systems lead to better patient care, meeting a so-called meaningful use standard by, for example, checking for harmful drug interactions. [I note that meeting EHR "meaningful use" standards does not necessarily signify better care; the "standards" are experimental - ed.]

Hospitals and doctors are lying about their EHR efforts, in order to gain incentive payments, it seems.

In an article "IG says program is 'vulnerable' to abuse, better oversight needed", Fred Schulte at the Center for Public Integrity notes:

... the Centers for Medicare and Medicaid Services has since paid out more than $3.6 billion to medical professionals who made the switch without verifying they are meeting the required quality goals, according to a new federal audit to be released today

Observes the CEO of the American Health Information Management Association:

“We’ve gone from the horse and buggy to the Model T, and we don’t know the rules of the road. Now we’ve had a big car pileup,” said Lynne Thomas Gordon, the chief executive of the American Health Information Management Association, a trade group in Chicago. 

More Horse and Buggy than Model T.  At least the Model T was reasonably dependable. 

Also mentioned is this:

House Republicans echoed these concerns in early October in a letter to Kathleen Sebelius, secretary of health and human services. Citing the Times article, they called for suspending the incentive program until concerns about standardization had been resolved. “The top House policy makers on health care are concerned that H.H.S. is squandering taxpayer dollars by asking little of providers in return for incentive payments,” said a statement issued at the same time by the Republicans, who are likely to seize on the latest inspector general report as further evidence of lax oversight. Republicans have said they will continue to monitor the program.

In her letter in response, which has not been made public, Ms. Sebelius dismissed the idea of suspending the incentive program, arguing that it “would be profoundly unfair to the hospitals and eligible professionals that have invested billions of dollars and devoted countless hours of work to purchase and install systems and educate staff.”


I was taught "first, do no harm."  Fairness to patients injured and killed by this technology in its present "Horse and Buggy" state (buggy being a particularly apropos term) seems not a matter of particularly high concern to HHS.   A suspension of incentives would slow the adoption rate down, necessary in order to "get the bugs" out of the technology before mass deployment and develop safety, validation and surveillance standards (currently non-existent), as I wrote in my Oct. 24, 2012 "Letter To U.S. Senators and Representatives Who've Sought HHS Input On EHR Problems."

This is despite the fact that FDA, IOM and others have indicated the level of harm is not known, due to systematic impediments to diffusion of that knowledge (see IOM statements in the midsection of my post on health information technology hyper-enthusiasm at this link, and an internal FDA memo on HIT safety at this link). 

HHS seems to care not about health and human services, or at best to be severely misguided.  "Cybernetik Über Alles" seems their current credo.

-- SS

Wednesday, October 24, 2012

Letter To U.S. Senators and Representatives Who've Sought HHS Input On EHR Problems

Several members of Congress have written HHS demanding meetings on health IT issues such as upcoding, test overutilization, misuse of incentive programs, and other factors as here.

However, what was largely left out was the issue of safety.

I've written this letter to the congresspeople who've written to HHS secretary Sebelius (PDF available at this link):


October 24, 2012

To:

Sens. Coburn, Burr, Roberts and Thune
Reps. Ellmers, Camp, Herger, Upton and Pitts
United States Congress
Washington, DC

Re:  HITECH and healthcare information technology

Dear Senators and Representatives,

I applaud your recent inquiries to HHS regarding critical issues related to healthcare information technology (EHRs, physician order entry, decision supporting systems, etc.)  Issues such as the possible role of these systems in upcoding and Medicare overbilling, test overutilization, abuse of incentives, etc. must be addressed.

However, you did not address an issue probably more important to the public, indeed to us all as patients – that of health information technology safety.

Congress must be made aware that health IT exists in two forms:  good health IT and bad health ITBad health IT reduces safety, creates close calls, injures, kills, raises costs, and sacrifices information privacy and confidentiality, among other ill effects.

Congress must also be made aware that unfortunately due to systemic impediments to free flow of information about health IT systems and lack of FDA or other independent industry regulation, bad health IT is rarely removed from the marketplace or fixed. 

FDA and its director of the Center for Devices and Radiological Health (CDRH), Jeffrey Shuren MD JD, testified to HHS in Feb. 2010 that “under the Federal, Food, Drug, and Cosmetic Act, health information technology software is a medical device”, but that FDA has “largely refrained from enforcing our regulatory requirements with respect to HIT devices.” 

To clarify about the two types of health IT:


Good Health IT provides a good user experience, enhances cognitive function, puts essential information as effortlessly as possible into the physician’s hands, keeps eHealth information secure, protects patient privacy and facilitates better practice of medicine and better outcomes.

Bad Health IT is ill-suited to purpose, hard to use, unreliable, loses data or provides incorrect data, causes cognitive overload, slows rather than facilitates users, lacks appropriate alerts, creates the need for hypervigilance (i.e., towards avoiding IT-related mishaps) that increases stress, is lacking in security, compromises patient privacy or otherwise demonstrates suboptimal design and/or implementation.


The Agency for Healthcare Research and Quality (AHRQ) recently reported that the highest prevalence of medical technology safety issues was related to EHR systems.  Even worse, there is a lack of reporting transparency. Harms are known of, but the magnitude admittedly unknown due to systematic impediments to reporting transparency, collection and analysis, as noted by FDA in a 2010 internal memo and IOM itself in its 2012 report on health IT safety.  This is unprecedented in modern medicine, violates patient’s rights, and under no circumstances should be considered acceptable.

I personally know of adverse patient outcomes including death related to bad health IT that are unreported (even in a state that mandates reporting of medical incidents and serious events), as do numerous colleagues. 

The Institute of Medicine has just released a Discussion Paper written by experts in health information technology entitled “Comparative User Experiences of Health IT Products: How User Experiences Would Be Reported and Used"  (http://www.iom.edu/Global/Perspectives/2012/~/media/Files/Perspectives-Files/2012/Discussion-Papers/comparative-user-experiences.pdf). The recommendations in this paper need to be put into place, and Congressional awareness of the issues and official inquiry as to when this will happen is essential. 

This paper’s recommendations will not happen without the oversight of Congress.  As stated in the paper itself, “Some medical and IT leaders have invested their reputations, and their organization’s time and money, in the software [implementation] program; complaints that expose large problems may not be appreciated or carried forward.” 

Some claim safeguards are already in place in the form of HHS certification of health IT. 

Unfortunately, the HHS health IT certification guidelines do not have sufficient depth nor the correct focus to distinguish between bad health IT and good health IT.  Certification for MU does not look at real-world testing for safety, reliability and usability, for instance, under real loads, in actual clinical settings, and is not very thorough.

On the other hand,  NASA, the pharmaceutical industry (via FDA's regulation of pharmaceutical research and manufacturing IT) and others dependent on mission-critical software have rigorous validation procedures to check for such factors, e.g., NASA’s "Certification Processes for Safety-Critical andMission-Critical Aerospace Software" that includes rigorous testing to distinguish bad IT from good IT, and remediate or abandon the former.

p. 6-7:  In order to meet most regulatory guidelines, developers must build a safety case as a means of documenting the safety justification of a system. The safety case is a record of all safety activities associated with a system throughout its life. Items contained in a safety case include the following:

• Description of the system/software
• Evidence of competence of personnelinvolved in development of safety-critical software and any safety activity
• Specification of safety requirements
• Results of hazard and risk analysis
• Details of risk reductiontechniques employed
• Results of design analysis showing that the system design meets all required safety targets
Verification and validation strategy
• Results of all verification and validation activities
• Records of safety reviews
• Records of any incidents which occur throughout the life of the system
• Records of all changes to the system and justification of its continued safety


These processes need to be put in place regarding healthcare IT as well, but will take much time and regulatory push on the industry to occur.  In the absence of truly rigorous testing, though, transparency is essential.

The aforementioned IOM Discussion Paper outlines the creation of a nationwide post-marketing surveillance process and transparency on health IT usability problems, safety issues, billing fraud promotion, etc. is essential.  It recommends:

¨        “Flight simulator”-like, thorough laboratory evaluation of test scenarios;
¨        Point-of-use reporting by doctors and nurses on their experiences;
¨        Third party–administered doctor and nurse surveys about their experiences with EHR systems;
¨        Direct clinician-to-public reporting; and
¨        A formalized system of hazards reporting from EHR systems.

These measures are essential if the technology is to achieve the benefits of which it is theoretically capable, but not presently achieving despite the hundreds of billions of dollars being spent.

In conclusion, I ask you to add to your inquiries the subject of health information technology safety.  That includes the need for HHS to develop a robust, transparent national reporting system for safety problems created by the technology, and a system to ensure that bad health IT is either fixed in a timely manner or removed from the marketplace.

Sincerely,

Scot Silverstein, MD

-----------------------------------------------------------------
Scot M. Silverstein, MD
Adjunct faculty in Healthcare Informatics and IT (Sept. 2007-present)
Assistant Professor of Healthcare Informatics and IT, and Director, Institute for Healthcare Informatics (2005-7)

Drexel University
College of Information Science and Technology
3141 Chestnut St., Philadelphia, PA 19104-2875

Email:  sms88 AT drexel DOT edu


I hope this letter has some beneficial effect.

-- SS

Thursday, February 16, 2012

Hospitals and Doctors Use Health IT at Their Own Risk - Even if "Certified"

Due to my observations of confusion about health IT certification [1], and due to vague or incomplete seller language that could be misinterpreted by buyers (perhaps by design), I recently asked several ONC-ATCBs (HHS's Office of the National Coordinator for Health IT-Authorized Testing and Certification Bodies) the following.

I sent this question via email to their "questions" email addresses:

"Is EHR certification by an ATCB a certification of EHR safety, effectiveness, and a legal indemnification, i.e., certifying freedom from liability for EHR use of clinical users or organizations? Or does it signify less than that?"

One ONC-ATCB provided the following in response to my request for information.


From: Trivedi, Amit V (ICSA Labs)
Sent: Thursday, February 16, 2012 11:22 AM
To: Scot Silverstein
Subject: RE: Form submission from: Contact Us

Hello Scot,

Thanks for your email. Certification by an ATCB signifies that the product or system tested has the capabilities to meet specific criteria published by NIST and approved by the Office of the National Coordinator. In this case the criteria are designed to support providers and hospitals achieve "Meaningful Use." A subset of the criteria deal with the security and patient privacy capabilities of the system.

Here is a list of the specific criteria involved in our testing:
http://healthcare.nist.gov/use_testing/effective_requirements.html

In a nutshell, ONC-ATCB Certification deals with testing the capabilities of a system, some of them relate to patient safety, privacy and security functions (audit logging, encryption, emergency access, etc.).

What was suggested in the email below (freedom from liability for users of the system, etc.) would be out of scope for ONC-ATCB testing based on the given criteria. [I.e., certification criteria - ed.] I hope that helps to answer your question.

Thanks,

Amit

Amit Trivedi
Program Manager - Healthcare
ICSA Labs, an Independent Division of Verizon Business


Mar. 5, 2012 Addendum:  I also received a response from another ONC-ATCB, the Drummond Group:


From: Joani Hughes (Drummond Group)
Sent: Monday, March 05, 2012 1:06 PM
To: Scot Silverstein
Subject: RE: EHR certification question

Per our testing team:

It is less than that. It does not address indemnification although a certification could be used as a conditional part of some other form of indemnification function, such as a waiver or TOA, but that is ultimately out of the scope of the certification itself. Certification in this sense is an assurance that the EHR functions in way that could enable an eligible provider or eligible hospital to meet the CMS requirements of Meaningful Use Stage 1. Or to restate it more directly, CMS is expecting eligible providers or eligible hospitals to use their EHR in “meaningful way” quantified by various quantitative measure metrics and eligible providers or eligible hospitals can only be assured they can do this if they obtain a certified EHR technology.

Please let me know if you have any questions.

Thank you,
Joani.

Joani Hughes
Client Services Coordinator
Drummond Group Inc.

These are direct and clear statements.

My question was certainly answered. ONC cerification is not a safety validation, such as in a document from NASA on aerospace software safety certification, "Certification Processes for Safety-Critical and Mission-Critical Aerospace Software" (PDF) which specifies at pg. 6-7:

In order to meet most regulatory guidelines, developers must build a safety case as a means of documenting the safety justification of a system. The safety case is a record of all safety activities associated with a system throughout its life. Items contained in a safety case include the following:

• Description of the system/software
• Evidence of competence of personnel involved in development of safety-critical software and any
safety activity
• Specification of safety requirements
• Results of hazard and risk analysis
• Details of risk reduction techniques employed
• Results of design analysis showing that the system design meets all required safety targets
Verification and validation strategy
• Results of all verification and validation activities
• Records of safety reviews
• Records of any incidents which occur throughout the life of the system
• Records of all changes to the system and justification of its continued safety

Health IT testing conspicuously lacks attention to most of the aerospace software safety points above. I note that there appears to be no reasonable excuse for such omissions.

IOM has recently studied the issue of HIT safety. IOM states in a Nov. 2011 report that HIT safety and safety testing is unsatisfactory, and has recommended HHS study it as well. IOM recommends HHS annually re-evaluate whether regulation is needed to improve safety, although IOM favors industry self-policing [2].

Thus, buyers and users of even "ONC certified" health IT are not indemnified from liability due to medical errors or problems caused by the health IT.

Sellers who exaggerate the value of certification or imply its meaning is akin to FDA device approval, likewise, could be faulted for making false representations about their products.

It would appear the sellers could potentially be sued for doing so by purchasers/users who themselves get into legal hot water due to EHR defects or other problems.

-- SS

Note:

[1] I believe confusion about EHR "certification" is in part due to the term itself. I raised objections to this term when it was first proposed based on my experience in pharma, suggesting what I felt was the more accurate expression "
features qualification" instead.

[2] "Health IT and Patient Safety: Building Safer Systems for Better Care", Institute of Medicine of the National Academies, Nov. 2011, http://www.iom.edu/Reports/2011/Health-IT-and-Patient-Safety-Building-Safer-Systems-for-Better-Care.aspx


Friday, January 14, 2011

ONC Workgroup Document Misindentification - Just the Type of Computer "Glitch" That Can Kill People

A provocative title indeed.

The Office of the National Coordinator's Health IT Standards Committee Implementation Workgroup recently had a meeting, Jan. 10-11, 2010.

They've posted the testimony and supporting documents here: http://healthit.hhs.gov/portal/server.pt?open=512&objID=1482&&PageID=17128&mode=2 .

I've copied & pasted these document links directly from the site, at 12:45 PM EST 1/14/2011:


The problem is, some of the URL's are simply wrong, including several of the ones I've bolded.

For instance, I tried to download Dr. Willa Drummond's documents:


The links for "Collection of Problem Scenarios from Professional List Serve" and "Ten Commandments for Computerized Healthcare Information Systems" are simply wrong.

They lead to the incorrect documents as of this writing.

By experimentation (borne of experience!), I found I could locate the correct documents by manually altering a number in the URL.

For example, to locate the "Problem Scenarios" document whose URL is linked as:

http://healthit.hhs.gov/portal/server.pt/document/949972/drumexsum-imwg-11011_pdf

I had to alter the number 949972 to 949973, like this:

http://healthit.hhs.gov/portal/server.pt/document/949973/drumexsum-imwg-11011_pdf

I further had to experiment to find the "Ten Commandments" document, also erroneously listed as at this URL ...

http://healthit.hhs.gov/portal/server.pt/document/949972/drumexsum-imwg-11011_pdf

... but actually here at 949971:

http://healthit.hhs.gov/portal/server.pt/document/949971/drumexsum-imwg-11011_pdf

Presumably these erroneous indices will be fixed at some point. Are they due to computer and/or software error, or human error -- as in medicine, due to busy schedules, cognitive overload from a suboptimal IT user experience, and other factors?

I do not consider these errors "minor" or at all humorous. Leadership by example - through fine attention to detail - in a supposed "HITECH" paperless-medicine promoting government organization - is what I expect.

Similar "misidentification" errors in EHR systems can and do cause medications to be missed or given to the wrong patient - such as in the example at the Trinity Healthcare System as mentioned in my post "Huffington Post Investigative Fund: FDA, Obama Digital Medical Records Team at Odds over Safety Oversight" where an EHR "upgrade" caused considerable risk:

... Computers at a major Midwest hospital chain went awry on June 29, posting some doctors’ orders to the wrong medical charts in a few cases and possibly putting patients in harm’s way.

The digital records system “would switch to another patient record without the user directing it to do so,” said Stephen Shivinsky, vice-president for corporate communications at Trinity Health System. Trinity operates 46 hospitals, most in Michigan, Iowa and Ohio.

[In other words, data entered by clinicians was going into the wrong charts. How many charts were involved? Does the hospital system even know, I wonder? - ed.]


Less than two weeks later, an unrelated glitch caused Trinity to shut down its $400 million system for four hours at 10 hospitals in the network because electronic pharmacy orders weren’t being delivered to nurses for dispensing to patients, he said.

See the many questions I raised about this episode at the followup post "More on Huffington Post Investigative Fund: "FDA, Obama Digital Medical Records Team at Odds over Safety Oversight." (I understand that the initial "fix" to the problem of "orders going to the wrong chart" was to prevent clinicians from opening more than one chart at a time, thus further interfering with clinicians' work.)

"Glitches" cause sometimes crucial data to be lost, and even patients to be harmed or killed (e.g., see the gray banner at top of my site on HIT failure, and my recent post "EHR Problems? No, They're Merely Anecodotal; the Truth Must Be That I Attract Bad Electrons and Stale Bits" on this blog).

Ironically, the First Commandment in the mislinked Ten Commandments document above is:

"The Computer shall find and collate all data generated by other computers."

Perhaps it should read:

"The Computer shall find and correctly collate all data generated by other computers."

-- SS

1/14 addendum:

I looked specifically for those documents as my first retrievals on the HHS site due to past correspondence with Dr. Drummond. The pinball machine then tilted.

Perhaps it is simply those bad electrons and stale bits that follow me around once more.