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:
(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).
(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
0 nhận xét:
Đăng nhận xét