Meaningless Auditing of Meaningful Use

OK, back in the office today. Jammed up with meetings. One topic that surfaced in the REC staff meeting had to do with one of our early MU Attestors. He got the "Figliozzi Letter" (CMS Meaningful Use desk audit). Notwithstanding that he's one of our REC Golden Boys, a highly esteemed and scrupulous physician in our service area, he's getting jerked around over a couple of minor issues, one of which is utterly absurd.

MU Menu Set Measure 1

He is thus far unable to document to their satisfaction that his Rx formulary functionality has been turned on for "the entire EHR reporting period." Apparently his certified product's audit log doesn't capture that information. Like many, it likely comes "out of the box" with the functionality activated.

Upon a little digging, my pushback email reaction among staff:

It seems that certified EHR systems audit log requirements under the requisite NIST testing specs do not mandate that there be Attestation period logging of administrative functions such as enabling various functionalities -- which is not to say that the lack of it is a good thing. Do we have any idea as to the extent to which various Cert’ed EHRs log admin activity, data that are not specifically protected “electronic health information”? Turning on/off this or that software functionality identifies no patient.

healthcare.nist.gov/docs/170.302.r_AuditLog_v1.1.pdf

www.hipaasurvivalguide.com/hit-subchapter-d/hit-170-210.php

§170.210 Standards for health information technology to protect electronic health information created, maintained, and exchanged. The Secretary adopts the following standards to protect electronic health information created, maintained, and exchanged:

(a) Encryption and decryption of electronic health information.

(1) General. A symmetric 128 bit fixed-block cipher algorithm capable of using a 128, 192, or 256 bit encryption key must be used.

(2) Exchange. An encrypted and integrity protected link must be implemented.

(b) Record actions related to electronic health information. The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, deleted, or printed; and an indication of which action(s) occurred must also be recorded.

(c) Verification that electronic health information has not been altered in transit. Standard. A secure hashing algorithm must be used to verify that electronic health information has not been altered in transit. The secure hash algorithm (SHA) used must be SHA-1 or higher.

(d) Cross-enterprise authentication. A cross-enterprise secure transaction that contains sufficient identity information such that the receiver can make access control decisions and produce detailed and accurate security audit trails must be used.

(e) Record treatment, payment, and health care operations disclosures. The date, time, patient identification, user identification, and a description of the disclosure must be recorded for disclosures for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501.

Drug Formulary Cert Std: healthcare.nist.gov/docs/170.302.b_DrugFormularyChecks_v1.1.pdf 

• Neither the words “audit” nor the discrete word “ log “ are found therein.

Access Control Cert Std: healthcare.nist.gov/docs/170.302.o_AccessControl_v1.1.pdf  

• Neither the words “audit” nor the discrete word “ log “ are found therein.

45 CFR 164.312 (“Technical Safeguards”) 

(b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

(c) (1) Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

(2) Implementation specification: Mechanism to authenticate electronic protected health information (Addressable). Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.

(d) Standard: Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.

___

Q: Is the act of “enable drug formulary” tantamount to the “creation of electronic health information” within the intent and explicit scope of Meaningful Use?

btw, under TEST DATA (Audit log Cert px, pg 6)

“Vendor-supplied test data shall strictly focus on meeting the basic capabilities required of an EHR relative to the certification criterion rather than exercising the full breadth/depth of capability that an installed EHR might be expected to support”

Bobby

I'm all for documentation (including comprehensive audit logs, which I continue to view as "workflow" records) and rational accountability via auditing (which might have served a salutory purpose on Wall Street just a few years back), I but find this just stupid. I'd like to know exactly what are the MU auditing chops of these Figliozzi people (themselves comprising a HHS contractor) to show and start breaking legs over stuff like this.

LATE AFTERNOON UPDATE: Now they say they'll accept a letter from the Certified EHR vendor attesting on behalf of the EP that the Rx Formulary was enabled.

Yeah. Right. Backstroke, anyone?

WHILE WE'RE ON THE TOPIC OF EHR AUDIT LOGS

I'd like to have them [1] include all usage, inclusive of administrative functions, and [2] be a bit more granular with respect the DATETIME() field. SQL can now trace down to the microsecond.

The MySQL page continues:

MySQL 5.6.4 and up expands fractional seconds support for TIME, DATETIME, and TIMESTAMP values, with up to microseconds (6 digits) precision:

To define a column that includes a fractional seconds part, use the syntax type_name(fsp), where type_name is TIME, DATETIME, or TIMESTAMP, and fsp is the fractional seconds precision. For example:

CREATE TABLE t1 (t TIME(3), dt DATETIME(6));
The fsp value, if given, must be in the range 0 to 6. A value of 0 signifies that there is no fractional part. If omitted, the default precision is 0. (This differs from the standard SQL default of 6, for compatibility with previous MySQL versions.)

Functions that take temporal arguments accept values with fractional seconds. Return values from temporal functions include fractional seconds as appropriate.

Syntax for temporal literals produces temporal values: DATE 'str', TIME 'str', and TIMESTAMP 'str', and the ODBC-syntax equivalents. The resulting value includes a trailing fractional seconds part if specified. Previously, the temporal type keyword was ignored and these constructs produced the string value. See Standard SQL and ODBC Date and Time Literals

In some cases, previously accepted syntax may produce different results. The following items indicate where existing code may need to be changed to avoid problems:

Some expressions produce results that differ from previous results. Examples: The timestamp system variable returns a value that includes a microseconds fractional part rather than an integer. Functions that return a result that includes the current time (such as CURTIME(), SYSDATE(), or UTC_TIMESTAMP()) interpret an argument as an fsp value and the return value includes a fractional seconds part of that many digits. Previously, these functions permitted an argument but ignored it.

TIME values are converted to DATETIME by adding the time to the current date. (This means that the date part of the result differs from the current date if the time value is outside the range from '00:00:00' to '23:59:59'.) Previously, conversion of TIME values to DATETIME was unreliable. See Section 11.3.7, “Conversion Between Date and Time Types”.

TIMESTAMP(N) was permitted in old MySQL versions, but N was a display width rather than fractional seconds precision. Support for this behavior was removed in MySQL 5.5.3, so applications that are reasonably up to date should not be subject to this issue. Otherwise, code must be rewritten.

Capturing EHR audit log data down to even a 10th of a second (and, I would recommend going 2 decimals deep) would indeed require re-writes in code and restructuring of the log tables to add the fractions.

And, what about the SQL NOW() function? Probably gonna get significant EHR developer pushback on these ideas.

Nonethless, if you (correctly, IMO) view audit logs as essentially system workflow records (albeit absent physical task tracking, to be sure), then sufficient granularity is important.
___

More to come...