Showing posts with label upcoding. Show all posts
Showing posts with label upcoding. Show all posts

Thursday, December 19, 2013

EHR cut-and-paste problem is only one of the several mechanisms to clone documentation - and facilitate fraud

In my Dec. 10, 2013 post "44% of hospitals reported to HHS that they can delete the contents of their EHR audit logs whenever they'd like" (http://hcrenewal.blogspot.com/2013/12/44-of-hospitals-reported-to-oig-that.html) I observed that the "money quote" of the Modern Healthcare article that prompted the post, "Feds eye crackdown on cut-and-paste EHR fraud" by Joe Carlson was not the issue of EHR cut-and-paste features and billing fraud, but EHRs and audit trail alteration.

Dr. Stephen R. Levinson, an E/M compliance and healthcare quality expert among other areas of expertise (see http://www.linkedin.com/in/stephenlevinson), wrote me with the following regarding the issue I glossed over in favor of the audit trail concerns, namely, EHR cloning.

Reproduced with Dr. Levinson's permission:

This long-recognized and high-profile problem [EHR cut and paste, copy forward, etc. - ed.] covers only one of the several mechanisms EHRs provide to create CLONED Documentation.

Other non-compliant short-cuts include documentation by exception (auto-entry of extensive negative history reviews and normal comprehensive examinations), use of restricted pick list words and phrases, and "translation."

Translation is my own terminology for taking actively entered "yes" or "no" responses in medical history (and "normal" or "abnormal" findings in physical exam) and using pre-loaded software to convert (i.e., translate) the response to a long pseudo dictation paragraph. For example, check a box for lungs being "normal" may automatically appear in a paragraph as "lungs clear to percussion and auscultation; respiratory effort is normal on inspiration and expiration with normal excursions of the diaphragm; there are no rales or rhonchi, and no wheezes are present."

This extended statement will appear identically in patient after patient and visit after visit, regardless of whether this level exam was performed. Further, the likelihood of every patient having completely normal lungs is non-existent.  [This is one mechanism by which reams of "legible gibberish" are produced even with modest hospital stays, e.g., see my Feb. 27, 2011 post "Two Weeks, Two Reams" at http://hcrenewal.blogspot.com/2011/02/electronic-medical-records-two-weeks.html - ed.]

Finally, although cloned documentation is egregious, there are four other equally egregious non-compliant documentation and coding features, common to most EHRs, that are being totally ignored by OIG. These 4 features are:

1) non-compliant coding engines (including failure to consider medical necessity of the level of care)

2) Replacing narrative documentation of differential diagnoses with billing codes (ICD-9) and billing semantics

3) Failure to document the qualitative components of E/M coding, while addressing only quantitative components (e.g., when patient has a positive response to review of systems question on chest pain, compliance (and quality care) requires further investigation and documentation of further details; most current systems either lack ability to document these details or fail to guide and require physicians to document them)

4) Failure to incorporate consideration of "medical necessity" (indicated in E/M coding as the "nature of the presenting problems") into care, documentation, and coding

As evidenced by these explanations, common commercial EHRs in use today were either designed by amateurs or by crooks, with the gatekeepers turning a blind eye towards abuses since at least 2007 (per commenter and EHR compliance expert Dr. Reed Gelzer who, at http://hcrenewal.blogspot.com/2013/12/44-of-hospitals-reported-to-oig-that.html, indicated ONC and OIG knew of these issues since a 2007 report he contributed to).

The gatekeepers have turned a blind eye, that is, until now when they've finally opened one eye very slightly, like a ten-day-old puppy, as the abuses become more widely known.


Young puppy begins to open its eyes.


-- SS

Tuesday, December 10, 2013

44% of hospitals reported to HHS that they can delete the contents of their EHR audit logs whenever they'd like?

Modern Healthcare published an article "Feds eye crackdown on cut-and-paste EHR fraud" on Dec. 10, 2013 by Joe Carlson.

The article is about federal efforts to reduce the amount of clinician cut-and-paste from prior notes of a patient - which can even be done between charts of different patients.  This practice can result in overbilling for work not actually performed.  The practice can also result in no-longer-accurate data being carried forward; I have been consultant to cases where that phenomenon, in my opinion, contributed to grave patient injury in cases that have settled out of court.

It is at this link:  http://www.modernhealthcare.com/article/20131210/NEWS/312109965/feds-eye-crackdown-on-cut-and-paste-ehr-fraud?utm_source=articlelink&utm_medium=website&utm_campaign=TodaysHeadlines#

Subscription required, but googling the article title may allow reading it in its entirety.

The article begins:


Federal officials say the cut-and-paste features common to electronic health records invite fraudulent use of duplicated clinical notes and that there is a need to clamp down on the emerging threat. That concern is enhanced by the fact that it's too easy to turn off features of EHR systems that allow tracking of sloppy or fraudulent records.

In an audit report released Tuesday morning (PDF), [HHS Office of Inspector General, "NOT ALL RECOMMENDED FRAUD SAFEGUARDS HAVE BEEN IMPLEMENTED IN HOSPITAL EHR TECHNOLOGY"], HHS agencies confirmed that they are developing comprehensive plans to deter fraud and abuse involving EHRs, including guidelines for cut-and-paste features. The issue arises at a time when critics say federally subsidized digital patient record systems are sometimes being used inappropriately by providers to drive up reimbursement.

“Certain EHR documentation features, if poorly designed or used inappropriately, can result in poor data quality or fraud,” according a report from HHS' Office of the Inspector General.

None of this is a surprise to me, and to readers of this blog.

However, the real "money quote" in the article, I believe, is this:


"In addition, only 44% of hospitals' “audit log” systems could record whether cut-and-paste was used to enter data, and an identical percentage of hospitals reported [to OIG] that they can delete the contents of their internal audit logs whenever they'd like."


From page 11 of the HHS OIG Report linked above (http://www.modernhealthcare.com/assets/pdf/CH92135129.PDF):

[In 2006, ONC contracted with RTI International (RTI) to develop recommendations to enhance data protection; increase data validity, accuracy, and integrity; and strengthen fraud protection in EHR technology.]

... Hospitals' control over audit logs may be at odds with their RTI- recommended use as fraud safeguards:

RTI recommends that EHR users not be allowed to delete the contents of their audit log so that data are always available for fraud detection, yet nearly half of hospitals (44 percent) reported that they can delete their audit logs. Although these hospitals reported that they limit the ability to delete the audit log to certain EHR users, such as system administrators, one EHR vendor noted that any software programmer could delete the audit log.

RTI recommends that the ability to disable the audit log be limited to certain individuals, such as system administrators, and that EHR users, such as doctors and nurses, be prevented from editing the contents of the audit log because these actions can compromise the audit log's effectiveness. Hospitals reported they have the ability to disable (33 percent) and edit (11 percent) their audit logs, although they reported restricting those abilities to certain EHR users, such as system administrators or EHR vendors. All four EHR vendors we spoke with reported that the audit logs cannot be disabled in their products, but one vendor again noted that a programmer could disable the audit log.

I further note that, being voluntarily provided, i.e., not part of a formal investigation of any specific organization, those numbers are likely low, perhaps very low considering this issue.

An audit log or audit trail is an automatically-generated dataset, invisible to most users, containing items such as who viewed records, the date/time/location of viewing, and indication of actions they may have performed on the records such as editing/changes/additions/deletions, etc.

As an EHR itself is a collection of magnetized or optically encoded bits on some computer storage medium, it cannot be authenticated as complete and free from alteration by humans.

The audit trail is the only way to authenticate an EHR printout, however (as well as EHR screenshots or any other electronic data turned into a tangible form from those bits) as complete and free from alteration.

If an EHR printout cannot be authenticated as complete and free from alteration, its trustworthiness and perhaps even court admissibility as a business record under an exception to the hearsay rules regarding evidence may be damaged or invalidated.

My concern is that, if true, and considering the conflict of interest a hospital has regarding hiding potential fraud or malpractice that could cost them millions of dollars, a capability to "delete the contents of their internal audit logs whenever they'd like" and to edit audit trails (which based on the capabilities of relational databases also implies an ability to delete sections of audit logs selectively and/or to substitute false data) is simply alarming.

I don't think the EHR pioneers intended EHRs to be used for purposes of allowing evidence spoliation without traceability ...

-- SS

Dec. 13, 2013 Addendum:

I received the following reply from EHR compliance expert Dr. Reed D. Gelzer.  Re-posted with permission:

Good morning Dr Silverstein,

Thank you yet again for the illumination that you bring to matters of truth in Healthcare Information Technology.

Regarding the OIG report’s source document, the 2007 report to the ONC, I was the Fraud Prevention Workgroup Chair for that project, working under Principal Investigators Dr. Don Simborg and Susan Hanson, former Chair of AHIMA. 

For anyone who is interested in this subject matter, I would recommend that you go to the source document and, among other things, review the list of contributors.  These were all individuals who volunteered time to attempt to mitigate harms of defective HIT, in their capacities of records management systems, nearly 8 years ago now.   Many have gone on into leadership roles in related organizations and domains, some still working towards trustworthy health information technology systems.

I believe that I can say that none of those working on the report then would have believed that it was conceivable that even our most basic recommendations regarding the fitness of audit functions would remain "novel" in the industry in 2013.  One cannot be surprised at the low level of authenticity supports in hospitals’ EHRs systems given that fitness as record management systems for patient care has, to date, been either neglected or presumed, not tested or attested.   I am gratified that our 2007 work was utilized for the OIG report to illuminate the deplorable state of integrity supports in these patient care information systems.  This will undoubtedly spur interest in supportive resources such as the HL7 EHR System Functional Model Standard and the HL7 Records Management and Evidentiary Support Profile Standard.

All of us who worked on that ONC report are, I hope, as gratified as I am that the OIG removed our work product from its designated obscurity.   We developed the guidelines via methods that were more qualitative than quantitative, entirely intended to guide initial implementation backed by more methodical research.   We represented the most informed at that time, including those like myself and my ADIC associate Patricia Trites who had performed compliance testing on over 30 among the leading EHRs at the time and found extraordinary ranges of deficiencies, including audit functions that could be disabled at will.   Standards and tools existed then to support mitigation of risks and those Standards and tools have expanded since.  Now that the events and ONC decisions that led to inactions on the report are now in the past, we can more rapidly achieve the potentials nascent in HIT by rendering it more trustworthy, usable, and safe.

Thank you again for your ongoing vigilance.

Sincerely,

Reed D. Gelzer, MD, MPH, CHCC
Trustworthy EHR, LLC
Co-Facilitator, HL7 Records Management and Evidentiary Support Workgroup

To this I add that I also would not have found it conceivable that my concerns about bad health IT and the risks of patient harm it poses, as well as common healthcare IT project mismanagement, of which I started writing about in 1998 (http://cci.drexel.edu/faculty/ssilverstein/cases/) would remain "novel" ideas in the industry in 2013.

The Obamacare healthcare exchange website debacle has made the latter issue mainstream.  The former issues still need more sunlight.

-- SS

2/4/14 addendum:

HHS is apparently starting to pay attention to the importance of robust and secure EHR audit trails.

I note in the HHS document "Meaningful Use Stage 2, 2014 Edition EHR CERTIFICATION CRITERIA 45 CFR 170.314", page 7, regarding audit trails, available at this writing at http://www.healthit.gov/sites/default/files/meaningfulusetablesseries2_110112.pdf:

§170.314(d)(2) Auditable events and tamper-resistance.

(i) Record actions. EHR technology must be able to:
(A) Record actions related to electronic health information in accordance with the standard specified in § 170.210(e)(1);
(B) Record the audit log status (enabled or disabled) in accordance with the standard specified in § 170.210(e)(2) unless it cannot be disabled by any user; and
(C) Record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by EHR technology in accordance with the standard specified in § 170.210(e)(3) unless the EHR technology prevents electronic health information from being locally stored on end-user devices (see 170.314(d)(7) of this section).

(ii) Default setting. EHR technology must be set by default to perform the capabilities specified in paragraph (d)(2)(i)(A) of this section and, where applicable, paragraphs (d)(2)(i)(B) or (d)(2)(i)(C), or both paragraphs (d)(2)(i)(B) and (C).

(iii) When disabling the audit log is permitted. For each capability specified in paragraphs (d)(2)(i)(A), (B), and (C) of this section that EHR technology permits to be disabled, the ability to do so must be restricted to a limited set of identified users.

(iv) Audit log protection. Actions and statuses recorded in accordance with paragraph (d)(2)(i) must not be capable of being changed, overwritten, or deleted by the EHR technology.

(v) Detection. EHR technology must be able to detect whether the audit log has been altered. 

From a posting at http://healthcaresecprivacy.blogspot.com/2012/09/meaningful-use-stage-2-audit-logging.html:

... The Information that needs to be recorded: § 170.210(e)(1)(i):  These rules [in a column I did not show here - ed.] identify “sections 7.2 through 7.4, 7.6, and 7.7 of the standard specified”. This is simply the list of attributes that an audit log entry should contain that ASTM E2147 says are mandatory, and excludes the values it outlines as important but not mandatory. Below is about 90% of what is in section 7, I didn't want to copy all of it out of respect for the copyright. But, the part missing is just a one-line definition of each item, nothing more than that.
7. Audit Log Content
7.1 Audit log content is determined by regulatory initiatives, accreditation standards, and principles and organizational needs. Information is needed to adequately understand and oversee access to patient identifiable data in health information systems in order to perform security oversight tasks responsibly.
Logs must contain the following minimum data elements:
7.2 Date and Time of Event
7.3 Patient Identification
7.4 User Identification
7.5 Access Device (optional)
7.6 Type of Action (additions, deletions, changes, queries, print, copy)
7.7 Identification of the Patient Data that is Accessed(optional)
7.8 Source of Access (optional unless the log is combined from multiple systems or can be indisputably inferred)
7.9 Reason for Access (optional)
7.10 If capability exists, there should be recognition that both an electronic “copy” operation and a paper “print” operation are qualitatively different from other actions.

I am not sanguine about the "optional" components, especially 7.7 - the actual data that was accessed and acted upon.

I also note it is stunning that these audit trail 'rules' have only been promulgated recently.  It will be interesting to see how rigorous the EHR "certification" process will be regarding audit trails.

-- SS

Sunday, May 5, 2013

AMA says EHRs create 'appalling Catch-22' for docs - And just how many experts does it take to screw in a light bulb, anyway?

(NOTE:  this post, being about minor matters like death and financial mayhem, is particularly and unusually [even for me] biting and lacking in euphemisms and political correctness.  If you are easily offended and want the latter, and/or believe we all need to be 'nice' about banal issues like patient injury and death, fraud, and other minor matters, click here:  http://www.disney.com and skip the post below.)

You were warned.

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

At some point, so-called EHR "experts" and pundits need to stop being accommodated for their having ignored years of warnings, complaints, "anecdotes" -a particularly egregious term that comes from those who don't understand risk management, especially academics of the echo chamber-egghead subspecies (link) - and other signs that health IT is not a beneficent, omniscient gift from the Lords of Kobol. (The latter is a pun on the business-IT programming language Cobol, of course.)

Instead, they simply need to be ridiculed for being stupid.

I will do so:  folks, you have been, and remain, stupid:


The Bovine Stare of Incomprehension (click to enlarge)

The Bovine Stare of Incomprehension describes the reactions I've gotten over the years to many warnings about health IT.  It was like talking to a cow.

So now there's this:

AMA says EHRs create 'appalling Catch-22' for docs
May 03, 2013 | Tom Sullivan, Editor

As the healthcare industry moves to EHRs, the medical record has essentially been reduced to a tool for billing, compliance, and litigation that also has a sustained negative impact on doctors' productivity, according to Steven J. Stack, MD, chair of the American Medical Association’s board of trustees.

Gee, they're only realizing and complaining about that - now?  In 2013?

“Documenting a full clinical encounter in an EHR is pure torment,” Stack said during the CMS Listening Session: Billing and Coding with Electronic Health Records on Friday.

(What, the "pure torment" in such a mission-critical function only started with the most recent patches installed last month on the nation's EHRs?  EHRs were just dandy until then?)

It's nice to know in May 2013 that “documenting a full clinical encounter [essential to avoid injurious and even lethal mistakes, I anecdotally note - ed.] in an EHR is "pure torment”, several years into an accelerated "National Program for HIT in the HHS" costing hundreds of billions of dollars.

I guess sites like this blog, this site extant since 1998, and other materials written over the years by backwards stubborn health IT iconoclast fear-mongering Luddites were beyond the comprehension level of - those now proffering the exact same pronouncements.

EHRs are also driving the industry toward charts that look remarkably similar because they’re based on templates created by the technology vendors — that includes often using the same words. And that threatens to make doctors appear to be committing fraud by the practice of record cloning, or cutting and pasting from one record to another, when they are not, in fact, acting fraudulently

I guess putting patients in mortal danger from note cloning (and to those too stupid to understand why that is, get off your rear end and look it up, I'm not going to spoon-feed you) is a step better than acting fraudulently...

Alongside the federal mandate to implement an EHR under threat of a monetary fine, that creates what Stack called “an appalling Catch-22 for physicians.”

Put another way: The government mandates that doctors use an EHR, the EHR vendors’ templates can sometimes create an appearance of fraud and that, in turn, opens the door for payers to decline reimbursement or, even worse, the government to prosecute doctors for the crime.

I guess actual fraud is just anecdotal.

As dire as that sounds, it's an exception that belies the unproven perception that EHRs perpetuate fraud. “Upcoding does not necessarily equate to fraud and abuse,” said Sue Bowman, AHIMA’s senior director of coding and compliance at the same event. “This is an area where more study is needed. We really need to know the causes. Further research is needed on the fraud risk of using EHRs.”

Sure, let's study while rolling this stuff out as frantically as we can.  We'll fix it later -- and Jesus, I guess, will heal and reanimate any patients actually harmed by the technology (link to ECRI Institute Deep Dive Study: 36 hospitals!  Nine weeks!  171 health information technology-related problems voluntarily reported!  Eight injuries!  Three possible deaths!  All mere "anecdotes", of course).

Indeed, Jacob Reider, MD, CMO of ONC, explained that the government and industry do not have good data right now proving whether or not EHRs trigger fraud and abuse.

Per the IOM, the same industry does not have good data on harms levels.  (The previous link to a recent small ECRI "Deep Dive" study's probably the most robust we've got on that score, and the figures are not encouraging).

So - let's review -
  • poor data on harms, 
  • poor data on benefits, 
  • poor data on fraud and abuse.

 The logical, ethical course of action thus is:

D'OH!  LET'S ROLL THE TECHNOLOGY OUT AS FAST AS WE CAN, AND PENALIZE NON-ADOPTERS BESIDES!



See how simple logic, ethics and clear thinking can be?

“There is concern that some doctors are using the EHR to obtain payments to which they are not entitled,” said Mickey McGlynn of Siemens Medical Solutions and HIMSS EHR Association. “Any fraud is an important issue and we, as the vendor community, take that very seriously.”

Only after independent whistleblower investigations by Fred Schulte of the Center for Public Integrity ("Cracking the Codes"), and by New York Times reporters Reed Abelson and Julie Creswell, that is...

AMA’s Stack offered a triptych of suggestions to CMS and ONC: address EHR usability concerns, provide guidance on EHR use for coding and billing, and make meaningful use stage 2 more flexible for providers.

“My purpose is not to denigrate EHRs,” Stack said, explaining that he believes CMS and ONC are genuinely trying to better the current situation.

Nice to have Caspar Milquetoast  on the side of EHR criticism.

Knock knock, anyone home, McFly?


Knock knock, anyone home, McFly?


Today's EHR systems, for the aforementioned reasons above and more, deserve denigration for patients' sake.

There are efforts underway, within the government and industry, to more comprehensively understand the unintended consequences of EHR implementation.

But let's keep rollin' em out, anyway.  Wheeee!  What fun!

Class action attorneys, are you listening?

-- SS